[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #6 from Alan Modra  ---
(In reply to Peter Bergner from comment #4)
> Something like the attached patch?
No.  -mlong-double-128 overrides the configured --without-long-double-128. 
--without-long-double-128 doesn't *disable* 128-bit long doubles, it just sets
the default to 64-bit long double.

(In reply to Michael Meissner from comment #5)
Yes, -mno-gnu-attribute makes sense, however it should only apply to files
linked into the shared libgcc, not IMO to files in libgcc.a.

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[meissner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Michael Meissner  ---
One of my patches for adding IEEE 128-bit long double may help with this
situation.  The ibm-ldouble.c module was not being compiled with
-mno-gnu-attributes would affect things if a different long double type was
used:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556863.html

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Peter Bergner  ---
Created attachment 49436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49436=edit
patch file

So libgcc compiles are explicitly using -mlong-double-128, which doesn't seem
right when GCC is configured with --disable-multilib --without-long-double-128,
which seems to come from:

libgcc/config/rs6000/t-linux:HOST_LIBGCC2_CFLAGS += -mlong-double-128

Shouldn't we just use the compiler default for long double (ie, don't use that
option at all)?

Something like the attached patch?

[Bug c++/96742] [10/11 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

[hanicka at hanicka dot net via Gcc-bugs]

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

Hana Dusíková  changed:

   What|Removed |Added

 CC||hanicka at hanicka dot net

--- Comment #7 from Hana Dusíková  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to William Throwe from comment #2)
> > This warns if passed an array of length 0 because the for-loop condition is
> > always false.  Any change I can make to fix it seems to make the code worse.
> > I could replace "i < N" with "i + 1 < N + 1", but that certainly doesn't
> > make the code clearer (and in similar cases could lead to weird overflow
> > bugs).  I can't partially specialize the function, because that's not
> > allowed.  I could write an implementation struct and specialize that, but
> > that seems like massive overkill when the generic function works fine.
> 
> You can use N != 0 && i < N which doesn't have the overflow problem, but I
> agree it doesn't make the code clearer, and should not be necessary.

This is what I had in CTRE but it's also triggering same warning: 
https://compiler-explorer.com/z/fjY7sG

[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and on 10-branch.  Closing.

Thanks for the report!

[Bug ada/97557] New: [11 regression] several ada test case failures

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97557
   Summary: [11 regression] several ada test case failures
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: gnat.dg/derived_type3.adb (test for excess errors)
FAIL: gnat.dg/invalid1.adb (test for excess errors)
FAIL: gnat.dg/sso16.adb (test for excess errors)
FAIL: gnat.dg/validity_check.adb (test for excess errors)

I am not sure when these started failing because of the issue building ada
recently.

Executing on host: /home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatmake
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
--GNATBIND=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatbind
--GNATLINK=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatlink -cargs
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc -largs
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc\
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc\  -margs
--RTS=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libada
-q -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/gnat.dg/derived_type3.adb
  -fdiagnostics-plain-output -lm  -o ./derived_type3.exe(timeout = 300)
spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatmake
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
--GNATBIND=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatbind
--GNATLINK=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatlink -cargs
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc -largs
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc  -margs
--RTS=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libada
-q -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/gnat.dg/derived_type3.adb
-fdiagnostics-plain-output -lm -o ./derived_type3.exe^M
error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled^M
gnatmake: *** bind failed.^M
compiler exited with status 1
Executing on host:
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatclean -c -q -n
./derived_type3   (timeout = 300)
spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatclean -c -q -n
./derived_type3^M
./derived_type3.ali^M
./derived_type3.o^M
./derived_type3_pkg.ali^M
./derived_type3_pkg.o^M
FAIL: gnat.dg/derived_type3.adb (test for excess errors)
Excess errors:
error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled


Executing on host: /home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatmake
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
--GNATBIND=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatbind
--GNATLINK=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatlink -cargs
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc -largs
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc\
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc\  -margs
--RTS=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libada
-q -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/gnat.dg/invalid1.adb  
-fdiagnostics-plain-output   -gnatws -gnatVa  -lm  -o ./invalid1.exe   
(timeout = 300)
spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatmake
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
--GNATBIND=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatbind
--GNATLINK=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatlink -cargs
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc -largs
--GCC=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc  -margs
--RTS=/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libada
-q -f
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/gnat.dg/invalid1.adb
-fdiagnostics-plain-output -gnatws -gnatVa -lm -o ./invalid1.exe^M
invalid1.adb:8:03: run-time configuration error^M
invalid1.adb:8:03: entity "System.Scalar_Values.Is_Is16" not defined^M
gnatmake:
"/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/gnat.dg/invalid1.adb"
compilation error^M
compiler exited with status 1
Executing on host:
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatclean -c -q -n
./invalid1   (timeout = 300)
spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatclean -c -q -n
./invalid1^M
FAIL: gnat.dg/invalid1.adb (test for excess errors)
Excess errors:
invalid1.adb:8:03: run-time configuration error
invalid1.adb:8:03: entity "System.Scalar_Values.Is_Is16" not defined

Executing on host: /home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/gnatmake

[Bug tree-optimization/97556] New: ICE at -O2 and -O3 in 32-bit mode on x86_64-pc-linux-gnu in size_remaining, at builtins.c:235

[su at cs dot ucdavis.edu via Gcc-bugs]

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

Bug ID: 97556
   Summary: ICE at -O2 and -O3 in 32-bit mode on
x86_64-pc-linux-gnu in size_remaining, at
builtins.c:235
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[520] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201023 (experimental) [master revision
7991e963239:9cbfe237f74:757ba6653c2699761c2243e0194749a6695112d8] (GCC) 
[521] % 
[521] % gcctk -m32 -Os -c small.c
[522] % 
[522] % gcctk -m32 -O2 -c small.c
during GIMPLE pass: strlen
small.c: In function ‘f’:
small.c:4:6: internal compiler error: in size_remaining, at builtins.c:235
4 | void f () {
  |  ^
0x7a510b
access_ref::size_remaining(generic_wide_int >*)
const
../../gcc-trunk/gcc/builtins.c:235
0x7a53d5 access_ref::add_offset(generic_wide_int >
const&, generic_wide_int > const&)
../../gcc-trunk/gcc/builtins.c:334
0x7a6bd3 compute_objsize
../../gcc-trunk/gcc/builtins.c:4840
0x7a6b63 compute_objsize
../../gcc-trunk/gcc/builtins.c:4781
0x7a7de1 compute_objsize(tree_node*, int, access_ref*, range_query*)
../../gcc-trunk/gcc/builtins.c:5039
0x7a7f61 compute_objsize(tree_node*, int, tree_node**, tree_node**,
range_query*)
../../gcc-trunk/gcc/builtins.c:5063
0xf15fc2 maybe_warn_overflow
../../gcc-trunk/gcc/tree-ssa-strlen.c:2042
0xf1a7f8 maybe_warn_overflow
../../gcc-trunk/gcc/tree-ssa-strlen.c:2351
0xf1a7f8 handle_store
../../gcc-trunk/gcc/tree-ssa-strlen.c:5059
0xf1c744 check_and_optimize_stmt
../../gcc-trunk/gcc/tree-ssa-strlen.c:5697
0xf1c744 strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-strlen.c:5874
0x1729737 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:309
0xf0dd4f printf_strlen_execute
../../gcc-trunk/gcc/tree-ssa-strlen.c:5940
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[523] % 
[523] % cat small.c
char a[1][3];
int b;

void f () {
  unsigned c = 10;
  if (b)
goto L;
  while (b) {
c = ~0;
  L:
a[c][0] = 0;
  }
}

[Bug tree-optimization/97555] New: wrong code at -Os and above on x86_64-pc-linux-gnu

[su at cs dot ucdavis.edu via Gcc-bugs]

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

Bug ID: 97555
   Summary: wrong code at -Os and above on x86_64-pc-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[536] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201023 (experimental) [master revision
7991e963239:9cbfe237f74:757ba6653c2699761c2243e0194749a6695112d8] (GCC) 
[537] % 
[537] % gcctk -O1 small.c; ./a.out
[538] % 
[538] % gcctk -Os small.c
[539] % ./a.out
Floating point exception
[540] % 
[540] % cat small.c
struct {
  int a:1;
} b;

int c, d, e, f = 1, g;

int main ()
{
  for (; d < 3; d++) {
char h = 1 % f, i = ~(0 || ~0);
c = h;
f = ~b.a;
~b.a | 1 ^ ~i && g;
if (~e)
  i = b.a;
b.a = i;
  }
  return 0;
}

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 91741, which changed state.

Bug 91741 Summary: Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/91741] Implement new warning -Wsizeof-array-div

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Marek Polacek  ---
Implemented in r11-4328.

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Segher Boessenkool  ---
This part of the attribute (all but the low 2 bits) is not documented
in the as manual, btw.

[Bug middle-end/97552] missing waning passing null to a VLA argument declared [static]

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Keywords||diagnostic

--- Comment #2 from Martin Sebor  ---
Fixed in r11-4327.

[Bug c/97463] [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Martin Sebor  ---
Fixed in r11-432.

[Bug middle-end/97552] missing waning passing null to a VLA argument declared [static]

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:757ba6653c2699761c2243e0194749a6695112d8

commit r11-4327-g757ba6653c2699761c2243e0194749a6695112d8
Author: Martin Sebor 
Date:   Fri Oct 23 12:37:38 2020 -0600

PR middle-end/97552 - missing waning passing null to a VLA argument
declared [static]

gcc/ChangeLog:

PR middle-end/97552
* attribs.c (init_attr_rdwr_indices): Handle static VLA parameters.

gcc/c/ChangeLog:

PR middle-end/97552
* c-decl.c (get_parm_array_spec): Handle static VLA parameters.

gcc/testsuite/ChangeLog:

PR middle-end/97552
* gcc.dg/Wvla-parameter-2.c: Adjust text of expected warning.
* gcc.dg/Wnonnull-5.c: New test.

[Bug c/97463] [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:7991e963239160624b22a12caaacce95d3667e49

commit r11-4326-g7991e963239160624b22a12caaacce95d3667e49
Author: Martin Sebor 
Date:   Fri Oct 23 12:30:20 2020 -0600

PR c/97463 - ICE in warn_parm_ptrarray_mismatch on an incompatible function
redeclaration

gcc/c-family/ChangeLog:

PR c/97463
* c-warn.c (warn_parm_ptrarray_mismatch): Move null test earlier.

gcc/testsuite/ChangeLog:

PR c/97463
* gcc.dg/pr97463.c: New test.

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[bergner at gcc dot gnu.org via Gcc-bugs]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||seurer at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
There is no --with-long-double-64 configure option (for power).  The configure
script will just silently ignore it.  That said, you mentioned you used
--without-long-double-128 which is the correct way to get a 64-bit long double,
so there does seem to be a problem here.

I'm adding Alan and Mike to the CC list here for their input on how this is all
supposed to work.  Given you disabled multilib and forced 64-bit long double, I
don't know why libgcc has any 128-bit long double usage.

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[gustavowalbon at gmail dot com via Gcc-bugs]

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

Gustavo Walbon  changed:

   What|Removed |Added

 CC||gustavowalbon at gmail dot com

--- Comment #1 from Gustavo Walbon  ---
I have seeing a bunch of packages failing because this warning of linker when I
build several packages on Alpine for PowerPc.

I have a alpine container running on a PowerPC 8, and I rebuilt the all gcc
packages with the flags --with-long-double-64 and --without-long-double-128 to
avoid this error, but that still happens 

I used the same code as Tulio to reproduce that warning.

~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64le-alpine-linux-musl/10.2.0/lto-wrapper
Target: powerpc64le-alpine-linux-musl
Configured with: /home/devel/aports/main/gcc/src/gcc-10.2.0/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=powerpc64le-alpine-linux-musl --host=powerpc64le-alpine-linux-musl
--target=powerpc64le-alpine-linux-musl --with-pkgversion='Alpine 10.2.0'
--enable-checking=release --disable-fixed-point --disable-libstdcxx-pch
--disable-multilib --disable-nls --disable-werror --disable-symvers
--enable-__cxa_atexit --enable-default-pie --enable-default-ssp
--enable-cloog-backend --enable-languages=c,c++,objc,go,fortran,ada
--with-abi=elfv2 --enable-secureplt --enable-decimal-float=no
--enable-targets=powerpcle-linux --with-long-double-64
--without-long-double-128 --disable-libquadmath --disable-libssp
--disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared
--enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Alpine 10.2.0)

~ $ gcc -O0 -mlong-double-64 test-ldouble64.c && ./a.out
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccHidlkA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccHidlkA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
sizeof(long double) = 8
a * b = 16.00

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Thomas Koenig  ---
There are a couple of more constants for this could be tried.

Base 7:

static unsigned 
rem_7_v2 (mytype n)
{
  unsigned long a, b, c, d;
  a = n & MASK_48;
  b = (n >> 48) & MASK_48;
  c = n >> 96;
  return (a+b+c) % 7;
}

gives the reminder with respect to 7.

The reason is that 2^48-1 = 3*3*5*7*13*17*97*241*257*673, so a shift
of 48 bits works for any combination of these factors. However, for 15,
I would have to check if it would be better to use the 64-bit shift.

For 19, it's a shift of 56 that would work.

I think I'd better make a table.

[Bug bootstrap/97550] libgcc ICE on x86_64-linux-gnu compiler hosted on msys2

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
To be pedantically clear, there are two independent problems here.  The first
is the segmentation fault.  The second is that libbacktrace couldn't find an
executable to open.  I'll look at the libbacktrace problem but someone else
will have to look at the segmentation fault.

[Bug c++/97553] [missed optimization] constexprness not noticed when UBsan enabled

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Whether the function is constexpr or not doesn't really matter when you
evaluate it in non-constant expression contexts.  In those the ubsan
instrumentation is bypassed (the constant expression evaluation does similar
checking), but otherwise it is a normal function like any other, which
including the instrumentation is inlined etc.  And, the runtime sanitization
intentionally isn't heavily optimized away, because the intent is to detect
when the code is invalid, so it can't e.g. optimize away those checks based on
assumption that undefined behavior will not happen.
If you want a constant via C++ means, use int foo() { constexpr int x =
g().length(); return x; }

[Bug rtl-optimization/97554] New: ICE: during RTL pass: cprop /segfault in sbitmap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 97554
   Summary: ICE: during RTL pass: cprop /segfault in sbitmap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Created attachment 49435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49435=edit
reduced testcase

Attached is very reduced case from autogenerated verifier of observations, that
is now failing to compile after including newest meteorological data.
gcc version 11.0.0 20201023 (experimental) linux x86_64

$ gcc -Wall -Wextra -O2 -c nwp_test.c
during RTL pass: cprop
nwp_test.c: In function 'obs_verif_body_entry':
nwp_test.c:14043:13: internal compiler error: Segmentation fault
14043 |   return RC;}
  | ^
0xdef4ef crash_signal
/z/gg/gcc/toplev.c:330
0x7fffed80b81f ???
/z/glibc-2.32/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1909e50 sbitmap_vector_alloc(unsigned int, unsigned int)
/z/gg/gcc/sbitmap.c:171
0x1719767 alloc_cprop_mem
/z/gg/gcc/cprop.c:557
0x1719767 one_cprop_pass
/z/gg/gcc/cprop.c:1817
0x1719767 execute_rtl_cprop
/z/gg/gcc/cprop.c:1931
0x1719767 execute
/z/gg/gcc/cprop.c:1969
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Works with: 4.8.5 5.3 6.2 7.3 8.2
Fails with: 9.3  10.2 11-master

$ gcc-9 -O2 -c nwp_test.c
gcc-9: fatal error: Killed signal terminated program cc1

Able to compile with (time and memory usage is an issue):
gcc-9 -O2 -fno-ree
gcc-10 -O2 -fno-gcse -fno-ree
gcc-11 -O2 -fno-gcse

[Bug c++/97553] New: [missed optimization] constexprness not noticed when UBsan enabled

[eyalroz at technion dot ac.il via Gcc-bugs]

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

Bug ID: 97553
   Summary: [missed optimization] constexprness not noticed when
UBsan enabled
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

(GodBolt example: https://godbolt.org/z/Kvan5c)

Consider the following code:

  #include 

  constexpr std::string_view f() { return "hello"; }

  static constexpr std::string_view g() {
  auto x { f() };
  return x.substr(1, 3);
  } 

  int foo() { return g().length(); }

if you compile it with flags `--std=c++17 -O3`, it results in a pleasant:

  foo():
  mov eax, 3
  ret

but if you also enabled undefined-behavior sanitization, i.e. `--std=c++17
-fsanitize=undefined -O3`, then you get a much longer program with UB-related
instrumentation - which is never used.

I'm not sure if it's because some optimizations are disabled with UBsan, in
which case this might be a "misfeature", or whether they're enabled but the
optimization is just missed.

[Bug middle-end/97552] New: missing waning passing null to a VLA argument declared [static]

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97552
   Summary: missing waning passing null to a VLA argument declared
[static]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The call to f0() below is diagnosed as expected because the [static N] notation
implies that the argument must have at least N elements.

The call to f1() shouldn't be diagnosed because without [static] and witout
attribute nonnull the function should be expected to gracefully deal with null
a pointer when the bound is zero.

But because of the [static] the call to f2() should again be diagnosed, even
when n is zero.

$ cat a.c && /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O2 -S -Wall
a.c
void f0 (int, int a[static 0]); // a must be an array
void f1 (int n, int a[n]);  // a can be null
void f2 (int n, int a[static n]);   // a must be an array

void h (void)
{
  f0 (0, 0);   // warning (good)
  f1 (0, 0);   // no warning (good)
  f2 (0, 0);   // missing warning
}
a.c: In function ‘h’:
a.c:7:3: warning: argument 2 to ‘int[static 4]’ is null where non-null expected
[-Wnonnull]
7 |   f0 (0, 0);   // warning (good)
  |   ^
a.c:1:6: note: in a call to function ‘f0’
1 | void f0 (int, int a[static 0]); // a must be an array
  |  ^~

See https://gcc.gnu.org/pipermail/gcc/2020-October/234036.html for more
context.

[Bug c/97551] New: ICE: verify_cgraph_node failed with "-O2 -fno-toplevel-reorder -fno-tree-dce -fno-tree-forwprop -fno-tree-fre -fipa-cp-clone"

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 97551
   Summary: ICE: verify_cgraph_node failed with "-O2
-fno-toplevel-reorder -fno-tree-dce -fno-tree-forwprop
-fno-tree-fre -fipa-cp-clone"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
  Target Milestone: ---

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int a=0, b=0;
char c=0;
long d=0;
long (e)(int f, int g) { return f && g || g > 0 && f || f <= 0 && g && f && g <
0 ?  : g; }
void h(int f) {
  for (; c;) {
e(7, d);
for (; a;)
  b = !f;
  }
}
void i() { h(0); }
int main() { return 0; }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/suocy/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/home/suocy/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/suocy/bin/gcc-dev/
--disable-multilib --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201023 (experimental) (GCC)

git version: 43868df37b0e1fa19c32175b41dd7dc1e7c515fd
***
Command Lines:
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O2 -fno-toplevel-reorder
-fno-tree-dce -fno-tree-forwprop -fno-tree-fre -fipa-cp-clone a.c
a.c: In function ‘e’:
a.c:4:35: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
4 | long (e)(int f, int g) { return f && g || g > 0 && f || f <= 0 && g &&
f && g < 0 ?  : g; }
  | ~~^~~~
a.c:4:74: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
4 | long (e)(int f, int g) { return f && g || g > 0 && f || f <= 0 && g &&
f && g < 0 ?  : g; }
  |
~^~~~
a.c:4:86: warning: the omitted middle operand in ‘?:’ will always be ‘true’,
suggest explicit middle operand [-Wparentheses]
4 | long (e)(int f, int g) { return f && g || g > 0 && f || f <= 0 && g &&
f && g < 0 ?  : g; }
  |
 ^
a.c: In function ‘i’:
a.c:12:12: error: edge points to wrong declaration:
   12 | void i() { h(0); }
  |^~~~
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f04246400a8
arg-types 
chain >>
pointer_to_this >
readonly addressable used nothrow static decl_5 QI a.c:4:7 align:8
warn_if_not_align:0 context >
 Instead of: 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7f04244ed738 precision:64 min  max 
pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f042460d2a0
arg-types 
chain 
chain >>>
pointer_to_this >
readonly addressable asm_written used nothrow public static decl_5 QI
a.c:4:7 align:8 warn_if_not_align:0 context  initial 
result 
ignored regdecl DI a.c:4:7 size 
unit-size 
align:64 warn_if_not_align:0 context 
(reg:DI 0 ax [orig:89  ] [89])>
(mem:QI (symbol_ref:DI ("e") [flags 0x3] )
[0  S1 A8]) chain >
h.constprop.0/8 (h.constprop) @0x7f042462c540
  Type: function definition analyzed
  Visibility: no_reorder artificial
  References: d/3 (read) b/1 (write) a/0 (read) c/2 (read)
  Referring:
  Function h.constprop/8 is inline copy in i/6
  Availability: local
  Function flags: count:1073741824 (estimated locally) body local nonfreeing_fn
  Called by: i/6 (inlined) (1073741824 (estimated locally),1.00 per call)
  Calls: e.constprop.0.isra.0/10 (8687547438 (estimated locally),8.09 per call)
during IPA pass: inline
a.c:12:12: internal compiler error: verify_cgraph_node failed
0x9939e0 cgraph_node::verify_node()
../../gcc/cgraph.c:3800
0x9869d4 symtab_node::verify()
../../gcc/symtab.c:1318
0xe490cb expand_call_inline
../../gcc/tree-inline.c:4833
0xe4b9f9 gimple_expand_calls_inline
../../gcc/tree-inline.c:5266
0xe4b9f9 optimize_inline_calls(tree_n

[Bug c++/97550] New: libgcc ICE on x86_64-linux-gnu compiler hosted on msys2

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97550
   Summary: libgcc ICE on x86_64-linux-gnu compiler hosted on
msys2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

during RTL pass: expand
../../../gcc/libgcc/libgcc2.c: In function '__mulxc3':
../../../gcc/libgcc/libgcc2.c:1989:10: internal compiler error: Segmentation
fault
 1989 |   if (isinf (a) || isinf (b))
  |  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See/build-gcc/./gcc/xgcc -B/build-gcc/./gcc/ -B/x86_64-linux/x86_64-linux/bin/
-B/x86_64-linux/x86_64-linux/lib/ -isystem /x86_64-linux/x86_64-linux/include
-isystem /x86_64-linux/x86_64-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _clrsbsi2_s.o -MT
_clrsbsi2_s.o -MD -MP -MF _clrsbsi2_s.dep -DSHARED -DL_clrsbsi2 -c
../../../gcc/libgcc/libgcc2.c
  for instructions.
make[2]: *** [Makefile:507: _mulxc3_s.o] Error 1
make[2]: *** Waiting for unfinished jobs
during RTL pass: expand
../../../gcc/libgcc/libgcc2.c: In function '__divxc3':
../../../gcc/libgcc/libgcc2.c:1950:33: internal compiler error: Segmentation
fault
 1950 | #define COPYSIGNCONCAT2(__builtin_copysign, CEXT)
  | ^
../../../gcc/libgcc/libgcc2.c:1940:25: note: in definition of macro '_CONCAT2'
 1940 | #define _CONCAT2(A,B)   A##B
  | ^
../../../gcc/libgcc/libgcc2.c:1950:25: note: in expansion of macro 'CONCAT2'
 1950 | #define COPYSIGNCONCAT2(__builtin_copysign, CEXT)
  | ^~~
../../../gcc/libgcc/libgcc2.c:2067:15: note: in expansion of macro 'COPYSIGN'
 2067 |   x = COPYSIGN (INFINITY, c) * a;
  |   ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:507: _divxc3_s.o] Error 1
make[2]: Leaving directory '/build-gcc/x86_64-linux/libgcc'
make[1]: *** [Makefile:13415: all-target-libgcc] Error 2
make[1]: Leaving directory '/build-gcc'
make: *** [Makefile:974: all] Error 2

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[vmakarov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to Hongtao.liu from comment #6)
> 
> 
> Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply
> legitimate_address_p?

memory_operand does not imply legitimate_address_p.  When LRA processes regular
memory it calls legitimate_address_p.  But for special memory it did not do
this.  It is a responsibility of special constraint to check it.  That is why
it is called special (it might require more constraints on addressing or hard
registers can be used).  I guess you should check it in the constraint that
base and index registers are of the right class.

[Bug libstdc++/97549] New: include/pstl rebase breaking

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97549
   Summary: include/pstl rebase breaking 
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

I'm seeing compilation errors of a file that just contains:

#include 

following 
* e957b86ca26 2020-10-21 | libstdc++: Rebase include/pstl to current upstream
[Thomas Rodgers]


/data/users/nathans/me/r-e957b86ca26/obj/x86_64/gcc/testsuite/g++/../../xg++
-B/data/users/nathans/me/r-e957b86ca26/obj/x86_64/gcc/testsuite/g++/../../
-g
-I/data/users/nathans/me/r-e957b86ca26/src/gcc/testsuite/../../libsanitizer/include
-fdiagnostics-plain-output  -nostdinc++
-I/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/libsupc++
-I/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/backward
-I/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/testsuite/util
-fmessage-length=0   -O2   
-L/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs

-B/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs

-L/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/./libitm/
-L/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/./libitm/.libs
-lm  -c xtreme-header-2_a.C

In file included from
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/parallel_backend.h:14,
 from
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/algorithm_impl.h:22,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/pstl/glue_execution_defs.h:50,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/execution:32,
 from xtreme-header-2_a.C:5:
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/parallel_backend_serial.h:134:25:
error: '__serial' is not a namespace-name; did you mean '__internal'?
In file included from
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/algorithm_impl.h:22,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/pstl/glue_execution_defs.h:50,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/execution:32,
 from xtreme-header-2_a.C:5:
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/parallel_backend.h:17:43:
error: 'namespace __pstl::__par_backend = __pstl::__pstl::__serial_backend;'
conflicts with a previous declaration
In file included from
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/parallel_backend.h:14,
 from
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/algorithm_impl.h:22,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/pstl/glue_execution_defs.h:50,
 from
/data/users/nathans/me/r-e957b86ca26/obj/x86_64/x86_64-pc-linux-gnu/libstdc++-v3/include/execution:32,
 from xtreme-header-2_a.C:5:
/data/users/nathans/me/r-e957b86ca26/src/libstdc++-v3/include/pstl/parallel_backend_serial.h:132:11:
note: previous declaration 'namespace __pstl::__par_backend { }'

... more errors follow,
it seems parallel_backend.h is being #included twice, with inconsistent
settings of _PSTL_PAR_BACKEND_SERIAL and _PSTL_PAR_BACKEND_TBB

am I missing something?

[Bug c/97548] New: bogus -Wvla-parameter on a bound expression involving a parameter

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97548
   Summary: bogus -Wvla-parameter on a bound expression involving
a parameter
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

>From https://gcc.gnu.org/pipermail/gcc/2020-October/234036.html:

The warning on the redeclaration of g() is a false positive.

$ cat a.c && gcc -S -Wall a.c 
int n;

void f (int, int [n + 1]);
void f (int, int [n + 1]); // ok

void g (int k, int [k + 1]);
void g (int k, int [k + 1]);   // bogus warning
a.c:7:16: warning: argument 2 of type ‘int[k + 1]’ declared with mismatched
bound ‘k + 1’ [-Wvla-parameter]
7 | void g (int k, int [k + 1]);   // bogus warning
  |^~~
a.c:6:16: note: previously declared as ‘int[k + 1]’ with bound ‘k + 1’
6 | void g (int k, int [k + 1]);
  |^~~

The warning code relies on operand_equal_p() to match the bounds.  The function
fails to match the bound expressions because the PARM_DECL referenced in each
is distinct.  The code in operand_compare::operand_equal_p() that fails to
match them is:

case tcc_declaration:
  /* Consider __builtin_sqrt equal to sqrt.  */
  return (TREE_CODE (arg0) == FUNCTION_DECL
  && fndecl_built_in_p (arg0) && fndecl_built_in_p (arg1)
  && DECL_BUILT_IN_CLASS (arg0) == DECL_BUILT_IN_CLASS (arg1)
  && (DECL_UNCHECKED_FUNCTION_CODE (arg0)
  == DECL_UNCHECKED_FUNCTION_CODE (arg1)));

The matching between two expressions will never be perfect but it should work
for the basic cases.

[Bug c++/96742] [10/11 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||erenon2 at gmail dot com

--- Comment #6 from Marek Polacek  ---
*** Bug 97544 has been marked as a duplicate of this bug. ***

[Bug c++/97544] -Wtype-limits triggered for comparison to template argument

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Marek Polacek  ---
Sorry, I'll make sure the warning is suppressed in this case.

*** This bug has been marked as a duplicate of bug 96742 ***

[Bug c++/97544] -Wtype-limits triggered for comparison to template argument

[erenon2 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Benedek Thaler  ---
FTR, Using (N != 0 && i < N) does not silence the warning.
https://gcc.godbolt.org/z/WqaT3G

[Bug fortran/97547] New: How to fix problem causing warning?

[cesces1 at sbcglobal dot net via Gcc-bugs]

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

Bug ID: 97547
   Summary: How to fix problem causing warning?
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesces1 at sbcglobal dot net
  Target Milestone: ---

GNU Fortran (GCC) version 10.2.0 (x86_64-pc-cygwin)
compiled by GNU C version 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.22.1-GMP

warning: MPC header version 1.1.0 differs from library version 1.2.0.

[Bug tree-optimization/97546] [11 Regression][SVE] ICE with -fenable-tree-bswap

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #2)
> Likely find_bswap_or_nop just needs to bail out if !cst_and_fits_in_hwi
> (TYPE_SIZE_UNIT (gimple_expr_type (stmt)))

I'll test a patch to that effect.

[Bug c++/96742] [10/11 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
Oh and since C++17 you can do:

if constexpr (N != 0)
  for (size_t i = 0; i < N; ++i) {
ret += i * x[i];
  }

but it still shouldn't be necessary :-)

[Bug target/97546] [11 Regression][SVE] ICE with -fenable-tree-bswap

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Likely find_bswap_or_nop just needs to bail out if !cst_and_fits_in_hwi
(TYPE_SIZE_UNIT (gimple_expr_type (stmt)))

[Bug c++/96742] [10/11 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to William Throwe from comment #2)
> This warns if passed an array of length 0 because the for-loop condition is
> always false.  Any change I can make to fix it seems to make the code worse.
> I could replace "i < N" with "i + 1 < N + 1", but that certainly doesn't
> make the code clearer (and in similar cases could lead to weird overflow
> bugs).  I can't partially specialize the function, because that's not
> allowed.  I could write an implementation struct and specialize that, but
> that seems like massive overkill when the generic function works fine.

You can use N != 0 && i < N which doesn't have the overflow problem, but I
agree it doesn't make the code clearer, and should not be necessary.

[Bug target/97546] [11 Regression][SVE] ICE with -fenable-tree-bswap

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Target||aarch64
  Known to fail||11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-23
  Known to work||10.2.1
   Keywords||ice-on-valid-code
Summary|[SVE] ICE with  |[11 Regression][SVE] ICE
   |-fenable-tree-bswap |with -fenable-tree-bswap

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. GCC 10 branch doesn't ICE.

[Bug c++/97544] -Wtype-limits triggered for comparison to template argument

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
So it's probably a dup of my bug 96742.

[Bug c++/97544] -Wtype-limits triggered for comparison to template argument

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
It's right, but it's not helpful. There are other instantiations of the
template where the condition isn't always true, and users shouldn't have to
write the condition as (N != 0 && i < N) just to silence this warning.

G++ used to have loads of these warnings in templates, and most of them have
been suppressed because we've usually decided that it's not helpful to warn
about template code where some instantiations result in "always true"
comparisons.

[Bug target/97546] New: [SVE] ICE with -fenable-tree-bswap

[adhemerval.zanella at linaro dot org via Gcc-bugs]

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

Bug ID: 97546
   Summary: [SVE] ICE with -fenable-tree-bswap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adhemerval.zanella at linaro dot org
  Target Milestone: ---

The reduced testcase:

--
#include 

static svbool_t visinf_vo_vf(svfloat32_t d)
{
  return svcmpeq_n_f32 (svptrue_b8 (),
svabs_f32_x (svptrue_b8 (), d),
__builtin_inff ());
}

const svint32_t _ZGVsNxv_ilogbf(svfloat32_t d)
{
  svint32_t e = svreinterpret_s32_f32 (svdup_n_f32 (0.0f));
  e = svsel_s32 (svcmpne_f32 (svptrue_b8(), d, d),
 svdup_n_s32 (2147483647),
 e);
  e = svsel_s32 (visinf_vo_vf (d),
 svdup_n_s32 (0x7fff),
 e);
  return e;
}
--

ICE with gcc with:

$ aarch64-unknown-linux-gnu-gcc -march=armv8.2-a+sve reproducer.c -c -O1
-fenable-tree-bswap
cc1: note: enable pass tree-bswap for functions in the range of [0, 4294967295]
during GIMPLE pass: bswap
reproducer.c: In function ‘_ZGVsNxv_ilogbf’:
reproducer.c:81:17: internal compiler error: tree check: expected integer_cst,
have poly_int_cst in find_bswap_or_nop, at gimple-ssa-store-merging.c:859
   81 | const svint32_t _ZGVsNxv_ilogbf(svfloat32_t d)
  | ^~~
0x692107 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-git-master/gcc/tree.c:9731
0x1849ed3 tree_int_cst_elt_check(tree_node*, int, char const*, int, char
const*)
../../gcc-git-master/gcc/tree.h:3503
0x1849ed3 find_bswap_or_nop
../../gcc-git-master/gcc/gimple-ssa-store-merging.c:859
0x1849ed3 execute
../../gcc-git-master/gcc/gimple-ssa-store-merging.c:1261
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97538] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Aldy Hernandez  ---
Created attachment 49434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49434=edit
proposed patch in testing

Ranger was returning undefined, which caused get_size_range() to use an
uninitialized wide_int.

I am testing the attached patch.

These bug reports have been incredibly useful.  Thanks for reporting them.

[Bug tree-optimization/97545] New: ICE since commit 90e88fd376b and using selective-scheduling2

[stefansf at linux dot ibm.com via Gcc-bugs]

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

Bug ID: 97545
   Summary: ICE since commit 90e88fd376b and using
selective-scheduling2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

Created attachment 49433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49433=edit
reduced failing example

Since commit 90e88fd376b compiling the attached program on S/390 results in:

$ gcc -O3 -fselective-scheduling2 t.i
during RTL pass: sched2
: In function 'main':
:67:1: internal compiler error: Segmentation fault
0x21e3323 crash_signal
/home/stefansf/devel/gcc-2/src/gcc/toplev.c:330
0x171da48 NEXT_INSN(rtx_insn const*)
/home/stefansf/devel/gcc-2/src/gcc/rtl.h:1469
0x28be551 s390_sched_init
/home/stefansf/devel/gcc-2/src/gcc/config/s390/s390.c:15129
0x213c1f7 sel_region_init
/home/stefansf/devel/gcc-2/src/gcc/sel-sched.c:6929
0x213e5d7 sel_sched_region(int)
/home/stefansf/devel/gcc-2/src/gcc/sel-sched.c:7624
0x213e853 run_selective_scheduling()
/home/stefansf/devel/gcc-2/src/gcc/sel-sched.c:7720
0x2104d47 rest_of_handle_sched2
/home/stefansf/devel/gcc-2/src/gcc/sched-rgn.c:3738
0x21050b1 execute
/home/stefansf/devel/gcc-2/src/gcc/sched-rgn.c:3882
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

whereas gcc -O3 -fselective-scheduling2 t.i -fevrp-mode=legacy works fine.

It looks like as if current_sched_info->prev_head gets corrupted at some point.
 Adding a breakpoint prior the ICE and then trying to debug print results in:

(gdb) call debug (current_sched_info->prev_head)
(??? bad code 42405
)

[Bug c++/97544] -Wtype-limits triggered for comparison to template argument

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why do you think the warning is wrong?

[Bug c++/97544] New: -Wtype-limits triggered for comparison to template argument

[erenon2 at gmail dot com via Gcc-bugs]

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

Bug ID: 97544
   Summary: -Wtype-limits triggered for comparison to template
argument
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erenon2 at gmail dot com
  Target Milestone: ---

The following code triggers -Wtype-limits:

template 
constexpr int f(unsigned i)
{
  return (i < N) ? 0 : 1;
}

int main()
{
  return f<0>(1);
}

On GCC 10.2 and trunk, it produces this warning:

: In instantiation of 'constexpr int f(unsigned int) [with unsigned int
N = 0]':
:4:13: warning: comparison of unsigned expression in '< 0' is always
false [-Wtype-limits]

4 |   return (i < N) ? 0 : 1;

  |  ~~~^~~~

On GCC 10.1, there's no warning.
godbolt: https://gcc.godbolt.org/z/cqzq8P

[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
2588   /* For special_memory_operand, there could be a memory operand
inside,
2589  and it would cause a mismatch for constraint_satisfied_p.  */
2590   if (UNARY_P (op) && op == extract_mem_from_operand (op))
2591 op = XEXP (op, 0);

the upper code is supposed to only prevent special_memory_constraint, but
mistakenly handled below insn.

(insn 7 6 10 2 (parallel [
(asm_operands/v ("") ("") 0 [
(not:SI (mem/c:SI (symbol_ref:DI
("mt7615_add_interface_dev_0") [flags 0x2]  ) [1 mt7615_add_interface_dev_0+0 S4 A32]))
]
 [
(asm_input:SI ("rm") test.c:2)
]
 [] test.c:2)
(clobber (reg:CC 17 flags))
]) "test.c":2:18 -1
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Host||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=26778

--- Comment #7 from H.J. Lu  ---
I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=26778

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 49432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49432=edit
a-stzunb.s.xz

The assembly (though, I don't have binutils 2.35.1+ around, so can't verify
easily myself now).

[Bug libgcc/97543] New: powerpc64le: libgcc has unexpected long double in .gnu_attribute

[tuliom at ascii dot art.br via Gcc-bugs]

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

Bug ID: 97543
   Summary: powerpc64le: libgcc has unexpected long double in
.gnu_attribute
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tuliom at ascii dot art.br
  Target Milestone: ---

Alpine Linux uses musl as C Library.
musl only supports long double as IEEE binary64.
It does not support IBM long double.

In this scenario, building gcc with --disable-multilib --with-long-double-64
still creates a libgcc with a .gnu_attribute pointing to IBM long double,
causing unnecessary link time warnings.

Reproduced as:

$ cat test.c
#include 
#include 
int
main()
{
  long double a = 2.0;
  __int128 b = 8;
  printf("sizeof(long double) = %ld\n", sizeof(long double));
  printf("a * b = %Lf\n", a * (long double) b);
  return 0;
}
$ gcc test.c && ./a.out
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccmCAapA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccmCAapA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
sizeof(long double) = 8
a * b = 16.00
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64le-alpine-linux-musl/10.2.0/lto-wrapper
Target: powerpc64le-alpine-linux-musl
Configured with: /home/devel/aports/main/gcc/src/gcc-10.2.0/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=powerpc64le-alpine-linux-musl --host=powerpc64le-alpine-linux-musl
--target=powerpc64le-alpine-linux-musl --with-pkgversion='Alpine 10.2.0'
--enable-checking=release --disable-fixed-point --disable-libstdcxx-pch
--disable-multilib --disable-nls --disable-werror --disable-symvers
--enable-__cxa_atexit --enable-default-pie --enable-default-ssp
--enable-cloog-backend --enable-languages=c,c++,objc,go,fortran,ada
--with-abi=elfv2 --enable-secureplt --enable-decimal-float=no
--enable-targets=powerpcle-linux --with-long-double-64 --disable-libquadmath
--disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer
--enable-shared --enable-threads --enable-tls --with-system-zlib
--with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Alpine 10.2.0)

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[mark at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Mark Wielaard  ---
(In reply to Jakub Jelinek from comment #4)
> # 82 "s-atocou.adb" 1
> isn't a .file assignment though.
> As I said earlier, if we don't want to revert the r11-3693 change and be
> able to specify -gdwarf-5 etc. to gas even when compiling files that contain
> explicit .debug_info from the compiler, then we need gas to act as if all
> that option affects is the version of the .debug_line emitted for explicit
> .file*/.loc* directives if present and nothing else (whenever the assembly
> contains manual
> .file*/.loc* directives or .debug_{info,line,...} sections).

That is the intention indeed, and I believe that is what binutils gas should be
doing. There used to be a bug where that didn't work for .file 1, but I thought
that was fixed upstream. Is this different from
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

The assembly posted doesn't seem complete, what does ada really pass to gas?

>  So, basically,
> gas can start preparing for generation of its own .debug_* sections but
> should roll all that back when it sees .file/.loc directives or user
> .debug_{info,line} sections (perhaps some others).

Like I said above, that is the intention. So if it doesn't work like that it is
simply a bug in gas. It would be helpful to attach the preprocessed file that
ada generates to investigate what is really going on.

> Or, the other option is not to pass -gdwarf-5 to gas, but pass
> -gdwarf-line-version=5 or whatever other new option, which would only change
> the decision on if gas emits .debug_line section because of .file*/.loc*
> directives (and .debug_line is not present), what version of that to use.

That would be another option. But I like to first understand what is really
going on here.

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at redhat dot com|mark at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
# 82 "s-atocou.adb" 1
isn't a .file assignment though.
As I said earlier, if we don't want to revert the r11-3693 change and be able
to specify -gdwarf-5 etc. to gas even when compiling files that contain
explicit .debug_info from the compiler, then we need gas to act as if all that
option affects is the version of the .debug_line emitted for explicit
.file*/.loc* directives if present and nothing else (whenever the assembly
contains manual
.file*/.loc* directives or .debug_{info,line,...} sections).  So, basically,
gas can start preparing for generation of its own .debug_* sections but should
roll all that back when it sees .file/.loc directives or user
.debug_{info,line} sections (perhaps some others).
Or, the other option is not to pass -gdwarf-5 to gas, but pass
-gdwarf-line-version=5 or whatever other new option, which would only change
the decision on if gas emits .debug_line section because of .file*/.loc*
directives (and .debug_line is not present), what version of that to use.

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> So isn't that yet another thing that needs to be changed/fixed in gas?
> Plus on the gcc side add a test for that once it is fixed in binutils?

I think this is a GCC bug.  We can't assign the same file number to different
files:

# 82 "s-atocou.adb" 1
...
.file 1 "a-stzunb.adb"

This seems to be Ada specific.  I can't find a testcase in C nor C++.

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So isn't that yet another thing that needs to be changed/fixed in gas?
Plus on the gcc side add a test for that once it is fixed in binutils?

[Bug libgomp/97542] Enable OpenMP efficient performance profiling via ITT tracing

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||openmp

--- Comment #3 from Richard Biener  ---
Please send patches to gcc-patc...@gcc.gnu.org

[Bug libgomp/97542] Enable OpenMP efficient performance profiling via ITT tracing

[vitaly.slobodskoy at huawei dot com via Gcc-bugs]

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

--- Comment #2 from Vitaly Slobodskoy  ---
Created attachment 49431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49431=edit
Autogenerated files changes

[Bug libgomp/97542] Enable OpenMP efficient performance profiling via ITT tracing

[vitaly.slobodskoy at huawei dot com via Gcc-bugs]

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

--- Comment #1 from Vitaly Slobodskoy  ---
Created attachment 49430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49430=edit
ITT API

[Bug libgomp/97542] New: Enable OpenMP efficient performance profiling via ITT tracing

[vitaly.slobodskoy at huawei dot com via Gcc-bugs]

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

Bug ID: 97542
   Summary: Enable OpenMP efficient performance profiling via ITT
tracing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vitaly.slobodskoy at huawei dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49429=edit
OpenMP runtime changes

In order to optimize OpenMP workloads, it is quite important to have a
dedicated performance analysis tool familiar with the OpenMP runtime specifics.
The typical OpenMP performance issues are:
- Not all the performance-critical code is parallel
  * Serial time significantly affects scaling (Amdahl’s law)
- Work balance is not good
  * Not all the cores doing useful work
- Overhead on
  * Synchronization
  * Scheduling
  * Threads creation

Performance analysis tool should be able to identify serially executed portion
and parallel execution within work-sharing construct. Imbalance within the
parallel region can hardly be calculated without dedicated runtime support.

The proposal is to instrument GCC OpenMP runtime with add ITT API
(https://github.com/intel/ittapi) like it was already done for LLVM
(https://github.com/llvm/llvm-project/tree/master/openmp/runtime/src/thirdparty/ittnotify)
to enable dedicated OpenMP support within the tools like Intel VTune
(https://software.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/methodologies/openmp-code-analysis-method.html)
and others. This would enable "Serial Time", "Parallel Time", "Imbalance Time"
metrics and would allow performance tools to focus on serial or parallel
execution.

ITT is a lightweight API for source-based instrumentation. Open-source part is
simply a set of APIs and single .c file for loading dynamic ITT library
(so-called ITT collector, can be easily created by anyone). In order to enable
tracing, target application needs to be launched under the
"INTEL_LIBITTNOTIFY64=" environment variable. Otherwise all the ITT
calls would do nothing without causing any noticeable runtime overhead.

Attaching the initial proposal for the ITT integration enabling Serial/Parallel
Time metrics:
- core.patch is the actual changes within the OpenMP runtime
- Itt.patch is integration of ITT API (GPLv2 license is used)
- autogenerated.patch - the list of autogenerated files as result of
"autoreconf" launch within libgomp directory

This proposal adds new "--disable-itt-instrumentation" configure option which
completely disables (removes) all the tracing. The tracing is ON by default.
OpenMP Imbalance time calculation is not included in this patch.

[Bug tree-optimization/97539] [10/11 Regression] ICE verify_ssa failed since r10-4200-gb7ff7cef5005721e

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |10.3
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
Mine.

[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
target?

[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-23
 Status|UNCONFIRMED |NEW
 CC||jakub at redhat dot com

--- Comment #1 from H.J. Lu  ---
This is triggered by r11-3693:

commit 6923255e35a3d54f2083ad0f67edebb3f1b86506
Author: Jakub Jelinek 
Date:   Wed Oct 7 10:55:35 2020 +0200

debug: Pass --gdwarf-N to assembler if fixed gas is detected during
configure

[Bug ada/97541] New: Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 97541
   Summary: Ada failed to bootstrap: Error: file table slot 1 is
already occupied by a different file
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

With --gdwarf-4 assembler on Linux/x86-64, I got

$ /export/users/hjl/build/gnu/tools-build/gcc/build-x86_64-linux/./gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc/build-x86_64-linux/./gcc/
-B/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/bin/
-B/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/lib/ -isystem
/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/include -isystem
/usr/gcc-11.0.0-x86-64/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -c -g -O2
-m32  -W -Wall -gnatpg -nostdinc -m32  a-stzunb.adb -c
/tmp/cc6QPugj.s: Assembler messages:
/tmp/cc6QPugj.s:42: Error: file table slot 1 is already occupied by a different
file (/tmp/cc6QPugj.s vs a-stzunb.adb)

Ada generates:

.file   "a-stzunb.adb"
.text
.Ltext0:
.align 2
.p2align 4
.globl  ada__strings__wide_wide_unbounded___size__2
.type   ada__strings__wide_wide_unbounded___size__2, @function
ada__strings__wide_wide_unbounded___size__2:
.LFB5:
.cfi_startproc
movl$64, %eax
xorl%edx, %edx
ret
.cfi_endproc
.LFE5:
.size   ada__strings__wide_wide_unbounded___size__2,
.-ada__strings__wid
e_wide_unbounded___size__2
.align 2
.p2align 4
.globl 
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2
.type  
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2, @function
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA__2:
.LFB12:
.cfi_startproc
movl4(%esp), %eax
movl4(%eax), %eax
#APP
# 82 "s-atocou.adb" 1   File 1
lock incl   4(%eax)
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE12:
.size  
ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA_
_2, .-ada__strings__wide_wide_unbounded__unbounded_wide_wide_stringDA__2
.align 2
.p2align 4
.globl  ada__strings__wide_wide_unbounded__adjust__2
.type   ada__strings__wide_wide_unbounded__adjust__2, @function
ada__strings__wide_wide_unbounded__adjust__2:
.LVL0:
.LFB47:
.file 1 "a-stzunb.adb"  File 1 again
.loc 1 478 4 view -0
.cfi_startproc
.LBB706:
.LBB707:
.LBB708:
.file 2 "s-atocou.adb"

[Bug target/97528] [10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-10-23
 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
A better testcase, using arm_neon.h intrinsics is:
#include 

typedef __simd64_int16_t a;
typedef __simd64_uint16_t b;
unsigned short c;
int d;
b e;
void f() {
  unsigned short *dst = 
  int g = d, bw = 4;
  b dc = e;
  for (int h = 0; h < bw; h++) {
unsigned short *i = dst;
b j = dc;
vst1_s16 ((int16_t *)i, (a) j);
dst += g;
  }
}

I see this ICEing on 9.3.1 as well (GCC 8 branch is ok)

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-10-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
(In reply to Alexandre Oliva from comment #5)
> Created attachment 49427 [details]
> patch that should fix the remaining s390 problem
> 
> So, the issue is already fixed on aarch64-*, powerpc*-*, and
> sparc*-sun-solaris*.
> 
> Stefan, could you possibly confirm that this patch fixes it on s390?

Build is successful on s390. Testsuite still running.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

[aoliva at gcc dot gnu.org via Gcc-bugs]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Alexandre Oliva  ---
Fixed

[Bug rtl-optimization/97535] [9/10/11 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Tamar Christina  ---
Yeah, the overflow in the signed type is causing the number of instructions
guard to fail.

I'll submit a patch.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:9e3b9ddb996f18d541a3e03611d46c3a6c0c0b5f

commit r11-4314-g9e3b9ddb996f18d541a3e03611d46c3a6c0c0b5f
Author: Alexandre Oliva 
Date:   Fri Oct 23 06:37:07 2020 -0300

more wraplf for aux long long float: s390, sparc and powerpc

The wraplf version of Ada.Numerics.Aux_Long_Long_Float is needed on
s390* as well.  Also add it to sparc*-linux-gnu and powerpc-darwin,
that were missed when adding it for sparc and ppc targets.


for  gcc/ada/ChangeLog

PR ada/97504
* Makefile.rtl (LIBGNAT_TARGET_PAIRS): Select wraplf version
of Aux_Long_Long_Float for s390 and remaining sparc and
powerpc targets.

[Bug tree-optimization/97538] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||11.0
  Known to work||10.2.0
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
Summary|ICE in during GIMPLE pass:  |ICE in during GIMPLE pass:
   |wrestrict   |wrestrict since
   ||r11-4135-ge864d395b4e862ce

--- Comment #2 from Martin Liška  ---
Or one can see it with valgrind. Started with r11-4135-ge864d395b4e862ce.

[Bug tree-optimization/97538] ICE in during GIMPLE pass: wrestrict

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Liška  ---
Created attachment 49428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49428=edit
test-case

I see it also on x86_64-linux-gnu with ASAN:

$ /home/marxin/Programming/gcc2/objdir/gcc/xg++ -B
/home/marxin/Programming/gcc2/objdir/gcc/ utf.ii -c -O2
utf.ii: In instantiation of ‘_ForwardIterator
__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, _Tp)
[with _InputIterator = const short unsigned int*; _ForwardIterator = short
unsigned int*; _Tp = _Vector_base::_Vector_impl]’:
utf.ii:128:25:   required from ‘void vector< ,
 >::_M_range_insert(vector< ,
 >::iterator, _ForwardIterator, _ForwardIterator, int)
[with _ForwardIterator = const short unsigned int*;  =
short int;  = short int; vector<
,  >::iterator =
__normal_iterator >]’
utf.ii:105:20:   required from ‘void vector< ,
 >::_M_insert_dispatch(vector<
,  >::iterator, _InputIterator,
_InputIterator, int) [with _InputIterator = const short unsigned int*;
 = short int;  = short int;
vector< ,  >::iterator =
__normal_iterator >]’
utf.ii:99:23:   required from ‘void vector< ,
 >::insert(vector< ,
 >::const_iterator, _InputIterator, _InputIterator)
[with _InputIterator = const short unsigned int*;  =
short int;  = short int; vector<
,  >::const_iterator =
__normal_iterator >]’
utf.ii:150:48:   required from here
utf.ii:67:11: warning: address of local variable ‘__trans_tmp_25’ returned
[-Wreturn-local-addr]
   67 |   return &__trans_tmp_25;
  |   ^~
utf.ii:65:18: note: declared here
   65 |   unsigned short __trans_tmp_25;
  |  ^~
utf.ii: In instantiation of ‘_OI __copy_move_a1(_II, _II, _OI) [with int
 = 0; _II = const short unsigned int*; _OI = short unsigned int*]’:
utf.ii:32:28:   required from ‘void __copy_move_a(_II, _II, _OI) [with int
_IsMove = 0; _II = const short unsigned int*; _OI = short unsigned int*]’
utf.ii:36:47:   required from ‘void copy(_II, _II, _OI) [with _II = const short
unsigned int*; _OI = short unsigned int*]’
utf.ii:66:7:   required from ‘_ForwardIterator
__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, _Tp)
[with _InputIterator = const short unsigned int*; _ForwardIterator = short
unsigned int*; _Tp = _Vector_base::_Vector_impl]’
utf.ii:128:25:   required from ‘void vector< ,
 >::_M_range_insert(vector< ,
 >::iterator, _ForwardIterator, _ForwardIterator, int)
[with _ForwardIterator = const short unsigned int*;  =
short int;  = short int; vector<
,  >::iterator =
__normal_iterator >]’
utf.ii:105:20:   required from ‘void vector< ,
 >::_M_insert_dispatch(vector<
,  >::iterator, _InputIterator,
_InputIterator, int) [with _InputIterator = const short unsigned int*;
 = short int;  = short int;
vector< ,  >::iterator =
__normal_iterator >]’
utf.ii:99:23:   required from ‘void vector< ,
 >::insert(vector< ,
 >::const_iterator, _InputIterator, _InputIterator)
[with _InputIterator = const short unsigned int*;  =
short int;  = short int; vector<
,  >::const_iterator =
__normal_iterator >]’
utf.ii:150:48:   required from here
utf.ii:27:11: warning: address of local variable ‘__trans_tmp_33’ returned
[-Wreturn-local-addr]
   27 |   return &__trans_tmp_33;
  |   ^~
utf.ii:25:18: note: declared here
   25 |   unsigned short __trans_tmp_33;
  |  ^~
=
==636==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffcb78
at pc 0x019f4ab8 bp 0x7fffc380 sp 0x7fffc378
READ of size 8 at 0x7fffcb78 thread T0
#0 0x19f4ab7 in generic_wide_int
>::elt(unsigned int) const ../../gcc/wide-int.h:912
#1 0x3517131 in wide_int_to_tree_1 ../../gcc/tree.c:1532
#2 0x35189de in wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
../../gcc/tree.c:1724
#3 0x1596e31 in get_size_range(range_query*, tree_node*, gimple*,
tree_node**, int) ../../gcc/calls.c:1382
#4 0x1d9becc in builtin_memref ../../gcc/gimple-ssa-warn-restrict.c:259
#5 0x1db412c in check_bounds_or_overlap(range_query*, gimple*, tree_node*,
tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/gimple-ssa-warn-restrict.c:2011
#6 0x1db3f23 in check_call ../../gcc/gimple-ssa-warn-restrict.c:1977
#7 0x1d9b20a in wrestrict_walk ../../gcc/gimple-ssa-warn-restrict.c:93
#8 0x1d9b41d in execute ../../gcc/gimple-ssa-warn-restrict.c:103
#9 0x25a938a in execute_one_pass(opt_pass*) ../../gcc/passes.c:2517
#10 0x25a9c40 in execute_pass_list_1 ../../gcc/passes.c:2605
#11 0x25a9cbb in execute_pass_list_1 ../../gcc/passes.c:2606
#12 0x25a9d5f in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2616
#13 0x1732da9 in cgraph_node::expand() ../../gcc/cgraphunit.c:2310
#14 0x1734080 in expand_all_functions ../../gcc/cgraphunit.c:2478
#15 0x17360dd in symbol_table::compile() ../../gcc/cgraphunit.c:2842

[Bug preprocessor/97537] gcc -H Option Issue, incomplete dependency tree listing

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Oh sorry, I misread your example. The second #include "header3.h" is indeed
reached. The header is skipped due to the optimization described at
https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html so the second include
is skipped and the file doesn't get reopened. I suppose that's the cause:
because the file is skipped, it isn't considered "used" again.

So I think I agree with your bug report, the output should not be affected by
the optimization, and header3.h should be considered "used" again, even if it
isn't actually opened again.

[Bug preprocessor/97537] gcc -H Option Issue, incomplete dependency tree listing

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
But the compiler never sees that #include, because it's guarded by the #ifndef

The -H option is not a general purpose dependency scanner, it just shows the
result of preprocessing. The documentation is clear:

"Print the name of each header file used, in addition to other normal
activities."

It prints the names of the headers USED, i.e. actually included, not a complete
graph of all possible paths that could be taken (which could easily lead to
cycles). The file header3.h is only used once, because there is only one
#include naming it which is actually processed.

I think this is invalid, the option is working exactly as intended and as
documented.

[Bug tree-optimization/97539] [10/11 Regression] ICE verify_ssa failed since r10-4200-gb7ff7cef5005721e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||10.2.0, 11.0
   Last reconfirmed||2020-10-23
  Component|c   |tree-optimization
  Known to work||9.3.0
 Ever confirmed|0   |1
Summary|error: definition in block  |[10/11 Regression] ICE
   |5 does not dominate use in  |verify_ssa failed since
   |block 24|r10-4200-gb7ff7cef5005721e
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r10-4200-gb7ff7cef5005721e with -fno-finite-loops.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[ams at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from Andrew Stubbs  ---
(In reply to Andrew Stubbs from comment #21)
> (In reply to Richard Biener from comment #19)
> > GCN also uses MODE_INT for the mask mode and thus may be similarly affected.
> > Andrew - are the bits in the mask dense?  Thus for a V4SImode compare
> > would the mask occupy only the lowest 4 bits of the DImode mask?
> 
> Yes, that's correct.

Or rather, I should say that that *will* be the case when I add partial vector
support; right now it can only be done via masking V64SImode.

A have a patch set, but the last problem is that while_ult doesn't operate on
partial integer masks, leading to wrong code. AArch64 doesn't have a problem
with this because it uses VBI masks of the right size. I have a patch that adds
the vector size as an operand to while_ult; this seems to fix the problems on
GCN, but I need to make corresponding changes for AArch64 also before I can
submit those patches, and time is tight.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[ams at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from Andrew Stubbs  ---
(In reply to Richard Biener from comment #19)
> GCN also uses MODE_INT for the mask mode and thus may be similarly affected.
> Andrew - are the bits in the mask dense?  Thus for a V4SImode compare
> would the mask occupy only the lowest 4 bits of the DImode mask?

Yes, that's correct.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #7)
> memory_operand calls general_operand which for MEM does:
>   /* Use the mem's mode, since it will be reloaded thus.  LRA can
>  generate move insn with invalid addresses which is made valid
>  and efficiently calculated by LRA through further numerous
>  transformations.  */
>   if (lra_in_progress
>   || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE
> (op)))
> return 1;
> So, during LRA it accepts anything, and at the end of LRA it ICEs because it
> isn't recognized.
> So, I think LRA needs to know somewhere what is the address operand of the
> MEM even inside of the bcst_mem_operand and know that it should fix it up.

Yes, and i saw at least two places needed to be adjusted.

First in process_address_1 (int nop, bool check_only_p,
---
3430   /* Do not attempt to decompose arbitrary addresses generated by combine
3431  for asm operands with loose constraints, e.g 'X'.  */
3432   else if (MEM_P (op)  ---> Here!!!
3433&& !(INSN_CODE (curr_insn) < 0
3434 && get_constraint_type (cn) == CT_FIXED_FORM
3435 && constraint_satisfied_p (op, cn)))
3436 decompose_mem_address (, op);
3437   else if (GET_CODE (op) == SUBREG
3438&& MEM_P (SUBREG_REG (op)))
3439 decompose_mem_address (, SUBREG_REG (op));
3440   else
3441 return false;
---

Then in valid_address_p which would be called in process_address_1
---
 398 /* Return true if the eliminated form of AD is a legitimate target
address.
 399If OP is a MEM, AD is the address within OP, otherwise OP should be
 400ignored.  CONSTRAINT is one constraint that the operand may need
 401to meet.  */
 402 static bool
 403 valid_address_p (rtx op, struct address_info *ad,
 404  enum constraint_num constraint)
 405 {
 406   address_eliminator eliminator (ad);
 407 
 408   /* Allow a memory OP if it matches CONSTRAINT, even if CONSTRAINT is
more
 409  forgiving than "m".  */
 410   if (MEM_P (op) ---> Here.
 411   && (insn_extra_memory_constraint (constraint)
 412   || insn_extra_special_memory_constraint (constraint))
 413   && constraint_satisfied_p (op, constraint))
 414 return true;
 415 
 416   return valid_address_p (ad->mode, *ad->outer, ad->as);
 417 }
---

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:50bc94898fac1bd9cc1dabf227208fb5d369c4c4

commit r11-4282-g50bc94898fac1bd9cc1dabf227208fb5d369c4c4
Author: Jakub Jelinek 
Date:   Fri Oct 23 10:05:17 2020 +0200

stor-layout: Reject forming arrays with elt sizes not divisible by elt
alignment [PR97164]

As mentioned in the PR, since 2005 we reject if array elements are smaller
than their alignment (i.e. overaligned elements), because such arrays don't
make much sense, only their first element is guaranteed to be aligned as
user requested, but the next element can't be.
The following testcases show something we've been silent about but is
equally bad, the 2005 case is just the most common special case of that
the array element size is not divisible by the alignment.  In those arrays
too only the first element is guaranteed to be properly aligned and the
second one can't be.

This patch rejects those cases too, but keeps the existing wording for the
old common case.

Unfortunately, the patch breaks bootstrap, because libbid uses this mess
(forms arrays with 24 byte long elements with 16 byte element alignment).
I don't really see justification for that, so I've decreased the alignment
to 8 bytes instead.

2020-10-23  Jakub Jelinek  

PR tree-optimization/97164
gcc/
* stor-layout.c (layout_type): Also reject arrays where element
size
is constant, but not a multiple of element alignment.
gcc/testsuite/
* c-c++-common/pr97164.c: New test.
* gcc.c-torture/execute/pr36093.c: Move ...
* gcc.dg/pr36093.c: ... here.  Add dg-do compile and dg-error
directives.
* gcc.c-torture/execute/pr43783.c: Move ...
* gcc.dg/pr43783.c: ... here.  Add dg-do compile, dg-options and
dg-error directives.
libgcc/config/libbid/
* bid_functions.h (UINT192): Decrease alignment to 8 bytes.

[Bug rtl-optimization/97535] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

[icenowy at aosc dot io via Gcc-bugs]

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

--- Comment #3 from Icenowy Zheng  ---
A minimal reproduction: (Compile with gcc -c -O1)

```
#include 

#define SIZE 2181038080

extern char raw_buffer[SIZE];

void setRaw(const void *raw)
{
memcpy(raw_buffer, raw, SIZE);
}
```

[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
  Known to work||10.2.0
   Last reconfirmed||2020-10-23
  Known to fail||11.0

[Bug rtl-optimization/97540] New: [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97540
   Summary: [11 Regression] ICE in lra_set_insn_recog_data, at
lra.c:1004 since r11-4202-g4de7b010038933dd
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---

The following fails, it's reduced from linux kernel:

$ cat mediatek.i
int mt7615_add_interface_dev_0;
int ffs(int x) { asm("" : : "rm"(x)); }
int mt7615_add_interface() { ffs(~mt7615_add_interface_dev_0); }

$ gcc mediatek.i -c -O2
during RTL pass: reload
mediatek.i: In function ‘mt7615_add_interface’:
mediatek.i:3:64: internal compiler error: in lra_set_insn_recog_data, at
lra.c:1004
3 | int mt7615_add_interface() { ffs(~mt7615_add_interface_dev_0); }
  |^
0x6a2457 lra_set_insn_recog_data(rtx_insn*)
/home/marxin/Programming/gcc/gcc/lra.c:1004
0xc2434f lra_get_insn_recog_data
/home/marxin/Programming/gcc/gcc/lra-int.h:488
0xc2434f remove_scratches_1
/home/marxin/Programming/gcc/gcc/lra.c:2064
0xc244a3 lra_emit_move(rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/lra.c:506
0xc368c6 curr_insn_transform
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4523
0xc37db6 lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:5123
0xc24d8c lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2415
0xbe0171 do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5529
0xbe0171 execute
/home/marxin/Programming/gcc/gcc/ira.c:5715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||11.0
 Resolution|--- |FIXED
  Known to fail||10.2.0

--- Comment #9 from Martin Liška  ---
Fixed, not planning to backport it.

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:6fade5a6044b7102758f4ca66c8715ebc12a6306

commit r11-4279-g6fade5a6044b7102758f4ca66c8715ebc12a6306
Author: Martin Liska 
Date:   Thu Oct 22 14:07:29 2020 +0200

LTO: check that make command works

gcc/ChangeLog:

PR lto/97524
* lto-wrapper.c (make_exists): New function.
(run_gcc): Use it to check that make is present and working
for parallel execution.

[Bug rtl-optimization/97535] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-10-23
   Keywords||needs-reduction
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
Confirmed. I'm reducing that right now.

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
memory_operand calls general_operand which for MEM does:
  /* Use the mem's mode, since it will be reloaded thus.  LRA can
 generate move insn with invalid addresses which is made valid
 and efficiently calculated by LRA through further numerous
 transformations.  */
  if (lra_in_progress
  || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE
(op)))
return 1;
So, during LRA it accepts anything, and at the end of LRA it ICEs because it
isn't recognized.
So, I think LRA needs to know somewhere what is the address operand of the MEM
even inside of the bcst_mem_operand and know that it should fix it up.

[Bug c/97539] New: error: definition in block 5 does not dominate use in block 24

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97539
   Summary: error: definition in block 5 does not dominate use in
block 24
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int a, b;
void c() {
  char d;
  for (; b;)
for (;;)
  for (; d <= 7; d += 1) {
a = 7;
for (; a; a += 1)
e:
  d += d;
d ^= 0;
  }
  goto e;
}

compiled by -g and -O3 on recent gcc trunk, does this:

$ /home/dcb/gcc/results/bin/gcc -c -g -O3 bug658.c
bug658.c: In function ‘c’:
bug658.c:2:6: error: definition in block 5 does not dominate use in block 24
2 | void c() {
  |  ^
for SSA_NAME: d_20 in statement:
# DEBUG d => d_20
during GIMPLE pass: vect
bug658.c:2:6: internal compiler error: verify_ssa failed
0xf0c686 verify_ssa(bool, bool)
../../trunk.git/gcc/tree-ssa.c:1208
0xbd5d01 execute_function_todo(function*, void*)
../../trunk.git/gcc/passes.c:1999

The bug seems to have appeared sometime before 20200923.

[Bug tree-optimization/97538] ICE in during GIMPLE pass: wrestrict

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug tree-optimization/97538] New: ICE in during GIMPLE pass: wrestrict

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97538
   Summary: ICE in during GIMPLE pass: wrestrict
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-linux-gnu

The following fails with a cross compiler:

$ cat restrict.C
void *b, *c;
struct H {
  virtual bool accept(const char *, unsigned long, int *, bool);
};
char accept_bt[1], accept_cd[1];
int accept_cb;
bool accept_cb_0;
class t : H {
  bool accept(const char *, unsigned long bd, int *bg, bool) {
long bu = sizeof(int) + bd;
char *bw = bu > sizeof(accept_bt) ? new char : accept_bt,
 *cf = bd ? new char : accept_cd;
__builtin___memcpy_chk(b, c, bd, 0);
if (bw != accept_bt)
  delete bw;
bool ci = cj((int *)cf, bg), atran = bp && accept_cb_0;
atran & &(_cb);
  }
  bool cj(int *, int *);
  bool cm(int *);
  bool bp;
};
void bj() { new t; }

$ ~/BIG/bin/aarch64/dev/shm/buildbot/install/gcc/bin/aarch64-linux-gnu-gcc
restrict.C -fno-guess-branch-probability -fno-tree-pta -O1 -c
restrict.C: In member function ‘virtual bool t::accept(const char*, long
unsigned int, int*, bool)’:
restrict.C:18:3: warning: no return statement in function returning non-void
[-Wreturn-type]
   18 |   }
  |   ^
during GIMPLE pass: wrestrict
restrict.C:9:8: internal compiler error: Segmentation fault
9 |   bool accept(const char *, unsigned long bd, int *bg, bool) {
  |^~
0xcc48bf crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:330
0x776ae6bf ???
   
/usr/src/debug/glibc-2.32-1.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xf85dc7 wi::force_to_size(long*, long const*, unsigned int, unsigned int,
unsigned int, signop)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/wide-int.cc:369
0xf3094e wide_int_storage::from(generic_wide_int > const&, unsigned int, signop)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/wide-int.h:1172
0xf3094e wide_int_to_tree_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree.c:1538
0x8d402d get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/calls.c:1383
0xa68ce0 builtin_memref
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/gimple-ssa-warn-restrict.c:259
0xa6c5e7 check_bounds_or_overlap(range_query*, gimple*, tree_node*, tree_node*,
tree_node*, tree_node*, bool, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/gimple-ssa-warn-restrict.c:2011
0xa6f70b check_call
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/gimple-ssa-warn-restrict.c:1977
0xa6f70b wrestrict_walk
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/gimple-ssa-warn-restrict.c:93
0xa6f70b execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/gimple-ssa-warn-restrict.c:103
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Can't reproduce with a cross-compiler.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Richard Biener  ---
So at least the tree.c use of get_mask_mode only passes it MODE_VECTOR so
we don't have to second-guess the component size when passed a MODE_INT used
as representation for an integer vector type.

So I'm testing the following

tree
build_truth_vector_type_for_mode (poly_uint64 nunits, machine_mode mask_mode)
{
  gcc_assert (mask_mode != BLKmode);

  unsigned HOST_WIDE_INT esize;
  if (VECTOR_MODE_P (mask_mode))
{
  poly_uint64 vsize = GET_MODE_BITSIZE (mask_mode);
  esize = vector_element_size (vsize, nunits);
}
  else
esize = 1;

  tree bool_type = build_nonstandard_boolean_type (esize);

  return make_vector_type (bool_type, nunits, mask_mode);
}

[Bug lto/97524] Compiling with -flto=auto fails in make is not installed

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Martin Liška  ---
(In reply to Tom Stellard from comment #6)
> If I have make installed on my system, but am using something else (e.g.
> ninja) to build my project, will I still get parallel execution?

No, we construct an artificial Make file that we pass to make.
Anyway, a system w/o make is quite awkward, it's such an essential tool :)

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #19 from Richard Biener  ---
GCN also uses MODE_INT for the mask mode and thus may be similarly affected.
Andrew - are the bits in the mask dense?  Thus for a V4SImode compare
would the mask occupy only the lowest 4 bits of the DImode mask?

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Richard Biener  ---
Maybe the x86 backend should use partial integer modes here (though we'd have
quite some, eventually not even possible), so the mask mode precision would
tell us how to build the types.  Or the targetm.vectorize.get_mask_mode
needs to be amended to return the number of bits used per lane.

So the following "works" for the testcase in this bug and the FAILs reported
but of course breaks the non-AVX512 case because we cannot distinguish
between integer mode vectors and integer mode masks :/  The target hook
docs leave the option to return no mask mode but the default implementation
would already always return an integer vector mode if it exists.

So given that changing x86 to use MODE_VECTOR_BOOL is unlikely we need a way
to distinguish MODE_INT vectors from MODE_INT vector bools, thus, the target
needs to tell us the precision of the elements.

diff --git a/gcc/expr.c b/gcc/expr.c
index 9d951e82522..ae16f077758 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -10356,16 +10355,10 @@ expand_expr_real_1 (tree exp, rtx target,
machine_mode tmode,
scalar_int_mode int_mode;
if (is_int_mode (mode, _mode))
  {
-   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
- return const_scalar_mask_from_tree (int_mode, exp);
-   else
- {
-   tree type_for_mode
- = lang_hooks.types.type_for_mode (int_mode, 1);
-   if (type_for_mode)
- tmp = fold_unary_loc (loc, VIEW_CONVERT_EXPR,
-   type_for_mode, exp);
- }
+   tree type_for_mode = lang_hooks.types.type_for_mode (int_mode, 1);
+   if (type_for_mode)
+ tmp = fold_unary_loc (loc, VIEW_CONVERT_EXPR,
+   type_for_mode, exp);
  }
if (!tmp)
  {
diff --git a/gcc/tree.c b/gcc/tree.c
index 555ba97e68b..608f124 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -10926,9 +10926,7 @@ build_truth_vector_type_for_mode (poly_uint64 nunits,
machine_mode mask_mode)
 {
   gcc_assert (mask_mode != BLKmode);

-  poly_uint64 vsize = GET_MODE_BITSIZE (mask_mode);
-  unsigned HOST_WIDE_INT esize = vector_element_size (vsize, nunits);
-  tree bool_type = build_nonstandard_boolean_type (esize);
+  tree bool_type = build_nonstandard_boolean_type (1);

   return make_vector_type (bool_type, nunits, mask_mode);
 }

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:7cda498920dbf244e9e06fdb2fc710a118a8c033

commit r11-4278-g7cda498920dbf244e9e06fdb2fc710a118a8c033
Author: Richard Biener 
Date:   Fri Oct 23 08:21:39 2020 +0200

Revert "middle-end/97521 - fix VECTOR_CST expansion"

2020-10-23  Richard Biener  

PR middle-end/97521
* expr.c (expand_expr_real_1): Revert last change.

* gcc.target/i386/pr97521.c: Remove.
This reverts commit b960a9c83a93b58a84a7a370002990810675ac5d.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

[aoliva at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 49427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49427=edit
patch that should fix the remaining s390 problem

So, the issue is already fixed on aarch64-*, powerpc*-*, and
sparc*-sun-solaris*.

Stefan, could you possibly confirm that this patch fixes it on s390?

I've put in the fix for sparc*-linux-gnu as well, for good measure.

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Richard Biener  ---
(In reply to Richard Biener from comment #15)
> CI with -march=cascadelake reports
> 
..
> FAIL: gcc.target/i386/avx2-vpcmpeqq-2.c execution test

expands

(gdb) p debug_tree (exp)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7683a348 precision:2 min  max >
QI size  unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7683a3f0 nunits:4>
constant tree_0 npatterns:2 nelts-per-pattern:2
elt:0:  
constant 0>
elt:1:  
constant -1> elt:2:   elt:3:  >

which shows the heuristic cannot work.  We possibly can refine it to
key on mode-precision component types - which _might_ work since it seems
x86 uses the smallest integer mode to hold nunits bits - but that's of course
not something guaranteed for non-x86.

I wonder why we're insisting to "fill" the mask mode on GENERIC/GIMPLE
while RTL produces packed bits.  Thus, why do we use a
QImode vector(4)  here instead of a
QImode vector(4)  if the target in the end will produce that
from say, a V4SImode compare-to-mask?  As long as we didn't expose
temporaries of those types this was well-hidden up to RTL expansion which
then did "magic" but now we're really facing inconsistent representations.

Now targets _could_ opt to use QImode vector(4)  but then
with representing { -1, -1, -1, -1 } as 0b (with the 'padding bits'
sign-extended).

For now I'm going to revert the patch but I still believe
const_scalar_mask_from_tree is a red herring.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

[aoliva at gcc dot gnu.org via Gcc-bugs]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Alexandre Oliva  ---
Mine

[Bug c++/97533] ICE encountering operator() within lambda expression within templated struct

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from Richard Biener  ---
clang rejects it

[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug target/97521] [11 Regression] wrong code with -mno-sse2 since r11-3394

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #15 from Richard Biener  ---
CI with -march=cascadelake reports

FAIL: c-c++-common/torture/vector-compare-2.c   -O0  execution test
FAIL: gcc.target/i386/avx2-vpcmpeqq-2.c execution test
FAIL: gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
FAIL: gfortran.dg/bound_6.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/bound_6.f90   -O3 -g  execution test