This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/14715] [3.3-hammer] internal compiler bug in gcc 3.3.3_pre20040215 triggered by mozilla-1.6r1 source
- From: "amodra at bigpond dot net dot au" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Apr 2004 07:52:43 -0000
- Subject: [Bug target/14715] [3.3-hammer] internal compiler bug in gcc 3.3.3_pre20040215 triggered by mozilla-1.6r1 source
- References: <20040324121224.14715.eger@theboonies.us>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From amodra at bigpond dot net dot au 2004-04-15 07:52 -------
>From my preliminary analysis, I would guess that this bug affects 3.4 and 3.5
too, and it's just a matter of finding the right testcase.
With hammer branch, the underlying problem is that a stack temp is allocated to
the same location as a gpr save slot. Flow analysis notices that the gpr save
is overwritten, so decides that the gpr save is dead and should be deleted.
This leads to the ICE.
Stack vars and temps are allocated at STARTING_FRAME_OFFSET, which rs6000.h
defines as:
#define STARTING_FRAME_OFFSET \
(RS6000_ALIGN (current_function_outgoing_args_size, \
TARGET_ALTIVEC ? 16 : 8) \
+ RS6000_VARARGS_AREA \
+ RS6000_SAVE_AREA)
The first term of this expression accounts for parameter save area, but
rs6000.c:rs6000_stack_info uses
info_ptr->parm_size = RS6000_ALIGN (current_function_outgoing_args_size,
8);
It is the difference in alignment that results in stack layout errors. Note
that this error may be masked by alignment of other elements of the stack.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at redhat dot com
Known to work|3.5.0 3.3.4 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14715