| Age | Commit message (Collapse) | Author |
|---|
|
after switching to __guard_local. OK matthew@, miod@.
|
|
if reload_completed; INITIAL_ELIMINATION_OFFSET() invokes it (which is very
likely a source for more bugs, to be investigated)
|
|
The array_size was uninitialized and used to work by accident.
Spotted with SSP on MIPS.
OK miod@. Tested by jasper@.
|
|
the following manner:
([reg:A & -8] << (64 - (((reg:FP+reg:B) & 0x7) << 3))) >> 56
This fails when we're doing loads with the offset from the frame
pointer %8. Since it's aligned, optimizer makes it a zero. The
correct expression is:
([reg:A & -8] << (56 - (((reg:FP+reg:B-1) & 0x7) << 3))) >> 56
This is actually a 13-year-old bug. Checked by Miod; a few files
in the kernel were affected. Spotted with SSP for Alpha.
OK miod@. Tested by naddy@.
|
|
|
|
|
|
one, gas, to correctly output pc-relative jumps.
|
|
considerations.
|
|
been done.
|
|
it reports the dest and source parts of the set insn are identical, we need
to check whether they are volatile memory references, and return 0 (not a
noop) in that case.
This allows `*volatile_ptr = *volatile_ptr;' constructs to no longer be
incorrectly optimized away on platforms which can perform memory to memory
transfers in a single instruction (i.e. m68k and vax).
Found the hard way on vax, where some systems need to frob the interrupt
stack early, before being able to handle faults, and a gcc3-built kernel
would have this operation optimized away, leading to a quick system reset.
|
|
|
|
|
|
protector code will conflict with the way variadic functions spill the
registers on the stack, causing the latter to be partially overwritten with
the value of __guard. Core dumps and hilarity ensues. This can probably be
fixed by changing the time registers are spilled from the backend for
__builtin_expand_saveregs(), to setup_incoming_varargs(), as done on e.g.
rs6000. But that's far from a trivial change, and I'd like to be able to
exercize gcc 3 a bit more on m88k before sacrificing more brain cells to
the gcc evil deities.
|
|
No functional change.
|
|
per-platform basis.
|
|
CPP_PREDEFINES; try to deuglify CPP_SPEC whenever possible as well.
|
|
them to all platforms). Both of them had been added very late in a release
cycle, which caused us to prefer workarounds with minimal side effects.
Since the issue they are avoiding may happen on other platforms, there is no
harm in making sure no other platform gets bitten by them. And at the moment
no supported platform runs gcc 3, so this does not cause any regression.
|
|
flavour. From etoh@'s gcc 3.4 tree. While there, also kill
change_arg_use_of_insns_2() which is now a dim wrapper around
change_arg_use_of_insns(), from etoh@'s tree as well.
|
|
predecrement cases with gcc 2.95. This had been needed for m68k but somehow
etoh@ missed this when porting the gcc 2.95 fixes back to its 3.3, then 3.4
tree.
This fixes passing of struct by value on m68k, and lets gcc 3 reliably
bootstrap itself now.
|
|
va_arg(). __vfprintf() still unhappy in some edge cases I am investigating.
|
|
variadic arguments passed in registers: these functions may pass a va_list to
another function, which will then need to rely upon a properly filled
__va_list struct and can't assume anything about the way arguments have been
passed to its caller.
|
|
spill the registers on __va_reg instead of calling move_block_from_reg().
|
|
of memory which will be used for the __va_reg register spill.
|
|
varagrs implementation being utterly wrong.
This is the same logic as the one I wrote for gcc 2.95, with a few more
optimizations whenever possible (such as not outputting instructions to fill
fields of the __va_list struct we know won't be accessed, now that we have
total control of the struct in the compiler).
It should now be possible to mix varags code compiled by gcc 2.95, with code
compiled with gcc 3, with the following exception: as I have finally found and
fixed the buglet causing all arguments to be passed on the stack if any of the
named arguments (before varargs) is a struct of 32 bytes or more passed by
value, such a (pretty uncommon) case will not be interoperable. One such case
can be found as va-arg-4.c in gcc's testsuite.
With these changes, all the following varargs exercizers from gcc's testsuite
now pass when compiled with the in-tree gcc 3:
gcc.c-torture/execute/920625-1.c
gcc.c-torture/execute/931004-10.c
gcc.c-torture/execute/931004-12.c
gcc.c-torture/execute/931004-14.c
gcc.c-torture/execute/931004-4.c
gcc.c-torture/execute/931004-6.c
gcc.c-torture/execute/931004-8.c
gcc.c-torture/execute/strct-varg-2.c
gcc.c-torture/execute/va-arg-1.c
gcc.c-torture/execute/va-arg-2.c
gcc.c-torture/execute/va-arg-4.c
gcc.c-torture/execute/va-arg-5.c
gcc.c-torture/execute/va-arg-6.c
as well as the few others of my own I had been using while working on gcc 2.95
more than 8 years ago.
|
|
if null_prologue(), i.e. if there is no stack frame to undo and no r1 to
restore.
Make the "epilogue" insn construct no longer depend on "return", but rather
on "(use (const_int 0))" as "prologue" and as generally done on other backends.
On the other hand, make it unconditionnal, instead of "! null_prologue()".
These changes make sure than a leaf procedure call does not end up "returning"
(i.e. jmp r1) upon return from the call, without restoring r1 and r30 (whenever
applicable) from the existing stack frame.
This makes a gcc3-compiled __main() (from libgcc2.c) no longer spin after
invoking the constructors, and gives the real payload (i.e. main() and whatever
follows from there) a chance to run.
|
|
string if not defined already, when cross-compiling. (curse words censored)
|
|
clobbered (e.g. in leaf functions). While saving it helps debugging, reading
it back is just useless in that case.
|
|
as recommended by the documentation. I have not seen a difference in the
generated code so far, but I'd rather play safe at the moment.
|
|
reloading the return address register from the stack in the epilogue isn't
a useless operation anymore.
|
|
other problems by making the optimizer more eager to optimize out the whole
prologue and epilogue away in some cases.
|
|
and try to get the builtin varargs code to work. I have tried to mimic the
gcc2 varargs logic, which is optimal in the sense that no argument gets
duplicated and as many arguments as possible are passed in registers, to no
avail (read: hair-pulling ICE out of nowhere in variadic functions). So I am
now sticking to the original gcc 2.7 varargs, where an argument passed on the
stack consumes the registers it would have been passed as, if its type would
have allowed it. This spills too much memory on the stack, but on the other
hand makes the expansion of va_arg() much simpler.
This means that, should gcc3 on m88k platforms be solid enough, mixing varargs
objects compiled with gcc 2 and gcc 3 will not be possible. But we're not there
yet.
|
|
|
|
(the a.out assembler doesn't enforce alignment for "half" and "word" data).
Needed because gcc 3 will produce such statements.
|
|
and after the keyword.
|
|
expression attributes to the conditional C statement chunk, for this is the
only way to have them honored with gcc 3 (thanks for genrecog to warn about
this).
Note that most of the affected operands were ``register_operand'', hence the
"r" constraint is implied. There are a few `register + ccmode' constructs which
could have caused wrong code generation before this change, though.
|
|
``insn deleted'' notes. This prevents the optimizer from chewing too far.
|
|
units.
|
|
frame setup and varargs handling, which need some more work at the moment.
|
|
.type, .size, .set and .globl stanzas, similar to openbsd.h r1.9 in gcc 2.95
|
|
This allows mozilla trunk to finally link again on ppc (with --relax),
otherwise it fails badly with relocations overflow.
From http://sourceware.org/ml/binutils/2005-01/msg00115.html
ok kettenis@, no objection miod@
|
|
|
|
does not implement stack-protector, and when it does, the workaround might not
be necessary after all.
|
|
|
|
of GCC do.
ok millert@, guenther@, pascal@, deraadt@
|
|
that controls the behaviour of Intel's Supervisor Mode Access Prevention
(SMAP) feature.
'looks correct' miod@ ok deraadt@
|
|
|
|
wrapping them with an implicit extern "C" since that breaks the webkit port.
Help from matthew@ and landry@.
ok landry@
|
|
maybe not the simplest fix, but I'd rather it gets fixed now, while we
discuss details :)
|
|
references into a STANDARDS section;
|
|
performance hit on some architectures (almost 20% on hppa, more than 25% on
sparc64). And there are no real benefits associated with ASLR for a compiler.
ok deraadt@
|
