[Bug c/106172] New: Multiple ICEs building gcc-13 with gcc-12

[Bug c/106172] New: Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

            Bug ID: 106172
           Summary: Multiple ICEs building gcc-13 with gcc-12
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chris2553 at googlemail dot com
  Target Milestone: ---

Created attachment 53246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53246&action=edit
GCC diagnostics file 1

I'm trying to build the gcc-13-20220626 snapshot with the gcc-12-20220702
snapshot but get multiple ICEs. I got the same (or similar) bunch of ICE's last
week trying to build gcc-13-20220626 with gcc-12-20220625, but didn't have time
to get the diagnostics and report it last week)

I've run the build again with the recommended -freport-bug added to CFLAGSand
the files saved to /tmp/ are attached as is a file containing the text splat on
the console when the ICEs happened.

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #1 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53247&action=edit
GCC diagnostics file 2

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #2 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53248&action=edit
GCC diagnostics file 3

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #3 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53249&action=edit
GCC diagnostics file 4

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #4 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53250&action=edit
GCC diagnostics file 5

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #5 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53251&action=edit
GCC diagnostics file 6

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #6 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53252&action=edit
GCC diagnostics file 7

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #7 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53253&action=edit
GCC diagnostics file 8

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #8 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53254&action=edit
GCC diagnostics file 9

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #9 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53255&action=edit
Error messages output to terminal

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> ---
How did you build the bootstrap compiler?

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #11 from Chris Clayton <chris2553 at googlemail dot com> ---
On 03/07/2022 12:00, schwab@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
> 
> --- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> ---
> How did you build the bootstrap compiler?
> 

I assume that by bootstrap compiler you mean xgcc/xg++. If not, what is it?

In any case, I didn't do anything in particular. As I understand it, the
bootstrap compiler is built as an early step of
the gcc build system so it will have been built with gcc-12-20220702.

