Bug 105432 - [13 regression] bootstrap build error in mpfr in stage2
Summary: [13 regression] bootstrap build error in mpfr in stage2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: 13.0
Assignee: Aldy Hernandez
URL:
Keywords: build
: 105434 105439 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-04-29 14:05 UTC by seurer
Modified: 2022-10-31 19:52 UTC (History)
9 users (show)

See Also:
Host: powerpc64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu
Target: powerpc64-linux-gnu, powerpc64le-linux-gnu,x86_68,i686,powerpc-apple-darwin*, aarch64-linux-gnu
Build: powerpc64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2022-04-29 00:00:00

Attachments
atan.i (22.24 KB, text/plain)
2022-04-29 19:24 UTC, seurer 		Details
untested patch (426 bytes, patch)
2022-04-29 20:43 UTC, Aldy Hernandez 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description seurer 2022-04-29 14:05:27 UTC 
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include -fno-checking -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LITTLE_ENDIAN=1 -DHAVE_CLOCK_GETTIME=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STRUCT_LCONV_DECIMAL_POINT=1 -DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_UINTPTR_T=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SIGNAL=1 -DHAVE_SIGACTION=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_NORETURN=1 -DMPFR_HAVE_BUILTIN_UNREACHABLE=1 -DMPFR_HAVE_CONSTRUCTOR_ATTR=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_SUBNORM_DBL=1 -DHAVE_SUBNORM_FLT=1 -DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_DOUBLE_IEEE_LITTLE_ENDIAN=1 -DHAVE_LDOUBLE_MAYBE_DOUBLE_DOUBLE=1 -DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1 -DMPFR_WANT_DECIMAL_FLOATS=1 -DDECIMAL_DPD_FORMAT=1 -DMPFR_WANT_FLOAT128=1 -DMPFR_USE_STATIC_ASSERT=1 -DHAVE_ATTRIBUTE_MODE=1 -DPRINTF_L=1 -DPRINTF_T=1 -DPRINTF_GROUPFLAG=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -DMPFR_LONG_WITHIN_LIMB=1 -DMPFR_INTMAX_WITHIN_LIMB=1 -DHAVE_GETRUSAGE=1 -I. -I/home/seurer/gcc/git/gcc-test/mpfr/src -I/home/seurer/gcc/git/build/gcc-test/gmp -DNO_ASM -g -O2 -fno-checking -gtoggle -MT atan.lo -MD -MP -MF .deps/atan.Tpo -c /home/seurer/gcc/git/gcc-test/mpfr/src/atan.c -o atan.o
during GIMPLE pass: vrp
/home/seurer/gcc/git/gcc-test/mpfr/src/atan.c: In function 'mpfr_atan':
/home/seurer/gcc/git/gcc-test/mpfr/src/atan.c:286:1: internal compiler error: in set_range_info_raw, at tree-ssanames.cc:356
  286 | mpfr_atan (mpfr_ptr atan, mpfr_srcptr x, mpfr_rnd_t rnd_mode)
      | ^~~~~~~~~
0x11807ae3 set_range_info_raw(tree_node*, value_range_kind, generic_wide_int<wide_int_ref_storage<false, true> > const&, generic_wide_int<wide_int_ref_storage<false, true> > const&)
	/home/seurer/gcc/git/gcc-test/gcc/tree-ssanames.cc:356
0x118081f7 set_range_info
	/home/seurer/gcc/git/gcc-test/gcc/tree-ssanames.cc:414
0x1180832f set_range_info(tree_node*, int_range<1u> const&)
	/home/seurer/gcc/git/gcc-test/gcc/tree-ssanames.cc:424
0x118f3633 vrp_asserts::remove_range_assertions()
	/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:3754
0x118f4d97 execute_vrp
	/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:4245
0x118f53a7 execute
	/home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:4415


I am still looking for the source.
Comment 1 seurer 2022-04-29 17:40:36 UTC 
This is what breaks things:

g:6ccc4356e7c5b4ca69d2029898a6439bb735cbc5, r13-32-g6ccc4356e7c5b4

