------- 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