I think I'm nearing the end of stage0, LOL! (10x slower in this qemu VM)
Should I attempt to test if the next stage compiler is actually up to the modified spec or do I have to wait until the very end?
And besides, if I'm successful, is the produced rustc going to be completely useless for building any future versions? That would make me a sad, saad panda 
The way I see it, the stage0 binary you were told to use is a static one so definitely it's going to generate sse2 rust libs and sse2 rustc with the new spec however. In the next stage it should probably generate a set of libs plus rustc itself according to the new spec - btw what modifications did you make?
All right, here's a puzzle.
I modified the built-in i686 spec and changed the pentium4 to pentium2 according to the original suggestion from gkoz.
Stage0 was completed successfully, but stage1 kept failing at some point (libsyntax I think it was) with a, you'll never guess, SIGILL!
Repeating the stage in gdb has allowed it to proceed further so it's either a heisenbug or a problem with qemu host (I'm using a debian wheezy image with local llvm 3.5).
As if on cue, this pops up!
I think I've finally arrived at a point where our mythical rust developer should probably have a look:
rustc: i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/librustc_trans
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/user/rustc.bin...(no debugging symbols found)...done.
Starting program: /home/user/rustc.bin --cfg stage1 -O --cfg rtopt -C prefer-dynamic --target=i686-unknown-linux-gnu -D warnings -L i686-unknown-linux-gnu/rt -L /usr/lib/llvm-3.5/lib --out-dir i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib -C extra-filename=-d8ace771 src/librustc_trans/lib.rs
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0x44bffb40 (LWP 2339)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x44bffb40 (LWP 2339)]
0x42c818b2 in llvm::APFloat::bitwiseIsEqual(llvm::APFloat const&) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
(gdb) bt
#0 0x42c818b2 in llvm::APFloat::bitwiseIsEqual(llvm::APFloat const&) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#1 0x42b01cd3 in bool llvm::DenseMapBase<llvm::DenseMap<llvm::DenseMapAPFloatKeyInfo::KeyTy, llvm::ConstantFP*, llvm::DenseMapAPFloatKeyInfo>, llvm::DenseMapAPFloatKeyInfo::KeyTy, llvm::ConstantFP*, llvm::DenseMapAPFloatKeyInfo>::LookupBucketFor<llvm::DenseMapAPFloatKeyInfo::KeyTy>(llvm::DenseMapAPFloatKeyInfo::KeyTy const&, std::pair<llvm::DenseMapAPFloatKeyInfo::KeyTy, llvm::ConstantFP*> const*&) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#2 0x42b02128 in llvm::ConstantFP::get(llvm::LLVMContext&, llvm::APFloat const&) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#3 0x42b0c333 in llvm::Constant::getNullValue(llvm::Type*) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#4 0x42b0c417 in llvm::ConstantAggregateZero::getStructElement(unsigned int) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#5 0x42b0c4bf in llvm::ConstantAggregateZero::getElementValue(unsigned int) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#6 0x42b0c91f in llvm::Constant::getAggregateElement(unsigned int) const ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#7 0x42981e1b in llvm::ConstantFoldLoadFromConstPtr(llvm::Constant*, llvm::DataLayout const*) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#8 0x42987484 in llvm::ConstantFoldInstruction(llvm::Instruction*, llvm::DataLayout const*, llvm::TargetLibraryInfo const*) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#9 0x429b1291 in llvm::SimplifyInstruction(llvm::Instruction*, llvm::DataLayout const*, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#10 0x427363a7 in (anonymous namespace)::EarlyCSE::runOnFunction(llvm::Function&) [clone .part.229] ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#11 0x42bcdd92 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#12 0x42bcde4f in llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#13 0x42bcdf2f in llvm::legacy::FunctionPassManager::run(llvm::Function&) ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_llvm-d8ace771.so
#14 0x41d796af in LLVMRustRunFunctionPassManager (PM=0x5b76f850, M=0x44c02de0)
at /home/user/rustc-1.2.0/src/rustllvm/PassWrapper.cpp:205
#15 0x409f92c9 in back::write::execute_work_item::h1cf904f8958d5ba6hid ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_trans-d8ace771.so
#16 0x409f5358 in back::write::run_passes::ha981b3a3c2430a1a3Xc ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_trans-d8ace771.so
#17 0x400561e9 in driver::phase_5_run_llvm_passes::ha2768cc6772c712cJPa ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#18 0x40035105 in driver::compile_input::hfb939c39028d35f7Tba ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#19 0x4010c35a in run_compiler::h2cb353316910fce3h6b ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#20 0x40109d42 in boxed::F.FnBox$LT$A$GT$::call_box::h17478496365684867531 ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#21 0x40109612 in rt::unwind::try::try_fn::h2533614896584927268 ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#22 0x40296f2b in rust_try_inner ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/libstd-d8ace771.so
#23 0x40296f04 in rust_try ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/libstd-d8ace771.so
#24 0x401f850d in rt::unwind::try::inner_try::h907993daac7f91f03yw ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/libstd-d8ace771.so
#25 0x4010982a in boxed::F.FnBox$LT$A$GT$::call_box::h15266350114794237384 ()
from /home/user/rustc-1.2.0/i686-unknown-linux-gnu/stage1/lib/librustc_driver-d8ace771.so
#26 0x4020a0a1 in sys::thread::Thread::new::thread_start::h3feffa1e52194ed50Iv ()
#27 0x437a0d97 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#28 0x405fbdfe in clone () from /lib/i386-linux-gnu/libc.so.6
disass 0x42c818b2,+10
Dump of assembler code from 0x42c818b2 to 0x42c818bc:
=> 0x42c818b2 <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+34>: mov (%edi),%eax
0x42c818b4 <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+36>: cmp %eax,(%esi)
0x42c818b6 <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+38>: je 0x42c818c8 <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+56>
0x42c818b8 <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+40>: add $0x1c,%esp
0x42c818bb <_ZNK4llvm7APFloat14bitwiseIsEqualERKS0_+43>: xor %eax,%eax
End of assembler dump.
It's repeatable so probably not down to the VM and also llvm data layout appears in there!
Please help as soon as you've finished Windows XP support - it might come in handy 
Thanks
I've noticed you posted on the subject of local llvm in rust.internals - configure doesn't complain about llvm 3.5, is it a bug?
Nobody cares about this arch but the answer to this question could document the build process better which is why I asked about it on github.
Right now I've borrowed an old pentium4 box that has a debian squeeze partition and I'm going to try a native build of 1.3 using llvm 3.5.
I don't have time for any silly trial and error stuff (that you seem to be enjoying) so don't ask me for anything more.
EDIT:
You may proceed, llvm's not the problem.
No, it's definitely not going to work out of the box.
After trying again with 1.3 source, this time disabling jemalloc and using explicit CFLAGS (pentium2) so as to avoid any possible mixing and matching of gcc code I still got the very same crash (segfault in gdb, SIGILL in linux) at librustc_trans stage.
I guess llvm must have been the problem all along and even though in retrospect it feels like a fool's errand I was still able to learn a few things.
Interesting stuff!
If you care about it so much why don't you try building the bundled LLVM with your flags first? You might learn even more 
Bingo man! You didn't think I was idle all this time, did you?
I got fed up with qemu and the mega slow romantic way so I switched to a 32-bit Porteus (Slackware to the rescue!) on a 64-bit laptop and voila, no processor left behind!
With CFLAGS (for jemalloc), CXXFLAGS (for llvm) and the modified llvm target pointing to the same processor architecture (pentium2) it all went smoothly in a few hours.
I was then able to build cargo with my generic i686 rustc-1.3.0 and test the whole setup on sokoban-rs which also built and ran without a problem on the target machine. Yipee!
Here's the fruit of my labours:
[quote="PeteVine, post:33, topic:2787"]
CFLAGS (for jemalloc), CXXFLAGS (for llvm) and the modified llvm target
[/quote]This isn't very informative because you're still not saying what exactly you did -- which diffs applied, which commands run.
So we can expect a blog post detailing your findings, yes? 
I might have come across not too clearly how trivial it was in the end!
After changing the one line in i686_unknown_linux_gnu.rs to pentium2 (from pentium4),
exporting CFLAGS=-march=pentium2 CXXFLAGS=-march=pentium2
and running the rust configure script with no fancy options (no local llvm!) is all it took. I have no idea if it'd be possible to go all the way down to i486 with no real patching.
EDIT:
(probably yes)
The problem I had initially encountered probably arose either because of the precompiled version of llvm 3.5 or the gcc version 4.7 present in the debian image and/or some mixing of different architecture code.
Only the necessity of emulation and its slowness using a premade image dictated these initial choices. In the end I used a windows laptop running linux from a USB stick. (and gcc 4.8)
No blog posts necessary 
Thanks for sharing!
[quote="PeteVine, post:36, topic:2787"]
After changing the one line in i686_unknown_linux_gnu.rs to pentium2 (from pentium4),exporting CFLAGS=-march=pentium2 CXXFLAGS=-march=pentium2
[/quote]I suspect you can avoid setting CFLAGS by changing "i686" to "i586" in llvm_target in i686_unknown_linux_gnu.rs
As long as it takes care of both C(CXX)FLAGS I'd be all for creating a separate target and having both capabilities in a single rust compiler.
That should be possible right? (I mean being able to run on i5(6)86 but still generating P4 code by default with an option to generate and link against the other target or vice versa). Probably two sets of rust libs would be needed so not very attractive.
(This could apply to Windows XP support, Linux users are fine as it is)
EDIT:
Some projects can only be built with an unstable nightly, here's one from 20151002:
https://www.dropbox.com/s/7zl2whf1t9mbhh1/rust-1.5.0-i686_generic_linux.tar.bz2?dl=0
I've built for myself an unofficial stage0 equivalent rustc (commit 1af31d4) that can be run on any Pentium Pro class processor:
To build rustc natively on any i686 non-SSE2 linux system it's first necessary to pass:
--enable-local-rust --local-rust-root=$PATH_TO_stage0-i686
to the configure script, where PATH_TO_stage0-i686 should be pointing to the unpacked archive's top-level directory.
Naturally, the described modifications still apply. The snapshot should work until about 2015-12-20 nightly, afterwards a new snapshot is required (commit 3391630)
EDIT:
As my final upload I present the first-ever natively produced unofficial build (took about
2.5h on a 2.2 GHz Athlon) of nightly rustc 1.6 from 2015-12-03.
(plus cargo and cargo-bake):
EDIT2:
It turns out the surprising phenomenon of getting a SIGILL described earlier in the thread was not such a big mystery after all.