[Bug c++/97671] ICE: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have parm_decl in push_template_decl, at cp/pt.c:6102

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-03

--- Comment #1 from Martin Liška  ---
Confirmed, likely started with GCC 5.1.0.

Re: [Bug c/97578] ice during IPA pass: inline

[Jan Hubicka]

> It needs to refer to the DW_TAG_formal_parameter DIEs, and only the PARM_DECLs
> map to those.
It has problem with the partitioning (if we call a callee from different
parititon) and also if the callee is compiled before caller (as it
should) we will call cgraph_node::release_body and that will likely
remove pointer to them.

[Bug c/97578] ice during IPA pass: inline

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #10 from Jan Hubicka  ---
> It needs to refer to the DW_TAG_formal_parameter DIEs, and only the PARM_DECLs
> map to those.
It has problem with the partitioning (if we call a callee from different
parititon) and also if the callee is compiled before caller (as it
should) we will call cgraph_node::release_body and that will likely
remove pointer to them.

[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
IMHO sth reasonable to do for phiopt which already value-replaces other
forms of true/false so it shouldn't be too hard to add.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2020-11-03

--- Comment #3 from Richard Biener  ---
Ah.  So I guess

diff --git a/gcc/testsuite/gcc.dg/vect/tree-vect.h
b/gcc/testsuite/gcc.dg/vect/tree-vect.h
index 5d8d9eba3f8..c4b81441216 100644
--- a/gcc/testsuite/gcc.dg/vect/tree-vect.h
+++ b/gcc/testsuite/gcc.dg/vect/tree-vect.h
@@ -52,7 +52,7 @@ check_vect (void)
 want_level = 1, want_d = bit_SSE2;
 # endif

-if (!__get_cpuid (want_level, , , , )
+if (!__get_cpuid_count (want_level, 0, , , , )
|| ((b & want_b) | (c & want_c) | (d & want_d)) == 0)
   exit (0);
   }

will work.

[Bug target/70210] -march=native and -mcpu=native do not detect ARM cortex-a53 in 32 bit mode on Linux

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Viktor Engelmann from comment #3)
> I see a (probably related) problem in gcc 9.3 on docker image alpine:latest
> on raspberry pi 3. There, Makefiles generated by autoconf pass -mcpu=armv7l.
> And you can't just force it to use a different cpu by passing --host= to
> ./configure in your Dockerfile, because that would break the Dockerfiles'
> cross-platform compatibility. This breaks all autoconf projects in docker on
> raspberry pi 3.
> 
> This shouldn't be that hard IMHO, because -mcpu=armv7l only needs to be
> reinterpreted as -mcpu=cortex-a53.

That's not correct usage though. -mcpu isn't documented to accepted
architecture names (see
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/ARM-Options.html#ARM-Options for
the accepted list of arguments accepted by mcpu/mtune)

There is the option -march that accepts architecture names, but armv7l isn't a
valid architecture either. I'm not familiar with what Docker does here, but
from the aarch32 GCC backend perspective the architecture for Cortex-A53 is
-march=armv8-a+crc+simd

BTW, I believe the original bug in this report has been fixed for some time.
All currently supported GCC versions (GCC 8.4 onwards) have the right part
number for Cortex-A53

[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1

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

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

--- Comment #2 from Jonathan Wakely  ---
More generally, Clang seems to reliably turn

cond ? (2<

[Bug fortran/97692] GNU Fortran is not working

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
aarch64-xilinx-linux-gfortran: command not found
seems like user error.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #2 from Richard Biener  ---
Hmm, it doesn't work on a i7-8565U either ...

Doesn't work means check_vect () does exit (0).  Those do not end up
UNSUPPORTED (not sure if using a magic exit code to communicate this
would be possible).

Looks like $rcx is not cleared before 'cpuid' and we get garbage?!

If I set $rcx to zero it works.  The comment in cpuid.h says

/* At least one cpu (Winchip 2) does not set %ebx and %ecx
   for cpuid leaf 1. Forcibly zero the two registers before
   calling cpuid as a precaution.  */

but it does the clearing only for constant level (doesn't work at -O0
which is where I debugged check_vect).  At -O2 I see

Dump of assembler code for function check_vect:
   0x00400680 <+0>: push   %rbx
   0x00400681 <+1>: mov$0x4006c0,%esi
   0x00400686 <+6>: mov$0x4,%edi
   0x0040068b <+11>:callq  0x400490 
=> 0x00400690 <+16>:xor%eax,%eax
   0x00400692 <+18>:cpuid  
   0x00400694 <+20>:cmp$0x6,%eax
   0x00400697 <+23>:jbe0x4006a5 
   0x00400699 <+25>:mov$0x7,%eax
   0x0040069e <+30>:cpuid  
   0x004006a0 <+32>:and$0x20,%ebx
   0x004006a3 <+35>:jne0x4006ac 
   0x004006a5 <+37>:xor%edi,%edi
   0x004006a7 <+39>:callq  0x4004a0 
   0x004006ac <+44>:xor%esi,%esi
   0x004006ae <+46>:mov$0x4,%edi
   0x004006b3 <+51>:pop%rbx
   0x004006b4 <+52>:jmpq   0x400490 

so no zeroing of the regs of the result of the __maxlevel call and
we call cpuid with

rax0x7 7
rbx0x68747541  1752462657
rcx0x444d4163  1145913699
rdx0x69746e65  1769238117
rsi0x7fffd8b0  140737488345264
rdi0x0 0

and on zen2 get

rax0x0 0
rbx0x0 0
rcx0x0 0
rdx0x0 0

on i7-8565U the garbage is similar:

rax  0x7
rbx  0x756e6547
rcx  0x6c65746e
rdx  0x49656e69

with same all-zero result.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

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

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

commit r9-9021-ge42cb1d48035b85a43adb202433ff0193c151410
Author: Richard Biener 
Date:   Tue Nov 3 10:24:02 2020 +0100

testsuite/97688 - fix check_vect () with __AVX2__

This fixes the cpuid check to always specify a subleaf zero
which is required to detect AVX2 and doesn't hurt for level one.
Without this fix we get zero runtime coverage when -mavx2 is
specified.

2020-11-03  Richard Biener  

PR testsuite/97688
* gcc.dg/vect/tree-vect.h (check_vect): Fix the x86 cpuid
check to always specify subleaf zero.

(cherry picked from commit 8414529156e0bca37647c440c71beeca1d04ac86)

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

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

https://gcc.gnu.org/g:725244355f83de56f8692abc6c0e1b3d4d248198

commit r10-8968-g725244355f83de56f8692abc6c0e1b3d4d248198
Author: Richard Biener 
Date:   Tue Nov 3 10:24:02 2020 +0100

testsuite/97688 - fix check_vect () with __AVX2__

This fixes the cpuid check to always specify a subleaf zero
which is required to detect AVX2 and doesn't hurt for level one.
Without this fix we get zero runtime coverage when -mavx2 is
specified.

2020-11-03  Richard Biener  

PR testsuite/97688
* gcc.dg/vect/tree-vect.h (check_vect): Fix the x86 cpuid
check to always specify subleaf zero.

(cherry picked from commit 8414529156e0bca37647c440c71beeca1d04ac86)

[Bug fortran/97692] New: GNU Fortran is not working

[nju044 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97692
   Summary: GNU Fortran is not working
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nju044 at hotmail dot com
  Target Milestone: ---

Created attachment 49492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49492=edit
build error log

I'm integrating meta-ros into xilinx zynqmp.

Console output snapshot:
| checking whether -lc should be explicitly linked in... no
| checking dynamic linker characteristics... GNU/Linux ld.so
| checking how to hardcode library paths into programs... immediate
| checking for shl_load... no
| checking for shl_load in -ldld... no
| checking for dlopen... no
| checking for dlopen in -ldl... yes
| checking whether a program can dlopen itself... cross
| checking whether stripping libraries is possible... yes
| checking if libtool supports shared libraries... yes
| checking whether to build shared libraries... yes
| checking whether to build static libraries... no
| checking for aarch64-xilinx-linux-gfortran... aarch64-xilinx-linux-gfortran 
-march=armv8-a+crc -mtune=cortex-a72.cortex-a53 -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
| checking whether we are using the GNU Fortran compiler... no
| checking whether aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
accepts -g... no
| checking if libtool supports shared libraries... yes
| checking whether to build shared libraries... yes
| checking whether to build static libraries... no
| libtool.m4: error: problem compiling FC test program
| checking for aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
option to produce PIC...
| checking if aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
static flag  works... no
| checking if aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
supports -c -o file.o... no
| checking if aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
supports -c -o file.o... (cached) no
| checking whether the aarch64-xilinx-linux-gfortran  -march=armv8-a+crc
-mtune=cortex-a72.cortex-a53 -fstack-protector-strong  -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
linker (aarch64-xilinx-linux-ld
--sysroot=/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
) supports shared libraries... yes
| checking dynamic linker characteristics... (cached) GNU/Linux ld.so
| checking how to hardcode library paths into programs... immediate
| checking whether the GNU Fortran compiler is working... no
| configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/gcc-9.2.0/build.aarch64-xilinx-linux.aarch64-xilinx-linux/aarch64-xilinx-linux/libgfortran/config.log

[Bug fortran/97692] GNU Fortran is not working

[nju044 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from ninos  ---
Created attachment 49493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49493=edit
gfortran config log

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

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

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

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

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

commit r11-4652-gac6affba97130bcbffb21bd9f8ca53c7aac89551
Author: Richard Biener 
Date:   Tue Nov 3 11:52:47 2020 +0100

tree-optimization/80928 - SLP vectorize nested loop induction

This adds SLP vectorization of nested inductions.

2020-11-03  Richard Biener 

PR tree-optimization/80928
* tree-vect-loop.c (vectorizable_induction): SLP vectorize
nested inductions.

* gcc.dg/vect/vect-outer-slp-2.c: New testcase.
* gcc.dg/vect/vect-outer-slp-3.c: Likewise.

[Bug tree-optimization/97666] [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

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

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

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

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

commit r11-4653-g9d1b813d0f7c9a8d80b0aee6eb1418b0afdf0f84
Author: Richard Biener 
Date:   Tue Nov 3 12:06:19 2020 +0100

bootstrap/97666 - fix array of bool allocation

This fixes the bad assumption that sizeof (bool) == 1

2020-11-03  Richard Biener  

PR bootstrap/97666
* tree-vect-slp.c (vect_build_slp_tree_2): Scale
allocation of skip_args by sizeof (bool).

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #12 from H.J. Lu  ---
Created attachment 49495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49495=edit
Something like this.

[Bug tree-optimization/97691] [11 regression] pr91293-3.c fails since r11-4614

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Any chance that it is fixed by f53e9d40de7212413b361758d66aafb833173dd9?

[Bug target/97642] Incorrect replacement of vmovdqu32 with vpblendd can cause fault

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

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

--- Comment #4 from Jakub Jelinek  ---
Ok, but please also during expansion try to detect the all ones mask case and
already during expansion emit normal non-masked load (+ we need a
define_insn_and_split for it with pre-reload splitting just in case it gets
propagated in combine).

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #3)
> Ah.  So I guess
> 
> diff --git a/gcc/testsuite/gcc.dg/vect/tree-vect.h
> b/gcc/testsuite/gcc.dg/vect/tree-vect.h
> index 5d8d9eba3f8..c4b81441216 100644
> --- a/gcc/testsuite/gcc.dg/vect/tree-vect.h
> +++ b/gcc/testsuite/gcc.dg/vect/tree-vect.h
> @@ -52,7 +52,7 @@ check_vect (void)
>  want_level = 1, want_d = bit_SSE2;
>  # endif
>  
> -if (!__get_cpuid (want_level, , , , )
> +if (!__get_cpuid_count (want_level, 0, , , , )
> || ((b & want_b) | (c & want_c) | (d & want_d)) == 0)
>exit (0);
>}
> 
> will work.

Exactly.  The patch is pre-approved.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed everywhere.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

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

https://gcc.gnu.org/g:80b6f6cf6374a6541a7515d7bfef1a3506db2a3d

commit r8-10606-g80b6f6cf6374a6541a7515d7bfef1a3506db2a3d
Author: Richard Biener 
Date:   Tue Nov 3 10:24:02 2020 +0100

testsuite/97688 - fix check_vect () with __AVX2__

This fixes the cpuid check to always specify a subleaf zero
which is required to detect AVX2 and doesn't hurt for level one.
Without this fix we get zero runtime coverage when -mavx2 is
specified.

2020-11-03  Richard Biener  

PR testsuite/97688
* gcc.dg/vect/tree-vect.h (check_vect): Fix the x86 cpuid
check to always specify subleaf zero.

(cherry picked from commit 8414529156e0bca37647c440c71beeca1d04ac86)

[Bug tree-optimization/97678] [11 regression] execution fail for gcc.target/powerpc/p9-vec-length-epil-run-5.c after r11-4614

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1

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

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

--- Comment #1 from Jonathan Wakely  ---
It seems to be target-independent. For aarch64, -O3 and -Os both give:

f(bool):
tst w0, 255
csetw0, ne
lsl w0, w0, 1
ret
g(bool):
ubfiz   w0, w0, 1, 8
ret


And avr -Os is horrible:

__zero_reg__ = 1
f(bool):
cpse r24,__zero_reg__
rjmp .L3
ldi r25,0
ldi r24,0
ret
.L3:
ldi r24,lo8(2)
ldi r25,0
ret
g(bool):
ldi r25,0
lsl r24
rol r25
ret

[Bug tree-optimization/97690] New: (cond ? 2 : 0) is not optimized to int(cond) << 1

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

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

Bug ID: 97690
   Summary: (cond ? 2 : 0) is not optimized to int(cond) << 1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

enum E { init=0, active=1, done=2 };

int f(bool d)
{
return d ? done : init;
}

int g(bool d)
{
return int(d) << 1;
}

The first function is more readable and less fragile (in case the order of bits
is changed) but GCC produces larger code for it.

For x86_64 with -O3:

f(bool):
xor eax, eax
testdil, dil
setne   al
add eax, eax
ret
g(bool):
movzx   eax, dil
add eax, eax
ret

And for x86_64 -Os:

f(bool):
neg dil
sbb eax, eax
and eax, 2
ret
g(bool):
movzx   eax, dil
add eax, eax
ret


Clang produces the same code for both functions at all optimization levels:

f(bool):  # @f(bool)
lea eax, [rdi + rdi]
ret
g(bool):  # @g(bool)
lea eax, [rdi + rdi]
ret

[Bug c/97578] ice during IPA pass: inline

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r11-4648-gf89dcf93348b44b8ea2b57f940fcdaeae0f764f6
Author: Jan Hubicka 
Date:   Tue Nov 3 11:56:05 2020 +0100

Avoid recursion in tree-inline

gcc/ChangeLog:

2020-11-03  Jan Hubicka  

PR ipa/97578
* ipa-inline-transform.c (maybe_materialize_called_clones): New
function.
(inline_transform): Use it.

gcc/testsuite/ChangeLog:

2020-11-03  Jan Hubicka  

* gcc.c-torture/compile/pr97578.c: New test.

[Bug tree-optimization/97693] New: [11 Regression] SVE: ICE in prepare_load_store_mask, at tree-vect-stmts.c since r11-1143-gb05d5563

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

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

Bug ID: 97693
   Summary: [11 Regression] SVE: ICE in prepare_load_store_mask,
at tree-vect-stmts.c since r11-1143-gb05d5563
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following C testcase:

extern short a[];
int b;
short c, d;
unsigned e() {
  if (c)
return c;
  return d;
}
void f() {
  for (unsigned g = b; g; g += 6)
for (_Bool h = 0; h < (_Bool)e(); h = 1)
  a[g] = 1 / b;
}

AArch64 GCC ICEs with -O3 -march=armv8.2-a+sve since
r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0. To reproduce:

$ aarch64-elf-gcc -c -O3 -march=armv8.2-a+sve test.c
during GIMPLE pass: vect
test.c: In function 'f':
test.c:9:6: internal compiler error: in prepare_load_store_mask, at
tree-vect-stmts.c:1758
9 | void f() {
  |  ^
0x106d15f prepare_load_store_mask
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:1758
0x108784a vectorizable_call
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:3440
0x109972f vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:10838
0x109ffbc vect_transform_loop_stmt
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:8933
0x10bd364 vect_transform_loop(_loop_vec_info*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:9367
0x10e9a7e try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1091
0x10ea1ab try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1148
0x10ea585 vectorize_loops()
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1229
0xf76a5b execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97693] [11 Regression] SVE: ICE in prepare_load_store_mask, at tree-vect-stmts.c since r11-1143-gb05d5563

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Known to fail||11.0
   Target Milestone|--- |11.0
 Target||aarch64

[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales

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

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

--- Comment #1 from Matthew Malcomson  ---
I guess this may also happen for the emission of ASAN_MARK in
`gimple_target_expr`, but haven't yet been able to trigger that.

[Bug c++/97670] [11 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in finish_omp_clauses, at cp/semantics.c:8251 since r11-4471-g3a8b20947f2b1559

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Known to fail||11.0
Summary|[11 Regression] ICE: tree   |[11 Regression] ICE: tree
   |check: expected tree that   |check: expected tree that
   |contains 'decl minimal' |contains 'decl minimal'
   |structure, have 'mem_ref'   |structure, have 'mem_ref'
   |in finish_omp_clauses, at   |in finish_omp_clauses, at
   |cp/semantics.c:8251 |cp/semantics.c:8251 since
   ||r11-4471-g3a8b20947f2b1559
 Ever confirmed|0   |1
  Known to work||10.2.0
   Last reconfirmed||2020-11-03
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r11-4471-g3a8b20947f2b1559.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
AVX2 should be detected using __get_cpuid_count, because a sub-leaf needs to be
specified for leaf 7.

[Bug c/97689] New: (ceilf(begin/(float)tstep))*tstep

[jkaltes at hotmail dot nl via Gcc-bugs]

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

Bug ID: 97689
   Summary: (ceilf(begin/(float)tstep))*tstep
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jkaltes at hotmail dot nl
  Target Milestone: ---

Created attachment 49490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49490=edit
.i file

#include 
#include 


int main() {
unsigned int begin=1604288179,tstep=3600;
unsigned int first=(ceilf(begin/(float)tstep))*tstep;
unsigned int first2=((unsigned int)ceilf(begin/(float)tstep))*tstep;
printf("%d %d\n",first,first2);

}
./a.out
gives:
1604289536 1604289600

[Bug c/97689] (ceilf(begin/(float)tstep))*tstep

[jkaltes at hotmail dot nl via Gcc-bugs]

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

--- Comment #1 from Jaap Korthals Altes  ---
Created attachment 49491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49491=edit
gcc -v

[Bug c++/97658] Tired of having to change make files on every new version. Damnit!

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

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

--- Comment #4 from Jonathan Wakely  ---
Nonsense. Your code is buggy, the warning tells you about it.

If you don't want to know that your code has undefined behaviour, don't enable
warnings.

[Bug c++/97658] Tired of having to change make files on every new version. Damnit!

[hubert.vansteenhuyse at freecode dot be via Gcc-bugs]

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

--- Comment #3 from hubert.vansteenhuyse at freecode dot be ---
You are killing that marvelous gcc compiler by doing this, this is my point.

[Bug tree-optimization/97691] New: [11 regression] pr91293-3.c fails since r11-4614

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

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

Bug ID: 97691
   Summary: [11 regression] pr91293-3.c fails since r11-4614
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since commit r11-4614 (g:e881774d0dda6d5127eb8f0642f6edc16dc0b1e7), I've
noticed:
FAIL: gcc.dg/vect/pr91293-3.c execution test
on arm and aarch64

[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 80928, which changed state.

Bug 80928 Summary: SLP vectorization does not handle induction in outer loop 
vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928

   What|Removed |Added

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

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #33 from Richard Biener  ---
Now fixed.

[Bug tree-optimization/97666] [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed I think.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 3 Nov 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97688
> 
> --- Comment #10 from H.J. Lu  ---
> FWIW, x86 source in gcc testsuite should be converted to
> __builtin_cpu_supports().

The check_vect () is quite convenient since it allows you to
build-test with target support you cannot run on via
--target_board=unix/-mavx512f for example (well, it is
incomplete and support for avx512 testing hasn't been added).

I don't see how the same functionality can be achieved with
a series of __builtin_cpu_supports checks (unless we only
adjust tree-vect.h to do

# if defined(__AVX2__)
  if (!__builtin_cpu_supports ("magic"))
exit (0);
# ...

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-03
   Keywords||needs-bisection, wrong-code
   Target Milestone|--- |11.0
  Component|tree-optimization   |ipa
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|wrong code at -O3 on|[11 Regression] wrong code
   |x86_64-pc-linux-gnu |at -O3 on
   ||x86_64-pc-linux-gnu
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
Confirmed.  Somehow IPA ends up with

  iftmp.0_20 = d.1_13 / h_17(D);

which is a parameter that is dropped.  -fno-ipa-cp avoids the issue.

[Bug tree-optimization/97693] [11 Regression] SVE: ICE in prepare_load_store_mask, at tree-vect-stmts.c since r11-1143-gb05d5563

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Keywords||ice-on-valid-code

--- Comment #1 from Richard Biener  ---
Somebody familiar with the prepare_load_store_mask code needs to look (ISTR a
duplicate in the same area).

[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Schwinge
:

https://gcc.gnu.org/g:5ceaf8a54abb3f9bd3c268fe420999a7962b2a15

commit r10-8965-g5ceaf8a54abb3f9bd3c268fe420999a7962b2a15
Author: Thomas Schwinge 
Date:   Tue Oct 27 17:14:10 2020 +0100

[Fortran] More precise location information for OpenACC 'gang', 'worker',
'vector' clauses with argument [PR92793]

gcc/fortran/
PR fortran/92793
* trans-openmp.c (gfc_trans_omp_clauses): More precise location
information for OpenACC 'gang', 'worker', 'vector' clauses with
argument.
gcc/testsuite/
PR fortran/92793
* gfortran.dg/goacc/pr92793-1.f90: Adjust.

(cherry picked from commit 41f7f6178e2d35288273656dc55dae8fcf3edeb5)

[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:41f7f6178e2d35288273656dc55dae8fcf3edeb5

commit r11-4639-g41f7f6178e2d35288273656dc55dae8fcf3edeb5
Author: Thomas Schwinge 
Date:   Tue Oct 27 17:14:10 2020 +0100

[Fortran] More precise location information for OpenACC 'gang', 'worker',
'vector' clauses with argument [PR92793]

gcc/fortran/
PR fortran/92793
* trans-openmp.c (gfc_trans_omp_clauses): More precise location
information for OpenACC 'gang', 'worker', 'vector' clauses with
argument.
gcc/testsuite/
PR fortran/92793
* gfortran.dg/goacc/pr92793-1.f90: Adjust.

[Bug c/97689] (ceilf(begin/(float)tstep))*tstep

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Richard Biener  ---
What do you expect? 445636*3600 isn't exact representable in float but it is
in unsigned int.

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

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

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

--- Comment #14 from Richard Biener  ---
The following works with and without -flto (fixes the endless loop without
and the execute fail with)

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7129dcbe6d..4643fff243f 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2647,6 +2647,8 @@ gfc_get_derived_type (gfc_symbol * derived, int codimen)
   typenode = make_node (RECORD_TYPE);
   TYPE_NAME (typenode) = get_identifier (derived->name);
   TYPE_PACKED (typenode) = flag_pack_derived;
+  if (!got_canonical)
+   SET_TYPE_STRUCTURAL_EQUALITY (typenode);
   derived->backend_decl = typenode;
 }

[Bug fortran/97694] New: ICE with optional assumed rank class(*) argument

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 97694
   Summary: ICE with optional assumed rank class(*) argument
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 49494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49494=edit
Fortran source code

The attached code crashs with an ICE. It requires that the argument has type
class(*) and is optional.

classstar_rank.f90:14:0:

   14 |  s = '0'
  | 
internal compiler error: Segmentation fault
0xbe205f crash_signal
../../gcc-repo/gcc/toplev.c:328
0x793007 trans_associate_var
../../gcc-repo/gcc/fortran/trans-stmt.c:1765
0x798fe1 gfc_trans_block_construct(gfc_code*)
../../gcc-repo/gcc/fortran/trans-stmt.c:2283
0x724950 trans_code
../../gcc-repo/gcc/fortran/trans.c:1960
0x79a89f gfc_trans_select_rank_cases
../../gcc-repo/gcc/fortran/trans-stmt.c:3703
0x79a89f gfc_trans_select_rank(gfc_code*)
../../gcc-repo/gcc/fortran/trans-stmt.c:3758
0x724aa3 trans_code
../../gcc-repo/gcc/fortran/trans.c:1984
0x798f70 gfc_trans_block_construct(gfc_code*)
../../gcc-repo/gcc/fortran/trans-stmt.c:2276
0x724950 trans_code
../../gcc-repo/gcc/fortran/trans.c:1960
0x791065 gfc_trans_if_1
../../gcc-repo/gcc/fortran/trans-stmt.c:1448
0x798a8b gfc_trans_if(gfc_code*)
../../gcc-repo/gcc/fortran/trans-stmt.c:1480
0x724b23 trans_code
../../gcc-repo/gcc/fortran/trans.c:1952
0x74dd44 gfc_generate_function_code(gfc_namespace*)
../../gcc-repo/gcc/fortran/trans-decl.c:6835
0x728571 gfc_generate_module_code(gfc_namespace*)
../../gcc-repo/gcc/fortran/trans.c:2264
0x6ca905 translate_all_program_units
../../gcc-repo/gcc/fortran/parse.c:6293
0x6ca905 gfc_parse_file()
../../gcc-repo/gcc/fortran/parse.c:6545
0x721c4f gfc_be_parse_file
../../gcc-repo/gcc/fortran/f95-lang.c:210

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #10 from H.J. Lu  ---
FWIW, x86 source in gcc testsuite should be converted to
__builtin_cpu_supports().

[Bug sanitizer/97696] New: ICE since ASAN_MARK does not handle poly_int sized varibales

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

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

Bug ID: 97696
   Summary: ICE since ASAN_MARK does not handle poly_int sized
varibales
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

asan_expand_mark_ifn asserts that the length to check is a SHWI.
(i.e. it uses `gcc_assert (tree_fits_shwi_p (len))` ).

It attempts to ensure this by avoiding VLA's in `gimplify_decl_expr`.
poly_int sized decls were added, and they were not treated as VLA's since
commit 22b62991 (SVN r275870).

Since then, poly_int sized variables can have ASAN_MARK called on them, which
means the `len` parameter of ASAN_MARK can be a poly_int causing an ICE in
asan_expand_mark_ifn  (n.b. in order to emit an ASAN_CHECK on a poly_int sized
variable so that the ASAN_MARK is not removed in the sanopt pass we need to
pass the poly_int sized variable to a builtin memory function).


An example  (modified from gcc/testsuite/c-c++-common/asan/pr80308.c):



(v3) work-lin:gcc [Tue 12:25:10] % cat ~/asan-ice.c
#include 

__attribute__((noinline, noclone)) int
foo (char *a)
{
  int i, j = 0;
  asm volatile ("" : "+r" (a) : : "memory");
  for (i = 0; i < 12; i++)
j += a[i];
  return j;
}

int
main ()
{
  int i, j = 0;
  for (i = 0; i < 4; i++)
{
  char a[12];
  __SVInt8_t freq;
  __builtin_bcmp (, a, 10);
  __builtin_memset (a, 0, sizeof (a));
  j += foo (a);
}
  return j;
}


(v3) work-lin:gcc [Tue 12:31:53] %
/installdir/aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc
-march=armv8.6-a+sve -fsanitize=address -fsanitize-address-use-after-scope
~/asan-ice.c -S  -o /dev/null
during GIMPLE pass: sanopt
/home/matmal01/asan-ice.c: In function ‘main’:
/home/matmal01/asan-ice.c:14:1: internal compiler error: in
asan_expand_mark_ifn, at asan.c:3235
   14 | main ()
  | ^~~~
0xdde454 asan_expand_mark_ifn(gimple_stmt_iterator*)
/builddir/src/gcc/gcc/asan.c:3235
0xdf6b7a execute
/builddir/src/gcc/gcc/sanopt.c:1341
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/97697] New: Segmentation fault on while (true) loop

[marcin.jachu19 at gmail dot com via Gcc-bugs]

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

Bug ID: 97697
   Summary: Segmentation fault on while (true) loop
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.jachu19 at gmail dot com
  Target Milestone: ---

Created attachment 49496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49496=edit
source file

May be a duplicate of 97627, but this time it seg faults, -fwrapv doesn't help
and there is only one for loop inside. It seems to not reach the end of the
while(true) loop and crashes just before. Observed on gcc 9.x and 10.x (all
versions). 

GCC version (in practice any 9.x and 10.x):
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --enable-languages=c,c++
--enable-multilib
Thread model: posix
gcc version 9.2.0 (GCC)
GNU C++17 (GCC) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8, isl version none

System type (doesn't matter, any Linux, for this example used):
centos-release-7-7.1908.0.el7.centos.x86_64

GCC compilation options:
../gcc-9.2.0/configure --enable-languages=c,c++ --enable-multilib

Test compilation options:
g++ -Wall -Wextra -fPIC -O2 -std=c++17 -o test test.cpp

Compiler output:
(none)

Source files attached, the problematic part:

for (unsigned int nrn_idx = 0; nrn_idx < nrn_pass_num; ++nrn_idx)
{
bar();
}
baz();

Expected behavior:
test enters the end of the loop and prints "all OK"

Actual behavior:
Segmentation fault (core dumped)

Command line
./test

More comments:
- gcc 8.x works OK on this example
- gcc trunk works OK as well
- -fwrapv doesn't change anything, it was helping in 97627
- -O1 works fine

I hoped we can move from 8.x to 9.x using -fwrapv workaround, but it doesn't
help here. Can you please suggest any temporal workaround other than -O1 ?

[Bug fortran/97694] ICE with optional assumed rank class(*) argument

[mscfd at gmx dot net via Gcc-bugs]

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

martin  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91926

--- Comment #1 from martin  ---
There are two resolved bug reports which are very similar, bug 61881 and bug
91926. At least bug 91926 is working fine. The other is pretty old and lacks
the optional attribute.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug target/70210] -march=native and -mcpu=native do not detect ARM cortex-a53 in 32 bit mode on Linux

[Viktor.Engelmann at googlemail dot com via Gcc-bugs]

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

--- Comment #5 from Viktor Engelmann  
---
Hmmm the problem isn't related to docker - I get the same problem when I run
gcc on the raspberry directly with -mcpu=armv7l as autoconf does in docker.

When I run gcc manually with -mcpu=cortex-a53, everything is fine.
lscpu says

Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   4
Model name:  Cortex-A53
Stepping:r0p4
CPU max MHz: 1200.
CPU min MHz: 600.
BogoMIPS:38.40
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva
idivt vfpd32 lpae evtstrm crc32

and /proc/cpuinfo is basically the same as the one Andrew Roberts had posted.
Maybe it's a problem in autoconf for passing armv7l (the "Architecture:" line)
to -mcpu.

[Bug c++/97632] unhelpful -Winit-list-lifetime warning for default-initialized object in unevaluated context

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug middle-end/92936] missing warning on a past-the-end store to a PHI

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-03
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557807.html

[Bug c++/97670] [11 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in finish_omp_clauses, at cp/semantics.c:8251 since r11-4471-g3a8b20947f2b1559

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/97703] New: [11 Regression] ICE in fix_reg_equiv_init at gcc/ira.c:2683

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

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

Bug ID: 97703
   Summary: [11 Regression] ICE in fix_reg_equiv_init at
gcc/ira.c:2683
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, rdsandiford at googlemail dot 
com,
rearnsha at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

The following fails:

$ arm-linux-gnueabi-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c
-mcpu=cortex-r4f -Ofast -fno-toplevel-reorder -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c: In
function ‘test_op_ignore’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:80:10:
note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4
   80 |   (void) __sync_fetch_and_nand (, 1);
  |  ^
during RTL pass: ira
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:90:1:
internal compiler error: Segmentation fault
   90 | }
  | ^
0xb0e06f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/toplev.c:330
0x776ae6bf ???
   
/usr/src/debug/glibc-2.32-1.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x964bbb rtx_insn_list::next() const
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl.h:1407
0x964bbb fix_reg_equiv_init
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/ira.c:2683
0x96cb8f fix_reg_equiv_init
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/ira.c:2674
0x96cb8f find_moveable_pseudos
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/ira.c:4874
0x96cb8f ira
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/ira.c:5533
0x96cb8f execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/ira.c:5861
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/97704] New: [11 Regression][concepts] Not working with explicit types in function signatures?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

Bug ID: 97704
   Summary: [11 Regression][concepts] Not working with explicit
types in function signatures?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

consider the following program:

```c++
struct non_exisiting {};

template 
auto hard_error(t in)
{
static_assert(in, "Failure");
return;
}

template 
requires requires { hard_error(t{}); }
constexpr auto foo(t, non_exisiting);

template 
constexpr auto foo(t, bool) { return false; };

int main()
{
foo(0, false);
};
```

This worked since at least g++-7 up until g++-10.2, works with clang (11 and
trunk), as well as msvc.

I would expect that `foo(t, non_exisiting)` will not be considered, because it
would not be meaningful in this case (`bool` is not of type `non_exisiting` and
there is no conversion sequence from `bool` to `non_exisiting`).

See https://godbolt.org/z/3W5eG8

I hope this is a bug and not intended behaviour, because I encountered this
problem by using a range adaptor from the stdlib inside a templated class which
all of a sudden found `operator|` (a hidden friend of that range adaptor) by
ADL even though that operator did not match signature-wise.

If this is intended behaviour, what in world is the type of the second
parameter of `foo(t, non_exisiting)`?

Thank you!

[Bug gcov-profile/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[johannes.ziegenbalg at mailbox dot org via Gcc-bugs]

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

johannes.ziegenbalg at mailbox dot org changed:

   What|Removed |Added

 CC||johannes.ziegenbalg@mailbox
   ||.org

--- Comment #2 from johannes.ziegenbalg at mailbox dot org ---
I get the same bug with GCC 10.2.0 in one of my c++ test-cases.
I also tested GCC 11 (GNU Fortran (GCC) 11.0.0 20201029) with the attached file
and got the same result.

After a little digging I found out that the expanded region for 'sbr' starts at
line 8 (`use foo`) and ends at line 4 (`end subroutine sbr`).

But I have no idea why `expand_location` returns line 8.

[Bug gcov-profile/95847] [9/10/11 Regression] Internal error when processing pFUnit generated files with --coverage

[johannes.ziegenbalg at mailbox dot org via Gcc-bugs]

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

--- Comment #3 from johannes.ziegenbalg at mailbox dot org ---
I get the same bug with GCC 10.2.0 in one of my c++ test-cases.
I also tested GCC 11 (GNU Fortran (GCC) 11.0.0 20201029) with the attached file
and got the same result.

After a little digging I found out that the expanded region for 'sbr' starts at
line 8 (`use foo`) and ends at line 4 (`end subroutine sbr`).

But I have no idea why `expand_location` returns line 8.

[Bug testsuite/97699] [11 regression] zero-scratch-regs tests fail on arm

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #2 from qinzhao at gcc dot gnu.org ---
this might be expected behavior since the implementation should work for
aarch64 and x86. 
other platforms either need to skip this testing or finish the implementation
at backend.

[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |11.0

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in the following patch for pr92936:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557807.html

[Bug c++/96115] Char literal, decays to a pointer when passed to function pointer

[ldalessandro at gmail dot com via Gcc-bugs]

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

Luke Dalessandro  changed:

   What|Removed |Added

 CC||ldalessandro at gmail dot com

--- Comment #1 from Luke Dalessandro  ---
This continues to be a problem in gcc trunk, and impacts real code that
attempts to use `std::span` arguments.

Templates are not necessary to reproduce this behavior.

https://godbolt.org/z/PYreGK

```
struct span
{
span( int (&)[2] ) {}
};

bool foo(span) {
return true;
}

bool baz(bool ()(span), int i, int j) {
int array[] = {i, j};
int ()[2] = array;
return op(ref);
}

auto x = baz(foo, 1, 2);
```

[Bug target/97701] [10/11 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6

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

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

--- Comment #1 from Richard Biener  ---
Must be a latent problem then I guess.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

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

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

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

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

commit r11-4674-gd0d8a1658054258baae87b445678c1c0c08d9455
Author: Richard Biener 
Date:   Tue Nov 3 14:53:24 2020 +0100

middle-end/97579 - fix VEC_COND_EXPR ISEL optab query

This fixes a mistake in the optab query done by ISEL.  It
doesn't fix the PR but shifts the ICE elsewhere.

2020-11-03  Richard Biener  

PR middle-end/97579
* gimple-isel.cc (gimple_expand_vec_cond_expr): Use
the correct types for the vcond_mask/vec_cmp optab queries.

[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

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

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

commit r11-4675-gc5b49c3e092c0de5cd684b0acd244129dfaae324
Author: Richard Biener 
Date:   Tue Nov 3 15:03:41 2020 +0100

tree-optimization/97623 - limit PRE hoist insertion

This limits insert iteration caused by PRE insertions generating
hoist insertion opportunities and vice versa.  The patch limits
the hoist insertion iterations to three by default.

2020-11-03  Richard Biener  

PR tree-optimization/97623
* params.opt (-param=max-pre-hoist-insert-iterations): New.
* doc/invoke.texi (max-pre-hoist-insert-iterations): Document.
* tree-ssa-pre.c (insert): Do at most
max-pre-hoist-insert-iterations
hoist insert iterations.

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-4676-gabe93733a265f8a8b56dbdd307380f8c83dd3ab5
Author: Yang Yang 
Date:   Tue Nov 3 16:13:47 2020 +

PR target/96342 Change field "simdlen" into poly_uint64

This is the first patch of PR96342. In order to add support for
"omp declare simd", change the type of the field "simdlen" of
struct cgraph_simd_clone from unsigned int to poly_uint64 and
related adaptation. Since the length might be variable for the
SVE cases.

2020-11-03  Yang Yang  

gcc/ChangeLog:

* cgraph.h (struct cgraph_simd_clone): Change field "simdlen" of
struct cgraph_simd_clone from unsigned int to poly_uint64.
* config/aarch64/aarch64.c
(aarch64_simd_clone_compute_vecsize_and_simdlen): adaptation of
operations on "simdlen".
* config/i386/i386.c (ix86_simd_clone_compute_vecsize_and_simdlen):
Printf formats update.
* gengtype.c (main): Handle poly_uint64.
* omp-simd-clone.c (simd_clone_mangle): Likewise.Re
(simd_clone_adjust_return_type): Likewise.
(create_tmp_simd_array): Likewise.
(simd_clone_adjust_argument_types): Likewise.
(simd_clone_init_simd_arrays): Likewise.
(ipa_simd_modify_function_body): Likewise.
(simd_clone_adjust): Likewise.
(expand_simd_clones): Likewise.
* poly-int-types.h (vector_unroll_factor): New macro.
* poly-int.h (constant_multiple_p): Add two-argument versions.
* tree-vect-stmts.c (vectorizable_simd_clone_call): Likewise.

[Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637

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

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

Bug ID: 97705
   Summary: [11 regression]
cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after
r11-4637
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f5e18dd9c7dacc9671044fc669bd5c1b26b6bdba, r11-4637

make  -k check-gcc
RUNTESTFLAGS="unsorted.exp=gcc.c-torture/unsorted/dump-noaddr.c"

FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.ira,  -O3 -g  comparison

# of expected passes1467
# of unexpected failures1

There are many (thousands?) of lines of miscompare for the failing test.

commit f5e18dd9c7dacc9671044fc669bd5c1b26b6bdba
Author: Kewen Lin 
Date:   Tue Nov 3 02:51:47 2020 +

[Bug fortran/97692] GNU Fortran is not working

[nju044 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from ninos  ---
(In reply to Jakub Jelinek from comment #2)
> aarch64-xilinx-linux-gfortran: command not found
> seems like user error.

FYI
target system: arm64-xilinx-linux
build system: ubuntu 16.04
yocto version: zeus (git commit id unkown, because xilinx provides it)
meta-ros version: https://github.com/ros/meta-ros/tree/zeus, git_commit_id
5707a46
action: use xilinx "petalinux-tools" (wrapping on bitbake) to integrate
meta-ros into xilinx device.

I think aarch64-xilinx-linux-gfortran is the gfortran used in target system, so
it can't be found in build system, which is user system.
Do you know why gfortran is thought to be misconfigured as indicated by
"/home/kn/xlxnew/petalinux/map_loc_os/zcu104/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/gcc-9.2.0/build.aarch64-xilinx-linux.aarch64-xilinx-linux/aarch64-xilinx-linux/libgfortran/config.log"
(attached as "gfortran config log") ?

[Bug middle-end/97699] New: [11 regression] zero-scratch-regs tests fail on arm

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

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

Bug ID: 97699
   Summary: [11 regression] zero-scratch-regs tests fail on arm
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Some of the recently added zero-scratch-regs-* tests fail on arm.

For instance when configuring GCC
--target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

I can see:
FAIL: c-c++-common/zero-scratch-regs-10.c  -Wc++-compat  (test for excess
errors)
FAIL: c-c++-common/zero-scratch-regs-11.c  -Wc++-compat  (test for excess
errors)
FAIL: c-c++-common/zero-scratch-regs-9.c  -Wc++-compat  (test for excess
errors)


The logs say:
/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:77:1: sorry, unimplemented:
'-fzero-call-used_regs' not supported on this target

The other tests pass.

BTW, there's a typo in the error message, it should say
fzero-call-used-regs rather than fzero-call-used_regs (that is '-' instead of
'_' before 'regs')

[Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2))

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Wilson Snyder from comment #7)
> Thanks for the quick service.  I can't easily try GCC trunk, but:
> 
> -O2
>   compile 98.61s
>   runtime 25.76s
> 
> -O2 -fno-code-hoisting
>   compile 40.13s
>   runtime 26.40s (+2.5%)

Hmm, OK.  Can you provide the output of -O2 -fno-code-hoisting -ftime-report?

I have a patch limiting hoist insertions to 3 and that makes the reduced
testcase drop from 13s to 2.5s and drop PRE into reasonable territory:

 tree PRE   :   0.44 ( 18%)   0.00 (  0%)   0.45 ( 18%)
 1177k (  5%)

and with -fno-code-hoisting

 tree PRE   :   0.37 ( 15%)   0.00 (  0%)   0.38 ( 15%)
  477k (  2%)

where it takes only two insert iterations (the last iteration is always
a no-op, so that's perfect).  Before limiting but after the already
committed patch it was

 tree PRE   :  10.41 ( 81%)   0.01 ( 33%)  10.48 ( 81%)
   11M ( 33%)

The function is quite big and ANTIC_IN compute is costly and more
importantly AVAIL_OUT is quadratic in size (ugh).

> -Os
>   compile 4.25s
>   runtime 23.42s (-10%)
> 
> That -Os runs faster is expected as this program is generally
> instruction-fetch limited.  I'd have expected -fno-code-hoisting to help
> more, compile time wise.

Me, too.

> Am I correct in understanding that the slowdown is roughly correlated to the
> number of "if" or "?:" statements?

Yeah, that's the case.

[Bug c/97702] New: comma operator does not drop qualifiers during lvalue conversion

[uecker at eecs dot berkeley.edu via Gcc-bugs]

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

Bug ID: 97702
   Summary: comma operator does not drop qualifiers during lvalue
conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at eecs dot berkeley.edu
  Target Milestone: ---

The following code 

const int x = 0;
typeof(0, x) y = 0;
y = x;

yields an error because '(0, x)' and then 'y' is const 
qualified. This is incorrect as lvalue conversion
should remove the qualifier (ISO C17 6.3.2.1p2).

I assume this is a residual problem from the time
where GCC had generalized lvalues.

[Bug libstdc++/84323] call_once uses TLS even when once_flag is set

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug middle-end/92940] incorrect offset and size in -Wstringop-overflow for out-of-bounds store into VLA and two offset ranges

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-03
 Ever confirmed|0   |1
   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Martin Sebor  ---
Fixed in the following patch for pr92936:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557807.html

[Bug c++/96872] [11 Regression] ICE: Segmentation fault

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

--- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you; was fixed!

[Bug target/97701] New: [10/11 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6

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

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

Bug ID: 97701
   Summary: [10/11 Regression] aarch64: ICE in
extract_constrain_insn since r10-4447-g095f78c6
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following testcase:

extern char a[][12][18][17][17];
extern short b[][12][18][17][17];
extern int c[][2][8][7];
short *d;
void e(signed f, int g, char h, char i, char j) {
  for (int k = 648; k; k += f)
for (short l; l < j; l += 9)
  for (long m = f + 6LL; m < (h ? h : i); m += 2)
for (int n = 0; n < 16; n += 3LL) {
  for (int o = g; o; o++)
a[k][l][m][n][o] = b[k][l][m][n][o] = d[k] ? 2 : 0;
  c[k][l][m][0] = 0;
}
}

AArch64 GCC ICEs at -O3 since
r10-4447-g095f78c62157124ad479a3f98b6995ced090b807. To reproduce:

$ aarch64-elf-gcc -c test.c -O3
test.c: In function 'e':
test.c:14:1: error: insn does not satisfy its constraints:
   14 | }
  | ^
(insn 2496 2495 2497 5 (set (reg:DI 32 v0 [1415])
(lo_sum:DI (reg:DI 6 x6 [1416])
(symbol_ref/u:DI ("*.LC0") [flags 0x82]))) 1007 {add_losym_di}
 (nil))
during RTL pass: reload
test.c:14:1: internal compiler error: in extract_constrain_insn, at
recog.c:2212
0xd1ab2f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0xd1ab60 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:118
0xcec957 extract_constrain_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2212
0xbbe58d check_rtl
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2038
0xbc3451 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2447
0xb76cff do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5725
0xb76cff execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5911
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97701] [10/11 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
  Known to fail||11.0
 Target||aarch64

[Bug c++/97632] unhelpful -Winit-list-lifetime warning for default-initialized object in unevaluated context

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-4670-gf620e64a6f13371b95be5b17abba0acf15bf7cae
Author: Marek Polacek 
Date:   Thu Oct 29 15:08:31 2020 -0400

c++: Disable -Winit-list-lifetime in unevaluated operand [PR97632]

Jon suggested turning this warning off when we're not actually
evaluating the operand.  This patch does that.

gcc/cp/ChangeLog:

PR c++/97632
* init.c (build_new_1): Disable -Winit-list-lifetime for an
unevaluated
operand.

gcc/testsuite/ChangeLog:

PR c++/97632
* g++.dg/warn/Winit-list4.C: New test.

[Bug target/70210] -march=native and -mcpu=native do not detect ARM cortex-a53 in 32 bit mode on Linux

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

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Viktor Engelmann from comment #5)
> Hmmm the problem isn't related to docker - I get the same problem when I run
> gcc on the raspberry directly with -mcpu=armv7l as autoconf does in docker.
> 

yep, armv7l is not a valid argument to -mcpu by design.

> When I run gcc manually with -mcpu=cortex-a53, everything is fine.
> lscpu says
> 
> Architecture:armv7l
> Byte Order:  Little Endian
> CPU(s):  4
> On-line CPU(s) list: 0-3
> Thread(s) per core:  1
> Core(s) per socket:  4
> Socket(s):   1
> Vendor ID:   ARM
> Model:   4
> Model name:  Cortex-A53
> Stepping:r0p4
> CPU max MHz: 1200.
> CPU min MHz: 600.
> BogoMIPS:38.40
> Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva
> idivt vfpd32 lpae evtstrm crc32
> 
> and /proc/cpuinfo is basically the same as the one Andrew Roberts had posted.
> Maybe it's a problem in autoconf for passing armv7l (the "Architecture:"
> line) to -mcpu.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

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

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #14 from Bernd Edlinger  ---
fixed on trunk.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

--- Comment #13 from Richard Biener  ---
(In reply to H.J. Lu from comment #12)
> Created attachment 49495 [details]
> Something like this.

Doesn't look much better IMHO.

A __builtin_cpu_supported_as_compiled () would be nice to have though
(match up what is supported with the active -mISA flags).

[Bug c++/97697] Segmentation fault on while (true) loop

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

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

--- Comment #4 from Jakub Jelinek  ---
I guess an optimization barrier will always work.
E.g. adding
__asm ("" : "+g" (nrn_pass_num));
before the loop.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Bernd Edlinger :

https://gcc.gnu.org/g:23ac7a009ecfeec3eab79136abed8aac9768b458

commit r11-4668-g23ac7a009ecfeec3eab79136abed8aac9768b458
Author: Bernd Edlinger 
Date:   Sun Nov 1 07:32:20 2020 +0100

Fix PR97205

This makes sure that stack allocated SSA_NAMEs are
at least MODE_ALIGNED.  Also increase the MEM_ALIGN
for the corresponding rtl objects.

gcc:
2020-11-03  Bernd Edlinger  

PR target/97205
* cfgexpand.c (align_local_variable): Make SSA_NAMEs
at least MODE_ALIGNED.
(expand_one_stack_var_at): Increase MEM_ALIGN for SSA_NAMEs.

gcc/testsuite:
2020-11-03  Bernd Edlinger  

PR target/97205
* gcc.c-torture/compile/pr97205.c: New test.

[Bug c++/97632] unhelpful -Winit-list-lifetime warning for default-initialized object in unevaluated context

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter

[ensadc at mailnesia dot com via Gcc-bugs]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83258

--- Comment #1 from ensadc at mailnesia dot com ---
The lambda is not needed to reproduce the bug. This also triggers the error:

void fun() {}
struct S 
{ 
void (*f)(); 
}; 

template struct X {};
using x = X;

[Bug tree-optimization/97678] [11 regression] execution fail for gcc.target/powerpc/p9-vec-length-epil-run-5.c after r11-4614

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

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

--- Comment #3 from Richard Biener  ---
Ah, the vectorized epilogue is wrong since we do not represent the initial
value there correctly.  We still have the {0, 0} invariant in the corresponding
SLP tree.

Hmm.

So previously we're relying on the actual PHI node(s) preheader value plus
eventually honoring LOOP_VINFO_MASK_SKIP_NITERS.

[Bug testsuite/97688] New: check_vect doesn't detect AVX2 on zen

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

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

Bug ID: 97688
   Summary: check_vect doesn't detect AVX2 on zen
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Running on a zen2 machine (3900X) check_vect() doesn't detect AVX2 which
asks for

/* Determine what instruction set we've been compiled for, and detect
   that we're running with it.  This allows us to at least do a compile
   check for, e.g. SSE4.1 when the machine only supports SSE2.  */
# if defined(__AVX2__)
want_level = 7, want_b = bit_AVX2;

but __get_cpuid returns 0 for b

__maxlevel is 16

and regs after cpuid are

(gdb) info reg 
rax0x0 0
rbx0x0 0
rcx0x0 0
rdx0x0 0
rsi0x68747541  1752462657
rdi0x0 0

[Bug c++/97681] noinline attribute ignored on constexpr function

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

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

--- Comment #7 from Jakub Jelinek  ---
Guess that particular spot could be changed with:
--- gcc/cp/typeck2.c2020-09-12 13:36:42.500499341 +0200
+++ gcc/cp/typeck2.c2020-11-03 10:44:10.257021110 +0100
@@ -935,9 +935,11 @@ store_init_value (tree decl, tree init,
 }
   /* Don't fold initializers of automatic variables in constexpr functions,
  that might fold away something that needs to be diagnosed at constexpr
- evaluation time.  */
+ evaluation time.  Don't fold initializers of automatic variables
+ with -O0 either.  */
   if (!current_function_decl
-  || !DECL_DECLARED_CONSTEXPR_P (current_function_decl)
+  || (!DECL_DECLARED_CONSTEXPR_P (current_function_decl)
+ && optimize)
   || TREE_STATIC (decl))
 value = cp_fully_fold_init (value);

but we have dozens if not hundreds of other places.  And, just disabling
constant evaluation at -O0 except in manifestly constant contexts can't really
work, e.g. many of the warnings heavily relies on the foldings being possible.

[Bug tree-optimization/97678] [11 regression] execution fail for gcc.target/powerpc/p9-vec-length-epil-run-5.c after r11-4614

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

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

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

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

commit r11-4646-gf53e9d40de7212413b361758d66aafb833173dd9
Author: Richard Biener 
Date:   Tue Nov 3 09:53:11 2020 +0100

tree-optimization/97678 - fix SLP induction epilogue vectorization

This restores not tracking SLP nodes for induction initial values
in not nested context because this interferes with peeling and
epilogue vectorization.

2020-11-03  Richard Biener  

PR tree-optimization/97678
* tree-vect-slp.c (vect_build_slp_tree_2): Do not track
the initial values of inductions when not nested.
* tree-vect-loop.c (vectorizable_induction): Look at
PHI node initial values again for SLP and not nested
inductions.  Handle LOOP_VINFO_MASK_SKIP_NITERS and cost
invariants.

* gcc.dg/vect/pr97678.c: New testcase.

[Bug testsuite/97688] check_vect doesn't detect AVX2 on zen

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

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

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

https://gcc.gnu.org/g:8414529156e0bca37647c440c71beeca1d04ac86

commit r11-4647-g8414529156e0bca37647c440c71beeca1d04ac86
Author: Richard Biener 
Date:   Tue Nov 3 10:24:02 2020 +0100

testsuite/97688 - fix check_vect () with __AVX2__

This fixes the cpuid check to always specify a subleaf zero
which is required to detect AVX2 and doesn't hurt for level one.
Without this fix we get zero runtime coverage when -mavx2 is
specified.

2020-11-03  Richard Biener  

PR testsuite/97688
* gcc.dg/vect/tree-vect.h (check_vect): Fix the x86 cpuid
check to always specify subleaf zero.

[Bug c/97578] ice during IPA pass: inline

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

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

--- Comment #8 from Jan Hubicka  ---
OK, I comitted patch as is and we could see if any memory can be conserved by
being more precise.  I still think the debug info should not need decls here.
Honza

[Bug c/97578] ice during IPA pass: inline

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
It needs to refer to the DW_TAG_formal_parameter DIEs, and only the PARM_DECLs
map to those.

[Bug tree-optimization/97695] New: wrong code at -O3 on x86_64-pc-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97695
   Summary: wrong code at -O3 on x86_64-pc-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201103 (experimental) [master revision
682ed7ad230:259379fab27:0caf400a865cb771f76bf1025cfc2a83e8ef00ed] (GCC) 
[509] % 
[509] % gcctk -O2 small.c; ./a.out
[510] % 
[510] % gcctk -O3 small.c; ./a.out
Floating point exception
[511] % 
[511] % cat small.c
int *a, b, **c = , d, e;

int f(int g, int h) { return !h || (g && h == 1) ? 0 : g / h; }

static void *i(int g) {
  while (e < 2)
if (!f(g, 9)) {
  while (b)
;
  return 0;
}
  return 0;
}

void j() {
  i(1);
  *c = i(d);
}

int main() { j(); return 0; }

[Bug c++/97697] Segmentation fault on while (true) loop

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't see any difference from this and PR97627.

[Bug c++/97697] Segmentation fault on while (true) loop

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Yeah, a reliable workaround is hard.

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

[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

--- Comment #7 from Richard Biener  ---
Smaller testcase from other PR, still needs the C++ FE

struct S { unsigned short x, y; } m = { 0, 0 };
void __attribute__((noipa)) bar() {}
void __attribute__((noipa)) baz()
{
  __builtin_exit (0);
}
void foo()
{
  while (1)
{ 
  unsigned int nrn_pass_num = m.x + 1;
  for (unsigned int nrn_idx = 0; nrn_idx < nrn_pass_num; ++nrn_idx)
bar();
  baz();
}
}
int main()
{
  foo();
  return 0;
}

[Bug c/85019] configure: error: GNU Fortran is not working

[nju044 at hotmail dot com via Gcc-bugs]

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

ninos  changed:

   What|Removed |Added

 CC||nju044 at hotmail dot com

--- Comment #2 from ninos  ---
(In reply to Sabin NS from comment #0)
> Created attachment 43725 [details]
> config log
> 
> While building libgfortran-native in Yocto Build system getting below error:
> 
> 
> | checking whether to build shared libraries... yes
> | checking whether to build static libraries... yes
> | libtool.m4: error: problem compiling FC test program
> | checking for gfortran  option to produce PIC...
> | checking if gfortran  static flag  works... no
> | checking if gfortran  supports -c -o file.o... no
> | checking if gfortran  supports -c -o file.o... (cached) no
> | checking whether the gfortran  linker (ld  -m elf_x86_64) supports shared
> libraries... yes
> | checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> | checking how to hardcode library paths into programs... immediate
> | checking whether the GNU Fortran compiler is working... no
> | configure: error: GNU Fortran is not working; please report a bug in
> http://gcc.gnu.org/bugzilla

Hi, I have a similar issue. Is your building ok?

[Bug c/85019] configure: error: GNU Fortran is not working

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Normally libgfortran is built with the just built compiler (so it would be
compiled with /gcc/xgcc -B /gcc/ , /gcc/gfortran -B /gcc/
etc.),
that is clearly not the case for you, so the Yocto build system is doing
something wrong.

[Bug c++/97700] New: Bogus error when a class containing a function pointer is used as a non-type template parameter

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 97700
   Summary: Bogus error when a class containing a function pointer
is used as a non-type template parameter
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
CC: jason at redhat dot com
  Target Milestone: ---

Originally discovered by cigien on StackOverflow. See
https://stackoverflow.com/questions/64655958/can-a-class-containing-a-function-pointer-be-used-as-a-non-type-template-parameter

GCC does not like this program:



struct S 
{ 
void (*f)(); 
}; 

constexpr S s {[]{}};

template struct X {};
using x = X;



It complains with:


error: '::_FUN' is not a valid template argument of type 'void (*)()'
because '::_FUN' is not a variable
using x = X;
 ^


As mentioned in the StackOverflow post, it appears that
`invalid_tparm_referent_p` (called by `get_template_parm_object`) fails to
account for the pointer-to-function case.

[Bug middle-end/97699] [11 regression] zero-scratch-regs tests fail on arm

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
See also PR97680