[Bug c++/97712] New: Attribute nodiscard in virtual methods is ignored

[pacoarjonilla at yahoo dot es via Gcc-bugs]

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

Bug ID: 97712
   Summary: Attribute nodiscard in virtual methods is ignored
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pacoarjonilla at yahoo dot es
  Target Milestone: ---

The standard attribute [[nodiscard]] is ignored if the function is virtual.
Versions GNU C++ trunk and GNU C++ 10.2 fails to issue a warning on the
following snippet:

>>>

struct B {
[[nodiscard]] virtual int f() = 0;
};

struct D : public B {
[[nodiscard]] int f() override {return 1;}
};

int main() {
B * b = new D;
b->f(); // GNU C++ does not warn about discarded value
}

<

Clang does issue a warning appropriately.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #12 from Levy  ---
(In reply to Kito Cheng from comment #11)
> > Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c
> 
> Seems like shorten_memrefs pass didn't handle zero_extend and sign_extend
> with memory.
> 
> You can take a look into
> riscv-shorten-memrefs.c:pass_shorten_memrefs::analyze and add logic to
> handle zero_extend and sign_extend.
> 
> 
> > With one instruction less, the patched one seems right and even faster to 
> > me. However we still need a test on sign extend and check performance
> 
> shorten_memrefs is optimize for size, the idea is transform several load
> instructions with large immediate to a load immediate instruction and load
> instructions with small immediate, to use C-extensions instruction as
> possible.
> 
> so the instruction count seems increased, but the code size is smaller.

Thank you cheng, I'll have a look.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #11 from Kito Cheng  ---
> Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c

Seems like shorten_memrefs pass didn't handle zero_extend and sign_extend with
memory.

You can take a look into riscv-shorten-memrefs.c:pass_shorten_memrefs::analyze
and add logic to handle zero_extend and sign_extend.


> With one instruction less, the patched one seems right and even faster to me. 
> However we still need a test on sign extend and check performance

shorten_memrefs is optimize for size, the idea is transform several load
instructions with large immediate to a load immediate instruction and load
instructions with small immediate, to use C-extensions instruction as possible.

so the instruction count seems increased, but the code size is smaller.

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #10 from Levy  ---
Created attachment 49500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49500=edit
Optimzation Patch for QI/HImode(32bit) and QI/HI/SImode(64bit)

Proposing second patch for QI/HImode(32bit) and QI/HI/SImode(64bit)
Both Zero-Extend & Subreg

Tested with make report-gcc
Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c

Both were failed due to dejaGNU rule:
/* { dg-final { scan-assembler "load1r:\n\taddi" } } */

But if we look at the assembly code, for same input in both file:

int load1r (int *array)
{
  int a = 0;
  a += array[200];
  a += array[201];
  a += array[202];
  a += array[203];
  return a;
}

Current gcc risc-v port will produce:
load1r:
addia5,a0,768
lw  a4,36(a5)
lw  a0,32(a5)
addwa0,a0,a4
lw  a4,40(a5)
addwa4,a4,a0
lw  a0,44(a5)
addwa0,a0,a4
ret
Patched new port will produce:
load1r:
lwu a4,800(a0)
lwu a5,804(a0)
addwa5,a5,a4
lwu a4,808(a0)
lwu a0,812(a0)
addwa5,a5,a4
addwa0,a5,a0
ret
With one instruction less, the patched one seems right and even faster to me.
However we still need a test on sign extend and check performance

Test case and performance evaluation will be provided later (hopefully)

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

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Hongtao.liu  ---
Fixed in GCC11.

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

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
Fixed in GCC11.

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

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r11-4703-gdb8b3e148d5cc5358cd48886e5334bd50d2d3317
Author: liuhongt 
Date:   Mon Oct 26 20:45:23 2020 +0800

Fix invalid address for special_memory_constraint.

gcc/ChangeLog
PR target/97532
* lra-constraints.c (valid_address_p): Handle operand of
special memory constraint.
(process_address_1): Ditto.

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

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:2e0aa43fc6ae689c595902310baec604e7e0d695

commit r11-4704-g2e0aa43fc6ae689c595902310baec604e7e0d695
Author: liuhongt 
Date:   Mon Oct 26 20:46:42 2020 +0800

Don't extract memory from operand for normal memory constraint.

gcc/ChangeLog
PR target/97540
* ira.c: (ira_setup_alts): Extract memory from operand only
for special memory constraint.
* recog.c (asm_operand_ok): Ditto.
* lra-constraints.c (process_alt_operands): MEM_P is
required for normal memory constraint.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr97540.c: New test.

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

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #2 from Kewen Lin  ---
Thanks for reporting and sorry for the failure. I did run the regression
testing on P8 LE, but thought it's endianness irrelevant and didn't run it on
BE.

[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 #4 from ninos  ---
(In reply to Jakub Jelinek from comment #2)
> aarch64-xilinx-linux-gfortran: command not found
> seems like user error.


I grep "command not found" and find more suspectible items, especially item
"19":
ac_cv_fc_compiler_gnu=no
ac_cv_func_dlopen=no
ac_cv_func_shl_load=no
ac_cv_header_minix_config_h=no 
ac_cv_lib_dld_shl_load=no
ac_cv_prog_fc_g=no
lt_cv_archive_cmds_need_lc=no
lt_cv_prog_compiler_c_o_FC=no
lt_cv_prog_compiler_rtti_exceptions=no
lt_cv_prog_compiler_static_works_FC=no
lt_cv_shlibpath_overrides_runpath=no
enable_static='no'

I googled "ac_cv_fc_compiler_gnu", think it means GNU Fortran Compiler. If
true, the fortran compiler is not enabled?

For detailed suspectible items, see below (grep from "gfortran config log"): 

1. --enable-version-specific-runtime-libs is no

2. "enable maintainer-specific portions of Makefiles" is no

3. aarch64-xilinx-linux-gcc  -march=armv8-a+crc -mtune=cortex-a72.cortex-a53
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
-V >&5
   aarch64-xilinx-linux-gcc: error: unrecognized command line option '-V'
   aarch64-xilinx-linux-gcc: fatal error: no input files

4. aarch64-xilinx-linux-gcc  -march=armv8-a+crc -mtune=cortex-a72.cortex-a53
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
-qversion >&5
   aarch64-xilinx-linux-gcc: error: unrecognized command line option
'-qversion'; did you mean '--version'?
   aarch64-xilinx-linux-gcc: fatal error: no input files

5. aarch64-xilinx-linux-gcc -E
--sysroot=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
 -march=armv8-a+crc -mtune=cortex-a72.cortex-a53 -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
conftest.c
   conftest.c:9:10: fatal error: ac_nonexistent.h: No such file or directory
   9 | #include 

6. aarch64-xilinx-linux-gcc  -march=armv8-a+crc -mtune=cortex-a72.cortex-a53
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
-c  -O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0=/usr/src/debug/libgfortran/9.2.0-r0

-fdebug-prefix-map=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0=/usr/src/debug/libgfortran/9.2.0-r0

-fdebug-prefix-map=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot=

-fdebug-prefix-map=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot-native=
  conftest.c >&5
   conftest.c:52:10: fatal error: minix/config.h: No such file or directory
  52 | #include 
failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Fortran Runtime Library"
| #define PACKAGE_TARNAME "libgfortran"
| #define PACKAGE_VERSION "0.3"
| #define PACKAGE_STRING "GNU Fortran Runtime Library 0.3"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgfortran/;
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
| #include 
| #ifdef HAVE_SYS_TYPES_H
| # include 
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include 
| #endif
| #ifdef STDC_HEADERS
| # include 
| # include 
| #else
| # ifdef HAVE_STDLIB_H
| #  include 
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include 
| # endif
| # include 
| #endif
| #ifdef HAVE_STRINGS_H
| # include 
| #endif
| #ifdef HAVE_INTTYPES_H
| # include 
| #endif
| #ifdef HAVE_STDINT_H
| # include 
| #endif
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| #include 

7. aarch64-xilinx-linux-gcc -E
--sysroot=/home/base/zynqmp/build/tmp/work/aarch64-xilinx-linux/libgfortran/9.2.0-r0/recipe-sysroot
 -march=armv8-a+crc -mtune=cortex-a72.cortex-a53 -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
conftest.c
   conftest.c:19:10: fatal error: minix/config.h: No such file or directory
  19 | #include 
failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Fortran Runtime Library"
| #define PACKAGE_TARNAME "libgfortran"
| #define PACKAGE_VERSION "0.3"
| #define PACKAGE_STRING "GNU Fortran Runtime Library 0.3"
| #define 

[Bug tree-optimization/97711] New: Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"

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

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

Bug ID: 97711
   Summary: Failure to optimise "x & 1 ? x - 1 : x" to "x & -2"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't optimise the expression:

  int f (int x) { return x & 1 ? x - 1 : x; }

to x & -2 (but clang does).  The original motivation was actually:

  char *g (char *x) { return (__UINTPTR_TYPE__) x & 1 ? x - 1 : x; }

which I guess might require a different pattern.

(And the reason for writing g that way was to do all pointer
arithmetic on pointers rather than converting to a uintptr_t,
doing arithmetic, and converting back.)

[Bug c++/90629] Support for -Wmismatched-new-delete

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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

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

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

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

commit r11-4700-gab4664eb73f9401a5ca65d21cdf87d69fe0026dc
Author: Jan Hubicka 
Date:   Wed Nov 4 00:19:59 2020 +0100

Fix copying of clone_info while reshaping clone tree.

2020-11-04  Jan Hubicka  

PR ipa/97695
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Fix ICE
with
in dumping code.
(cgraph_node::remove): Save clone info before releasing it and pass
it
to unregister.
* cgraph.h (symtab_node::unregister): Add clone_info parameter.
(cgraph_clone::unregister): Likewise.
* cgraphclones.c (cgraph_node::find_replacement): Copy clone info
* symtab-clones.cc (clone_infos_t::duplicate): Remove.
(clone_info::get_create): Simplify.
* symtab.c (symtab_node::unregister): Pass around clone info.
* varpool.c (varpool_node::remove): Update.

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Please provide a stand-alone testcase.  The one from
https://bugs.llvm.org/show_bug.cgi?id=33708#c6 compiles with GCC (with
-std=c++11 and up).

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

--- Comment #8 from Jakub Jelinek  ---
That is how GCC deals with all reloading, so I don't understand what is
surprising about it.
If you ask for something to be in register (or register class) xyz and it isn't
there, it is copied there.
Look at e.g.:
void
foo (void)
{
  register int a __asm ("eax") = 1;
  __asm ("# %0 " : : "r" (a));
  __asm ("# %0 " : : "a" (a));
  __asm ("# %0 " : : "c" (a));
//  __asm ("# %0 " : : "m" (a));
}

In the first case, "r" constraint allows the "eax" register in which the
(local) register variable lives, so it goes there.  In the second case
likewise, it is the only register in which it can go.  In the third case, you
ask for it to be passed in the ecx register and so the compiler does that.  The
commented out case errors out because "m" essentially requires taking the
address of the passed object, which is not valid for register variables.  But
e.g. "g" which doesn't require just mem can handle also non-mems and will be in
that case essentially treated just like "r", because the address of it can't be
taken.

[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

Thanks for the report!

[Bug c++/97710] New: Help with breaking change? cast point-to-member address in template parameter list

[mick.pearson at wildblue dot net via Gcc-bugs]

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

Bug ID: 97710
   Summary: Help with breaking change? cast point-to-member
address in template parameter list
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mick.pearson at wildblue dot net
  Target Milestone: ---

GCC used to agree with MSVC in letting pointer-to-member addresses be cast
inside templates, i.e. compile time constants. Cygwin updated me to 10.2.0 and
this now produces an "error: 'reinterpret_cast' is not a constant expression"
diagnostic.

The Clang tracker laughed at a request I made in the past to enable this for
Clang. (Please reach consensus? https://bugs.llvm.org/show_bug.cgi?id=33708) I
doubt Microsoft will break this in future versions of MSVC since that's not
it's style, so I wonder if this is an oversight in GCC, and if not what
recourse exists. 

Thank you, maybe related:
https://patchwork.ozlabs.org/project/gcc/patch/or604puqhd@lxoliva.fsfla.org/

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

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #3 from joseph at codesourcery dot com  ---
T5 in that list is an lvalue, so it seems right not to drop qualifiers 
there.

[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures

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

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

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

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

commit r10-8970-ga00894a3a3eb2852cd782a9cc6ee5bd83bfff542
Author: Harald Anlauf 
Date:   Tue Oct 27 20:25:23 2020 +0100

PR fortran/97491 - Wrong restriction for VALUE arguments of pure procedures

A dummy argument with the VALUE attribute may be redefined in a PURE or
ELEMENTAL procedure.  Adjust the associated purity check.

gcc/fortran/ChangeLog:

* resolve.c (gfc_impure_variable): A dummy argument with the VALUE
attribute may be redefined without making a procedure impure.

gcc/testsuite/ChangeLog:

* gfortran.dg/value_8.f90: New test.

(cherry picked from commit a764c40079a493826a3678174f908941a383644e)

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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

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

--- Comment #7 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #5)
> I see you have patch, too :)
> However we do not want to copy clone info to every inline clone (since
> the body is materialized just once).  The problem is that in case the
> offline copy is removed we move clone info to first inline clone and
> reshape the tree.  This is quite old code to save little memory for the
> extra symbol that I may get rid of becuase it also trigger quadratic
> time issues with tree-inline, but for now we should copy the info
> correctly.  Code is not very well structured for this since it first
> calls removal hooks and only then looks for replacement so patch is bit
> ugly.  I will clean it up incrementally.
> 

Umm, OK, can you please adjust comments of all the functions which get a new
clone_info parameter too?

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

[bp at alien8 dot de via Gcc-bugs]

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

--- Comment #7 from Boris  ---
(In reply to Jakub Jelinek from comment #6)
> I agree with Andrew here, the compiler does what it is asked to do, so puts
> the value into either memory or general purpose register.  Neither "r" nor
> "g" allows putting the value into an SSE register.  Use "x" constraint for
> that.

Look at the documentation:

"‘g’ Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers."

so this reads to me like "g" doesn't allow xmm registers. What gcc does is go
"around the corner" and stick it in a g-allowed register.

So that behavior should *at* *least* be documented so that people know what's
going on here. Because it is confusing...

[Bug tree-optimization/97559] [11 Regression] ICE at -O1 and above on x86_64-pc-linux-gnu: verify_ssa failed

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

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

Zhendong Su  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #4 from Zhendong Su  ---
Another repro for the same ICE (but only at -Os):

[541] % gcctk -O1 -c small.c
[542] % gcctk -O2 -c small.c
[543] % gcctk -O3 -c small.c
[544] %
[544] % gcctk -Os -c small.c
small.c: In function ‘e’:
small.c:3:6: error: stmt with wrong VUSE
3 | void e() {
  |  ^
# VUSE <.MEM_7(D)>
f_8 = b;
expected .MEM_5
during GIMPLE pass: sink
small.c:3:6: internal compiler error: verify_ssa failed
0xf707cb verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1208
0xbfe3e7 execute_function_todo
../../gcc-trunk/gcc/passes.c:2046
0xbff192 execute_todo
../../gcc-trunk/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[545] %
[545] % cat small.c
int a, b, c, d;

void e() {
  int f = b;
  if (a) {
  L1:
a = 0;
  L2:
if (a) {
  c = b;
  goto L1;
}
  }
  if (d)
goto L2;
}

[Bug c/97702] 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

--- Comment #2 from Martin Uecker  ---
Thank you for the explanation.

Interestingly, from the following list, the only example that
removes the cast is the last one (which seems correct
as ISO C specifies casts to produce a value with the
unqualified type, for whatever reason).

#define T1(x) ((void)0,x)
#define T2(x) (+x)
#define T3(x) (-x)
#define T4(x) (1?x:x)
#define T5(x) (*&(x))
#define T6(x) ((const int)x)

int f(void)
{
const int j = 0;
__typeof__(T6(j)) i = 0;
i = 0;
return i;
}

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I agree with Andrew here, the compiler does what it is asked to do, so puts the
value into either memory or general purpose register.  Neither "r" nor "g"
allows putting the value into an SSE register.  Use "x" constraint for that.

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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

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

--- Comment #6 from Zhendong Su  ---
Another repro for the same issue (as -fno-ipa-cp also avoids it): 

[579] % gcctk -O2 small.c; ./a.out
[580] % gcctk -O3 small.c; ./a.out
Aborted
[581] % gcctk -O3 -fno-ipa-cp small.c; ./a.out
[582] % 
[582] % cat small.c
int a, b, c, *d = , e, f;

char g (char h)
{
  return h < 0 || a || h ? h : 0;
}

static int i (int h)
{
  f = g (1);
  e = *d = f && h;
  a = 0;
  return b;
}

int main ()
{
  e = i (1);
  while (b)
i (0);
  if (!c)
__builtin_abort ();
  return 0;
}

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Segher Boessenkool  ---
The only supported use for this feature is to specify registers
for input and output operands when calling Extended @code{asm} 
(@pxref{Extended Asm}).  This may be necessary if the constraints for a 
particular machine don't provide sufficient control to select the desired 
register.  To force an operand into a register, create a local variable 
and specify the register name after the variable's declaration.  Then use 
the local variable for the @code{asm} operand and specify any constraint 
letter that matches the register:


Stop marking this as invalid.  It is not.


"r" *is* valid.  And even if it was not, the compiler should just error,
not silently do the wrong thing!

Re: [Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

[Jan Hubicka]

I see you have patch, too :)
However we do not want to copy clone info to every inline clone (since
the body is materialized just once).  The problem is that in case the
offline copy is removed we move clone info to first inline clone and
reshape the tree.  This is quite old code to save little memory for the
extra symbol that I may get rid of becuase it also trigger quadratic
time issues with tree-inline, but for now we should copy the info
correctly.  Code is not very well structured for this since it first
calls removal hooks and only then looks for replacement so patch is bit
ugly.  I will clean it up incrementally.

gcc/ChangeLog:

2020-11-03  Jan Hubicka  

* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Fix ICE with
in dumping code.
(cgraph_node::remove): Save clone info before releasing it and pass it
to unregister.
* cgraph.h (symtab_node::unregister): Add clone_info parameter.
(cgraph_clone::unregister): Likewise.
* cgraphclones.c (cgraph_node::find_replacement): Copy clone info
* symtab-clones.cc (clone_infos_t::duplicate): Remove.
(clone_info::get_create): Simplify.
* symtab.c (symtab_node::unregister): Pass around clone info.
* varpool.c (varpool_node::remove): Update.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 36bdb009bf8..19dfe2be23b 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1503,14 +1503,13 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge 
*e)
 
   if (symtab->dump_file)
 {
-
   fprintf (symtab->dump_file, "updating call of %s -> %s: ",
   e->caller->dump_name (), e->callee->dump_name ());
   print_gimple_stmt (symtab->dump_file, e->call_stmt, 0, dump_flags);
   if (callee_info && callee_info->param_adjustments)
callee_info->param_adjustments->dump (symtab->dump_file);
   unsigned performed_len
-   = vec_safe_length (caller_info->performed_splits);
+   = caller_info ? vec_safe_length (caller_info->performed_splits) : 0;
   if (performed_len > 0)
fprintf (symtab->dump_file, "Performed splits records:\n");
   for (unsigned i = 0; i < performed_len; i++)
@@ -1861,12 +1860,19 @@ cgraph_node::release_body (bool keep_arguments)
 void
 cgraph_node::remove (void)
 {
+  bool clone_info_set = false;
+  clone_info *info, saved_info;
   if (symtab->ipa_clones_dump_file && symtab->cloned_nodes.contains (this))
 fprintf (symtab->ipa_clones_dump_file,
 "Callgraph removal;%s;%d;%s;%d;%d\n", asm_name (), order,
 DECL_SOURCE_FILE (decl), DECL_SOURCE_LINE (decl),
 DECL_SOURCE_COLUMN (decl));
 
+  if ((info = clone_info::get (this)) != NULL)
+{
+  saved_info = *info;
+  clone_info_set = true;
+}
   symtab->call_cgraph_removal_hooks (this);
   remove_callers ();
   remove_callees ();
@@ -1878,7 +1884,7 @@ cgraph_node::remove (void)
   force_output = false;
   forced_by_abi = false;
 
-  unregister ();
+  unregister (clone_info_set ? _info : NULL);
   if (prev_sibling_clone)
 prev_sibling_clone->next_sibling_clone = next_sibling_clone;
   else if (clone_of)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index cd22676ff9e..c87180f1e96 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -631,7 +631,7 @@ protected:
 
   /* Remove node from symbol table.  This function is not used directly, but 
via
  cgraph/varpool node removal routines.  */
-  void unregister (void);
+  void unregister (struct clone_info *);
 
   /* Return the initialization and finalization priority information for
  DECL.  If there is no previous priority information, a freshly
@@ -949,7 +949,7 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public 
symtab_node
 
   /* cgraph node being removed from symbol table; see if its entry can be
replaced by other inline clone.  */
-  cgraph_node *find_replacement (void);
+  cgraph_node *find_replacement (struct clone_info *);
 
   /* Create a new cgraph node which is the new version of
  callgraph node.  REDIRECT_CALLERS holds the callers
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 36ca6477139..a49e58ce279 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -650,7 +650,7 @@ cgraph_node::create_virtual_clone (vec 
redirect_callers,
 /* callgraph node being removed from symbol table; see if its entry can be
replaced by other inline clone.  */
 cgraph_node *
-cgraph_node::find_replacement (void)
+cgraph_node::find_replacement (clone_info *info)
 {
   cgraph_node *next_inline_clone, *replacement;
 
@@ -690,7 +690,6 @@ cgraph_node::find_replacement (void)
   clones = NULL;
 
   /* Copy clone info.  */
-  clone_info *info = clone_info::get (this);
   if (info)
*clone_info::get_create (next_inline_clone) = *info;
 
diff --git a/gcc/symtab-clones.cc b/gcc/symtab-clones.cc
index 76b86c6496f..ad154f6522d 100644
--- a/gcc/symtab-clones.cc
+++ b/gcc/symtab-clones.cc
@@ -42,22 +42,8 @@ class GTY((user)) 

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #5 from Jan Hubicka  ---
I see you have patch, too :)
However we do not want to copy clone info to every inline clone (since
the body is materialized just once).  The problem is that in case the
offline copy is removed we move clone info to first inline clone and
reshape the tree.  This is quite old code to save little memory for the
extra symbol that I may get rid of becuase it also trigger quadratic
time issues with tree-inline, but for now we should copy the info
correctly.  Code is not very well structured for this since it first
calls removal hooks and only then looks for replacement so patch is bit
ugly.  I will clean it up incrementally.

gcc/ChangeLog:

2020-11-03  Jan Hubicka  

* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Fix ICE with
in dumping code.
(cgraph_node::remove): Save clone info before releasing it and pass it
to unregister.
* cgraph.h (symtab_node::unregister): Add clone_info parameter.
(cgraph_clone::unregister): Likewise.
* cgraphclones.c (cgraph_node::find_replacement): Copy clone info
* symtab-clones.cc (clone_infos_t::duplicate): Remove.
(clone_info::get_create): Simplify.
* symtab.c (symtab_node::unregister): Pass around clone info.
* varpool.c (varpool_node::remove): Update.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 36bdb009bf8..19dfe2be23b 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1503,14 +1503,13 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge
*e)

   if (symtab->dump_file)
 {
-
   fprintf (symtab->dump_file, "updating call of %s -> %s: ",
   e->caller->dump_name (), e->callee->dump_name ());
   print_gimple_stmt (symtab->dump_file, e->call_stmt, 0, dump_flags);
   if (callee_info && callee_info->param_adjustments)
callee_info->param_adjustments->dump (symtab->dump_file);
   unsigned performed_len
-   = vec_safe_length (caller_info->performed_splits);
+   = caller_info ? vec_safe_length (caller_info->performed_splits) : 0;
   if (performed_len > 0)
fprintf (symtab->dump_file, "Performed splits records:\n");
   for (unsigned i = 0; i < performed_len; i++)
@@ -1861,12 +1860,19 @@ cgraph_node::release_body (bool keep_arguments)
 void
 cgraph_node::remove (void)
 {
+  bool clone_info_set = false;
+  clone_info *info, saved_info;
   if (symtab->ipa_clones_dump_file && symtab->cloned_nodes.contains (this))
 fprintf (symtab->ipa_clones_dump_file,
 "Callgraph removal;%s;%d;%s;%d;%d\n", asm_name (), order,
 DECL_SOURCE_FILE (decl), DECL_SOURCE_LINE (decl),
 DECL_SOURCE_COLUMN (decl));

+  if ((info = clone_info::get (this)) != NULL)
+{
+  saved_info = *info;
+  clone_info_set = true;
+}
   symtab->call_cgraph_removal_hooks (this);
   remove_callers ();
   remove_callees ();
@@ -1878,7 +1884,7 @@ cgraph_node::remove (void)
   force_output = false;
   forced_by_abi = false;

-  unregister ();
+  unregister (clone_info_set ? _info : NULL);
   if (prev_sibling_clone)
 prev_sibling_clone->next_sibling_clone = next_sibling_clone;
   else if (clone_of)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index cd22676ff9e..c87180f1e96 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -631,7 +631,7 @@ protected:

   /* Remove node from symbol table.  This function is not used directly, but
via
  cgraph/varpool node removal routines.  */
-  void unregister (void);
+  void unregister (struct clone_info *);

   /* Return the initialization and finalization priority information for
  DECL.  If there is no previous priority information, a freshly
@@ -949,7 +949,7 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public
symtab_node

   /* cgraph node being removed from symbol table; see if its entry can be
replaced by other inline clone.  */
-  cgraph_node *find_replacement (void);
+  cgraph_node *find_replacement (struct clone_info *);

   /* Create a new cgraph node which is the new version of
  callgraph node.  REDIRECT_CALLERS holds the callers
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 36ca6477139..a49e58ce279 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -650,7 +650,7 @@ cgraph_node::create_virtual_clone (vec
redirect_callers,
 /* callgraph node being removed from symbol table; see if its entry can be
replaced by other inline clone.  */
 cgraph_node *
-cgraph_node::find_replacement (void)
+cgraph_node::find_replacement (clone_info *info)
 {
   cgraph_node *next_inline_clone, *replacement;

@@ -690,7 +690,6 @@ cgraph_node::find_replacement (void)
   clones = NULL;

   /* Copy clone info.  */
-  clone_info *info = clone_info::get (this);
   if (info)
*clone_info::get_create (next_inline_clone) = *info;

diff --git a/gcc/symtab-clones.cc b/gcc/symtab-clones.cc
index 76b86c6496f..ad154f6522d 100644
--- a/gcc/symtab-clones.cc

[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide

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

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

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

https://gcc.gnu.org/g:875225301e356759982573d5578ed7ca54f81f86

commit r11-4695-g875225301e356759982573d5578ed7ca54f81f86
Author: Jakub Jelinek 
Date:   Tue Nov 3 21:42:51 2020 +0100

c++: Don't try to parse a function declaration as deduction guide [PR97663]

While these function declarations have NULL decl_specifiers->type,
they have still type specifiers specified from which the default int
in the return type is added, so we shouldn't try to parse those as
deduction guides.

2020-11-03  Jakub Jelinek  

PR c++/97663
* parser.c (cp_parser_init_declarator): Don't try to parse
C++17 deduction guides if there are any type specifiers even when
type is NULL.

* g++.dg/cpp1z/class-deduction75.C: New test.

[Bug c/97709] New: powerpc: ICE when building glibc with latest gcc

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

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

Bug ID: 97709
   Summary: powerpc: ICE when building glibc with latest gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msc at linux dot ibm.com
  Target Milestone: ---

Created attachment 49499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49499=edit
Pre-processed source with the issue

This was first observed when upgrading GCC on Advance Toolchain, but I was also
able to reproduce this with upstream GCC (commit 93e79ed391b9c636f0). 

Trying to build glibc with latest GCC causes an internal compiler error:

vfprintf-internal.c: In function ‘__vfprintf_internal’:
vfprintf-internal.c:1320:1: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be
set
for SSA_NAME: _1972 in statement:
prec_413(ab) = PHI <_1972(36)>
PHI argument
_1972
for PHI node
prec_413(ab) = PHI <_1972(36)>
during GIMPLE pass: slp
vfprintf-internal.c:1320:1: internal compiler error: verify_ssa failed
0x10dfa0d3 verify_ssa(bool, bool)
/home/mscastanho/src/gcc/gcc/tree-ssa.c:1208
0x1099fc1f execute_function_todo
/home/mscastanho/src/gcc/gcc/passes.c:2046
0x109a088b do_per_function
/home/mscastanho/src/gcc/gcc/passes.c:1687
0x109a0aaf execute_todo
/home/mscastanho/src/gcc/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.



Preprocessed source generated with -save-temps is attached to the bug. The
issue only happens if I use -mcpu=power9 or -mcpu=power10. -mcpu=power8 seems
to be OK.

Cmdline used:
~/usr/bin/gcc -m64 ./stdio-common/vfprintf-internal.i -c -std=gnu11
-fgnu89-inline  -g -O3 -mcpu=power9 -Wall



NOTE: The original Advance Toolchain build used a slightly older GCC (commit
943cc2a1b70f), and the error message I saw was a bit different (although still
somewhat related):

Unable to coalesce ssa_names 219 and 1972 which are marked as MUST COALESCE.   
   
   
 prec_219(ab) and  _1972 
during RTL pass: expand
vfprintf-internal.c: In function ‘__vfprintf_internal’:
vfprintf-internal.c:148:25: internal compiler error: SSA corruption 
  148 | # define vfprintf   __vfprintf_internal 
  | ^~~ 
vfprintf-internal.c:1320:1: note: in expansion of macro ‘vfprintf’  
 1320 | vfprintf (FILE *s, const CHAR_T *format, va_list ap, unsigned int
mode_flags)
  | ^~~~
0x109e7dc7 fail_abnormal_edge_coalesce 
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1003
 
0x109e7dc7 coalesce_partitions   
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1425
0x109e7dc7 coalesce_ssa_name(_var_map*)
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-ssa-coalesce.c:1755
0x1097f8bb remove_ssa_form
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-outof-ssa.c:1065
0x1097f8bb rewrite_out_of_ssa(ssaexpand*)
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/tree-outof-ssa.c:1323
0x1035f04b execute
   
/home/mscastanho/AT/broken-gcc-p910/build/at15.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/gcc/cfgexpand.c:6378

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #3)
> Yes, exactly.  GCC silently does the wrong thing, contradicting its
> documentation.

Whihc part:
Then use the local variable for the asm operand and specify any constraint
letter that matches the register:
?

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-11-03
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
Yes, exactly.  GCC silently does the wrong thing, contradicting its
documentation.

[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

--- Comment #34 from Jonathan Wakely  ---
Untested sketch of a solution for Solaris and BSDs:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557928.html

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

[bp at alien8 dot de via Gcc-bugs]

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

--- Comment #2 from Boris  ---
(In reply to Andrew Pinski from comment #1)
> "g" constraint won't work here:

So in that case gcc should fail the build. Which it does not.

[Bug inline-asm/97708] Inline asm does not use the local register asm specified with register ... asm() as input

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
"g" constraint won't work here:
‘g’
Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers.
 CUT ---
Notice the last part: "registers that are not general register".
You need to use the "x" constraint here which is for sse register.

[Bug inline-asm/97708] New: Inline asm does not use the local register asm specified with register ... asm() as input

[bp at alien8 dot de via Gcc-bugs]

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

Bug ID: 97708
   Summary: Inline asm does not use the local register asm
specified with register ... asm() as input
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bp at alien8 dot de
  Target Milestone: ---

Building the below on x86-64 with gcc9, gcc10 and Segher built with gcc11
20201015:

---
int main(void)
{

register float foo asm ("xmm0") = 0.99f;

asm volatile("movl %0, %%r8d\n\t"
  "vmcall\n\t"
  :: "g" (foo));

return 0;
}
---

results in gcc not using the xmm0 register directly as the input register to
the asm statement but does something funky:

1125 :
1125:   55  push   %rbp
1126:   48 89 e5mov%rsp,%rbp
1129:   f3 0f 10 05 d3 0e 00movss  0xed3(%rip),%xmm0# 2004
<_IO_stdin_used+0x4>
1130:   00 
1131:   66 0f 7e c0 movd   %xmm0,%eax
1135:   41 89 c0mov%eax,%r8d
1138:   0f 01 c1vmcall 

by loading through the %eax GPR and producing wrong code without even a
warning. I'm not saying this example is supposed to make sense but this should
fail instead by trying to compile:

$ cat xmm1.s
movl %xmm0,%eax

$ x86_64-linux-as xmm1.s -o xmm1.o
xmm1.s: Assembler messages:
xmm1.s:1: Error: unsupported instruction `mov'

and fail the build because plain MOV cannot use an XMM reg as a source.

Thx.

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

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

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

--- Comment #4 from Michael Meissner  ---
You need the patch that fixes PR libgcc/97543, which is another side of the
same coin.  PR 97543 was about making long double default to 64-bits, PR 97643
is about making long double default to IEEE 128-bit.

For both PRs, you need to make sure the modules that deal with IBM 128-bit
values using -mabi=ibmlongdouble.  And also as a good measure, disable GNU
attributes to prevent linker warnings.

Here is the patch that should be applied:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557413.html

[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble

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

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug middle-end/54202] Overeager warning about freeing non-heap objects

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end

--- Comment #7 from Martin Sebor  ---
All late warnings are susceptible to the same problem.  The only way to tell
from the IL that the free call isn't unconditional is from the CFG.  While that
could be used to issue either a "maybe" kind of a warning or a definitive one
per function, it would just turn most instances of these warnings into the
"maybe" kind.  Which is how all warnings need to be viewed regardless.

What might help more than rewording every warning to say "this may be
undefined" is printing the chain of conditions that need to be satisfied in
order for the warning to trigger.  The infrastructure to do this is all there,
it's just a matter of taking advantage of it: when a warning is issued, walk
the shortest path from the entry to the basic block with the problem statement
and print each conditional along the way.  With that, we should end up with
output very close to that of the analyzer:

pr54202.c:17:9: warning: ‘free’ of ‘_null’ which points to memory not on
the heap [CWE-590] [-Wanalyzer-free-of-non-heap]
   17 | free(d);
  | ^~~
  ‘f’: events 1-3
|
|   16 | if (d->refcount == 0)
|  |^
|  ||
|  |(1) following ‘true’ branch...
|   17 | free(d);
|  | ~~~
|  | |
|  | (2) ...to here
|  | (3) call to ‘free’ here
|

Removing basic block 5
f ()
{
  int _2;

   [local count: 1073741824]:
  _2 = shared_null.refcount;
  if (_2 == 0)   <<< condition
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  free (_null); [tail call]   <<< conditional invalid call

   [local count: 1073741824]:
  return;

}

[Bug c++/97453] Implement CWG issue 2303

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r11-4693-ged7f9957bbb5e899099e1ef0e5f6234c453ef7da
Author: kamlesh kumar 
Date:   Mon Nov 2 20:40:21 2020 +0530

c++: DR2303, ambiguous base deduction [PR97453]

When there are two possible matches and one is a base of the other, choose
the derived class rather than fail.

gcc/cp/ChangeLog

2020-10-21  Kamlesh Kumar  
Jason Merrill  

PR c++/97453
DR2303
* pt.c (get_template_base): Consider closest base in template
deduction when base of base also matches.

gcc/testsuite/ChangeLog

2020-10-21  Kamlesh Kumar  

* g++.dg/DRs/dr2303.C: New test.

[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1

[Bug ipa/97698] [11 Regression] ICE: Segmentation fault (in duplicate_thunk_for_node) since r11-4587-gae7a23a3fab74

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

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

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

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

commit r11-4692-ga2058f5812bea3673859a68f9bfea61dbce6730f
Author: Jan Hubicka 
Date:   Tue Nov 3 20:31:23 2020 +0100

Add missing non-NULL check in cgraphclones

2020-11-03  Jan Hubicka  

PR ipa/97698
* cgraphclones.c (duplicate_thunk_for_node): Check that info is
non-NULL.

[Bug c++/78209] Decltype of rvalue reference

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||anders.granlund.0 at gmail dot 
com

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

[Bug c++/97363] Missing diagnostics when trying to initialize rvalue reference variable with lvalue expression when using decltype(auto) type deduction.

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Thanks, looks like a dup of 78209 for which I had a fix, but never posted it.

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

[Bug c++/97645] Rejects valid subscript expression on array of unknown bound in constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/97704] [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

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I forgot to add the error message:

```
: In instantiation of 'auto hard_error(t) [with t = int]':

:11:35:   required by substitution of 'template  requires
requires{hard_error({});} constexpr auto foo(t, non_exisiting) [with t = int]'

:19:17:   required from here
:6:19: error: non-constant condition for static assertion
6 | static_assert(in, "Failure");
  |   ^~

:6:19: error: 'in' is not a constant expression
```

(For some reasons godbolt shows everything in the compliance view as green,
this link https://godbolt.org/z/Go8Mc5 should also show the compiler error)

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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

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

--- Comment #4 from Martin Jambor  ---
And the reason is not copying tree_map in cgraph_node::create_clone
(when called from clone_inlined_nodes).  The following should fix it.
In theory we need a mechanism for create_virtual_clone to create_clone
that it has a new tree_map for the clone but since IPA-CP is the only
pass creating new tree_maps now, it is not a real inefficiency, at
least not yet.


diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index b5793f90b64..aa16a9efbec 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -409,6 +409,9 @@ cgraph_node::create_clone (tree new_decl, profile_count
prof_count,
   new_node->merged_extern_inline = merged_extern_inline;
   clone_info *info = clone_info::get (this);

+  if (info && info->tree_map)
+clone_info::get_create (new_node)->tree_map
+  = vec_safe_copy (info->tree_map);
   if (param_adjustments)
 clone_info::get_create (new_node)->param_adjustments = param_adjustments;
   else if (info && info->param_adjustments)

[Bug c++/97643] Accepts invalid qualification conversion involving array of unknown bound [P0388]

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Accepted since my

commit 89e0a492af5bec8ffa2ec5d99c4858df50d22c16
Author: Marek Polacek 
Date:   Wed Oct 9 20:58:00 2019 +

Implement C++20 P0388R4, DR 1307, and DR 330.

[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

--- Comment #33 from Jonathan Wakely  ---
Fixed for linux targets, not others though.

[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
Bug 66146 depends on bug 84323, which changed state.

Bug 84323 Summary: call_once uses TLS even when once_flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323

   What|Removed |Added

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

[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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Jonathan Wakely  ---
Fixed for GCC 11.

[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

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

--- Comment #5 from Jonathan Wakely  ---
Fixed

[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
Bug 55394 depends on bug 84323, which changed state.

Bug 84323 Summary: call_once uses TLS even when once_flag is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84323

   What|Removed |Added

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

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

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

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

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

https://gcc.gnu.org/g:93e79ed391b9c636f087e6eb7e70f14963cd10ad

commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
Author: Jonathan Wakely 
Date:   Tue Nov 3 18:44:32 2020 +

libstdc++: Rewrite std::call_once to use futexes [PR 66146]

The current implementation of std::call_once uses pthread_once, which
only meets the C++ requirements when compiled with support for
exceptions. For most glibc targets and all non-glibc targets,
pthread_once does not work correctly if the init_routine exits via an
exception. The pthread_once_t object is left in the "active" state, and
any later attempts to run another init_routine will block forever.

This change makes std::call_once work correctly for Linux targets, by
replacing the use of pthread_once with a futex, based on the code from
__cxa_guard_acquire. For both glibc and musl, the Linux implementation
of pthread_once is already based on futexes, and pthread_once_t is just
a typedef for int, so this change does not alter the layout of
std::once_flag. By choosing the values for the int appropriately, the
new code is even ABI compatible. Code that calls the old implementation
of std::call_once will use pthread_once to manipulate the int, while new
code will use the new std::once_flag members to manipulate it, but they
should interoperate correctly. In both cases, the int is initially zero,
has the lowest bit set when there is an active execution, and equals 2
after a successful returning execution. The difference with the new code
is that exceptional exceptions are correctly detected and the int is
reset to zero.

The __cxa_guard_acquire code (and musl's pthread_once) use an additional
state to say there are other threads waiting. This allows the futex wake
syscall to be skipped if there is no contention. Glibc doesn't use a
waiter bit, so we have to unconditionally issue the wake in order to be
compatible with code calling the old std::call_once that uses Glibc's
pthread_once. If we know that we're using musl (and musl's pthread_once
doesn't change) it would be possible to set a waiting state and check
for it in std::once_flag::_M_finish(bool), but this patch doesn't do
that.

This doesn't fix the bug for non-linux targets. A similar approach could
be used for targets where we know the definition of pthread_once_t is a
mutex and an integer. We could make once_flag._M_activate() use
pthread_mutex_lock on the mutex member within the pthread_once_t, and
then only set the integer if the execution finishes, and then unlock the
mutex. That would require careful study of each target's pthread_once
implementation and that work is left for a later date.

This also fixes PR 55394 because pthread_once is no longer needed, and
PR 84323 because the fast path is now just an atomic load.

As a consequence of the new implementation that doesn't use
pthread_once, we can also make std::call_once work for targets with no
gthreads support. The code for the single-threaded implementation
follows the same methods as on Linux, but with no need for atomics or
futexes.

libstdc++-v3/ChangeLog:

PR libstdc++/55394
PR libstdc++/66146
PR libstdc++/84323
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
* include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
even when gthreads is not supported.
(once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
from __gthread_once_t to int.
(once_flag::_M_passive(), once_flag::_M_activate())
(once_flag::_M_finish(bool), once_flag::_Active_execution):
Define new members for futex and non-threaded implementation.
[_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
RAII helper type.
(call_once): Use new members of once_flag.
* src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
(std::once_flag::_M_finish): Define.
* testsuite/30_threads/call_once/39909.cc: Do not require
gthreads.
* testsuite/30_threads/call_once/49668.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/call_once/call_once1.cc: Likewise.
* testsuite/30_threads/call_once/dr2442.cc: Likewise.
* testsuite/30_threads/call_once/once_flag.cc: Add test for
constexpr constructor.
* testsuite/30_threads/call_once/66146.cc: New test.
* testsuite/30_threads/call_once/constexpr.cc: Removed.
* testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.

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

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

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

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

https://gcc.gnu.org/g:93e79ed391b9c636f087e6eb7e70f14963cd10ad

commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
Author: Jonathan Wakely 
Date:   Tue Nov 3 18:44:32 2020 +

libstdc++: Rewrite std::call_once to use futexes [PR 66146]

The current implementation of std::call_once uses pthread_once, which
only meets the C++ requirements when compiled with support for
exceptions. For most glibc targets and all non-glibc targets,
pthread_once does not work correctly if the init_routine exits via an
exception. The pthread_once_t object is left in the "active" state, and
any later attempts to run another init_routine will block forever.

This change makes std::call_once work correctly for Linux targets, by
replacing the use of pthread_once with a futex, based on the code from
__cxa_guard_acquire. For both glibc and musl, the Linux implementation
of pthread_once is already based on futexes, and pthread_once_t is just
a typedef for int, so this change does not alter the layout of
std::once_flag. By choosing the values for the int appropriately, the
new code is even ABI compatible. Code that calls the old implementation
of std::call_once will use pthread_once to manipulate the int, while new
code will use the new std::once_flag members to manipulate it, but they
should interoperate correctly. In both cases, the int is initially zero,
has the lowest bit set when there is an active execution, and equals 2
after a successful returning execution. The difference with the new code
is that exceptional exceptions are correctly detected and the int is
reset to zero.

The __cxa_guard_acquire code (and musl's pthread_once) use an additional
state to say there are other threads waiting. This allows the futex wake
syscall to be skipped if there is no contention. Glibc doesn't use a
waiter bit, so we have to unconditionally issue the wake in order to be
compatible with code calling the old std::call_once that uses Glibc's
pthread_once. If we know that we're using musl (and musl's pthread_once
doesn't change) it would be possible to set a waiting state and check
for it in std::once_flag::_M_finish(bool), but this patch doesn't do
that.

This doesn't fix the bug for non-linux targets. A similar approach could
be used for targets where we know the definition of pthread_once_t is a
mutex and an integer. We could make once_flag._M_activate() use
pthread_mutex_lock on the mutex member within the pthread_once_t, and
then only set the integer if the execution finishes, and then unlock the
mutex. That would require careful study of each target's pthread_once
implementation and that work is left for a later date.

This also fixes PR 55394 because pthread_once is no longer needed, and
PR 84323 because the fast path is now just an atomic load.

As a consequence of the new implementation that doesn't use
pthread_once, we can also make std::call_once work for targets with no
gthreads support. The code for the single-threaded implementation
follows the same methods as on Linux, but with no need for atomics or
futexes.

libstdc++-v3/ChangeLog:

PR libstdc++/55394
PR libstdc++/66146
PR libstdc++/84323
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
* include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
even when gthreads is not supported.
(once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
from __gthread_once_t to int.
(once_flag::_M_passive(), once_flag::_M_activate())
(once_flag::_M_finish(bool), once_flag::_Active_execution):
Define new members for futex and non-threaded implementation.
[_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
RAII helper type.
(call_once): Use new members of once_flag.
* src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
(std::once_flag::_M_finish): Define.
* testsuite/30_threads/call_once/39909.cc: Do not require
gthreads.
* testsuite/30_threads/call_once/49668.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/call_once/call_once1.cc: Likewise.
* testsuite/30_threads/call_once/dr2442.cc: Likewise.
* testsuite/30_threads/call_once/once_flag.cc: Add test for
constexpr constructor.
* testsuite/30_threads/call_once/66146.cc: New test.
* testsuite/30_threads/call_once/constexpr.cc: Removed.
* testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.

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

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

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

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

https://gcc.gnu.org/g:93e79ed391b9c636f087e6eb7e70f14963cd10ad

commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
Author: Jonathan Wakely 
Date:   Tue Nov 3 18:44:32 2020 +

libstdc++: Rewrite std::call_once to use futexes [PR 66146]

The current implementation of std::call_once uses pthread_once, which
only meets the C++ requirements when compiled with support for
exceptions. For most glibc targets and all non-glibc targets,
pthread_once does not work correctly if the init_routine exits via an
exception. The pthread_once_t object is left in the "active" state, and
any later attempts to run another init_routine will block forever.

This change makes std::call_once work correctly for Linux targets, by
replacing the use of pthread_once with a futex, based on the code from
__cxa_guard_acquire. For both glibc and musl, the Linux implementation
of pthread_once is already based on futexes, and pthread_once_t is just
a typedef for int, so this change does not alter the layout of
std::once_flag. By choosing the values for the int appropriately, the
new code is even ABI compatible. Code that calls the old implementation
of std::call_once will use pthread_once to manipulate the int, while new
code will use the new std::once_flag members to manipulate it, but they
should interoperate correctly. In both cases, the int is initially zero,
has the lowest bit set when there is an active execution, and equals 2
after a successful returning execution. The difference with the new code
is that exceptional exceptions are correctly detected and the int is
reset to zero.

The __cxa_guard_acquire code (and musl's pthread_once) use an additional
state to say there are other threads waiting. This allows the futex wake
syscall to be skipped if there is no contention. Glibc doesn't use a
waiter bit, so we have to unconditionally issue the wake in order to be
compatible with code calling the old std::call_once that uses Glibc's
pthread_once. If we know that we're using musl (and musl's pthread_once
doesn't change) it would be possible to set a waiting state and check
for it in std::once_flag::_M_finish(bool), but this patch doesn't do
that.

This doesn't fix the bug for non-linux targets. A similar approach could
be used for targets where we know the definition of pthread_once_t is a
mutex and an integer. We could make once_flag._M_activate() use
pthread_mutex_lock on the mutex member within the pthread_once_t, and
then only set the integer if the execution finishes, and then unlock the
mutex. That would require careful study of each target's pthread_once
implementation and that work is left for a later date.

This also fixes PR 55394 because pthread_once is no longer needed, and
PR 84323 because the fast path is now just an atomic load.

As a consequence of the new implementation that doesn't use
pthread_once, we can also make std::call_once work for targets with no
gthreads support. The code for the single-threaded implementation
follows the same methods as on Linux, but with no need for atomics or
futexes.

libstdc++-v3/ChangeLog:

PR libstdc++/55394
PR libstdc++/66146
PR libstdc++/84323
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
* include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
even when gthreads is not supported.
(once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
from __gthread_once_t to int.
(once_flag::_M_passive(), once_flag::_M_activate())
(once_flag::_M_finish(bool), once_flag::_Active_execution):
Define new members for futex and non-threaded implementation.
[_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
RAII helper type.
(call_once): Use new members of once_flag.
* src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
(std::once_flag::_M_finish): Define.
* testsuite/30_threads/call_once/39909.cc: Do not require
gthreads.
* testsuite/30_threads/call_once/49668.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/call_once/call_once1.cc: Likewise.
* testsuite/30_threads/call_once/dr2442.cc: Likewise.
* testsuite/30_threads/call_once/once_flag.cc: Add test for
constexpr constructor.
* testsuite/30_threads/call_once/66146.cc: New test.
* testsuite/30_threads/call_once/constexpr.cc: Removed.
* testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.

[Bug c++/97648] Rejects valid direct initialization from prvalue (private destructor)

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This is also rejected by clang++ and icc.

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

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #1 from joseph at codesourcery dot com  ---
The C front end doesn't have any kind of general lvalue-to-rvalue 
conversion in the IR (other than for atomic lvalues where the code 
required for such a conversion is more than a simple load, as handled by 
convert_lvalue_to_rvalue) that tries to drop qualifiers; the DECL node is 
used directly to represent a load of a variable, even when the rvalue 
would have the unqualified type.  The circumstances in which typeof 
produces a qualified result type are underspecified.  When a C standard 
construct uses a type in a way that cares about qualifiers not being 
present on rvalues (which I think only applies to _Generic), the removal 
is handled at that point; see this code from c_parser_generic_selection:

  selector = default_function_array_conversion (selector_loc, selector);
[...]
  selector_type = TREE_TYPE (selector.value);
  /* In ISO C terms, rvalues (including the controlling expression of
 _Generic) do not have qualified types.  */
  if (TREE_CODE (selector_type) != ARRAY_TYPE)
selector_type = TYPE_MAIN_VARIANT (selector_type);
  /* In ISO C terms, _Noreturn is not part of the type of expressions
 such as , but in GCC it is represented internally as a type
 qualifier.  */
  if (FUNCTION_POINTER_TYPE_P (selector_type)
  && TYPE_QUALS (TREE_TYPE (selector_type)) != TYPE_UNQUALIFIED)
selector_type
  = build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (selector_type)));

That said, the resolution of bug 45584 means casts always produce a result 
with explicitly unqualified type (including casts to a qualified type, see 
gcc.dg/pr13519-1.c).  It would seem reasonable to do the same for the 
comma operator.  There will be other places as well that do not remove 
qualifiers when constructing the internal representation for rvalues and 
would need adjusting to make the constness of the IR more consistent.  
One example is applying unary '+' to a const int variable; combine that 
with typeof and it shows the result to be const at present.

[Bug ipa/97695] [11 Regression] wrong code at -O3 on x86_64-pc-linux-gnu since r11-4587-gae7a23a3fab74.

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

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

--- Comment #3 from Martin Jambor  ---
It is a clone materialization problem.  IPA-CP clones f.part.0 twice and the
second time tree_function_versioning receives NULL tree_map.

[Bug c++/97646] FAIL: obj-c++.dg/template-4.mm due to ICE in n potential_constant_expression_1, at cp/constexpr.c:8417

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed, Iain has a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557673.html

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

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Thanks for the report. Started with r9-4216-g390e529e2b98983d and yes it's
about a function ending sooner than it starts.
I'll take a look.

[Bug tree-optimization/97707] New: avx12 math function invoked even if -mprefer-vector-width=256 specified

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 97707
   Summary: avx12 math function invoked even if
-mprefer-vector-width=256 specified
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

this code will invoke _ZGVeN8v_sin instead of _ZGVdN4v_sin making use of zmm
registers
#include

int main() {

  double res=0;

  for (int x=0; x<1024;x++) {
double y = x; 
res += std::sin(y);
  }


 return res > 0.5;

}

NOTE if I specify
for (long long x=0; x<1024;x++) {

it will correcty invoke _ZGVdN4v_sin (no zmm)


compiler options
-Ofast -march=skylake-avx512 -mprefer-vector-width=256

[Bug tree-optimization/97706] [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/97706] New: [11 Regression] ICE with LTO at -O3: verify_gimple failed (incompatible types in 'PHI' argument 0)

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

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

Bug ID: 97706
   Summary: [11 Regression] ICE with LTO at -O3: verify_gimple
failed (incompatible types in 'PHI' argument 0)
   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: ---

Since r11-4428-g4a369d199bf2f34e037030b18d0da923e8a24997 I'm seeing an ICE when
compiling the following two (dubious) source files with LTO at -O3 on AArch64:

$ cat f1.c
void a(_Bool x);
void test(char**);
int var_19;
char **d;
_Bool arr_8;
int main()
{
  test(d);
  a(arr_8);
  return var_19;
}

$ cat f2.c
extern int var_19;
extern _Bool arr_8[][6][11];
void test(char **p)
{
  for (int c; c < 9; c++)
for (int d = 0; d < 3; d -= 4LL)
  for (int e = 0; e < 10; e++) {
var_19 = 0;
arr_8[5][d][e] = p[d][e];
  }
}

$ aarch64-elf-gcc -O3 -flto f1.c f2.c
f1.c: In function 'main':
f1.c:6:5: error: incompatible types in 'PHI' argument 0
6 | int main()
  | ^
vector(8) unsigned char

vector(8) 

vect__29.9_48 = PHI 
during GIMPLE pass: slp
f1.c:6:5: internal compiler error: verify_gimple failed
0xcd1728 verify_gimple_in_cfg(function*, bool)
/home/alecop01/toolchain/src/gcc/gcc/tree-cfg.c:5461
0xb7ea24 execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2039
0xb7ec1e do_per_function
/home/alecop01/toolchain/src/gcc/gcc/passes.c:1687
0xb7edb9 execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: aarch64-elf-gcc returned 1 exit status
compilation terminated.
/home/alecop01/toolchain/build-aarch64-elf/install/lib/gcc/aarch64-elf/11.0.0/../../../../aarch64-elf/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/97661] Bogus error message about initializing a using declaration

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
template  struct A {};
struct B : A<> {};
template  struct C {
  A<> *a;
  using V = A<>;
};

C(A<> *)->C<>;

template auto declval() -> decltype(T());
template()})::V> struct
D;
template struct J { };
template using U = J>;

void
fn ()
{
  U u;
}

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

This seems to work (though untested so far except for phi-opt*.c tests).

[Bug c++/97675] GCC does not allow turning off the warning for exceptions being caught by an earlier handler

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug other/97705] [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

--- Comment #1 from seurer at gcc dot gnu.org ---
I tried this on multiple systems and it looks like it may only fail on a BE
system.

[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 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 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 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/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 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 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++/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 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/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 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 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 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 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 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 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

[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 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 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 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 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 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 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 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 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 testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Err, please dg-skip the tests for ! supported targets.  They also fail on
> x86_64 with -m32 btw.

x86_64 with -m32 failure should be already fixed by Uros already.

[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

[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 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 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++/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.