[Bug rtl-optimization/100263] [11/12 Regression] RTL optimizers miscompile loop

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
You are right. I got lured by the fact that the assignments c__lsm.20_94 = 1;
and c__lsm_flag.21_95 = 1; of bb5 are "moved" into the PHI as e.g.

   # c__lsm.20_51 = PHI 
   # c__lsm_flag.21_53 = PHI 

I will have a look at the RTL output then.

[Bug c++/100279] [ICE in trunk] ICE caused by negative double NTTP. Error: Two symbols with same comdat_group are not linked by the same_comdat_group list.

[bobmiller at nvidia dot com via Gcc-bugs]

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

--- Comment #3 from Bob Miller  ---
Further minimized example. Same ICE. 
ICE is visible here: https://godbolt.org/z/o7M9nYYYE

template struct T {};

template
void f(T) {}

int main(int, char**) 
{
f(T<-1.0>{});
f(T<-2.0>{});
return 0;
}

[Bug c++/100279] Invalid generated assembly for NTTP lambda with negative double value

[bobmiller at nvidia dot com via Gcc-bugs]

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

--- Comment #2 from Bob Miller  ---
In further minifying this example, I've discovered a related ICE. The ICE can
be seen on godbolt here: https://godbolt.org/z/vxzG1zMjo

I've attached a new preprocessed file that triggers the ICE. Code is as
follows:

template struct T {};

template
void f(T) {}

template
void E()
{
f(T{});
f(T{});
}

void foo()
{
E<-1.0, -2.0>();
}

int main(int, char**) {return 0;}

New example's error output:

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20210426/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210425 (experimental) (Compiler-Explorer-Build) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-std=c++20' '-v' '-save-temps' '-Wall' '-Wextra'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-trunk-20210426/bin/../libexec/gcc/x86_64-linux-gnu/12.0.0/cc1plus
-E -quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/
-D_GNU_SOURCE  -masm=intel -mtune=generic -march=x86-64 -std=c++20
-Wall -Wextra -fdiagnostics-color=always -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -g -fworking-directory -fpch-preprocess -o
/app/output.ii
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0

/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/backward

/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/include

/opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/x86_64-linux-gnu/12.0.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-trunk-20210426/bin/../lib/gcc/../../include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-std=c++20' '-v' '-save-temps' '-Wall' '-Wextra'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-trunk-20210426/bin/../libexec/gcc/x86_64-linux-gnu/12.0.0/cc1plus
-fpreprocessed /app/output.ii -quiet -dumpdir /app/ -dumpbase output.cpp
-dumpbase-ext .cpp -masm=intel -mtune=generic -march=x86-64 -g -Wall -Wextra
-std=c++20 -version -fdiagnostics-color=always -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -o /app/output.s
GNU C++20 (Compiler-Explorer-Build) version 12.0.0 20210425 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heap

[Bug c++/100279] Invalid generated assembly for NTTP lambda with negative double value

[bobmiller at nvidia dot com via Gcc-bugs]

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

--- Comment #1 from Bob Miller  ---
Created attachment 50684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50684=edit
New preprocessed source for more minimal example. This one leads to an ICE on
godbolt's GCC version.

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:a633f7f96daac391fe0bc5d87427c0e7cf1ab1b3

commit r10-9772-ga633f7f96daac391fe0bc5d87427c0e7cf1ab1b3
Author: Michael Meissner 
Date:   Mon Apr 26 22:45:02 2021 -0400

[PATCH] Backport fix for PR target/98952

The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
if the trampoline size is greater than the expected size.  It should abort
when the trampoline size is less than the expected size.  I fixed the test
so the operands are reversed.  I then folded the load immediate into the
compare instruction.

I verified this by creating a 32-bit trampoline program and manually
changing the size of the trampoline to be 48 instead of 40.  The program
aborted with the larger size.  I updated this code and ran the test again
and it passed.

I added a test case that runs on PowerPC 32-bit Linux systems and it calls
the __trampoline_setup function with a larger buffer size than the
compiler uses.  The test is not run on 64-bit systems, since the function
__trampoline_setup is not called.  I also limited the test to just Linux
systems, in case trampolines are handled differently in other systems.

libgcc/
2021-04-26  Michael Meissner  

PR target/98952
* config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix
trampoline size comparison in 32-bit by reversing test and
combining load immediate with compare.  Fix backported from trunk
change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.
(__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison
in 32-bit by reversing test and combining load immediate with
compare.

gcc/testsuite/
2021-04-26  Michael Meissner  

PR target/98952
* gcc.target/powerpc/pr98952.c: New test.  Test backported from
trunk change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.

[Bug c++/97420] [8/9/10/11/12 Regression] NTTP function reference cannot bind to noexcept function

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||10.3.0, 11.0, 8.4.0, 9.3.0
   Target Milestone|--- |8.5
 CC||ppalka at gcc dot gnu.org
  Known to work||7.5.0
Summary|NTTP function reference |[8/9/10/11/12 Regression]
   |cannot bind to noexcept |NTTP function reference
   |function|cannot bind to noexcept
   ||function

--- Comment #3 from Patrick Palka  ---
We started to reject the testcase in comment #2 (with -std=c++17) after
r8-1259.

[Bug c++/100240] Compiler crashes with segmentation fault on a chrono library using nvcc

[taraba.peter at mail dot com via Gcc-bugs]

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

--- Comment #8 from Peter Taraba  ---
So, this is happening also with gcc11:

pepe@pepe-MS-7C90:~/code/DeeperThought$ ./compile.sh 
/usr/include/c++/10/chrono: In substitution of ‘template template using __is_harmonic =
std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))),
((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den,
_Period::den)) * (_Period::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 =
_Period2; _Rep = _Rep; _Period = _Period]’:
/usr/include/c++/10/chrono:473:154:   required from here
/usr/include/c++/10/chrono:428:27: internal compiler error: Segmentation fault
  428 |  _S_gcd(intmax_t __m, intmax_t __n) noexcept
  |   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
pepe@pepe-MS-7C90:~/code/DeeperThought$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11-20210417-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-pzZXCn/gcc-11-11-20210417/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-pzZXCn/gcc-11-11-20210417/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210417 (experimental) [master revision
c1c86ab96c2:b6fb0ccbb48:8ae884c09fbba91e9cec391290ee4a2859e7ff41] (Ubuntu
11-20210417-1ubuntu1)

[Bug c++/100279] New: Invalid generated assembly for NTTP lambda with negative double value

[bobmiller at nvidia dot com via Gcc-bugs]

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

Bug ID: 100279
   Summary: Invalid generated assembly for NTTP lambda with
negative double value
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobmiller at nvidia dot com
  Target Milestone: ---

Created attachment 50683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50683=edit
The preprocessed file that triggers the bug

