GCC Bugzilla Bug 29841

The following example (reduced from openssl) causes GCC 4.2 to ICE when -O2 is
used it works ok with -O1. It does not ICE with GCC 4.1 as well with 3.4.6

gcc -c -O2 xxx.c

xxx.c: In function 'foo':
xxx.c:8: warning: function called through a non-compatible type
xxx.c:8: note: if this code is reached, the program will abort
xxx.c:9: internal compiler error: Segmentation fault


xxx.c
============================
typedef void (*fp)(void);
extern char* bar(void* a1, int a2);
extern char* mar(int n);
char* cptr;
void foo()
{
  cptr = mar(6);
  ((char *(*)(void *,int (*)(void *,unsigned char **),char
**))((fp)bar))(0,0,(void*)(0));
}

This works just fine in 4.2.0 20061112 plus valgrind says nothing.

Yeah it worked fine when configured  --target=i686-*-linux-gnu but not with 
--target=i586-*-linux-gnu --with-cpu=i586 

Note the code as given is undefined anyways so it will abort at runtime.
Here is a reduced testcase:
void mar(int n);
void foo()
{
  mar(6);
  __builtin_trap ();
}

The ICEs I get:
With 4.2.0:
t.c: In function ‘foo’:
t.c:6: internal compiler error: in maybe_add_or_update_back_dep_1, at
sched-deps.c:245
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

With the trunk:
t.c: In function ‘foo’:
t.c:6: internal compiler error: in check_cfg, at haifa-sched.c:4654
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

*** Bug 29301 has been marked as a duplicate of this bug. ***

*** Bug 29750 has been marked as a duplicate of this bug. ***

Hi!

Sorry for the late response.

The scheduler fails to process a basic block with barrier inside it.
The basic block looks like this:

- Basic block 2 - begin -
<some insns>

(insn:HI 14 12 16 2 (set (mem/f/c/i:SI (symbol_ref:SI ("cptr") <var_decl
0x20000000035e3c80 cptr>) [2 cptr+0 S4 A32])
        (reg:SI 0 ax [orig:59 D.1637 ] [59])) 34 {*movsi_1} (nil)
    (nil))

(insn:HI 16 14 17 2 (trap_if (const_int 1 [0x1])
        (const_int 6 [0x6])) 551 {trap} (nil)
    (nil))

(barrier:HI 17 16 18)

(insn:HI 18 17 33 2 (parallel [
            (set (reg/f:SI 7 sp)
                (plus:SI (reg/f:SI 7 sp)
                    (const_int 16 [0x10])))
            (clobber (reg:CC 17 flags))
        ]) 146 {*addsi_1} (nil)
    (nil))

<some insns>
- Basic block 2 - end -

GCC 4.1 doesn't fail on this code solely because there is no trap - barrier
pair generated for this testcase (if there were, it would have fail a bit later
on the assert that not all insns were scheduled - barrier will be counted as
insn but won't be scheduled).

To the best of my knowledge, this issue should be dealt with in dead code
eleminator as stated in cfgbuild.c: control_flow_insn_p ().

Also there was a patch by Jan Hubicka
(http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03461.html) which would've likely
fixed this problem.  The part of that patch we need wasn't checked in due to
some unknown reason.

If this kind of basic block is acceptable during scheduler then I can post a
patch that will make the scheduler handle the case properly.

Subject: Re:  [4.2/4.3 regression] ICE with scheduling and __builtin_trap

Hi,
barrier in the middle of basic block is invalid and should be noticed by
verify_flow_info and ICE.  What part of my patch you quote is supposed
to fix the problem?

Honza

(In reply to comment #8)
> Subject: Re:  [4.2/4.3 regression] ICE with scheduling and __builtin_trap
> 
> Hi,
> barrier in the middle of basic block is invalid and should be noticed by
> verify_flow_info and ICE.  What part of my patch you quote is supposed
> to fix the problem?
> 

cfgrtl.c: rtl_verify_flow_info () makes the same statement as
control_flow_insn_p ():
/* We may have a barrier inside a basic block before dead code
   elimination.  There is no BLOCK_FOR_INSN field in a barrier.  */

This hunk from your patch would've helped, I guess:
*************** control_flow_insn_p (rtx insn)
*** 118,123 ****
--- 119,129 ----
              || can_throw_internal (insn));

      case INSN:
+       /* We represent EH manipulation via unspec followed by barrier.
+          Such instruction is control flow instruction even when there is
+          no other clue specifying it.  */
+       if (NEXT_INSN (insn) && GET_CODE (NEXT_INSN (insn)) == BARRIER)
+       return true;
        return (flag_non_call_exceptions && can_throw_internal (insn));

      case BARRIER:

Subject: Re:  [4.2/4.3 regression] ICE with scheduling and __builtin_trap

> 
> cfgrtl.c: rtl_verify_flow_info () makes the same statement as
> control_flow_insn_p ():
> /* We may have a barrier inside a basic block before dead code
>    elimination.  There is no BLOCK_FOR_INSN field in a barrier.  */

Duh, I would consider HP's patch adding the hunk to verify_flow_info in
2004 as incorrect even if it was commited as obvious.  Clearly we don't
want to have barriers within basic blocks, dead code ellimination done
or not, especially not at the scheduling time! (frankly, we don't want
to have barriers at first place)

I would suggest put that hunk in (it was probably just merge omision
from my side) and try to remove the verify_flow_info bit and see if
everything works.  I can do it tonight or tomorrow unless you beat me.

Honza

> I would suggest put that hunk in (it was probably just merge omision
> from my side) and try to remove the verify_flow_info bit and see if
> everything works.  I can do it tonight or tomorrow unless you beat me.


OK, thanks!

*** Bug 30366 has been marked as a duplicate of this bug. ***

*** Bug 30596 has been marked as a duplicate of this bug. ***

*** Bug 30749 has been marked as a duplicate of this bug. ***

Is the patch mentioned by Maxim checked in now? Because this bug still occurs.

(In reply to comment #15)
> Is the patch mentioned by Maxim checked in now? Because this bug still occurs.
> 

I've posted a patch in http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01220.html
but Jan hasn't commited it yet.  Will ping the patch now.

Subject: Bug number PR rtl-optimization/29841

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html

Subject: Bug 29841

Author: ebotcazou
Date: Thu Apr 19 12:19:16 2007
New Revision: 123970

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123970
Log:
        PR rtl-optimization/29841
        * cfgbuild.c (control_flow_insn_p): Return TRUE for unconditional
        trap instructions.
        * sched-deps.c (sched_analyze_insn): Prevent all non-jump instructions
        that may cause control flow transfer from being moved.


Added:
    trunk/gcc/testsuite/gcc.dg/invalid-call-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgbuild.c
    trunk/gcc/sched-deps.c
    trunk/gcc/testsuite/ChangeLog

Subject: Bug 29841

Author: ebotcazou
Date: Thu Apr 19 12:19:39 2007
New Revision: 123971

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123971
Log:
        PR rtl-optimization/29841
        * cfgbuild.c (control_flow_insn_p): Return TRUE for unconditional
        trap instructions.
        * sched-deps.c (sched_analyze_insn): Prevent all non-jump instructions
        that may cause control flow transfer from being moved.


Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/invalid-call-1.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/cfgbuild.c
    branches/gcc-4_2-branch/gcc/sched-deps.c
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog

Should work now.

*** Bug 30815 has been marked as a duplicate of this bug. ***