------- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-14
23:12 -------
Subject: Re: [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed
> ------- Comment #48 from steven at gcc dot gnu dot org 2006-01-14 21:10
> -------
> I certainly don't see any way how this new issue has anything to do with the
> ICE due to Mustafa's patch.
Well, I doubt that you would ever see the ICE if reload hadn't used
r3 for two variables at the same time. If you think this issue that
I've pointed out is a bug, I can file a new PR.
> There's an easy check: is the code semantically equivalent to some other
> compiler you trust (e.g. older gcc, hp system compiler, anything)...
This what you get with HP cc at +O2:
-bash-2.05b$ cc -Ae +O2 -S pr24626.c
cc: line 19: warning 5004: Uninitialized variable "node" in function "F2"
(5004)
The assembly code is shown below. The interesting part is that
node is initialized to 0 in the calls to after_node_func and T.
At +O3, HP cc doesn't generate the warning but it still generates
code that uses a consistent uninitialized value for node.
Although an uninitialized object may invoke undefined behavior,
I couldn't find anywhere in the C standard that suggests it's
legitimate to use the same storage for two objects in the same
block. The HP code isn't equivalent to the GCC code as it uses
different storage for call_result and node. Thus, the call to
T probably will invoke different behavior.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
.LEVEL 2.0N
.SPACE $TEXT$,SORT=8
.SUBSPA $CODE$,QUAD=0,ALIGN=4,ACCESS=0x2c,CODE_ONLY,SORT=24
F2
.PROC
.CALLINFO CALLER,FRAME=16,SAVE_RP,ARGS_SAVED,ORDERING_AWARE
.ENTRY
STW %r2,-20(%r30) ;offset 0x0
LDO 64(%r30),%r30 ;offset 0x4
COPY %r0,%r26 ;offset 0x8
COPY %r24,%r22 ;offset 0xc
.CALL ARGW0=GR,RTNVAL=GR ;in=22,26;out=28;
B,L $$dyncall,%r31 ;offset 0x10
COPY %r31,%r2 ;offset 0x14
CMPB,<> %r28,%r0,$00000002 ;offset 0x18
COPY %r28,%r31 ;offset 0x1c
$00000001
.CALL ARGW0=GR,RTNVAL=GR ;in=26;out=28;
B,L T,%r2 ;offset 0x20
COPY %r0,%r26 ;offset 0x24
MOVB,TR %r0,%r31,$D0 ;offset 0x28
LDW -84(%r30),%r2 ;offset 0x2c
$00000002
STW %r31,-64(%r30) ;offset 0x30
.CALL ARGW0=GR,RTNVAL=GR ;in=26;out=28;
B,L T,%r2 ;offset 0x34
COPY %r0,%r26 ;offset 0x38
LDW -64(%r30),%r31 ;offset 0x3c
$00000003
$L0
LDW -84(%r30),%r2 ;offset 0x40
$D0
COPY %r31,%r28 ;offset 0x44
BVE (%r2) ;offset 0x48
.EXIT
LDO -64(%r30),%r30 ;offset 0x4c
.PROCEND ;in=24,25,26;out=28;
.SPACE $TEXT$
.SUBSPA $CODE$,QUAD=0,ALIGN=4,ACCESS=0x2c,CODE_ONLY,SORT=24
F1
.PROC
.CALLINFO CALLER,FRAME=16,SAVE_RP,ARGS_SAVED,ORDERING_AWARE
.ENTRY
STW %r2,-20(%r30) ;offset 0x50
LDO 64(%r30),%r30 ;offset 0x54
.CALL ARGW0=GR,RTNVAL=GR ;in=26;out=28;
B,L F3,%r2 ;offset 0x58
STW %r26,-64(%r30) ;offset 0x5c
LDW -64(%r30),%r26 ;offset 0x60
COPY %r0,%r24 ;offset 0x64
.CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,RTNVAL=GR ;in=24,25,26;out=28;
B,L F2,%r2 ;offset 0x68
COPY %r28,%r25 ;offset 0x6c
LDW -84(%r30),%r2 ;offset 0x70
BVE (%r2) ;offset 0x74
.EXIT
LDO -64(%r30),%r30 ;offset 0x78
.PROCEND ;in=26;out=28;
.SPACE $TEXT$
.SUBSPA $CODE$
.SUBSPA $CODE$
.SPACE $PRIVATE$,SORT=16
.IMPORT $$dyncall,MILLICODE
.IMPORT T,CODE
.SPACE $TEXT$
.SUBSPA $CODE$
.EXPORT F1,ENTRY,PRIV_LEV=3,ARGW0=GR,RTNVAL=GR,LONG_RETURN
.IMPORT F3,CODE
.END
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