I've stumbled across an obscure behavior that results in incorrect assembly
generation: the same signature is generated twice, which the assembler later
(correctly) rejects. I've tested this on GCC-11 and trunk, on my own machine
and godbolt ( example here: https://godbolt.org/z/6eEnKca9o )

Minimal example: 

template struct T {};

template void E(F &&) {}

template
void E(F &)
{
f(T{});
E(f);
}

void foo()
{
E<-1.0, -2.0>(
[&](T){});
}

int main(int, char**) {}
--

Interestingly, this does NOT occur for floats or long doubles: only doubles:
changing the suffixes of -1.0 and -2.0 above to -1.0f and -2.0f (or -1.0L and
-2.0L) results in valid generated code.

--
Output from gcc -v:

COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/home/bob/libexec/gcc/x86_64-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc/configure -v --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --prefix=/home/bob/
--enable-checking=release --enable-languages=c,c++ --disable-multilib
--program-suffix=-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210426 (experimental) (GCC) 


Command line to trigger bug: g++-11 --std=c++20 bugtest.cpp -o test

Compiler output:
/tmp/ccmrd0Wr.s: Assembler messages:
/tmp/ccmrd0Wr.s:106: Error: symbol
`_ZZ3foovENKUl1TIXT_EEE_clILdEEEDaS0_' is already defined

[Bug middle-end/100278] New: IBM Z: Segmentation fault when building valgrind with -march=z14

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

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

Bug ID: 100278
   Summary: IBM Z: Segmentation fault when building valgrind with
-march=z14
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iii at linux dot ibm.com
  Target Milestone: ---

Minimized test:

$ cat test.c
a() {
  register b asm("");
  if (b)
b = 1;
  for (; b;)
;
}

$ $HOME/gcc/build/dist/bin/gcc -m64 -O2 -g -finline-functions
-fno-stack-protector -fno-builtin -fomit-frame-pointer -fstrict-aliasing
-march=z14 -c test.c
test.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() {
  | ^
test.c: In function ‘a’:
test.c:2:12: warning: type defaults to ‘int’ in declaration of ‘b’
[-Wimplicit-int]
2 |   register b asm("");
  |^
during GIMPLE pass: pre
test.c:1:1: internal compiler error: Segmentation fault
1 | a() {
  | ^
0x1a33499 crash_signal
../../gcc/toplev.c:327
0x11e9bf2 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3466
0x1c57673 compute_avail
../../gcc/tree-ssa-pre.c:4163
0x1c580d9 execute
../../gcc/tree-ssa-pre.c:4370

Bisect points to:

commit 577d05fc914338cd7ddc254f3bee4532331f5c13
Author: Richard Biener 
Date:   Tue Mar 9 09:29:29 2021 +0100

tree-optimization/99473 - more cselim

[Bug c++/100277] New: ICE on cuda host code

[bowie.owens at gmail dot com via Gcc-bugs]

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

Bug ID: 100277
   Summary: ICE on cuda host code
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bowie.owens at gmail dot com
  Target Milestone: ---

The attached code to be compiled by the host compiler (g++) after processing by
the nvidia cuda compiler works with g++ 9.x but with 10.3.0 terminates with an
Internal Compiler Error.

Version information:

g++ -v
Using built-in specs.
COLLECT_GCC=/software/gcc/10.3.0/bin/g++
COLLECT_LTO_WRAPPER=/software/gcc/10.3.0/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.3.0/configure --prefix=/software/gcc/10.3.0
--enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC)


g++ -c -std=c++17 tmpxft_555d_-6_middlegame.cudafe1.ii

Generates console output of:

/software/gcc/10.3.0/include/c++/10.3.0/chrono: In substitution of
'template template using
__is_harmonic = std::__bool_constant<(std::ratio<((_Period2::num /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num, _Period::num)) *
(_Period::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den,
_Period::den))), ((_Period2::den / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::den, _Period::den)) * (_Period::num /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num,
_Period::num)))>::den == 1)> [with _Period2 = _Period2; _Rep = _Rep; _Period =
_Period]':
/software/gcc/10.3.0/include/c++/10.3.0/chrono:473:153:   required from here
/software/gcc/10.3.0/include/c++/10.3.0/chrono:428:27: internal compiler error:
Segmentation fault
  428 |  _S_gcd(intmax_t __m, intmax_t __n) noexcept
  |   ^~
0xc2be6f crash_signal
../../gcc-10.3.0/gcc/toplev.c:328
0x7233ad tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-10.3.0/gcc/cp/pt.c:15310
0x7363b6 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc-10.3.0/gcc/cp/pt.c:13225
0x72eda6 tsubst_aggr_type
../../gcc-10.3.0/gcc/cp/pt.c:13428
0x73909f tsubst_function_decl
../../gcc-10.3.0/gcc/cp/pt.c:13816
0x72fa49 tsubst_decl
../../gcc-10.3.0/gcc/cp/pt.c:14267
0x71da31 tsubst_copy
../../gcc-10.3.0/gcc/cp/pt.c:16512
0x72132a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:20707
0x71fe86 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19274
0x71fe86 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19896
0x71f2bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19274
0x71f2bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19588
0x71f286 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19274
0x71f286 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19587
0x731864 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19274
0x731864 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-10.3.0/gcc/cp/pt.c:18886
0x7363b6 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc-10.3.0/gcc/cp/pt.c:13225
0x72eda6 tsubst_aggr_type
../../gcc-10.3.0/gcc/cp/pt.c:13428
0x71eca7 tsubst_qualified_id
../../gcc-10.3.0/gcc/cp/pt.c:16215
0x7209cd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-10.3.0/gcc/cp/pt.c:19625
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:39f46514ca8a78a0fc2e1e0a73d0934fe515a78d

commit r9-9467-g39f46514ca8a78a0fc2e1e0a73d0934fe515a78d
Author: Michael Meissner 
Date:   Mon Apr 26 19:58:45 2021 -0400

[PATCH] Backport fix for PR target/98952

The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
if the trampoline size is greater than the expected size.  It should abort
when the trampoline size is less than the expected size.  I fixed the test
so the operands are reversed.  I then folded the load immediate into the
compare instruction.

I verified this by creating a 32-bit trampoline program and manually
changing the size of the trampoline to be 48 instead of 40.  The program
aborted with the larger size.  I updated this code and ran the test again
and it passed.

I added a test case that runs on PowerPC 32-bit Linux systems and it calls
the __trampoline_setup function with a larger buffer size than the
compiler uses.  The test is not run on 64-bit systems, since the function
__trampoline_setup is not called.  I also limited the test to just Linux
systems, in case trampolines are handled differently in other systems.

libgcc/
2021-04-26  Michael Meissner  

PR target/98952
* config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix
trampoline size comparison in 32-bit by reversing test and
combining load immediate with compare.  Fix backported from trunk
change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.
(__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison
in 32-bit by reversing test and combining load immediate with
compare.

gcc/testsuite/
2021-04-26  Michael Meissner  

PR target/98952
* gcc.target/powerpc/pr98952.c: New test.  Test backported from
trunk change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.

[Bug tree-optimization/100250] [11/12 Regression] ICE related to -Wmaybe-uninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568764.html

[Bug middle-end/90904] vec assignment and copying undefined

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568765.html

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:078d2c5efbc6d372411fa2b8f07efb50e23f70b9

commit r8-10923-g078d2c5efbc6d372411fa2b8f07efb50e23f70b9
Author: Michael Meissner 
Date:   Mon Apr 26 18:26:16 2021 -0400

[PATCH] Backport fix for PR target/989r2

The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
if the trampoline size is greater than the expected size.  It should abort
when the trampoline size is less than the expected size.  I fixed the test
so the operands are reversed.  I then folded the load immediate into the
compare instruction.

I verified this by creating a 32-bit trampoline program and manually
changing the size of the trampoline to be 48 instead of 40.  The program
aborted with the larger size.  I updated this code and ran the test again
and it passed.

I added a test case that runs on PowerPC 32-bit Linux systems and it calls
the __trampoline_setup function with a larger buffer size than the
compiler uses.  The test is not run on 64-bit systems, since the function
__trampoline_setup is not called.  I also limited the test to just Linux
systems, in case trampolines are handled differently in other systems.

libgcc/
2021-04-26  Michael Meissner  

PR target/98952
* config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix
trampoline size comparison in 32-bit by reversing test and
combining load immediate with compare.  Fix backported from trunk
change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.
(__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison
in 32-bit by reversing test and combining load immediate with
compare.

gcc/testsuite/
2021-04-26  Michael Meissner  

PR target/98952
* gcc.target/powerpc/pr98952.c: New test.  Test backported from
trunk change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.

[Bug c/989] Internal error: Floating point exception.

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:078d2c5efbc6d372411fa2b8f07efb50e23f70b9

commit r8-10923-g078d2c5efbc6d372411fa2b8f07efb50e23f70b9
Author: Michael Meissner 
Date:   Mon Apr 26 18:26:16 2021 -0400

[PATCH] Backport fix for PR target/989r2

The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
if the trampoline size is greater than the expected size.  It should abort
when the trampoline size is less than the expected size.  I fixed the test
so the operands are reversed.  I then folded the load immediate into the
compare instruction.

I verified this by creating a 32-bit trampoline program and manually
changing the size of the trampoline to be 48 instead of 40.  The program
aborted with the larger size.  I updated this code and ran the test again
and it passed.

I added a test case that runs on PowerPC 32-bit Linux systems and it calls
the __trampoline_setup function with a larger buffer size than the
compiler uses.  The test is not run on 64-bit systems, since the function
__trampoline_setup is not called.  I also limited the test to just Linux
systems, in case trampolines are handled differently in other systems.

libgcc/
2021-04-26  Michael Meissner  

PR target/98952
* config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix
trampoline size comparison in 32-bit by reversing test and
combining load immediate with compare.  Fix backported from trunk
change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.
(__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison
in 32-bit by reversing test and combining load immediate with
compare.

gcc/testsuite/
2021-04-26  Michael Meissner  

PR target/98952
* gcc.target/powerpc/pr98952.c: New test.  Test backported from
trunk change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.

[Bug c++/69698] [meta-bug] flexible array members

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

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

Bug 100124 Summary: Why is "flexible array member '...' in an otherwise empty 
'...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Martin Sebor  ---
Thus resolving as WONTFIX.

[Bug c++/100209] multiple inheritance with crtp pattern fails on sequentioal member access

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0120cd9382728fdc99d4cfdcb72cd0f55aca2ce3

commit r12-136-g0120cd9382728fdc99d4cfdcb72cd0f55aca2ce3
Author: Patrick Palka 
Date:   Mon Apr 26 17:30:39 2021 -0400

c++: constexpr pointer indirection with negative offset [PR100209]

During constexpr evaluation, a base-to-derived conversion may yield an
expression like (Derived*)( p+ -4) where D.2217 is the
derived object and D.2106 is the base.  But cxx_fold_indirect_ref
doesn't know how to resolve an INDIRECT_REF thereof to just D.2217,
because it doesn't handle POINTER_PLUS_EXPR of a COMPONENT_REF with
negative offset well: when the offset N is positive, it knows that
' p+ N' is equivalent to ' p+ (N - bytepos(f))', but it doesn't
know about the reverse transformation, that ' p+ N' is equivalent
to ' p+ (N + bytepos(f))' when N is negative, which is important for
resolving such base-to-derived conversions and for accessing subobjects
backwards.  This patch teaches cxx_fold_indirect_ref this reverse
transformation.

gcc/cp/ChangeLog:

PR c++/100209
* constexpr.c (cxx_fold_indirect_ref): Try to canonicalize the
object/offset pair for a POINTER_PLUS_EXPR of a COMPONENT_REF
with a negative offset into one whose offset is nonnegative
before calling cxx_fold_indirect_ref_1.

gcc/testsuite/ChangeLog:

PR c++/100209
* g++.dg/cpp1y/constexpr-base1.C: New test.
* g++.dg/cpp1y/constexpr-ptrsub1.C: New test.

[Bug c++/100240] Compiler crashes with segmentation fault on a chrono library using nvcc

[taraba.peter at mail dot com via Gcc-bugs]

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

--- Comment #7 from Peter Taraba  ---
Created attachment 50682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50682=edit
*.i files zipped

crashes on DNNLayerMatrix (attaching .i* files zipped).

[Bug target/99647] arm: GCC generates invalid MVE vmov instruction

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #6 from Alex Coplan  ---
Fixed for GCC 10.4 so fixed everywhere.

[Bug target/99647] arm: GCC generates invalid MVE vmov instruction

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:9266a101ac9707a164bd241c00675a45aae01373

commit r10-9770-g9266a101ac9707a164bd241c00675a45aae01373
Author: Alex Coplan 
Date:   Thu Apr 8 09:36:57 2021 +0100

arm: Various MVE vec_duplicate fixes [PR99647]

This patch fixes various issues with vec_duplicate in the MVE patterns.
Currently there are two patterns named *mve_mov. The second of
these is really a vector duplicate rather than a move, so I've renamed
it accordingly.

As it stands, there are several issues with this pattern:
1. The MVE_types iterator has an entry for TImode, but
   vec_duplicate:TI is invalid.
2. The mode of the operand to vec_duplicate is SImode, but it should
   vary according to the vector mode iterator.
3. The second alternative of this pattern is bogus: it allows matching
   symbol_refs (the cause of the PR) and const_ints (which means that it
   matches (vec_duplicate (const_int ...)) which is non-canonical: such
   rtxes should be const_vectors instead and handled by the main vector
   move pattern).

This patch fixes all of these issues, and removes the redundant
*mve_vec_duplicate pattern.

gcc/ChangeLog:

PR target/99647
* config/arm/iterators.md (MVE_vecs): New.
(V_elem): Also handle V2DF.
* config/arm/mve.md (*mve_mov): Rename to ...
(*mve_vdup): ... this. Remove second alternative since
vec_duplicate of const_int is not canonical RTL, and we don't
want to match symbol_refs.
(*mve_vec_duplicate): Delete (pattern is redundant).

gcc/testsuite/ChangeLog:

PR target/99647
* gcc.c-torture/compile/pr99647.c: New test.

(cherry picked from commit 67d56b272021363eb58c319ca3b73beba3a60817)

[Bug c++/100252] [8/9/10/11/12 Regression] Internal compiler error during template instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Reduced:

struct A {
  int x;
  int y = x;
};

struct B {
  int x = 0;
  int y = A{x}.y;
};

B b = {};

[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-26
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Obvious fix for NULL pointer dereference:

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 213f32b0a67..450ee7e3ae7 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6128,6 +6128,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  bool add_clobber;
  add_clobber = fsym && fsym->attr.intent == INTENT_OUT
&& !fsym->attr.allocatable && !fsym->attr.pointer
+   && e->symtree
&& !e->symtree->n.sym->attr.dimension
&& !e->symtree->n.sym->attr.pointer
&& !e->symtree->n.sym->attr.allocatable

[Bug fortran/100273] [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P4

[Bug fortran/100273] [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |NEW

--- Comment #2 from anlauf at gcc dot gnu.org ---
Looks very related to the len_trim issue in pr84868.  Possibly a duplicate.

[Bug fortran/100276] New: [12 regression] Many failures after r12-119

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

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

Bug ID: 100276
   Summary: [12 regression] Many failures after r12-119
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:22cff118f7526bec195ed6e41452980820fdf3a8, r12-119

FAIL: gfortran.dg/goacc/classify-serial.f95   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/classify-serial.f95   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/kernels-decompose-2.f95   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/kernels-decompose-2.f95   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: gfortran.dg/goacc/routine-module-mod-1.f90 (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-1.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
FAIL: libgomp.oacc-fortran/par-reduction-2-2.f 

[Bug fortran/100275] ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Additional variants :


$ cat z2.f90
program p
   type t
  integer :: a
   end type
   type(t) :: x
   data x /t(null())/
end


$ cat z3.f90
program p
   type t
  integer :: a(1)
   end type
   type(t) :: z
   data z /t(f())/
end


$ gfortran-11-20210425 -c z2.f90   # detected
z2.f90:6:13:

6 |data x /t(null())/
  | 1
Error: non-constant initialization expression at (1)


$ gfortran-11-20210425 -c z3.f90
z3.f90:1:9:

1 | program p
  | 1
internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:6230
0x785ae2 gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:6230
0x7c6d20 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7948
0x7c74b3 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:8863
0x7c6e79 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7983
0x7a756a gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1918
0x7ab08f generate_local_decl
../../gcc/fortran/trans-decl.c:5955
0x75b472 do_traverse_symtree
../../gcc/fortran/symbol.c:4170
0x7ac5cc generate_local_vars
../../gcc/fortran/trans-decl.c:6161
0x7ac5cc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6820
0x723fa6 translate_all_program_units
../../gcc/fortran/parse.c:6355
0x723fa6 gfc_parse_file()
../../gcc/fortran/parse.c:6624
0x770e5f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100275] New: ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417

[gscfq--- via Gcc-bugs]

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

Bug ID: 100275
   Summary: ICE in gfc_build_null_descriptor, at
fortran/trans-array.c:417
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This invalid code affects versions down to at least r5 :


$ cat z1.f90
program p
   type t
  integer :: a(1)
   end type
   type(t) :: x
   data x /t(null())/
end


$ gfortran-11-20210425 -c z1.f90
z1.f90:1:9:

1 | program p
  | 1
internal compiler error: in gfc_build_null_descriptor, at
fortran/trans-array.c:417
0x73c049 gfc_build_null_descriptor(tree_node*)
../../gcc/fortran/trans-array.c:417
0x74f727 gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc/fortran/trans-array.c:6227
0x7798a0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7948
0x7676e3 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:8863
0x7799f9 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7983
0x75c46f gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1918
0x75ef0f generate_local_decl
../../gcc/fortran/trans-decl.c:5955
0x71df02 do_traverse_symtree
../../gcc/fortran/symbol.c:4170
0x75feb4 generate_local_vars
../../gcc/fortran/trans-decl.c:6161
0x75feb4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6820
0x6e6a36 translate_all_program_units
../../gcc/fortran/parse.c:6355
0x6e6a36 gfc_parse_file()
../../gcc/fortran/parse.c:6624
0x732d2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100274] New: [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

[gscfq--- via Gcc-bugs]

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

Bug ID: 100274
   Summary: [9/10/11/12 Regression] ICE in
gfc_conv_procedure_call, at fortran/trans-expr.c:6131
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed with r9 between 20180916 and 20180923 :
(as a supplement to pr100154)


$ cat z1.f90
program p
   call s('x')
contains
   subroutine s(x)
  character(8), intent(out) :: x
   end
end


$ gfortran-9-20180916 -c z1.f90
z1.f90:2:10:

2 |call s('x')
  |  1
Warning: Character length of actual argument shorter than of dummy argument 'x'
(1/8) at (1) [-Wargument-mismatch]


$ gfortran-11-20210425 -c z1.f90
z1.f90:2:10:

2 |call s('x')
  |  1
Warning: Character length of actual argument shorter than of dummy argument 'x'
(1/8) at (1)
z1.f90:2:14:

2 |call s('x')
  |  1
internal compiler error: Segmentation fault
0xc0b78f crash_signal
../../gcc/toplev.c:327
0x77206f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6131
0x7a9ba8 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:424
0x739e38 trans_code
../../gcc/fortran/trans.c:2000
0x760094 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6885
0x6e6a36 translate_all_program_units
../../gcc/fortran/parse.c:6355
0x6e6a36 gfc_parse_file()
../../gcc/fortran/parse.c:6624
0x732d2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100273] [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

The following variants can be compiled and work as expected :


$ cat z2.f90
module m
   implicit none
contains
   character(4) function g(k)
  integer :: k
  character(3), parameter :: a(2) = ['1  ', '123']
  g = f(k)
   contains
  function f(n)
 integer :: n
 character(len_trim(a(n))) :: f
 f = 'abc'
  end
   end
end
program p
   use m
   print *, '>>' // g(1) // '<<'
   print *, '>>' // g(2) // '<<'
end


$ cat z3.f90
module m
   implicit none
   character(3), parameter :: a(2) = ['1  ', '123']
contains
   character(4) function g(k)
  integer :: k
  g = f(k)
   contains
  function f(n)
 integer :: n
 character(len_trim(a(n))) :: f
 f = 'abc'
  end
   end
end
program p
   use m
   print *, '>>' // g(1) // '<<'
   print *, '>>' // g(2) // '<<'
end

[Bug fortran/100273] New: [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

[gscfq--- via Gcc-bugs]

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

Bug ID: 100273
   Summary: [9/10/11/12 Regression] ICE in
gfc_create_module_variable, at
fortran/trans-decl.c:5352
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 before 20180426, r6 compiles it :


$ cat z1.f90
module m
   implicit none
contains
   character(4) function g(k)
  integer :: k
  g = f(k)
   contains
  function f(n)
 character(3), parameter :: a(2) = ['1  ', '123']
 integer :: n
 character(len_trim(a(n))) :: f
 f = 'abc'
  end
   end
end
program p
   use m
   print *, '>>' // g(1) // '<<'
   print *, '>>' // g(2) // '<<'
end


$ gfortran-6 -c z1.f90
$
$ gfortran-11-20210425 -c z1.f90
f951: internal compiler error: in gfc_create_module_variable, at
fortran/trans-decl.c:5352
0x75f716 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5350
0x71df02 do_traverse_symtree
../../gcc/fortran/symbol.c:4170
0x75fcbb gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5845
0x73a1f4 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2307
0x6e6531 translate_all_program_units
../../gcc/fortran/parse.c:6342
0x6e6531 gfc_parse_file()
../../gcc/fortran/parse.c:6624
0x732d2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug testsuite/100272] New: some incomplete dg-commands

[gscfq--- via Gcc-bugs]

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

Bug ID: 100272
   Summary: some incomplete dg-commands
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Missing a starting "{" after "//" :

./gcc/testsuite/g++.dg/ext/flexary13.C:  { 0, { } };   // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 1, { 2 } };   // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 2, { 3, 4 } }; // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 123, i };   // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 456, { i } }; // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 3, { i, j, k } }; // dg-warning
"initialization of a flexible array member" }
./gcc/testsuite/g++.dg/ext/flexary13.C:  { 1, { 2 } };   // dg-warning
"initialization of a flexible array member" }

./gcc/testsuite/g++.dg/diagnostic/ptrtomem1.C:22:requires (sizeof(T)==1) //
dg-message {\[with T = int \(X::\*\)\[5\]\]} }



Missing both starting "{" and ending "}" (if desired at all) :

./gcc/testsuite/g++.dg/template/spec26.C:1:// dg-do run

./gcc/testsuite/gcc.dg/pr20126.c:1:/* dg-do run */
./gcc/testsuite/gcc.dg/pr20126.c:2:/* dg-options "-O2" */

./gcc/testsuite/gcc.dg/tree-ssa/pr20739.c:3:/* dg-do compile */
./gcc/testsuite/gcc.dg/tree-ssa/pr20739.c:4:/* dg-options "-O" */

./gcc/testsuite/gcc.dg/tree-ssa/predcom-1.c:50:/* dg-final {
scan-tree-dump-times "looparound ref" 1 "pcom" } */

./libffi/testsuite/libffi.complex/complex_int.c:79:  /* dg-output "-2,8i 2,8i,
x 1234 1234, y 0 0" */



This dg-command seems to be truncated at "+" :

./gcc/testsuite/g++.dg/ipa/pr45572-2.C:2:// { dg-options
"-finline-small-functions -findirect-inlining -finline-function+
---
./gcc/testsuite/g++.dg/ipa/pr45572-2.C:2:// { dg-options
"-finline-small-functions -findirect-inlining -finline-functions" }

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[noloader at gmail dot com via Gcc-bugs]

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

Jeffrey Walton  changed:

   What|Removed |Added

 CC||noloader at gmail dot com

--- Comment #12 from Jeffrey Walton  ---
This may be helpful if someone starts on a port of GCC to the M1:
https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms

The GCC Compile Farm has an M1. I also have an M1 for testing. My M1 has
Command Line Tools (CLT), but lacks Xcode. (I don't have an Apple account
anymore). My M1 has Autotools but that's about it. My M1 gives some projects
some problems when they assume Xcode is present.

If you want an account on my box for testing, then send your authorized_keys to
noloader, gmail account. If you break my M1 it is no big deal. I'll just
reinstall the OS.

[Bug tree-optimization/100256] spurious stringop-overflow warning with memset(..., sizeof(dest)) on variable-length array at -O3

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Sebor  ---
I can reproduce the warning (at -O2 and -O3) but I don't see it as a bug in
GCC.  A slightly simplified test case below.  Using unsigned int for the size
avoids the warning but using size_t brings it back again.

The function is undefined when called with (n < 0 || n >= __INT_MAX__ / 2) (or
j_degree in the original test case) and asserting that's not the case makes the
warning go away and results in better code:

  if (n < 0 || n >= __INT_MAX__ / 2)
__builtin_unreachable ();

I suppose a possible improvement here that would avoid the warning is to teach
GCC to derive the same precondition based on the absence of the undefined
behavior and emit more optimal code.  But that's orthogonal to the warning
itself.

The only thing I find puzzling is that the range for the memset() bound in the
strlen dump (where the warning comes from) looks valid and would not trigger
the warning but the one returned from vr_values::range_of_expr () the warning
actually uses doesn't seem right:But the range returned from
vr_values::range_of_expr () is:

;;   basic block 12, loop depth 0, count 59461674 (estimated locally), maybe
hot
;;prev block 11, next block 13, flags: (NEW, REACHABLE, VISITED)
;;pred:   8 [always]  count:59055800 (estimated locally)
(FALLTHRU,EXECUTABLE)
;;5 [always]  count:405874 (estimated locally)
(FALLTHRU,EXECUTABLE)
  # .MEM_21 = PHI <.MEM_31(8), .MEM_40(5)>
  # VUSE <.MEM_21>
  return;
;;succ:   EXIT [always]  count:59461674 (estimated locally)
(EXECUTABLE)

;;   basic block 13, loop depth 0, count 52559662 (estimated locally), maybe
hot
;;   Invalid sum of incoming counts 55785408 (estimated locally), should be
52559662 (estimated locally)
;;prev block 12, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   6 [5.5% (guessed)]  count:55785408 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  # RANGE [0, 2147483647] NONZERO 2147483646
  _12 = n_25(D) * 2;
  # RANGE [1, 2147483647] NONZERO 2147483647
  _42 = _12 + 1;
  # RANGE [1, 2147483647] NONZERO 2147483647
  _11 = (sizetype) _42;
  # RANGE [4, 8589934588] NONZERO 8589934588
  _13 = _11 * 4;
  # .MEM_41 = VDEF <.MEM_38>
  # PT = { D.1985 }
  # ALIGN = 4, MISALIGN = 0
  # USE = nonlocal { D.1983 } (escaped, escaped heap)
  # CLB = nonlocal { D.1983 } (escaped, escaped heap)
  a.0_43 = __builtin_alloca_with_alignD.1906 (_13, 32);
  # .MEM_45 = VDEF <.MEM_41>
  # USE = nonlocal { D.1983 } (escaped, escaped heap)
  # CLB = nonlocal { D.1983 } (escaped, escaped heap)
  memsetD.897 (a.0_43, 0, _13);
  goto ; [100.00%]
;;succ:   9 [always]  count:52559662 (estimated locally)
(FALLTHRU,EXECUTABLE)

}


(gdb) p rng
$22 = VR_RANGE
(gdb) p debug_tree(vr.min())
 
constant 18446744065119617028>
$23 = void
(gdb) p debug_tree(vr.max())
 
constant 18446744073709551612>
$24 = void
(gdb) 


The slightly reduced test case:

$ cat pr100256.c && gcc -O2 -S -Wall pr100256.c 
void f (int n, int *q, int **p)
{
  for (int i = 0; i < n + 1; i++)
if (!(p[i] = __builtin_calloc (n + 1, sizeof (int
  return;

  int a[n * 2 + 1];

  __builtin_memset (a, 0, sizeof a);

  for (int i = 0; i < n * 2 + 1; i++)
{
  a[i]++;
  if (i < n + 1)
q[i]++;
}
}

pr100256.c: In function ‘f’:
pr100256.c:9:3: warning: ‘__builtin_memset’ writing between
18446744065119617028 and 18446744073709551612 bytes into a region of size
9223372036854775807 [-Wstringop-overflow=]
9 |   __builtin_memset (a, 0, sizeof a);
  |   ^
pr100256.c:7:7: note: destination object ‘a’ of size 9223372036854775807
7 |   int a[n * 2 + 1];
  |   ^

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #9 from Dominique d'Humieres  ---
> Patch (version 2) posted:
>
> https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html

Please assign the PR to yourself when you submit a patch!

[Bug tree-optimization/100263] [11/12 Regression] Wrong removal of statement in copyprop3

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

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

--- Comment #3 from Jakub Jelinek  ---
And, just to verify it, I've compiled the testcase with r11-39 with a
breakpoint on pass_expand::execute and set global_options.x_optimize = 0 there,
and resulting testcase passes.
So most likely things go wrong during RTL optimizations.

[Bug c++/95317] [8/9/10 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||zchendd at connect dot ust.hk

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

[Bug c++/100271] ICE in in tsubst_copy, at cp/pt.c:16480

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Fixed by r11-7993.  A dup.

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

[Bug c++/100271] New: ICE in in tsubst_copy, at cp/pt.c:16480

[zchendd at connect dot ust.hk via Gcc-bugs]

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

Bug ID: 100271
   Summary: ICE in in tsubst_copy, at cp/pt.c:16480
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zchendd at connect dot ust.hk
  Target Milestone: ---

Created attachment 50681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50681=edit
Compiler output

When compiling a c++ file with an enum within nested lambda with auto
parameter, the error described in the summary occur.

Test file:

int main()
{
auto l1 = [](auto a) {
auto l2 = [](auto b) {
enum {
x,y,z,
}v = x;
};
};
l1(0);
}

[Bug tree-optimization/100250] [11/12 Regression] ICE related to -Wmaybe-uninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||11.0, 12.0

[Bug tree-optimization/100250] [11/12 Regression] ICE related to -Wmaybe-uninitialized

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

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

--- Comment #2 from Martin Sebor  ---
This is a consequence of fixing pr97172 by clearing the VLA bounds encoded by
the front end in function attributes before the IL enters the middle end: they
VLA bounds aren't used to decide whether to diagnose code but they are used in
the text of the warnings.  That's why the originally submitted patches
preserved them (v2 of the patch encoded them as strings:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562318.html)

[Bug tree-optimization/100263] [11/12 Regression] Wrong removal of statement in copyprop3

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

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

--- Comment #2 from Jakub Jelinek  ---
Though, looking at the r11-39 optimized dump, I actually don't see anything
wrong.
The path taken in the testcase should be:
[local count: 1073741824]:
   b.0_1 = b;
   if (b.0_1 != 2)
 goto ; [96.34%]
...
[local count: 1034442872]:
...
[local count: 10321168952]:
   # b.12_44 = PHI 
   # c__lsm.20_50 = PHI 
   # c__lsm_flag.21_52 = PHI <0(3), c__lsm_flag.21_53(42)>
...
   if (a.1_7 != 0)
 goto ; [50.00%]
   else
 goto ; [50.00%]
...
[local count: 5160584476]:
   if (h.4_5 != 0)
 goto ; [89.00%]
   else
 goto ; [11.00%]
...
[local count: 9639533214]:
   # c__lsm.20_51 = PHI 
   # c__lsm_flag.21_53 = PHI 
...
   _32 = b.12_44 + 254;
   if (_32 != 2)
 goto ; [96.34%]
   else
 goto ; [3.66%]

[local count: 352806927]:
   if (c__lsm_flag.21_53 != 0)
 goto ; [66.67%]
   else
 goto ; [33.33%]

[local count: 235204617]:
   MEM[(char *) + 107B] = c__lsm.20_51;
where bb will loop 126 times and then fall through to bb 43, but when bb 42 is
reached from bb 5 (should be always), then both SSA_NAMEs 51 and 53 are 1 and
so
the store of 1 should happen.

[Bug target/100270] _Generic can't distinguish VLS SVE vectors and GNU vectors

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Working on a patch.

[Bug target/100270] New: _Generic can't distinguish VLS SVE vectors and GNU vectors

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

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

Bug ID: 100270
   Summary: _Generic can't distinguish VLS SVE vectors and GNU
vectors
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Compiling the following test with -march=armv8.2-a+sve -msve-vector-bits=256:

---
#include 

typedef svint32_t vls_svint32_t __attribute__((arm_sve_vector_bits(256)));
typedef int32_t gnu_svint32_t __attribute__((vector_size(32)));

int
f (vls_svint32_t x)
{
  return _Generic(x, vls_svint32_t: 1, gnu_svint32_t: 2, default: -1);
}
---

gives:

a.c: In function ‘f’:
a.c:9:40: error: ‘_Generic’ specifies two compatible types
9 |   return _Generic(x, vls_svint32_t: 1, gnu_svint32_t: 2, default: -1);
  |^
a.c:9:22: note: compatible type is here
9 |   return _Generic(x, vls_svint32_t: 1, gnu_svint32_t: 2, default: -1);
  |  ^
a.c:9:40: error: ‘_Generic’ selector matches multiple associations
9 |   return _Generic(x, vls_svint32_t: 1, gnu_svint32_t: 2, default: -1);
  |^
a.c:9:22: note: other match is here
9 |   return _Generic(x, vls_svint32_t: 1, gnu_svint32_t: 2, default: -1);
  |  ^

This is because aarch64_comp_type_attributes needs to return
false for this combination of types.

[Bug middle-end/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]

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

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

--- Comment #5 from Martin Sebor  ---
I should add: because mdesc is a member of another struct it can't have a
flexible array member, but as long as the enclosing struct mdesc_handle is not
embedded as a member in another struct it can have a trailing flexible array
member, like so:

struct mdesc_handle {
 struct list_head list;
 struct mdesc_mem_ops *mops;
 void *self_base;
 refcount_t refcnt;
 unsigned int handle_size;
 struct mdesc_hdr mdesc;
 char data[];
};

Then changing the accesses from the end of mdesc to those from the beginning of
the data array would also correct the problem and presumably be a cleaner way
of writing the code.

[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-04-26
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug middle-end/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]

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

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |middle-end
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Martin Sebor  ---
The warnings are by design.  They're all issued for the same underlying problem
involving accesses past the end of an object of the same type: struct
mdesc_handle and struct mdesc_hdr defined like so:

struct mdesc_handle {
 struct list_head list;
 struct mdesc_mem_ops *mops;
 void *self_base;
 refcount_t refcnt;
 unsigned int handle_size;
 struct mdesc_hdr mdesc;
};

struct mdesc_hdr {
 u32 version;
 u32 node_sz;
 u32 name_sz;
 u32 data_sz;
} __attribute__((aligned(16)));

static struct mdesc_elem *node_block(struct mdesc_hdr *mdesc)
{
 return (struct mdesc_elem *) (mdesc + 1);
}

static void *name_block(struct mdesc_hdr *mdesc)
{
 return ((void *) node_block(mdesc)) + mdesc->node_sz;
}

static void *data_block(struct mdesc_hdr *mdesc)
{
 return ((void *) name_block(mdesc)) + mdesc->name_sz;
}

u64 mdesc_node_by_name(struct mdesc_handle *hp,
 u64 from_node, const char *name)
{
 struct mdesc_elem *ep = node_block(>mdesc);
 const char *names = name_block(>mdesc);
^^

This is the cause of the warning: name_block() computes the address past the
end of hp->mdesc, effectively treating mdesc as if it was a flexible array
member.  What the code really seems to want to do is to compute the address
somewhere into the chunk pointed to by hp.  The expected way to do that is like
so:

 const char *names = (char*)hp + offsetof (struct mdesc_handle, mdesc);

[Bug bootstrap/100269] [12 Regression] i686 biarch compiler fails for Darwin after r12-36.

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |NEW
 Target||i686-darwin
Version|10.2.1  |12.0
   Keywords||build
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |12.0
 Ever confirmed|0   |1

[Bug bootstrap/100269] New: [12 Regression] i686 biarch compiler fails for Darwin after r12-36.

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

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

Bug ID: 100269
   Summary: [12 Regression] i686 biarch compiler fails for Darwin
after r12-36.
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

With the fix at r12-50-ga44895ce7ffbc26b4d765c40b5b346f8c9a9b762 applied,
bootstrap still fails for a 32b host with a 64b multilib.

$ ./gcc/xgcc -Bgcc -E -dM -m64 -xc /dev/null
cc1: sorry, unimplemented: 64-bit mode not compiled in

this is coming from i386-options.c:2050+

  if ((TARGET_64BIT_P (opts->x_ix86_isa_flags) != 0)
  != ((opts->x_ix86_isa_flags & OPTION_MASK_ISA_64BIT) != 0))
sorry ("%i-bit mode not compiled in",
   (opts->x_ix86_isa_flags & OPTION_MASK_ISA_64BIT) ? 64 : 32);

unfortunately, it is not obvious to me what fix I need to make here.

[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression

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

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

--- Comment #4 from Marek Polacek  ---
This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99465#c1 but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99465#c0.

[Bug target/100200] [10/11/12 Regression] UB evaluating aarch64_plus_immediate predicate

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50680=edit
gcc11-pr100200.patch

Untested fix.

[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r11-4656.

[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552

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

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

--- Comment #9 from Ilya Leoshkevich  ---
Created attachment 50679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50679=edit
regtesting this patch now

[Bug c++/100252] [8/9/10/11/12 Regression] Internal compiler error during template instantiation

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|Internal compiler error |[8/9/10/11/12 Regression]
   |during template |Internal compiler error
   |instantiation   |during template
   ||instantiation
   Target Milestone|--- |8.5
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Started with r216750.

[Bug target/100236] arm: UB in arm_compute_save_core_reg_mask (shift exponent 4294967295 is too large for 32-bit type 'int')

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Earnshaw  ---
Confirmed.  The macro THUMB2_WORK_REGS expands to

(0xff & ~(  (1 << THUMB_HARD_FRAME_POINTER_REGNUM) \
   | (1 << SP_REGNUM) | (1 << PC_REGNUM) \
   | (1 << PIC_OFFSET_TABLE_REGNUM)))

But PIC_OFFSET_TABLE_REGNUM in turn expands to

arm_pic_register

which may be INVALID_REGNUM (~0) in some circumstances.

[Bug tree-optimization/100263] [11/12 Regression] Wrong removal of statement in copyprop3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Wrong removal of statement  |[11/12 Regression] Wrong
   |in copyprop3|removal of statement in
   ||copyprop3
   Target Milestone|--- |11.2
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #1 from Jakub Jelinek  ---
In can confirm it is r11-39-gf9e1ea10e657af9fb02fafecf1a600740fd34409
Before lim2 the dump is identical, lim2 dump difference between r11-38 and
r11-39
is:
--- pr100263.c.131t.lim2.r11-38   2021-04-26 15:54:38.623719858 +0200
+++ pr100263.c.131t.lim2.r11-392021-04-26 15:54:53.982545411 +0200
@@ -165,26 +165,23 @@ main ()
   j_lsm_flag.23_69 = 0;
   k_lsm.24_70 = k;
   k_lsm_flag.25_71 = 0;
-  l_lsm.26_72 = l;
-  l_lsm_flag.27_73 = 0;
-  c__lsm.20_74 = MEM[(char *) + 107B];
-  c__lsm_flag.21_75 = 0;
+  l_lsm_flag.27_72 = 0;
+  c__lsm_flag.21_73 = 0;
   h.4_5 = h;
-  b_lsm.28_76 = b;
-  b_lsm_flag.29_77 = 0;
+  b_lsm_flag.29_74 = 0;

[local count: 10321168952]:
   # b.12_44 = PHI 
-  # c__lsm.20_50 = PHI 
-  # c__lsm_flag.21_52 = PHI 
+  # c__lsm.20_50 = PHI 
+  # c__lsm_flag.21_52 = PHI 
   # j_lsm.22_54 = PHI 
   # j_lsm_flag.23_56 = PHI 
   # k_lsm.24_58 = PHI 
   # k_lsm_flag.25_60 = PHI 
-  # l_lsm.26_62 = PHI 
-  # l_lsm_flag.27_64 = PHI 
-  # b_lsm.28_66 = PHI 
-  # b_lsm_flag.29_67 = PHI 
+  # l_lsm.26_62 = PHI 
+  # l_lsm_flag.27_64 = PHI 
+  # b_lsm.28_66 = PHI 
+  # b_lsm_flag.29_67 = PHI 
   if (a.1_7 != 0)
 goto ; [50.00%]
   else

I can reproduce the same problem even when replacing
  char *n = [3][8][2];
  *n = 1;
with
  c[3][8][2] = 1;

[Bug c/100268] New: lm32-uclinux: ../.././gcc/config/lm32/uclinux-elf.h:70: error: "LINK_GCC_C_SEQUENCE_SPEC" redefined [-Werror]

[jbglaw--- via Gcc-bugs]

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

Bug ID: 100268
   Summary: lm32-uclinux:
../.././gcc/config/lm32/uclinux-elf.h:70: error:
"LINK_GCC_C_SEQUENCE_SPEC" redefined [-Werror]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

I'm revamping my testing efforts, building cross compilers based on targets
listed in ./contrib/config-list.mk.

With .../configure --target=lm32-uclinux --enable-werror-always
--enable-languages=all --prefix=/tmp/gcc-lm32-uclinux (using g++ (Debian
20210320-1) 11.0.1 20210320 (experimental) [master revision
3279a9a5a9a:6526c452d22:5f256a70a05fcfc5a1caf56678ceb12b4f87f781] as the host's
compiler), build breaks (as of ed16241c6db23013d70b792a64f29080ad48a414) with
this (cf. http://toolchain.lug-owl.de:8080/jobs/gcc-lm32-uclinux/8):

make all-gcc
[...]
[all 2021-04-26 10:11:40.136777] /usr/lib/gcc-snapshot/bin/g++ -c   -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE
-fno-PIE -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include
 -I../.././gcc/../libcpp/include  \
[all 2021-04-26 10:11:40.136990]-o build/genpreds.o
../.././gcc/genpreds.c
[all 2021-04-26 10:11:40.413151] In file included from ./tm.h:29,
[all 2021-04-26 10:11:40.413344]  from
../.././gcc/genpreds.c:26:
[all 2021-04-26 10:11:40.413447] ../.././gcc/config/lm32/uclinux-elf.h:70:
error: "LINK_GCC_C_SEQUENCE_SPEC" redefined [-Werror]
[all 2021-04-26 10:11:40.413548]70 | #define LINK_GCC_C_SEQUENCE_SPEC \
[all 2021-04-26 10:11:40.413625]   | 
[all 2021-04-26 10:11:40.413708] In file included from ./tm.h:27,
[all 2021-04-26 10:11:40.413779]  from
../.././gcc/genpreds.c:26:
[all 2021-04-26 10:11:40.413850] ../.././gcc/config/gnu-user.h:117: note: this
is the location of the previous definition
[all 2021-04-26 10:11:40.413922]   117 | #define LINK_GCC_C_SEQUENCE_SPEC
GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC
[all 2021-04-26 10:11:40.413994]   | 
[all 2021-04-26 10:11:45.105909] cc1plus: all warnings being treated as errors
[all 2021-04-26 10:11:45.120330] make[1]: *** [Makefile:2815: build/genpreds.o]
Error 1
[all 2021-04-26 10:11:45.120546] make[1]: Leaving directory
'/var/lib/laminar/run/gcc-lm32-uclinux/8/gcc/host-x86_64-pc-linux-gnu/gcc'
[all 2021-04-26 10:11:45.139714] make: *** [Makefile:4428: all-gcc] Error 2

A simple undef will probably do?

Thanks,
Jan-Benedict

[Bug tree-optimization/100239] [10/11/12 Regression] ICE: in expand_expr_real_2, at expr.c:9865 with __builtin_shuffle()

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 50678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50678=edit
gcc11-pr100239.patch

Untested fix.

[Bug middle-end/100267] New: gcc -O2 for avx512 instrincts generates extra warnings and less optimizations

[konstantin.ananyev at intel dot com via Gcc-bugs]

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

Bug ID: 100267
   Summary: gcc -O2 for avx512 instrincts generates extra warnings
and less optimizations
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.ananyev at intel dot com
  Target Milestone: ---

The code snippet below compiles ok with '-O2' for gcc-9.
But with gcc-10 (and gcc-11) it generates -Wuninitialized warnings.
Another thing (which is probably worse) 'gcc-10 -O2' generates code with
unnecessary loads for ymm registers from the initiliazed portion of the stack.
As I understand, thats where from these -Wuninitialized warnings come from:
by some reason gcc-10 wants to put local '__m256i pdatap[2]' variables
on the stack.
Note that only '-O2' affected, '-O3' looks good for all versions I tried
(gcc-9, gcc-10, gcc-11)..

=
$ cat tavx512u5.c

#include 
#include 
#include 


struct flow_avx512 {
uint32_t num_packets;
uint32_t total_packets;
const uint8_t **idata;
};

static inline void
start_flow_avx512x8(const struct flow_avx512 *flow, uint32_t num,
uint32_t msk, __m256i pdata[2])
{
uint32_t n, m[2], nm[2];
__m256i nd[2];

m[0] = msk & 0xF;
m[1] = msk >> 4;

n = __builtin_popcount(m[0]);
nm[0] = (1 << n) - 1;
nm[1] = (1 << (num - n)) - 1;

nd[0] = _mm256_maskz_loadu_epi64(nm[0],
flow->idata + flow->num_packets);
nd[1] = _mm256_maskz_loadu_epi64(nm[1],
flow->idata + flow->num_packets + n);

pdata[0] = _mm256_mask_expand_epi64(pdata[0], m[0], nd[0]);
pdata[1] = _mm256_mask_expand_epi64(pdata[1], m[1], nd[1]);
}

__m256i
dummyf1_avx512x8(const struct flow_avx512 *flow)
{
__m256i pdata[2];

start_flow_avx512x8(flow, 8, 0xFF, pdata);
return _mm256_add_epi64(pdata[0], pdata[1]);
}


Good version (gcc-9) first:
gcc-9 -m64 -mavx512f -mavx512vl -mavx512cd -mavx512bw -Wall -O2 -o
tavx512u5.gcc9-O2.o -c tavx512u5.c

$ objdump -d tavx512u5.gcc9-O2.o

tavx512u5.gcc9-O2.o: file format elf64-x86-64

Disassembly of section .text:

 :
   0:   f3 0f 1e fa endbr64
   4:   8b 17   mov(%rdi),%edx
   6:   48 8b 47 08 mov0x8(%rdi),%rax
   a:   b9 0f 00 00 00  mov$0xf,%ecx
   f:   c5 f8 92 c9 kmovw  %ecx,%k1
  13:   62 f2 fd a9 89 0c d0vpexpandq (%rax,%rdx,8),%ymm1{%k1}{z}
  1a:   62 f2 fd a9 89 44 d0vpexpandq 0x20(%rax,%rdx,8),%ymm0{%k1}{z}
  21:   04
  22:   c5 f5 d4 c0 vpaddq %ymm0,%ymm1,%ymm0
  26:   c3  retq

===
Now gcc-10:
$ gcc-10 -m64 -mavx512f -mavx512vl -mavx512cd -mavx512bw -Wall -O2 -o
tavx512u5.gcc9-O2.o  -c tavx512u5.c
tavx512u5.c: In function ‘dummyf1_avx512x8’:
tavx512u5.c:32:13: warning: ‘pdata’ is used uninitialized in this function
[-Wuninitialized]
   32 |  pdata[0] = _mm256_mask_expand_epi64(pdata[0], m[0], nd[0]);
  | ^~~
tavx512u5.c:33:13: warning: ‘*((void *)+32)’ is used uninitialized in
this function [-Wuninitialized]
   33 |  pdata[1] = _mm256_mask_expand_epi64(pdata[1], m[1], nd[1]);
  | ^~~

$ objdump -d tavx512u5.gcc10-O2.o 

tavx512u5.gcc10-O2.o: file format elf64-x86-64

 :
   0:   f3 0f 1e fa endbr64
   4:   55  push   %rbp
   5:   b9 0f 00 00 00  mov$0xf,%ecx
   a:   c5 f8 92 c9 kmovw  %ecx,%k1
   e:   48 89 e5mov%rsp,%rbp
  11:   48 83 e4 e0 and$0xffe0,%rsp
  15:   48 83 ec 60 sub$0x60,%rsp
  19:   8b 17   mov(%rdi),%edx
  1b:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
  22:   00 00
  24:   48 89 44 24 58  mov%rax,0x58(%rsp)
  29:   31 c0   xor%eax,%eax
  2b:   48 8b 47 08 mov0x8(%rdi),%rax
  2f:   c5 fd 6f 04 24  vmovdqa (%rsp),%ymm0  <=== load uninit data
  34:   c5 fd 6f 4c 24 20   vmovdqa 0x20(%rsp),%ymm1 <=== from stack
  3a:   62 f2 fd 29 89 04 d0vpexpandq (%rax,%rdx,8),%ymm0{%k1}
  41:   62 f2 fd 29 89 4c d0vpexpandq 0x20(%rax,%rdx,8),%ymm1{%k1}
  48:   04
  49:   c5 fd d4 c1 vpaddq %ymm1,%ymm0,%ymm0
  4d:   48 8b 44 24 58  mov0x58(%rsp),%rax
  52:   64 48 2b 04 25 28 00sub%fs:0x28,%rax
  59:   00 00
  5b:   75 02   jne5f 
  5d:   c9  leaveq
  5e:   c3  retq
  5f:   c5 f8 77vzeroupper
  62:   e8 00 00 00 00  callq  67 

[Bug target/100266] [RISCV] Provide programmatic implementation of CAS

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph M.  ---
A patchset to resolve this can be found here:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568684.html

[Bug target/100265] [RISCV] Use proper fences for atomic load/store

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph M.  ---
A patchset to resolve this can be found here:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568684.html

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-26
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Confirmed.

[Bug target/100266] New: [RISCV] Provide programmatic implementation of CAS

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 100266
   Summary: [RISCV] Provide programmatic implementation of CAS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophm30 at gmail dot com
  Target Milestone: ---

At the moment CAS is implemented in form of a hard-coded sequence in sync.md.
When implementing this in a programmatic way (i.e. in riscv.c) we can make this
code much more maintainable. Moving this into C-code also allows to properly
emit the proper fences for ensuring the required memory ordering.

To do so we need to basically do the following:
* model LR and SC INSNs
* implement riscv_expand_compare_and_swap () in riscv.c

[Bug c/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]

[romain.naour at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Romain Naour  ---
Created attachment 50677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50677=edit
arch/sparc/kernel/mdesc.o generated with gcc -E

[Bug target/100265] New: [RISCV] Use proper fences for atomic load/store

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 100265
   Summary: [RISCV] Use proper fences for atomic load/store
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophm30 at gmail dot com
  Target Milestone: ---

On RISC-V we don't have load/store instructions with memory ordering bits.
To enforce memory ordering we need to use FENCE instructions.
The good thing is, we can have support for sub-word load/store.

The particular FENCE arguments (i.e. how to map the C ordering to RISC-V
ordering is documented in the RISC-V unpriv spec in section "Code Porting and
Mapping Guidelines").

Currenlty, GCC generates the following:

load_u32_n:
  lw a0,0(a0)
  sext.w a0,a0
  ret

load_u32_aq_n:
  lw a0,0(a0)
  fence iorw,iorw
  sext.w a0,a0
  ret

store_u32_n:
  amoswap.w zero,a1,0(a0)
  ret

store_u32_rl_n:
  fence iorw,ow
  amoswap.w zero,a1,0(a0)
  ret

The goal would be to generate this as follows:

load_u32_n:
  lw a0,0(a0)
  ret

load_u32_aq_n:
  lw a0,0(a0)
  fence r,rw
  ret

store_au32_n:
  sw a1,0(a0)
  ret

store_au32_rl_n:
  fence rw,w
  sw a1,0(a0)
  ret

[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.0
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Richard Biener  ---
Fixed for GCC 12.

[Bug tree-optimization/99956] loop interchange fails when altering bwaves inner loop

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

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

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

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

commit r12-125-g6ff66d1ea48960fe96bb51a750c01135e65fe452
Author: Richard Biener 
Date:   Wed Apr 7 14:53:40 2021 +0200

tree-optimization/99956 - improve loop interchange

When we apply store motion and DSE manually to the bwaves kernel
in gfortran.dg/pr81303.f loop interchange no longer happens because
the perfect nest considered covers outer loops we cannot analyze
strides for.  The following compensates for this by shrinking the
nest in this analysis which was already possible but on a too coarse
granularity.  It shares the shrinked nest with the rest of the DRs
so the complexity overhead should be negligible.

2021-04-07  Richard Biener  

PR tree-optimization/99956
* gimple-loop-interchange.cc (compute_access_stride):
Try instantiating the access in a shallower loop nest
if instantiating failed.
(compute_access_strides): Pass adjustable loop_nest
to compute_access_stride.

* gfortran.dg/pr99956.f: New testcase.

[Bug tree-optimization/99880] [10 Regression] ICE in maybe_set_vectorized_backedge_value, at tree-vect-loop.c:9161 since r10-3711-g69f8c1aef5cdcc54

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail||10.3.0

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/100053] [9/10 Regression] tree-fre incorrectly delete a condition

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:be0093e7273f00fe850578415c0b06bc7dec6dc0

commit r10-9769-gbe0093e7273f00fe850578415c0b06bc7dec6dc0
Author: Richard Biener 
Date:   Tue Apr 13 12:05:53 2021 +0200

tree-optimization/100053 - fix predication in VN

This avoids doing optimistic dominance queries involving
non-executable backedges when validating recorded predicated values
in VN because we have no way to force re-evaluating validity when
optimistically not executable edges become executable later.

2021-04-13  Richard Biener  

PR tree-optimization/100053
* tree-ssa-sccvn.c (vn_nary_op_get_predicated_value): Do
not use optimistic dominance queries for backedges to validate
predicated values.
(dominated_by_p_w_unex): Add parameter to ignore executable
state on backedges.
(rpo_elim::eliminate_avail): Adjust.

* gcc.dg/torture/pr100053.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-93.c: Likewise.

(cherry picked from commit f9810422f6768b914aabfcbffe64f535bdd18452)

[Bug tree-optimization/99954] [8/9/10 Regression] Copy loop over array of unions at -O3 generates memcpy instead of memmove, resulting in incorrect code

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:ee16f803357725df96e8c232b8066d9db3ec16a8

commit r10-9768-gee16f803357725df96e8c232b8066d9db3ec16a8
Author: Richard Biener 
Date:   Wed Apr 7 13:17:05 2021 +0200

tree-optimization/99954 - fix loop distribution memcpy classification

This fixes bogus classification of a copy as memcpy.  We cannot use
plain dependence analysis to decide between memcpy and memmove when
it computes no dependence.  Instead we have to try harder later which
the patch does for the gcc.dg/tree-ssa/ldist-24.c testcase by resorting
to tree-affine to compute the difference between src and dest and
compare against the copy size.

2021-04-07  Richard Biener  

PR tree-optimization/99954
* tree-loop-distribution.c: Include tree-affine.h.
(generate_memcpy_builtin): Try using tree-affine to prove
non-overlap.
(loop_distribution::classify_builtin_ldst): Always classify
as PKIND_MEMMOVE.

* gcc.dg/torture/pr99954.c: New testcase.

(cherry picked from commit c01ae2ab6b227e21835d128c90e974dce4604be9)

[Bug tree-optimization/99880] [10 Regression] ICE in maybe_set_vectorized_backedge_value, at tree-vect-loop.c:9161 since r10-3711-g69f8c1aef5cdcc54

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:05b35bc2ba6c96ef3d468b246ab141f95694d95a

commit r10-9767-g05b35bc2ba6c96ef3d468b246ab141f95694d95a
Author: Richard Biener 
Date:   Tue Apr 6 13:20:44 2021 +0200

tree-optimization/99880 - avoid vectorizing irrelevant PHI backedge defs

This adds a relevancy check before trying to set the vector def of
a backedge in an unvectorized PHI.

2021-04-06  Richard Biener  

PR tree-optimization/99880
* tree-vect-loop.c (maybe_set_vectorized_backedge_value): Only
set vectorized defs of relevant PHIs.

* gcc.dg/torture/pr99880.c: New testcase.

(cherry picked from commit e5c170e080399fb3d24a38bbfcd66bd4675abe53)

[Bug rtl-optimization/100264] REE does not work on PARALLEL expressions with a single register SET child

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph M.  ---
A patch can be found here:
 https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568680.html

It does not show any regressions (target riscv*).

The patch does not include a new test case to demonstrate it actually works,
because I don't know a generic way to test it.
At the moment I am testing indirectly using __atomic_compare_and_exchange () on
riscv64 to emit the required store-conditional. However, the code required for
that is not merged yet. Ideas on how to test this in a more generic way are
very much appreciated.

[Bug rtl-optimization/100264] New: REE does not work on PARALLEL expressions with a single register SET child

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 100264
   Summary: REE does not work on PARALLEL expressions with a
single register SET child
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophm30 at gmail dot com
  Target Milestone: ---

REE iterates over all SET expressions and tries to eliminate redundant
zero-extensions. In case of a PARALLEL expression, there is a check in place to
ensure that "only one child of a PARALLEL expression is a SET".

Let's imagine a PARALLEL expression with two register SETs.
An example would be store-conditional, which sets a memory location (store
target) as well as a register (return success value).
The current implementation is not able to optimize a zero-extension of the
return value of store-conditional.

This can be solved, by moving the check for register targets (i.e. REG_P ())
into the function get_sub_rtx () and change the restriction of REE to "only one
child of a PARALLEL expression is a SET register".

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

[jrfsousa at gmail dot com via Gcc-bugs]

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

--- Comment #8 from José Rui Faustino de Sousa  ---
Patch (version 2) posted:

https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html

[Bug tree-optimization/100263] New: Wrong removal of statement in copyprop3

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

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

Bug ID: 100263
   Summary: Wrong removal of statement in copyprop3
   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: ---
Target: s390*-*-*

Created attachment 50676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50676=edit
copyprop3

int a = 3, d, l, o, p, q;
unsigned char b, f, g;
unsigned char c[9][9][3];
long e;
unsigned h;
short j, k;
static unsigned char r(int s) {
  for (; b-2; b=b-2) {
int *m = 
if (a) {
  char *n = [3][8][2];
  *n = 1;
  for (; h;)
for (; g;)
  for (; e;)
;
} else {
  int i = 0;
  for (; i < 2; i++)
if (*m)
  return 0;
  if (s)
l = k |= ((j-- != b) <= s) - (long)s;
  else
return f;
}
  }
  return 0;
}
int main() {
  r(b);
  if (c[3][8][2] != 1)
__builtin_abort ();
}

The outermost loop is executed 127 times. Since variable `a` does not change
from its initial value 3, the store to `c[3][8][2]` must materialize since the
infinite loops over variables h, g, e are never executed. However, running `gcc
-march=z13 t.c -O1 && ./a.out` results in an abort. Runs are successfull if
using different optimization levels than 1.

Prior to copyprop3 we have


c__lsm.20_74 = MEM[(char *) + 107B];


if (a.1_7 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

 [local count: 5160584476]:
c__lsm.20_94 = 1;
c__lsm_flag.21_95 = 1;

whereas afterwards the store to `c__lsm.20_94` is removed. Dump file contains:

Removing dead stmt c__lsm.20_94 = 1;

In total we have that the only store to `c[3][8][2]` happens in inner loop over
variable `h` which is never executed. There we have `MEM[(char *) + 107B] =
1;`.

Tested against g:3971aee9dd8d6323c377d1b241173f7d2b51a835 on IBM Z where it
fails. Runs successfully on x86 (by chance?).
Bisection stops at g:f9e1ea10e657af9fb02fafecf1a600740fd34409 which might not
be the root cause.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 98117 Summary: [8 Regression] wrong code with "-O3 -fno-tree-scev-cprop" 
since r8-1163-g7078979b291419f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98117

   What|Removed |Added

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

[Bug tree-optimization/98117] [8 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.4.1
  Known to fail||8.4.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug lto/96591] [8 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||8.4.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||8.4.1

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug lto/96385] [8 Regression] GCC generates separate debug info with undefined symbols without relocations

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.4.1
 Resolution|--- |FIXED
  Known to fail||8.4.0

--- Comment #22 from Richard Biener  ---
Fixed.

[Bug lto/96591] [8 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:d0669d6ac82726cd751b73c7fb04194b446dfd49

commit r8-10921-gd0669d6ac82726cd751b73c7fb04194b446dfd49
Author: Richard Biener 
Date:   Mon Feb 8 09:52:56 2021 +0100

lto/96591 - walk VECTOR_CST elements in walk_tree

This implements walking of VECTOR_CST elements in walk_tree, mimicing
the walk of COMPLEX_CST elements.  Without this free-lang-data fails
to see some types in case they are only refered to via tree constants
used only as VECTOR_CST elements.

2021-02-08  Richard Biener  

PR lto/96591
* tree.c (walk_tree_1): Walk VECTOR_CST elements.

* g++.dg/lto/pr96591_0.C: New testcase.

(cherry picked from commit d4536e431316b4568e236afd7a6017e5efd1b0a1)

[Bug lto/96385] [8 Regression] GCC generates separate debug info with undefined symbols without relocations

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

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:e6a720bf5b1328ff018880063ae3d1e777e5b61d

commit r8-10922-ge6a720bf5b1328ff018880063ae3d1e777e5b61d
Author: Richard Biener 
Date:   Mon Aug 3 15:05:37 2020 +0200

lto/96385 - avoid unused global UNDEFs in debug objects

Unused global UNDEFs can have side-effects in some circumstances so
the following patch avoids them by treating them the same as other
to be discarded DEFs - make them local.

2020-08-03  Richard Biener  

PR lto/96385
libiberty/
* simple-object-elf.c
(simple_object_elf_copy_lto_debug_sections): Localize global
UNDEFs and reuse the prevailing name.

(cherry picked from commit b32c5d0b72fda2588b4e170e75a9c64e4bf266c7)

[Bug tree-optimization/98117] [8 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:c6da7015827a0557108a65f384419cddd6f8ba57

commit r8-10920-gc6da7015827a0557108a65f384419cddd6f8ba57
Author: Richard Biener 
Date:   Mon Dec 7 10:29:07 2020 +0100

tree-optimization/98117 - fix range set by vectorization on niter IVs

This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
count value causing wrong range info for the vector IV.  There's
still the case of VF == 1 where if we don't know whether we hit the
above case we cannot emit a range.

2020-12-07  Richard Biener  

PR tree-optimization/98117
* tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
Properly handle degenerate niter when setting the vector
loop IV range.

* gcc.dg/torture/pr98117.c: New testcase.

(cherry picked from commit 69894ce172412996c10c89838717980ede7c9003)

[Bug libstdc++/100243] [10 Regression] invalid use of incomplete type 'std::__detail::__iter_traits >' {aka 'struct std::indirectly_readable_traits'}

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jonathan Wakely  ---
Confirmed as fixed on the branch already.

[Bug libstdc++/100238] [11/12 Regression] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Jonathan Wakely  ---
I can't reproduce this using a x86_64-w64-mingw32 cross compiler on a linux
host.

Are you sure you did a clean build, not an incremental re-build? 

(In reply to Markus Böck from comment #0)
> /mnt/c/GCC-Build-Array/gcc/build-target-x86_64/x86_64-w64-mingw32/libstdc++-
> v3/src/debug/c++98/atomicity.cc:36: multiple definition of
> `__gnu_cxx::__exchange_and_add(int volatile*, int)';

This file should no longer exist. It looks like you didn't build in a clean
directory, and have an old symlink around from before the functions moved from
libc++98convenience.a to libsupc++.a

[Bug rtl-optimization/100254] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-guess-branch-probability -fipa-pta -fnon-call-exceptions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50675=edit
gcc11-pr100254.patch

Untested fix.

[Bug libstdc++/100259] ODR violations in

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:3f4aa4579a6c03e0a0b0a6aec68aa5a301264d45

commit r12-120-g3f4aa4579a6c03e0a0b0a6aec68aa5a301264d45
Author: Jonathan Wakely 
Date:   Mon Apr 26 11:37:38 2021 +0100

libstdc++: Add missing 'inline' specifiers to net::ip functions [PR 100259]

libstdc++-v3/ChangeLog:

PR libstdc++/100259
* include/experimental/internet (net::ip::make_error_code)
(net::ip::make_error_condition, net::ip::make_network_v4)
(net::ip::operator==(const udp&, const udp&)): Add 'inline'.

[Bug libfortran/98301] random_init() is broken

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #11 from Andre Vehreschild  ---
Waiting for review/acceptance.

[Bug libfortran/98301] random_init() is broken

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

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

--- Comment #10 from Andre Vehreschild  ---
Created attachment 50674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50674=edit
Delta from Steve's patch to one submitted for acceptance to implement
random_init for coarray=shared.

[Bug ada/100251] byte order mark in gnat.adc raises compilation error

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2021-04-26
Summary|Byte order mark in gnat.adc |byte order mark in gnat.adc
   |raises compilation error|raises compilation error
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
I guess essentially nobody puts a BOM, as it is neither required nor
recommended with UTF-8, let alone in the gnat.adc file.

[Bug target/100257] poor codegen with vcvtph2ps / stride of 6

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
> const __m128i in = _mm_setr_epi16(val_0, val_1, val_2, 0, 0, 0, 0, 0);

in ix86_expand_vector_init, we can generate asm like 


  vmovd val_0, %xmm0
  pinsrw $1, val_1, %xmm0
  pinsrw $2, val_2, %xmm0

and let rtl's optimization "merge" val_0 and val_1 since they come from
contiguous memory)