[Bug c/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #12 from Chris Clayton <chris2553 at googlemail dot com> ---
I've just run the build again with gcc-11-20220701 and get the same set of
ICEs. I've kept the files of diagnostics output by gcc and can provide them id
they will be helpful.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-Krisux-linux
               Host|                            |x86_64-Krisux-linux
          Component|middle-end                  |bootstrap
              Build|                            |x86_64-Krisux-linux

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
// Configured with: ../gcc-13-20220626/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/usr/local
--enable-shared --enable-threads=posix --enable-haifa
--enable-languages=c,c++,fortran --enable-long-long --enable-namespaces
--with-gnu-as --with-gnu-ld --with-system-zlib --without-x --disable-werror
--disable-checking --enable-__cxa_atexit --disable-nls
--without-included-gettext --disable-multilib --program-suffix=13
x86_64-Krisux-linux

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-07-03

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> make[2]: *** [Makefile:20255: all-stage2-target-libgcc] Error 2
> make[2]: Leaving directory '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu'
> make[1]: *** [Makefile:25739: stage2-bubble] Error 2
> make[1]: Leaving directory '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu'
> make: *** [Makefile:1072: all] Error 2


Did you set any CFLAGS or STAGE1_CFLAGS (or CXXFLAGS) env?
What the above means is stage1 is being miscompiled.
I Noticed you used --disable-checking, these days the default for releases is
--enable-checking=release rather than --disable-checking (slightly different
though).

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #15 from Chris Clayton <chris2553 at googlemail dot com> ---
On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
> 
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |WAITING
>      Ever confirmed|0                           |1
>    Last reconfirmed|                            |2022-07-03
> 
> --- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>> make[2]: *** [Makefile:20255: all-stage2-target-libgcc] Error 2
>> make[2]: Leaving directory '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu'
>> make[1]: *** [Makefile:25739: stage2-bubble] Error 2
>> make[1]: Leaving directory '/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu'
>> make: *** [Makefile:1072: all] Error 2
> 
> 
> Did you set any CFLAGS or STAGE1_CFLAGS (or CXXFLAGS) env?
> What the above means is stage1 is being miscompiled.

I build and manage packages with rpm. Through rpmbuild the default for CFLAGS
is "-O2 -g". To that I add
"-mindirect-branch=thunk" to build with retpoline enabled.

> I Noticed you used --disable-checking, these days the default for releases is
> --enable-checking=release rather than --disable-checking (slightly different
> though).

Is that likely to be the source of the problem? If not, I'll look into it when
this problem is solved.
> 

Another data point - I've just tried to build gcc-13-20220626 with gcc-10.4.0
and get the same batch of ICEs.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #16 from Chris Clayton <chris2553 at googlemail dot com> ---
I've tried two further build of gcc-13 using gcc-12-20220702.

The gcc-13-20220703 snapshot fails with the same ICEs but the 20220619 snapshot
builds successfully.

So we have 13-20220626 and 13-20220703 both fail but 13-20220619 succeeds.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #17 from Chris Clayton <chris2553 at googlemail dot com> ---
I've cloned git://gcc.gnu.org/git/gcc.git and bisected between 13-20220626
(ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd) and 13-20220619
(4390e7bfbc641a52c6192b448768dafdf4565527) as bad and good respectively.

The result is:

8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit
commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Sat Jun 25 18:58:02 2022 -0400

    Convert DOM to use Ranger rather than EVRP

    [Jeff, this is the same patch I sent you last week with minor tweaks
    to the commit message.]

    [Despite the verbosity of the message, this is actually a pretty
    straightforward patch.  It should've gone in last cycle, but there
    was a nagging regression I couldn't get to until after stage1
    had closed.]

    There are 3 uses of EVRP in DOM that must be converted.
    Unfortunately, they need to be converted in one go, so further
    splitting of this patch would be problematic.

    There's nothing here earth shattering.  It's all pretty obvious in
    retrospect, but I've added a short description of each use to aid in
    reviewing:

    * Convert evrp use in cprop to ranger.

      This is easy, as cprop in DOM was converted to the ranger API last
      cycle, so this is just a matter of using a ranger instead of an
      evrp_range_analyzer.

    * Convert evrp use in threader to ranger.

      The idea here is to use the hybrid approach we used for the initial
      VRP threader conversion last cycle.  The DOM threader will continue
      using the forward threader infrastructure while continuing to query
      DOM data structures, and only if the conditional does not relsolve,
      using the ranger.  This gives us the best of both worlds, and is a
      proven approach.

      Furthermore, as frange and prange come live in the next cycle, we
      can move away from the forward threader altogether, and just add
      another backward threader.  This will not only remove the last use
      of the forward threader, but will allow us to remove at least 1 or 2
      threader instances.

    * Convert conditional folding to use the method used by the ranger and
      evrp.  Previously DOM was calling into the guts of
      simplify_using_ranges::vrp_visit_cond_stmt.  The blessed way now is
      using fold_cond() which rewrites the conditional and edges
      automatically.

      When legacy is removed, simplify_using_ranges will be further
      cleaned up, and there will only be one entry point into simplifying
      a statement.

    * DOM was setting global ranges determined from unreachable edges as a
      side-effect of using the evrp engine.  We must handle these cases
      before nuking evrp, and DOM seems like a good fit.  I've just moved
      the snippet to DOM, but it could live anywhere else we do a DOM
      walk.

      For the record, this is the case *vrp handled:

            <bb C>:
            ...
            if (c_5(D) != 5)
            goto <bb N>;
            else
            goto <bb M>;
            <bb N>:
            __builtin_unreachable ();
            <bb M>:

      If M dominates all uses of c_5, we can set the global range of c_5
      to [5,5].

    I have tested on x86-64, pcc64le, and aarch64 Linux.

    I also ran threading benchmarks as well as performance benchmarks.

    DOM threads 1.56% more paths which ultimately yields a miniscule total
    increase of 0.03%.

    The conversion to ranger brings a 7.87% performance drop in DOM, which
    is a wash in overall compilation.  This is in line with other
    replacements of legacy evrp with ranger.  We handle a lot more cases.
    It's not free .

    There is a a regression on Wstringop-overflow-4.C which I'm planning
    on XFAILing.  It's another variant of the usual middle-end false
    positives: having no ranges produces no warnings, but slightly refined
    ranges, or worse-- isolating specific problematic cases in the
    threader causes flare-ups.

    As an aside, as Richi has suggested, I think we should discuss
    restricting the threader's ability to thread highly unlikely paths.
    These cause no end of pain for middle-end warnings.  However,
    I don't know if this would conflict with path isolation for
    things like null dereferencing.  ISTR you were interested in this.

    BTW, I think the Wstringop-overflow-4.C test is problematic and I've
    attached my analysis.  Basically the regression is caused by a bad
    interaction with the rounding/alignment that placement new has inlined
    into the IL.  This happens for int16_r[] which the test is testing.
    Ranger can glean some range info, which causes DOM threading to
    isolate a path which causes a warning.
    ...

I'll attach the bisect log shortly.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #18 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 53256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53256&action=edit
git bisect log

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #19 from Chris Clayton <chris2553 at googlemail dot com> ---
Hi

On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
> 
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |WAITING
>      Ever confirmed|0                           |1
>    Last reconfirmed|                            |2022-07-03
> 

I some additional diagnostics (the result of a bisect) to the bugzilla report
earlier this week. The first bad commit
was 8c99e307b20.

I've been busy since but have just checked out the first bad commit's parent
commit (54a5f478487) and built with
gcc-12-20220702. That build completed successfully.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #20 from Chris Clayton <chris2553 at googlemail dot com> ---
On 08/07/2022 15:02, Chris Clayton wrote:
> Hi
> 
> On 04/07/2022 00:12, pinskia at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
>>
>> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>              Status|UNCONFIRMED                 |WAITING
>>      Ever confirmed|0                           |1
>>    Last reconfirmed|                            |2022-07-03
>>
> 
> I some additional diagnostics (the result of a bisect) to the bugzilla report earlier this week. The first bad commit
> was 8c99e307b20.
> 
> I've been busy since but have just checked out the first bad commit's parent commit (54a5f478487) and built with
> gcc-12-20220702. That build completed successfully.

As an update, I've just tried to build the gcc-13-20220717 snapshot using a
compiler built with gcc-12-20220716
snapshot. The outcome is the same set of ICEs.

I've also realised this morning that I forgot to add the author of the first
bad coomit from the bisect that I reported
the results of. So, aldyh@redhat.com added as recipient of this email.

Aldy - the first bad commit from the bisect was
8c99e307b20c502e55c425897fb3884ba8f05882 (Convert DOM to use Ranger
rather than EVRP). It seems to be involved in some way in a batch of ICEs I see
when trying to build recent gcc-13
snapshots (20220626 and later) with recent gcc-12 snapshots. I aslo get the
ICEs trying to build gcc-13 with a gcc-11 or
gcc-10 compiler. The diagnostics I've collected are attached to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

> 
>

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org
             Status|WAITING                     |NEW

--- Comment #21 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed on x86-64 with: ./configure --enable-languages=c,c++
--enable-checking=no.

Interestingly, --enable-checking=release works.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #21)
> Confirmed on x86-64 with: ./configure --enable-languages=c,c++
> --enable-checking=no.
> 
> Interestingly, --enable-checking=release works.

well some gcc_assert is changed based on checking.

configure.ac:
        release)        ac_assert_checking=1 ; ac_checking= ; ac_df_checking= ;
                        ac_fold_checking= ; ac_gc_checking= ;