commit 6ccc4356e7c5b4ca69d2029898a6439bb735cbc5 (HEAD)
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon Mar 7 14:56:34 2022 +0100

    Prefer global range info setters that take a range.
Comment 2 Jakub Jelinek 2022-04-29 17:48:18 UTC 
Can you please attach preprocessed atan.c ?  How have you configured gcc (mostly, what -mcpu=/-mtune= it defaults to)?
Comment 3 seurer 2022-04-29 19:24:27 UTC 
Created attachment 52909 [details]
atan.i
Comment 4 seurer 2022-04-29 19:24:51 UTC 
configure was:

configure --enable-languages=c,fortran,c++ --with-cpu=power10 --enable-bootstrap

though note it also failed for power9, power8, and power7 and on both LE and BE.
Comment 5 Aldy Hernandez 2022-04-29 20:42:49 UTC 
set_range_info does not handle VR_VARYING because SSA_NAME_RANGE_TYPE can only store VR_RANGE or VR_ANTI_RANGE.  However, we allow storing a range of the entire domain because nonzero bits can be set on such a range.

This was working because the previous call to set_range_info was passing VR_RANGE and the extremes of the type.  This won't work if we go through a value_range, because the normalization code will see [MIN, MAX] and normalize it to VR_VARYING.  Ughh.

The correct thing to do here is to force VR_RANGE in this scenario.
Comment 6 Aldy Hernandez 2022-04-29 20:43:29 UTC 
Created attachment 52910 [details]
untested patch
Comment 7 Iain Sandoe 2022-04-30 13:03:29 UTC 
*** Bug 105434 has been marked as a duplicate of this bug. ***
Comment 8 Iain Sandoe 2022-04-30 13:04:14 UTC 
*** Bug 105439 has been marked as a duplicate of this bug. ***
Comment 9 cqwrteur 2022-05-01 06:14:06 UTC 
(In reply to Aldy Hernandez from comment #6)
> Created attachment 52910 [details]
> untested patch

when will this patch be applied to the main? I am working on building a new series of canadian toolchains.
Comment 10 Iain Sandoe 2022-05-01 06:21:12 UTC 
(In reply to Aldy Hernandez from comment #6)
> Created attachment 52910 [details]
> untested patch

FWIW, patch fixes bootstrap for {powerpc,i686,x86_64}-apple-darwin.
Comment 11 GCC Commits 2022-05-01 12:19:35 UTC 
The trunk branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:75bbc3da3e5f75f683fa33e309045c582efd20eb

commit r13-60-g75bbc3da3e5f75f683fa33e309045c582efd20eb
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Fri Apr 29 22:46:25 2022 +0200

    Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.
    
    We are ICEing in set_range_info_raw because value_range_kind cannot be
    VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE /
    VR_ANTI_RANGE.  Most of the time setting a VR_VARYING as a global
    range makes no sense.  However, we can have a range spanning the
    entire domain (VR_RANGE of [MIN,MAX] which is essentially a
    VR_VARYING), if the nonzero bits are set.
    
    This was working before because set_range_info_raw allows setting
    VR_RANGE of [MIN, MAX].  However, when going through an irange, we
    normalize this to a VR_VARYING, thus causing the ICE.  It's
    interesting that other calls to set_range_info with an irange haven't
    triggered this.
    
    One solution would be to just ignore VR_VARYING and bail, since
    set_range_info* is really an update of the current range semantic
    wise.  After all, we keep the nonzero bits which provide additional
    info.  But this would be a change in behavior, so not suitable until
    after GCC 12 is released.  So in order to keep with current behavior
    we can just denormalize the varying to VR_RANGE.
    
    Tested on x86-64 Linux.
    
                PR tree-optimization/105432
    
    gcc/ChangeLog:
    
            * tree-ssanames.cc (set_range_info): Denormalize VR_VARYING to
            VR_RANGE before passing a piecewise range to set_range_info_raw.
Comment 12 Aldy Hernandez 2022-05-01 12:20:54 UTC 
Fixed in mainline.

Sorry for the delay.  I had previous weekend commitments I wasn't able to reschedule.  Hopefully it didn't cause too much pain over the weekend.