[Bug debug/100254] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-guess-branch-probability -fipa-pta -fnon-call-exceptions

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

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

--- Comment #2 from Jakub Jelinek  ---
I think the problem is during Cross-jumping in jump2 pass, so the r11-5391
change just likely triggered a latent problem.  Will have a look in detail
soon.

[Bug libstdc++/100259] ODR violations in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
(In reply to Aaron Graham from comment #0)
> It seems these should be inline and/or constexpr.

They're not allowed to be constexpr, so have to be inline.

> There are probably others.

Almost certainly.

[Bug libstdc++/100233] [10/11/12] std::views::elements only accepts types that are defined on std::get

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to gcc-bugs from comment #0)
> https://eel.is/c++draft/range.elements#iterator-3
> 
> With some good-will you could say that `get` should be called unqualified :)

Nope, that call is required to be std::get.

https://eel.is/c++draft/contents#3

The standard does not support user-defined tuple types that have a get overload
in their own namespace.

[Bug c++/55578] Disabling warnings inside macro definition doesn't work

[vz-gcc at zeitlins dot org via Gcc-bugs]

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

Vadim Zeitlin  changed:

   What|Removed |Added

 CC||vz-gcc at zeitlins dot org

--- Comment #8 from Vadim Zeitlin  ---
For the record: with gcc 11 this bug now affects the existing code using
pragmas to locally suppress -Wsuggest-override, i.e. the warning is not
suppressed any longer, even though it used to work in all versions since gcc 5,
so not only this bug is still present, but it got worse in the latest version.

