Reducing this stuff from ~34500 line to roughly 400 was quite a nightmare.
Alas, I'm stuck now: If I try to further simplify the code (e.g. by removing
unused template parameters) the bug vanishes.
I'm afraid somebody has to debug this stuff to find the bug in gcc.
The good news is, the bug doesn't seem to show up in mainline or releases
before gcc 3.3.
Regards,
Volker

Created attachment 4342[details]
Now at 314 lines
Now at 314 lines. I start to think that this bug is essentially unrelated to
-frename-registers, since random changes either make the segfault go
away when compiled with -frename-registers, or let a segfault appear when
compiled
_without_!
Will try further.
W.

If it was Eric's patch, then this is a binutils bug because the asm looks the same between the two
versions (except for use of different registers), note this is still present in the latest cvs version of
binutils:
GNU assembler version 2.14.90 (i686-pc-linux-gnu) using BFD version 2.14.90 20030703.

Created attachment 4344[details]
Now 122 lines
OK, it's now 122 lines and I gotta go. Should now be a little simpler to
actually
figure out a) what the program is supposed to do, and b) why it's crashing.
W.

If bug 11320 is indeed a reload bug, no.
The problem pertains to aliasing here: the slot assigned to the temporary
matrix<>::iterator1(bam1.m)
is reused for
adaptor<>::a_iterator1 it2
because the types conflict according to objects_must_conflict_p. The reasoning
is probably that, since the types conflicts, operations on objects of these
types cannot be reordered by the scheduling passes later.
The problem is that at least one member of the first type (dead1) doesn't
conflict with at least one member of the second type (a), so the scheduling pass
swaps insn 27 and insn 83.