ac_extra_checking= ;
                        ac_gc_always_collect= ; ac_gimple_checking= ;
ac_rtl_checking= ;
                        ac_rtlflag_checking= ; ac_runtime_checking=1 ;
                        ac_tree_checking= ; ac_valgrind_checking= ;
                        ac_types_checking= ;;

        no|none)        ac_assert_checking= ; ac_checking= ; ac_df_checking= ;
                        ac_fold_checking= ; ac_gc_checking= ;
ac_extra_checking= ;
                        ac_gc_always_collect= ; ac_gimple_checking= ;
ac_rtl_checking= ;
                        ac_rtlflag_checking= ; ac_runtime_checking= ;
                        ac_tree_checking= ; ac_valgrind_checking= ;
                        ac_types_checking= ;;

...
system.h:
/* Use gcc_assert(EXPR) to test invariants.  */
#if ENABLE_ASSERT_CHECKING
#define gcc_assert(EXPR)                                                \
   ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0))
#elif (GCC_VERSION >= 4005)
#define gcc_assert(EXPR)                                                \
  ((void)(UNLIKELY (!(EXPR)) ? __builtin_unreachable (), 0 : 0))
#else
/* Include EXPR, so that unused variable warnings do not occur.  */
#define gcc_assert(EXPR) ((void)(0 && (EXPR)))
#endif

#if CHECKING_P
#define gcc_checking_assert(EXPR) gcc_assert (EXPR)
#else
/* N.B.: in release build EXPR is not evaluated.  */
#define gcc_checking_assert(EXPR) ((void)(0 && (EXPR)))
#endif

So if there is any side effects in gcc_assert that should not be there,
--enable-checking=no will actually not compile it.

[Bug bootstrap/106172] Multiple ICEs building gcc-13 with gcc-12

[chris2553 at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172

--- Comment #23 from Chris Clayton <chris2553 at googlemail dot com> ---
On 18/07/2022 19:13, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106172
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |aldyh at gcc dot gnu.org
>              Status|WAITING                     |NEW
> 
> --- Comment #21 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Confirmed on x86-64 with: ./configure --enable-languages=c,c++
> --enable-checking=no.
> 
> Interestingly, --enable-checking=release works.
> 
Yes, that build succeeds here too. I've had --disable-checking in the picture
for at least 5 years, and it's not been a
problem.  I've built hundreds of gcc-<dev_version> snapshots using
gcc-<current_version> snapshots in that time.

Anyway I can drop the checking option altogether because the documentation
states that --enable-checking=release is the
default.

But I guess there is a problem that needs to be fixed albeit maybe not an
urgent one. If anyone wants a fix testing, I'm
more than happy to help, so just drop me an email. I'll put a comment in my rpm
spec file to remind that I need to add
the option back in.

Thanks.