[Bug libstdc++/100243] [10 Regression] invalid use of incomplete type 'std::__detail::__iter_traits >' {aka 'struct std::indirectly_readable_traits'}

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

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

--- Comment #1 from Jonathan Wakely  ---
It should be already fixed on the branch by
32a859531e854382c18abf0b14a306d83f793eb5

[Bug c/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Keywords||diagnostic
 Target||sparc64

--- Comment #2 from Richard Biener  ---
Can you provide preprocessed source?

[Bug c++/100261] [11/12 Regression] ICE: tree check: expected var_decl or type_decl, have error_mark in emit_tinfo_decl, at cp/rtti.c:1643

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2
   Target Milestone|--- |11.2
   Last reconfirmed||2021-04-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to work||10.3.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/100260] DSE: join stores

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Last reconfirmed||2021-04-26

--- Comment #1 from Richard Biener  ---
Confirmed.  store-merging doesn't seem to consider memset() as candidate to
merge with:

Processing basic block <2>:
Starting active chain number 1 with statement:
s_pam.size = 1;
The base object is:
_pam
stmt causes chain termination:
_1 = use (_pam);
Terminating chain with 1 stores

unsigned int foo ()
{
  struct pam s_pam;
  int _1;
  unsigned int _6;

   [local count: 1073741824]:
  memset (_pam, 0, 20);
  s_pam.size = 1;
  _1 = use (_pam);
  _6 = (unsigned int) _1;
  s_pam ={v} {CLOBBER};
  return _6;

}

[Bug libstdc++/100238] [11/12 Regression] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-26
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
Summary|[11/12] Link failure in |[11/12 Regression] Link
   |debug libstdc++ on MinGW|failure in debug libstdc++
   |due to atomicitiy.cc|on MinGW due to
   ||atomicitiy.cc

--- Comment #1 from Jonathan Wakely  ---
This will be due to 6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c

[Bug target/100258] constant store pulled out of the loop causes an extra memory load

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

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

--- Comment #1 from Richard Biener  ---
Is it really so much more efficient?  The store from reg is 4 bytes
while a movl is 6 - for a larger loop keeping its size small would be
important.