How to regenerate aclocal.m4?

[Zopolis0 via Gcc]

I'm trying to regenerate autotools files in liboffloadmic (and other
directories) but when running automake it tells me I need to run aclocal,
which gives me a warning about not finding AM_ENABLE_MULTILIB in library,
which then translates into an autoconf error. How do I fix this? Is there a
specific aclocal version?

[PATCH v2] Disable tests that require fesetround() on platforms without it

[Palmer Dabbelt]

Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes.  This adds a DG check that fesetround() actually
functions, which is then used by all the tests that call fesetround()
explicitly.

gcc/testsuite/ChangeLog

* lib/target-supports.exp
(check_effective_target_fenv_setround): New function.
* gcc.dg/torture/fp-double-convert-float-1.c: Check
fenv_fesetround.
* gcc.dg/torture/fp-int-convert-float128-timode-3.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-2.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-3.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
* gcc.dg/torture/fp-uint64-convert-double-1.c: Likewise.
* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.
---
Changes since v1 <20220428155514.27063-1-pal...@rivosinc.com>:
  * Checks all defined IEEE rounding modes, rather than just using "1"
(which isn't itself a valid mode on all systems).  The original goal
was to avoid depending on the macros being defined in the first
place, but after thinking about it this seems better anyway as IIUC
users are supposed to be testing for those before using them already
(the trick here is that RISC-V may choose not to implement these at
runtime, even when they are defined).
  * Those atomics were a known issue, not sure how I forgot about them.
---
 .../torture/fp-double-convert-float-1.c   |  2 +-
 .../fp-int-convert-float128-timode-3.c|  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-2.c  |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-3.c  |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-4.c  |  2 +-
 .../torture/fp-uint64-convert-double-1.c  |  2 +-
 .../torture/fp-uint64-convert-double-2.c  |  2 +-
 gcc/testsuite/lib/target-supports.exp | 35 +++
 8 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c 
b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
index ec23274ea98..656e5c345e7 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
@@ -1,6 +1,6 @@
 /* PR57245 */
 /* { dg-do run } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-additional-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
index c445d10522e..499e8c0cabf 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
@@ -4,7 +4,7 @@
 /* { dg-require-effective-target __float128 } */
 /* { dg-require-effective-target base_quadfloat_support } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 /* { dg-add-options __float128 } */
 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
index a82f03d079c..3f91f8f3833 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
index 707d539335f..816fcb1120e 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
index 09600f90903..6337a6d3f1e 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c 
b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
index fadad8c3198..43aeb81a602 100644
--- 

Re: [patch, fortran, doc] Mention new CONVERT options for POWER

[Bernhard Reutner-Fischer via Gcc-patches]

On Fri, 29 Apr 2022 20:03:55 +0200
Thomas Koenig  wrote:

> On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
> > ISTM that this should be s/mod.e/mode./ ?  
> 
> Yep, fixed as obvious and simple on trunk with
> r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .

thanks!
> 
> OK for backport to gcc-12? (This is both extremely safe and
> not particularly important :-)

I'd say yes because it's 1) doc 2) trivial 3) obvious :)

But formally, i think RM approval is needed ATM.
Richard?

gcc-11-20220429 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220429 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220429/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 14aad65778c64eb62fd4055c0986af2f6e54f97b

You'll find:

 gcc-11-20220429.tar.xz   Complete GCC

  SHA256=d916b04b3b1e3ab67960967f6d49da64af76e43a04d0c66374bb1dfa694b5829
  SHA1=ce6e54b719d8944f3efac6acebd848b665fe0905

Diffs from 11-20220423 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug middle-end/105400] g++-11 regression produces -Warray-bounds false positive warning with -O2

[laurent.pinchart at ideasonboard dot com via Gcc-bugs]

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

--- Comment #3 from Laurent Pinchart  
---
Created attachment 52911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52911=edit
Original preprocessed sources

Here's the full preprocessed source, corresponding to
https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/base/object.cpp,
generated with

$ g++-11.2.1 -v -save-temps -Isrc/libcamera/base/libcamera-base.so.0.0.0.p
-Isrc/libcamera/base -I../../src/libcamera/base -Iinclude -I../../include
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O3 -Wshadow -include config.h
-fPIC -pthread -DLIBCAMERA_BASE_PRIVATE -MD -MQ
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o -MF
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o.d -o
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o -c
../../src/libcamera/base/object.cpp
Using built-in specs.
COLLECT_GCC=g++-11.2.1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.2.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.2.1/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
11.2.1_p20220115 p4' --disable-esp --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --disable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --without-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20220115 (Gentoo 11.2.1_p20220115 p4) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-v' '-save-temps' '-I'
'src/libcamera/base/libcamera-base.so.0.0.0.p' '-I' 'src/libcamera/base' '-I'
'../../src/libcamera/base' '-I' 'include' '-I' '../../include' '-D'
'_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-Wextra'
'-Werror' '-std=c++17' '-O3' '-Wshadow' '-include' 'config.h' '-fPIC'
'-pthread' '-D' 'LIBCAMERA_BASE_PRIVATE' '-MD' '-MQ'
'src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o' '-MF'
'src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o.d' '-o'
'src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'src/libcamera/base/libcamera-base.so.0.0.0.p/'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/cc1plus -E -quiet -v -I
src/libcamera/base/libcamera-base.so.0.0.0.p -I src/libcamera/base -I
../../src/libcamera/base -I include -I ../../include -MD
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.d -MF
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o.d -MQ
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.o -D_GNU_SOURCE
-D_REENTRANT -D _FILE_OFFSET_BITS=64 -D LIBCAMERA_BASE_PRIVATE -include
config.h ../../src/libcamera/base/object.cpp -mtune=generic -march=x86-64
-std=c++17 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -Wshadow
-fdiagnostics-color=always -fPIC -O3 -fpch-preprocess -o
src/libcamera/base/libcamera-base.so.0.0.0.p/object.cpp.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 src/libcamera/base/libcamera-base.so.0.0.0.p
 src/libcamera/base
 ../../src/libcamera/base
 include
 ../../include
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-v' '-save-temps' '-I'
'src/libcamera/base/libcamera-base.so.0.0.0.p' '-I' 'src/libcamera/base' '-I'
'../../src/libcamera/base' '-I' 'include' '-I' '../../include' '-D'
'_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-Wextra'
'-Werror' '-std=c++17' '-O3' '-Wshadow' '-include' 'config.h' 

[Bug c++/91618] [9/10/11 Regression] template-id required to friend a function template, even for a qualified-id

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

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

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

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

commit r13-55-ge9d2adc17d0dbe46db67e1b618dea888d5c7aca3
Author: Jason Merrill 
Date:   Fri Apr 8 13:48:25 2022 -0400

c++: reorganize friend template matching [PR91618]

The the different calling of check_explicit_specialization for class and
namespace scope friends bothered me, so this patch combines them.

PR c++/91618
PR c++/96604

gcc/cp/ChangeLog:

* friend.cc (do_friend): Call check_explicit_specialization here.
* decl.cc (grokdeclarator): Not here.
* decl2.cc (check_classfn): Or here.

[Bug c++/96604] rejects-valid on befriending specialization of conversion function template

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

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

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

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

commit r13-55-ge9d2adc17d0dbe46db67e1b618dea888d5c7aca3
Author: Jason Merrill 
Date:   Fri Apr 8 13:48:25 2022 -0400

c++: reorganize friend template matching [PR91618]

The the different calling of check_explicit_specialization for class and
namespace scope friends bothered me, so this patch combines them.

PR c++/91618
PR c++/96604

gcc/cp/ChangeLog:

* friend.cc (do_friend): Call check_explicit_specialization here.
* decl.cc (grokdeclarator): Not here.
* decl2.cc (check_classfn): Or here.

[pushed] c++: reorganize friend template matching [PR91618]

[Jason Merrill via Gcc-patches]

The the different calling of check_explicit_specialization for class and
namespace scope friends bothered me, so this patch combines them.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/91618
PR c++/96604

gcc/cp/ChangeLog:

* friend.cc (do_friend): Call check_explicit_specialization here.
* decl.cc (grokdeclarator): Not here.
* decl2.cc (check_classfn): Or here.
---
 gcc/cp/decl.cc   |  9 -
 gcc/cp/decl2.cc  |  9 ++---
 gcc/cp/friend.cc | 92 +---
 3 files changed, 49 insertions(+), 61 deletions(-)

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 16565bf0a0e..324498f399d 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -14142,15 +14142,6 @@ grokdeclarator (const cp_declarator *declarator,
 So set it here.  */
  funcdef_flag = true;
 
-   if (template_class_depth (current_class_type) == 0)
- {
-   decl = check_explicit_specialization
- (unqualified_id, decl, template_count,
-  2 * funcdef_flag + 4);
-   if (decl == error_mark_node)
- return error_mark_node;
- }
-
decl = do_friend (ctype, unqualified_id, decl,
  flags, funcdef_flag);
return decl;
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index d2b29208ed5..ae743c8a3df 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -799,14 +799,9 @@ check_classfn (tree ctype, tree function, tree 
template_parms)
 is replaced with the specialization chosen by deduction from the
 friend declaration or discarded if deduction fails."
 
-So ask check_explicit_specialization to find a matching template.  */
+So tell check_explicit_specialization to look for a match.  */
   SET_DECL_IMPLICIT_INSTANTIATION (function);
-  tree spec = check_explicit_specialization (DECL_NAME (function),
-function, /* tcount */0,
-/* friend flag */4,
-/* attrlist */NULL_TREE);
-  if (spec != error_mark_node)
-   matched = spec;
+  matched = function;
 }
 
   if (!matched)
diff --git a/gcc/cp/friend.cc b/gcc/cp/friend.cc
index acbe0eccb8e..124ed4f3962 100644
--- a/gcc/cp/friend.cc
+++ b/gcc/cp/friend.cc
@@ -506,6 +506,7 @@ do_friend (tree ctype, tree declarator, tree decl,
 error ("friend declaration %qD may not have virt-specifiers",
   decl);
 
+  tree orig_declarator = declarator;
   if (TREE_CODE (declarator) == TEMPLATE_ID_EXPR)
 {
   declarator = TREE_OPERAND (declarator, 0);
@@ -513,32 +514,33 @@ do_friend (tree ctype, tree declarator, tree decl,
declarator = OVL_NAME (declarator);
 }
 
+  /* CLASS_TEMPLATE_DEPTH counts the number of template headers for
+ the enclosing class.  FRIEND_DEPTH counts the number of template
+ headers used for this friend declaration.  TEMPLATE_MEMBER_P is
+ true if a template header in FRIEND_DEPTH is intended for
+ DECLARATOR.  For example, the code
+
+ template  struct A {
+   template  struct B {
+template  template 
+  friend void C::f(W);
+   };
+ };
+
+ will eventually give the following results
+
+ 1. CLASS_TEMPLATE_DEPTH equals 2 (for `T' and `U').
+ 2. FRIEND_DEPTH equals 2 (for `V' and `W').
+ 3. CTYPE_DEPTH equals 1 (for `V').
+ 4. TEMPLATE_MEMBER_P is true (for `W').  */
+
+  int class_template_depth = template_class_depth (current_class_type);
+  int friend_depth = current_template_depth - class_template_depth;
+  int ctype_depth = num_template_headers_for_class (ctype);
+  bool template_member_p = friend_depth > ctype_depth;
+
   if (ctype)
 {
-  /* CLASS_TEMPLATE_DEPTH counts the number of template headers for
-the enclosing class.  FRIEND_DEPTH counts the number of template
-headers used for this friend declaration.  TEMPLATE_MEMBER_P is
-true if a template header in FRIEND_DEPTH is intended for
-DECLARATOR.  For example, the code
-
-  template  struct A {
-template  struct B {
-  template  template 
-friend void C::f(W);
-};
-  };
-
-will eventually give the following results
-
-1. CLASS_TEMPLATE_DEPTH equals 2 (for `T' and `U').
-2. FRIEND_DEPTH equals 2 (for `V' and `W').
-3. TEMPLATE_MEMBER_P is true (for `W').  */
-
-  int class_template_depth = template_class_depth (current_class_type);
-  int friend_depth = current_template_depth - class_template_depth;
-  /* We will figure this out later.  */
-  bool template_member_p = false;
-
   tree cname = TYPE_NAME (ctype);
   if (TREE_CODE (cname) == TYPE_DECL)
cname = DECL_NAME (cname);
@@ 

[Bug c++/104470] [10/11/12/13 Regression] internal compiler error: Segmentation fault compiling std::variant with -std=c++20

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

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

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

https://gcc.gnu.org/g:4259c229b457361a9b5cdec157e058bf0c2c8b77

commit r13-54-g4259c229b457361a9b5cdec157e058bf0c2c8b77
Author: Jason Merrill 
Date:   Wed Apr 27 11:13:24 2022 -0400

c++: alias CTAD and member alias templates [PR104470]

In this testcase, we were trying to substitute into
variant>::__accepted_type, but failed to look it up because
variant> doesn't exist.  In other cases we already rewrite such
things into a dependent reference; we need to do that for alias templates
as
well.

This caused some testsuite regressions on alias uses outside of deduction
guides, so I've made all of this rewriting conditional on a new tf_dguide
tsubst flag.

PR c++/104470

gcc/cp/ChangeLog:

* cp-tree.h (enum tsubst_flags): Add tf_dguide.
* pt.cc (tsubst_aggr_type): Check it.
(tsubst_baselink, tsubst_copy): Check it.
(maybe_dependent_member_ref): Check it.
(instantiate_alias_template): Handle it.
(build_deduction_guide): Set it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/explicit11.C: Second example also ill-formed.
* g++.dg/cpp2a/class-deduction-alias12.C: New test.

[pushed] c++: alias CTAD and member alias templates [PR104470]

[Jason Merrill via Gcc-patches]

In this testcase, we were trying to substitute into
variant>::__accepted_type, but failed to look it up because
variant> doesn't exist.  In other cases we already rewrite such
things into a dependent reference; we need to do that for alias templates as
well.

This caused some testsuite regressions on alias uses outside of deduction
guides, so I've made all of this rewriting conditional on a new tf_dguide
tsubst flag.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/104470

gcc/cp/ChangeLog:

* cp-tree.h (enum tsubst_flags): Add tf_dguide.
* pt.cc (tsubst_aggr_type): Check it.
(tsubst_baselink, tsubst_copy): Check it.
(maybe_dependent_member_ref): Check it.
(instantiate_alias_template): Handle it.
(build_deduction_guide): Set it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/explicit11.C: Second example also ill-formed.
* g++.dg/cpp2a/class-deduction-alias12.C: New test.
---
 gcc/cp/cp-tree.h  |  1 +
 gcc/cp/pt.cc  | 27 +++
 .../g++.dg/cpp2a/class-deduction-alias12.C| 23 
 gcc/testsuite/g++.dg/cpp2a/explicit11.C   |  2 +-
 4 files changed, 47 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias12.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index e9a3d09ac4c..7217768 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5565,6 +5565,7 @@ enum tsubst_flags {
constraint normalization.  */
   tf_tst_ok = 1 << 12,  /* Allow a typename-specifier to name
a template (C++17 or later).  */
+  tf_dguide = 1 << 13, /* Building a deduction guide from a ctor.  */
   /* Convenient substitution flags combinations.  */
   tf_warning_or_error = tf_warning | tf_error
 };
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 81f7ef5c42b..81c3c598c71 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13730,8 +13730,8 @@ tsubst_aggr_type (tree t,
 complain, in_decl);
  if (argvec == error_mark_node)
r = error_mark_node;
- else if (!entering_scope
-  && cxx_dialect >= cxx17 && dependent_scope_p (context))
+ else if (!entering_scope && (complain & tf_dguide)
+  && dependent_scope_p (context))
{
  /* See maybe_dependent_member_ref.  */
  tree name = TYPE_IDENTIFIER (t);
@@ -16497,7 +16497,7 @@ tsubst_baselink (tree baselink, tree object_type,
name = make_conv_op_name (optype);
 
   /* See maybe_dependent_member_ref.  */
-  if (dependent_scope_p (qualifying_scope))
+  if ((complain & tf_dguide) && dependent_scope_p (qualifying_scope))
{
  if (template_id_p)
name = build2 (TEMPLATE_ID_EXPR, unknown_type_node, name,
@@ -16817,7 +16817,7 @@ static tree
 maybe_dependent_member_ref (tree t, tree args, tsubst_flags_t complain,
tree in_decl)
 {
-  if (cxx_dialect < cxx17)
+  if (!(complain & tf_dguide))
 return NULL_TREE;
 
   tree ctx = context_for_name_lookup (t);
@@ -17075,7 +17075,7 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 have to substitute this with one having context `D'.  */
 
  tree context = tsubst (DECL_CONTEXT (t), args, complain, in_decl);
- if (dependent_scope_p (context))
+ if ((complain & tf_dguide) && dependent_scope_p (context))
{
  /* When rewriting a constructor into a deduction guide, a
 non-dependent name can become dependent, so memtmpl
@@ -21715,6 +21715,21 @@ instantiate_alias_template (tree tmpl, tree args, 
tsubst_flags_t complain)
   if (tmpl == error_mark_node || args == error_mark_node)
 return error_mark_node;
 
+  /* See maybe_dependent_member_ref.  */
+  if (complain & tf_dguide)
+{
+  tree ctx = tsubst_aggr_type (DECL_CONTEXT (tmpl), args, complain,
+  tmpl, true);
+  if (dependent_scope_p (ctx))
+   {
+ tree name = DECL_NAME (tmpl);
+ tree fullname = build_nt (TEMPLATE_ID_EXPR, name,
+   INNERMOST_TEMPLATE_ARGS (args));
+ tree tname = build_typename_type (ctx, name, fullname, typename_type);
+ return TYPE_NAME (tname);
+   }
+}
+
   args =
 coerce_innermost_template_parms (DECL_TEMPLATE_PARMS (tmpl),
 args, tmpl, complain,
@@ -29279,6 +29294,8 @@ build_deduction_guide (tree type, tree ctor, tree 
outer_args, tsubst_flags_t com
   ++processing_template_decl;
   bool ok = true;
 
+  complain |= tf_dguide;
+
   fn_tmpl
= (TREE_CODE (ctor) == TEMPLATE_DECL ? ctor
   : DECL_TI_TEMPLATE (ctor));
diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias12.C 

[Bug c++/82980] [9/10/11 Regression] template keyword should not be required for captured decl of the "base" type since r6-6866-gff2faafcf689b6c2

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

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

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

https://gcc.gnu.org/g:53e7252140c95afc859ade521a61ab4115d7fb11

commit r13-53-g53e7252140c95afc859ade521a61ab4115d7fb11
Author: Jason Merrill 
Date:   Thu Apr 14 14:09:13 2022 -0400

c++: lambda capture dependent type [PR82980]

The stage 4 patch limited direct propagation of dependent type to capture
field/proxy to the "current instantiation", but many more types should be
suitable as well.

PR c++/82980

gcc/cp/ChangeLog:

* lambda.cc (type_deducible_expression_p): Allow more types.

[pushed] c++: lambda capture dependent type [PR82980]

[Jason Merrill via Gcc-patches]

The stage 4 patch limited direct propagation of dependent type to capture
field/proxy to the "current instantiation", but many more types should be
suitable as well.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

* lambda.cc (type_deducible_expression_p): Allow more types.
---
 gcc/cp/lambda.cc | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
index 65579edc316..10834d6b143 100644
--- a/gcc/cp/lambda.cc
+++ b/gcc/cp/lambda.cc
@@ -195,10 +195,9 @@ type_deducible_expression_p (tree expr)
   || TREE_CODE (expr) == EXPR_PACK_EXPANSION)
 return false;
   tree t = non_reference (TREE_TYPE (expr));
-  if (!t) return false;
-  while (TREE_CODE (t) == POINTER_TYPE)
-t = TREE_TYPE (t);
-  return currently_open_class (t);
+  return (t && TREE_CODE (t) != TYPE_PACK_EXPANSION
+ && !WILDCARD_TYPE_P (t) && !LAMBDA_TYPE_P (t)
+ && !type_uses_auto (t));
 }
 
 /* Returns the type to use for the FIELD_DECL corresponding to the

base-commit: 8189838d823ea65e560c573d38a65edc12f5c2e3
-- 
2.27.0

[Bug tree-optimization/105437] New: ICE on GIMPLE pass slp when vectorizer is enabled

[giuliano.belinassi at gmail dot com via Gcc-bugs]

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

Bug ID: 105437
   Summary: ICE on GIMPLE pass slp when vectorizer is enabled
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giuliano.belinassi at gmail dot com
  Target Milestone: ---

Given the following C++ input:
```
struct ControlClass
{
virtual ~ControlClass();

int Width;
int Height;
unsigned IsToRepaint : 1;
};

struct SelectClass : ControlClass
{
SelectClass(void);
};

int Non_Folded_Value();

SelectClass::SelectClass(void)
{
int factor = Non_Folded_Value();
Width = 32 << factor;
Height = 24 << factor;
}
```

saved as bug.cpp, and compiling with:

> g++-11 -O2 -ftree-vectorize -S bug.cpp

results in the following ICE:
```
during GIMPLE pass: ehcleanup
bug.cpp: In constructor ‘SelectClass::SelectClass()’:
bug.cpp:17:1: internal compiler error: in mark_reachable_handlers, at
tree->eh.c:4036
   17 | SelectClass::SelectClass(void)
  | ^~~
0x7f03bd2cd2bc __libc_start_main
???:0
```

This bug is still present on trunk. It happens even without -ftree-vectorize,
but the output is:
```
bug.cpp: In constructor ‘SelectClass::SelectClass()’:
bug.cpp:17:1: error: statement marked for throw in middle of block
   17 | SelectClass::SelectClass(void)
  | ^~~
# .MEM_8 = VDEF <.MEM_7>
_9 = Non_Folded_Value ();
during GIMPLE pass: slp
bug.cpp:17:1: internal compiler error: verify_gimple failed
0x112f364 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.cc:5561
0xfd5eae execute_function_todo
../../gcc/gcc/passes.cc:2085
0xfd6932 execute_todo
../../gcc/gcc/passes.cc:2139

```

I tracked this issue back to commit 9e5508c2d006f2d4f8670e6c3fed770ac1c85e64:
"refactor SLP constant insertion and provde entry insert helper", but simple
`git revert` doesn't work as one of the files seems to have been deleted/moved.

GCC-10 and older are unaffected. (tested until gcc 7.5.0)

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

--- Comment #6 from Aldy Hernandez  ---
Created attachment 52910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52910=edit
untested patch

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
   Last reconfirmed||2022-04-29
 Ever confirmed|0   |1

--- Comment #5 from Aldy Hernandez  ---
set_range_info does not handle VR_VARYING because SSA_NAME_RANGE_TYPE can only
store VR_RANGE or VR_ANTI_RANGE.  However, we allow storing a range of the
entire domain because nonzero bits can be set on such a range.

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

The correct thing to do here is to force VR_RANGE in this scenario.

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

--- Comment #3 from Marek Polacek  ---
I think the fix is just

--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -33224,7 +33224,6 @@ cp_parser_next_token_ends_template_argument_p
(cp_parser *parser)
  || ((cxx_dialect != cxx98) && token->type == CPP_RSHIFT)
  /* For better diagnostics, treat >>= like that too, that
 shouldn't appear non-nested in template arguments.  */
- || token->type == CPP_GREATER_EQ
  || token->type == CPP_RSHIFT_EQ);
 }


it doesn't regress anything and fixes this test.  Probably just an oversight,
the code doesn't match the comment.

*ping* [patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12

[Thomas Koenig via Gcc-patches]

the attached patch documents the support for IEEE long double for
Fortran.  OK?  Suggestions for better wording?


I'd like to get this in before the gcc12 release.  It would also
qualify as obviously correct, I think :-) so I'll commit this
on Sunday unless there are any objections.

Patch at

https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593780.html

Best regards

Thomas

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

--- Comment #2 from Marek Polacek  ---
The C++14 vs C++17 difference is due to:

  /* It must be a non-type argument.  In C++17 any constant-expression is
 allowed.  */
  if (cxx_dialect > cxx14)
goto general_expr;

in cp_parser_template_argument.  So in C++14 we get "N" as the targ but in
C++17 it is the whole "N >= 5" expression.

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #13 from Iain Sandoe  ---
I can repeat your observation on master; but at the moment not sure where the
problem lies.

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Joseph Myers]

On Fri, 29 Apr 2022, Jason Merrill via Gcc-patches wrote:

> Marek pointed out elsewhere that the first testcase should have
> 
> // { dg-additional-options -g }
> 
> OK for 13 with that change?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function

[ndesaulniers at google dot com via Gcc-bugs]

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

Nick Desaulniers  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #15 from Nick Desaulniers  ---
Any chance we could get -mdirect-extern-access implemented for aarch64? 
Otherwise we're discussing the use of `#pragma GCC visibility push(hidden)` for
use in the linux kernel since it's slightly more portable at the moment.

https://lore.kernel.org/linux-arm-kernel/20220427171241.2426592-3-a...@kernel.org/

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Keywords||rejects-valid

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

[Bug c++/105436] New: parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

Bug ID: 105436
   Summary: parse error with >= operator expression in template
argument list in C++14 mode since r13-40
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

After r13-40-ga282da2243103d we reject the following presumably valid snippet
in C++14 mode (and earlier):

template struct A;
template A= 5> f();

with the parse error:

testcase.C:2:21: error: ‘>=’ should be ‘> =’ to terminate a template argument
list
2 | template A= 5> f();
  | ^~
  | > =
testcase.C:2:24: error: expected unqualified-id before numeric constant
2 | template A= 5> f();

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

--- Comment #4 from seurer at gcc dot gnu.org ---
configure was:

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

though note it also failed for power9, power8, and power7 and on both LE and
BE.

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Created attachment 52909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52909=edit
atan.i

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

[Jason Merrill via Gcc-patches]

On 4/27/22 19:48, Jason Merrill wrote:

On 4/27/22 13:02, Joseph Myers wrote:

On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:


+  if (typedef_variant_p (type))
+    {
+  /* Set up the typedef all over again.  */


This seems wrong when the typedef is just being used in another
declaration with the mode attribute, as opposed to being defined using 
the

mode attribute.  E.g. the following test is valid and accepted before the
patch, but wrongly rejected after the patch because the typedef has had
its type changed.

typedef int I;
int x;
I y __attribute__ ((mode(QI)));
extern I x;


Ah, good point.  Fixed thus:


Marek pointed out elsewhere that the first testcase should have

// { dg-additional-options -g }

OK for 13 with that change?

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #4 from joseph at codesourcery dot com  ---
If you can identify specific arguments passed to mpc_asin for which it is 
excessively slow, that should be reported as an MPC bug.

Computing correctly rounded mpc_asin shouldn't need to be that slow - 
provided the algorithm used is appropriate to the input value.  See for 
example how glibc implements casin / casinh / cacos / cacosh.  Or 
https://dl.acm.org/doi/10.1145/275323.275324 (Hull et al, Implementing the 
complex arcsine and arccosine functions using exception handling, ACM TOMS 
vol. 23 no. 3 (Sep 1997) pp 299-335).  That may require several different 
algorithms to be implemented, but each such algorithm is straightforward.  
That's different from the case of Bessel functions of high order - for 
which there is some literature about computational techniques that 
shouldn't take time proportional to the order, but where the algorithms 
are certainly a lot more complicated.

[Bug c++/67048] [9/10/11/12 Regression] GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11/12/13 Regression]  |[9/10/11/12 Regression] GCC
   |GCC rejects well-formed |rejects well-formed program
   |program using empty |using empty anonymous enum
   |anonymous enum specifier in |specifier in a variable
   |a variable declaration  |declaration

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 13 so far.

[Bug c++/67048] [9/10/11/12/13 Regression] GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-51-gfd0d3e9121c5aa65150d242676be6bbdc8d4a92a
Author: Marek Polacek 
Date:   Thu Apr 28 16:50:06 2022 -0400

c++: pedwarn for empty unnamed enum in decl [PR67048]

[dcl.dcl]/5 says that

  enum { };

is ill-formed, and since r197742 we issue a pedwarn.  However, the
pedwarn also fires for

   enum { } x;

which is well-formed.  So only warn when {} is followed by a ;.  This
should be correct since you can't have "enum {}, " -- that
produces "expected unqualified-id before ',' token".

PR c++/67048

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enum_specifier): Warn about empty unnamed
enum
only when it's followed by a semicolon.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/enum42.C: New test.

[Bug c++/64679] Spurious redefinition error when parsing not-quite-most-vexing-parse declarations

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

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

Marek Polacek  changed:

   What|Removed |Added

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

Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Matthias Kretz via Gcc-patches]

On Friday, 29 April 2022 03:53:40 CEST Alexandre Oliva via Gcc-patches wrote:
> Thanks, awaiting feedback on the suggestion above to post the consolidated
> patch.

LGTM. I think this improves clarity for the __intrisic_type static assertions 
significantly.

And don't bother with my other mail. If `__vector double` without VSX was 
always ill-formed then I must be misremembering something.

Cheers,
  Matthias

-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──

Re: [PATCH] c++: pedwarn for empty unnamed enum in decl [PR67048]

[Jason Merrill via Gcc-patches]

On 4/29/22 10:12, Marek Polacek wrote:

[dcl.dcl]/5 says that

   enum { };

is ill-formed, and since r197742 we issue a pedwarn.  However, the
pedwarn also fires for

enum { } x;

which is well-formed.  So only warn when {} is followed by a ;.  This
should be correct since you can't have "enum {}, " -- that
produces "expected unqualified-id before ',' token".

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?  I think
this could go to 12.2 and 11.4 too.


OK.


PR c++/67048

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enum_specifier): Warn about empty unnamed enum
only when it's followed by a semicolon.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/enum42.C: New test.
---
  gcc/cp/parser.cc| 4 +++-
  gcc/testsuite/g++.dg/cpp0x/enum42.C | 7 +++
  2 files changed, 10 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/enum42.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 2235da10c7c..0fa37fdfb66 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -21007,7 +21007,9 @@ cp_parser_enum_specifier (cp_parser* parser)
/* If the next token is not '}', then there are some enumerators.  */
else if (cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_BRACE))
{
- if (is_unnamed && !scoped_enum_p)
+ if (is_unnamed && !scoped_enum_p
+ /* Don't warn for enum {} a; here.  */
+ && cp_lexer_nth_token_is (parser->lexer, 2, CPP_SEMICOLON))
pedwarn (type_start_token->location, OPT_Wpedantic,
 "ISO C++ forbids empty unnamed enum");
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum42.C 
b/gcc/testsuite/g++.dg/cpp0x/enum42.C
new file mode 100644
index 000..05b372a1947
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum42.C
@@ -0,0 +1,7 @@
+// PR c++/67048
+// { dg-do compile { target c++11 } }
+// { dg-options -Wpedantic }
+
+typedef enum {} X;
+enum {} x;
+enum {} y, z;

base-commit: 9ae8b993cd362e8aea4f65580aaf1453120207f2

Re: [PATCH] Use CASE_CONVERT in a few more cases

[Jason Merrill via Gcc-patches]

On 4/29/22 05:37, Richard Biener wrote:


This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?

Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EXPR and NOP_EXPR at the moment,
are the C++ bits nevertheless OK?


Yes.


2022-04-29  Richard Biener  

cp/
* constexpr.cc (fold_simple_1): Use CASE_CONVERT.
* cp-gimplify.cc (cp_fold): Likewise.
* pt.cc (tsubst_copy): Likewise.

* dojump.cc (do_jump): Use CASE_CONVERT.
* tree-ssa-dom.cc (edge_info::derive_equivalences): Likewise.
---
  gcc/cp/constexpr.cc   | 3 +--
  gcc/cp/cp-gimplify.cc | 3 +--
  gcc/cp/pt.cc  | 3 +--
  gcc/dojump.cc | 4 +---
  gcc/tree-ssa-dom.cc   | 3 +--
  5 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 47d5113ace2..c40efa6cc4e 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8016,9 +8016,8 @@ fold_simple_1 (tree t)
  case NEGATE_EXPR:
  case BIT_NOT_EXPR:
  case TRUTH_NOT_EXPR:
-case NOP_EXPR:
  case VIEW_CONVERT_EXPR:
-case CONVERT_EXPR:
+CASE_CONVERT:
  case FLOAT_EXPR:
  case FIX_TRUNC_EXPR:
  case FIXED_CONVERT_EXPR:
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index e4c2644af15..b52d9cb5754 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -2451,9 +2451,8 @@ cp_fold (tree x)
  case VIEW_CONVERT_EXPR:
rval_ops = false;
/* FALLTHRU */
-case CONVERT_EXPR:
-case NOP_EXPR:
  case NON_LVALUE_EXPR:
+CASE_CONVERT:
  
if (VOID_TYPE_P (TREE_TYPE (x)))

{
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 81f7ef5c42b..83600d52b33 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -17152,8 +17152,7 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
  case STATIC_CAST_EXPR:
  case DYNAMIC_CAST_EXPR:
  case IMPLICIT_CONV_EXPR:
-case CONVERT_EXPR:
-case NOP_EXPR:
+CASE_CONVERT:
{
tsubst_flags_t tcomplain = complain;
if (code == CAST_EXPR)
diff --git a/gcc/dojump.cc b/gcc/dojump.cc
index 0c880d65338..17a73da7448 100644
--- a/gcc/dojump.cc
+++ b/gcc/dojump.cc
@@ -421,14 +421,12 @@ do_jump (tree exp, rtx_code_label *if_false_label,
break;
  #endif
  
-case NOP_EXPR:

+CASE_CONVERT:
if (TREE_CODE (TREE_OPERAND (exp, 0)) == COMPONENT_REF
|| TREE_CODE (TREE_OPERAND (exp, 0)) == BIT_FIELD_REF
|| TREE_CODE (TREE_OPERAND (exp, 0)) == ARRAY_REF
|| TREE_CODE (TREE_OPERAND (exp, 0)) == ARRAY_RANGE_REF)
  goto normal;
-  /* FALLTHRU */
-case CONVERT_EXPR:
/* If we are narrowing the operand, we have to do the compare in the
   narrower mode.  */
if ((TYPE_PRECISION (TREE_TYPE (exp))
diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc
index 4a0cf2ef54c..89b05171d57 100644
--- a/gcc/tree-ssa-dom.cc
+++ b/gcc/tree-ssa-dom.cc
@@ -220,8 +220,7 @@ edge_info::derive_equivalences (tree name, tree value, int 
recursion_limit)
/* If LHS is an SSA_NAME and RHS is a constant integer and LHS was
   set via a widening type conversion, then we may be able to record
   additional equivalences.  */
-   case NOP_EXPR:
-   case CONVERT_EXPR:
+   CASE_CONVERT:
  {
tree rhs = gimple_assign_rhs1 (def_stmt);
tree rhs_type = TREE_TYPE (rhs);

[Bug c++/80351] Inconsistent warning for constexpr auto constant when using initializer list (-Wunused-variable)

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

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

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

https://gcc.gnu.org/g:8d0fcf135857869f7cff36d29bc3527c482372a9

commit r13-50-g8d0fcf135857869f7cff36d29bc3527c482372a9
Author: Jason Merrill 
Date:   Wed Mar 23 18:01:20 2022 -0700

c++: check completeness after auto deduction [PR80351]

Normally we check for incomplete type in start_decl, but that obviously
doesn't work for auto variables. Thanks to Pokechu22 for the analysis and
testcases:

"When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the const qualifier if the type is
not complete, which is appropriate for grokdeclarator, on the assumption
that the type will be complete when called by cp_finish_decl."

PR c++/80351

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Check completeness of deduced type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-77482.C: Adjust message.
* g++.dg/cpp1y/auto-fn27.C: Likewise.
* g++.dg/cpp1y/lambda-generic-variadic22.C: Likewise.
* g++.dg/cpp1z/decomp54.C: Likewise.
* g++.dg/cpp0x/initlist-const1.C: New test.
* g++.dg/warn/Wunused-var-37.C: New test.
* g++.dg/warn/Wunused-var-38.C: New test.
* g++.dg/warn/Wunused-var-39.C: New test.

[pushed] c++: check completeness after auto deduction [PR80351]

[Jason Merrill via Gcc-patches]

Normally we check for incomplete type in start_decl, but that obviously
doesn't work for auto variables. Thanks to Pokechu22 for the analysis and
testcases:

"When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first time
(this happened when auto deduces to an initializer_list).
cp_apply_type_quals_to_decl removes the const qualifier if the type is
not complete, which is appropriate for grokdeclarator, on the assumption
that the type will be complete when called by cp_finish_decl."

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/80351

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Check completeness of deduced type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-77482.C: Adjust message.
* g++.dg/cpp1y/auto-fn27.C: Likewise.
* g++.dg/cpp1y/lambda-generic-variadic22.C: Likewise.
* g++.dg/cpp1z/decomp54.C: Likewise.
* g++.dg/cpp0x/initlist-const1.C: New test.
* g++.dg/warn/Wunused-var-37.C: New test.
* g++.dg/warn/Wunused-var-38.C: New test.
* g++.dg/warn/Wunused-var-39.C: New test.
---
 gcc/cp/decl.cc| 11 
 gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C  |  2 +-
 gcc/testsuite/g++.dg/cpp0x/initlist-const1.C  |  7 ++
 gcc/testsuite/g++.dg/cpp1y/auto-fn27.C|  2 +-
 .../g++.dg/cpp1y/lambda-generic-variadic22.C  |  2 +-
 gcc/testsuite/g++.dg/cpp1z/decomp54.C |  4 +-
 gcc/testsuite/g++.dg/warn/Wunused-var-37.C| 64 +++
 gcc/testsuite/g++.dg/warn/Wunused-var-38.C| 16 +
 gcc/testsuite/g++.dg/warn/Wunused-var-39.C| 16 +
 9 files changed, 119 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-const1.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-37.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-38.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-var-39.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 2852093d624..45206c236c1 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8129,6 +8129,17 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
  TREE_TYPE (decl) = error_mark_node;
  return;
}
+  /* As in start_decl_1, complete so TREE_READONLY is set properly.  */
+  if (!processing_template_decl
+ && !type_uses_auto (type)
+ && !COMPLETE_TYPE_P (complete_type (type)))
+   {
+ error_at (location_of (decl),
+   "deduced type %qT for %qD is incomplete", type, decl);
+ cxx_incomplete_type_inform (type);
+ TREE_TYPE (decl) = error_mark_node;
+ return;
+   }
   cp_apply_type_quals_to_decl (cp_type_quals (type), decl);
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C
index 6f5c91621ce..bed66c7fa81 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C
@@ -3,4 +3,4 @@
 
 constexpr auto x;  // { dg-error "declaration\[^\n\r]*has no initializer" }
 extern struct S s;
-constexpr auto y = s;  // { dg-error "has incomplete type" }
+constexpr auto y = s;  // { dg-error "incomplete" }
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-const1.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-const1.C
new file mode 100644
index 000..de807316be6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-const1.C
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+const auto x = { 1, 2 };
+
+// { dg-final { scan-assembler-not {\.data} } }
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn27.C 
b/gcc/testsuite/g++.dg/cpp1y/auto-fn27.C
index c019d9ef583..b22647a38de 100644
--- a/gcc/testsuite/g++.dg/cpp1y/auto-fn27.C
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn27.C
@@ -31,7 +31,7 @@ F::bar (const G &)
 {
   auto s = I;
   typedef decltype (s) L;
-  auto u =[&](L) { auto t = foo (J::K (), 0); }; // { dg-error "25:declared 
void" }
+  auto u =[&](L) { auto t = foo (J::K (), 0); }; // { dg-error 
"25:incomplete|void" }
 }
 struct B {
   typedef int G;
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic22.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic22.C
index 670c598a865..9c02d0715c1 100644
--- a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic22.C
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic22.C
@@ -4,7 +4,7 @@
 template 
 auto f (T)
 {
-  auto a = [](auto ... i)  // { dg-prune-output "incomplete type" }
+  auto a = [](auto ... i)  // { dg-prune-output "incomplete" }
   {
 int x[][i] = { 0 };// { dg-error "not expanded" }
   }();
diff --git a/gcc/testsuite/g++.dg/cpp1z/decomp54.C 
b/gcc/testsuite/g++.dg/cpp1z/decomp54.C
index 1bee772d5ba..1094329e69d 100644
--- a/gcc/testsuite/g++.dg/cpp1z/decomp54.C
+++ b/gcc/testsuite/g++.dg/cpp1z/decomp54.C
@@ -3,9 +3,9 @@
 // { dg-options "" }
 
 extern int a[];

[Bug bootstrap/105434] Compiler ICE when build GCC 13 cross compiler with GCC 13 native compiler

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
Created attachment 52908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52908=edit
config.log

[Bug target/105435] Wtautological-constant-compare warning in trunk build

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||tobias.burnus at physik dot 
fu-ber
   ||lin.de

--- Comment #1 from David Binderman  ---
Adding author of original code.

[Bug bootstrap/105434] Compiler ICE when build GCC 13 cross compiler with GCC 13 native compiler

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
I am building a GCC 13 cross compiler with GCC 13 native compiler. It got ICE
when built with mpfr. Looks like a bug in the compiler itself

[Bug target/105435] New: Wtautological-constant-compare warning in trunk build

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105435
   Summary: Wtautological-constant-compare warning in trunk build
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just had a go at a clang-based build of gcc trunk
on arm, specifically Raspberry PI 3.

clang said:

trunk/gcc/config/arm/arm-c.cc:299:7: warning: converting the result of '?:'
with integer constants to a boolean always evaluates to 'true'
[-Wtautological-constant-compare]

Source code is

  if (TARGET_ARM_FP)

and

/* Set as a bit mask indicating the available widths of hardware floating
   point types.  Where bit 1 indicates 16-bit support, bit 2 indicates
   32-bit support, bit 3 indicates 64-bit support.  */
#define TARGET_ARM_FP   \
  (!TARGET_SOFT_FLOAT ? (TARGET_VFP_SINGLE ? 4  \
: (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \
  : 0)

Four ternary operators in one expression is a complex expression
and it looks like clang can find fault with it.

I hope there is a simpler way to write the code that hopefully
removes the clang warning.

[Bug c/105434] New: Compiler ICE when build GCC 13 cross compiler with GCC 13 native compiler

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 105434
   Summary: Compiler ICE when build GCC 13 cross compiler with GCC
13 native compiler
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 52907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52907=edit
Compiler ICE when build GCC 13 cross compiler with GCC 13 native compiler

See attachment
atan.c:286:1: internal compiler error: in set_range_info_raw, at
tree-ssanames.cc:356

Re: [patch, fortran, doc] Mention new CONVERT options for POWER

[Thomas Koenig via Gcc-patches]

On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:

ISTM that this should be s/mod.e/mode./ ?


Yep, fixed as obvious and simple on trunk with
r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .

OK for backport to gcc-12? (This is both extremely safe and
not particularly important :-)

Best regards

Thomas

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can you please attach preprocessed atan.c ?  How have you configured gcc
(mostly, what -mcpu=/-mtune= it defaults to)?

[gen-16862] Invitation to the CERT Vendor Meeting 2022 (June 6)

[cert+donotreply--- via Gcc]

While it's unusual for us to hold meetings so close together, it's been an 
unusual couple of years, and we are holding a full day, hybrid event on June 6 
2022, the Monday of RSAC 2022. The meeting will be held from 9 AM to 5 PM PDT, 
in person at the Marriott Marquis in San Francisco, CA, US, and online via Zoom 
Webinar.

Register here: 

Registration options include in-person, virtual, or both.

Questions/issues about registration, logistics, etc: 

Topical discussion: 

We actively seek ideas for topics that are of interest to you, and we welcome 
those wishing to speak or lead a discussion topic or participate on a panel. 
The draft/working list topics includes:

 * UEFI vulnerability analysis

 * Linux Vendor Firmware Service (LVFS), possibly connected to the UEFI topic, 
probably also with supply chain/SBOM implications

 * A CVD protocol

 * CVE

 * SBOM, VEX

 * Government regulations impacting CVD

While we're more or less happy to decide the agenda ourselves, we'd be happier 
with your input, and you might be too.

Regards,

 - Art




This e-mail was sent to you as a user of our VINCE service, in accordance with 
our privacy policy. Please advise us if you believe you have received this 
e-mail in error.

[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
This is what breaks things:

g:6ccc4356e7c5b4ca69d2029898a6439bb735cbc5, r13-32-g6ccc4356e7c5b4

commit 6ccc4356e7c5b4ca69d2029898a6439bb735cbc5 (HEAD)
Author: Aldy Hernandez 
Date:   Mon Mar 7 14:56:34 2022 +0100

Prefer global range info setters that take a range.

[PATCH] x86: Add missing .note.GNU-stack to assembly source

[H.J. Lu via Gcc-patches]

Add .note.GNU-stack assembly source to avoid linker warning:

ld: warning: /tmp/ccPZSZ7Z.o: missing .note.GNU-stack section implies 
executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version 
of the linker
FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c compilation,  -O0

PR testsuite/105433
* gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack.
* gcc.target/x86_64/abi/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx512fp16/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S: Likewise.
* gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise.
* gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise.
---
 gcc/testsuite/gcc.target/i386/iamcu/asm-support.S| 1 +
 gcc/testsuite/gcc.target/x86_64/abi/asm-support.S| 1 +
 gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S| 1 +
 gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S| 1 +
 gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S | 1 +
 .../gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S | 1 +
 .../gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S | 1 +
 gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S| 1 +
 8 files changed, 8 insertions(+)

diff --git a/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S 
b/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
index b4a4a140e54..db08f52a34f 100644
--- a/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
+++ b/gcc/testsuite/gcc.target/i386/iamcu/asm-support.S
@@ -300,3 +300,4 @@ iamcu_noprintf:
.align 4
 .LCiamcu_noprintf1:
.long   1132527616
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
index 7a8ed03d119..2f8d3a09c6b 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S
@@ -82,3 +82,4 @@ snapshot_ret:
.comm   xmm_regs,256,32
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
index 73a59191d6d..77b3480ac32 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S
@@ -79,3 +79,4 @@ snapshot_ret:
.comm   ymm_regs,512,32
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
index 0ef82876dd9..2e3306c44cb 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/asm-support.S
@@ -95,3 +95,4 @@ snapshot_ret:
.comm   zmm_regs,2048,64
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
index 7849acd2649..0793acf048b 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/asm-support.S
@@ -79,3 +79,4 @@ snapshot_ret:
.comm   xmm_regs,256,32
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
index 73a59191d6d..77b3480ac32 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S
@@ -79,3 +79,4 @@ snapshot_ret:
.comm   ymm_regs,512,32
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
index 0ef82876dd9..2e3306c44cb 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S
@@ -95,3 +95,4 @@ snapshot_ret:
.comm   zmm_regs,2048,64
.comm   x87_regs,128,32
.comm   volatile_var,8,8
+   .section.note.GNU-stack,"",@progbits
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S 
b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
index 7b891a140dc..f5dff4c10ab 100644

[Bug testsuite/105433] New: FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c

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

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

Bug ID: 105433
   Summary: FAIL:
gcc.target/i386/iamcu/test_3_element_struct_and_unions
.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

The linker in binutils 2.39 issues:

ld: warning: /tmp/ccPZSZ7Z.o: missing .note.GNU-stack section implies
executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version
of the linker
FAIL: gcc.target/i386/iamcu/test_3_element_struct_and_unions.c compilation, 
-O0

which causes many ABI test failures:

https://gcc.gnu.org/pipermail/gcc-regression/2022-April/076526.html

[Bug modula2/105411] gm2 testsuite should use TEST_ALWAYS_FLAGS

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-29

--- Comment #1 from Gaius Mulley  ---
I've added TEST_ALWAYS_FLAGS to the gcc/testsuite/lib/gm2.exp as per other
tests.

Re: [PATCH] Replace EVRP in DOM with ranger.

[Aldy Hernandez via Gcc-patches]

On Fri, Apr 29, 2022 at 12:13 PM Richard Biener
 wrote:
>
> On Fri, Apr 29, 2022 at 11:53 AM Aldy Hernandez  wrote:
> >
> > On Fri, Apr 29, 2022 at 9:09 AM Richard Biener
> >  wrote:
> > >
> > > On Thu, Apr 28, 2022 at 8:44 PM Jeff Law via Gcc-patches
> > >  wrote:
> > > >
> > > >
> > > >
> > > > On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > > > > [Jeff, this is the same patch I sent you last week with minor tweaks
> > > > > to the commit message.]
> > > > And I just dropped it into the tester.  We should have the vast majority
> > > > of targets tested by this time tomorrow.
> > > >
> > > > >
> > > > > [Despite the verbosity of the message, this is actually a pretty
> > > > > straightforward patch.  It should've gone in last cycle, but there
> > > > > was a nagging regression I couldn't get to until after stage1
> > > > > had closed.]
> > > > You had other, non-work/gcc priorities.  No worries at missing gcc-12.
> > > >
> > > >
> > > > >
> > > > > There are 3 uses of EVRP in DOM that must be converted.
> > > > > Unfortunately, they need to be converted in one go, so further
> > > > > splitting of this patch would be problematic.
> > > > ACK
> > > >
> > > >
> > > > > There's nothing here earth shattering.  It's all pretty obvious in
> > > > > retrospect, but I've added a short description of each use to aid in
> > > > > reviewing:
> > > > >
> > > > > * Convert evrp use in cprop to ranger.
> > > > >
> > > > >This is easy, as cprop in DOM was converted to the ranger API last
> > > > >cycle, so this is just a matter of using a ranger instead of an
> > > > >evrp_range_analyzer.
> > > > Yea.  We may have covered this before, but what does ranger do with a
> > > > conditional equivalence?
> > > >
> > > > ie if we have something like
> > > >
> > > > if (a == b)
> > > >{
> > > >  blah blah
> > > >}
> > > >
> > > > Within the true arm we know there's an equivalence.  *But* we don't want
> > > > to just blindly replace a with b or vice-versa.  The equivalence is
> > > > primarily useful for simplification rather than propagation.
> > > >
> > > > In fact, we every much do not want to cprop in these cases.   It rarely
> > > > helps in a meaningful way and there's no good way to know which is the
> > > > better value to use.  Canonicalization on SSA_NAMEs doesn't  really help
> > > > due to SSA_NAME recycling.
> > > >
> > > >
> > > > >
> > > > > * Convert evrp use in threader to ranger.
> > > > >
> > > > >The idea here is to use the hybrid approach we used for the initial
> > > > >VRP threader conversion last cycle.  The DOM threader will continue
> > > > >using the forward threader infrastructure while continuing to query
> > > > >DOM data structures, and only if the conditional does not relsolve,
> > > > >using the ranger.  This gives us the best of both worlds, and is a
> > > > >proven approach.
> > > > >
> > > > >Furthermore, as frange and prange come live in the next cycle, we
> > > > >can move away from the forward threader altogether, and just add
> > > > >another backward threader.  This will not only remove the last use
> > > > >of the forward threader, but will allow us to remove at least 1 or 
> > > > > 2
> > > > >threader instances.
> > > > Excellent.
> > > >
> > > > >
> > > > > * Convert conditional folding to use the method used by the ranger and
> > > > >evrp.  Previously DOM was calling into the guts of
> > > > >simplify_using_ranges::vrp_visit_cond_stmt.  The blessed way now is
> > > > >using fold_cond() which rewrites the conditional and edges
> > > > >automatically.
> > > > >
> > > > >When legacy is removed, simplify_using_ranges will be further
> > > > >cleaned up, and there will only be one entry point into simplifying
> > > > >a statement.
> > > > Sure.
> > > >
> > > > >
> > > > > * DOM was setting global ranges determined from unreachable edges as a
> > > > >side-effect of using the evrp engine.  We must handle these cases
> > > > >before nuking evrp, and DOM seems like a good fit.  I've just moved
> > > > >the snippet to DOM, but it could live anywhere else we do a DOM
> > > > >walk.
> > > >   It was a semi-desirable to record/refine global ranges in DOM, but I'd
> > > > be surprised if too much code depended on that.  Presumably there's a
> > > > testcase in the suite which we don't handle well if we don't let DOM
> > > > refine/record global ranges?
> > > >
> > > > >
> > > > >For the record, this is the case *vrp handled:
> > > > >
> > > > >   :
> > > > >   ...
> > > > >   if (c_5(D) != 5)
> > > > >   goto ;
> > > > >   else
> > > > >   goto ;
> > > > >   :
> > > > >   __builtin_unreachable ();
> > > > >   :
> > > > >
> > > > >If M dominates all uses of c_5, we can set the global range of c_5
> > > > >to [5,5].
> > > > And that will only happen if M eventually loops back to the conditional,
> > > > right?  Otherwise all the uses 

[Bug ipa/100413] [11/12/13 Regression] ICE: failed to reclaim unneeded function with custom flags since r11-4267-g0e590b68fa374365

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

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

--- Comment #9 from Martin Jambor  ---
Now fixed in trunk, I'll backport to 12 and 11 after 12.1 is released.

[Bug ipa/100413] [11/12/13 Regression] ICE: failed to reclaim unneeded function with custom flags since r11-4267-g0e590b68fa374365

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

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

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

https://gcc.gnu.org/g:27ee75dbe81bb781214c66a9e6a759c08b7deb60

commit r13-48-g27ee75dbe81bb781214c66a9e6a759c08b7deb60
Author: Martin Jambor 
Date:   Fri Apr 29 17:38:15 2022 +0200

ipa: Release body of clone_of when removing its last clone (PR 100413)

In the PR, the verifier complains that we did not manage to remove the
body of a node and it is right.  The node is kept for materialization
of two clones but after one is materialized, the other one is removed
as unneeded (as a part of delete_unreachable_blocks_update_callgraph).
The problem is that the node removal does not check for this situation
and can leave the clone_of node there with a body attached to it even
though there is no use for it any more.  This patch does checks for it
and handles the situation in a simlar way that
cgraph_node::materialize_clone does it, except that it also has to be
careful that the removed node itself does not have any clones, which
would still need the clone_of's body.  Failing to do that results in a
bootstrap failure.

gcc/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* cgraph.cc (cgraph_node::remove): Release body of the node this
is clone_of if appropriate.

gcc/testsuite/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* g++.dg/ipa/pr100413.C: New test.

[Bug tree-optimization/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:210cda732832ec589b02c722b2c73f7fa50b97ce

commit r13-47-g210cda732832ec589b02c722b2c73f7fa50b97ce
Author: Andre Vieira 
Date:   Fri Apr 29 16:31:08 2022 +0100

aarch64: Add option to pr105219 testcase

Add option that originally caused testcase to fail for aarch64.

gcc/testsuite/ChangeLog:

PR tree-optimization/105219
* gcc.dg/vect/pr105219.c: Add aarch64 target option.

Re: [PATCH] Use CASE_CONVERT in a few more cases

[Jeff Law via Gcc-patches]

On 4/29/2022 3:37 AM, Richard Biener via Gcc-patches wrote:

This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?

Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EXPR and NOP_EXPR at the moment,
are the C++ bits nevertheless OK?

2022-04-29  Richard Biener  

cp/
* constexpr.cc (fold_simple_1): Use CASE_CONVERT.
* cp-gimplify.cc (cp_fold): Likewise.
* pt.cc (tsubst_copy): Likewise.

* dojump.cc (do_jump): Use CASE_CONVERT.
* tree-ssa-dom.cc (edge_info::derive_equivalences): Likewise.

The dojump and tree-ssa-dom bits are fine.

jeff

GCC 12.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The first release candidate for GCC 12.1 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/
 ftp://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/

and shortly its mirrors.  It has been generated from git commit
r12-8321-g621650f64fb667.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, I'd like to release 12.1 on Friday, May 6th.

Re: FW: ompd_get_thread_id in OMPD implementation

[Jakub Jelinek via Gcc]

On Sat, Apr 09, 2022 at 12:38:11AM +0200, Ahmed Sayed Mousse wrote:
> Sorry for the late reply.
> I did check gomp_thread_self but I'm still not sure about what I should do,
> maybe because I lack experience/knowledge.
> Here is where my thinking is going right now and I hope you tell me if I'm
> wrong.

Sorry for the delay, I've been busy with GCC 12.

> in gomp_thread_to_pthread_t there are 4 possible outputs
> 1 - if LIBGOMP_USE_PTHREADS is enabled
>  {
> first  pthread_self() if the thread calling is the same thread as the
> function input.
> or  gomp_thread->handle in case GOMP_NEEDS_THREAD_HANDLE is enabled.
> or  pthread_self () + ((uintptr_t) input_thread - (uintptr_t)
> calling_thread)
> }

ompd_get_thread_id is for mapping of the OMPD thread id to the native
thread id.  If LIBGOMP_USE_PTHREADS, we are using POSIX threads, so
OMPD_THREAD_ID_PTHREAD is what we want to provide.
If GOMP_NEEDS_THREAD_HANDLE, then we want to read the handle member for
it and return it.  Otherwise as the comment says, we optimize and
because we know that in the initial-exec TLS model _tls_data - 
pthread_self ()
is the same for each thread, we don't store the handle at all, so
ompd_get_thread_id instead needs to compute the bias.
If it is too hard to do it in libgompd.so alone, perhaps during
gompd_load libgomp.so.1 could compute it and store in some variable
that libgompd.so can then read.

> 2 -if LIBGOMP_USE_PTHREADS not enabled
> - empty struct casted to a pthread_t
> currently think i should check for the GOMP_NEED_THREAD_HANDLE, if it's
> enabled i extract the pthread_t  from the gomp_thread handle given in the
> function and return that.
> If it's not enabled then I return an empty struct or an rc_unspported
> return code.
> Note:
> The openmp specification doesn't really tell me how things should be
> done so I get confused a lot and I think I have a misunderstanding of the
> function.
>  I would appreciate it a lot if I get any directions to where I can
> increase my knowledge around this part.

If LIBGOMP_USE_PTHREADS is not enabled, then it is libgomp.a built for one
of the offloading targets, either NVPTX or GCN.  We then can't return
OMPD_THREAD_ID_PTHREAD, threads are numbered differently there, they are
either the CUDA threads or GCN threads.  But I think at least initially
we only build libgompd.so for the host so how exactly we OMPD offloading
should be postponed until after the host handling works.

Jakub

[Bug libstdc++/105417] [11 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11 Regression]
   |powerpc64le-linux abilist   |powerpc64le-linux abilist
   |changes based on|changes based on
   |--with-long-double-format=  |--with-long-double-format=

--- Comment #10 from Jonathan Wakely  ---
Fixed for trunk and 12, backport to 11 still needed.

[PATCH] c++: fix ICE on invalid attributes [PR96637]

[Marek Polacek via Gcc-patches]

This patch fixes crashes with invalid attributes.  Arguably it could
make sense to assert seen_error() too.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13?

PR c++/96637

gcc/ChangeLog:

* attribs.cc (decl_attributes): Check error_mark_node.

gcc/cp/ChangeLog:

* decl2.cc (cp_check_const_attributes): Check error_mark_node.

gcc/testsuite/ChangeLog:

* g++.dg/parse/error64.C: New test.
---
 gcc/attribs.cc   | 3 +++
 gcc/cp/decl2.cc  | 2 ++
 gcc/testsuite/g++.dg/parse/error64.C | 4 
 3 files changed, 9 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/parse/error64.C

diff --git a/gcc/attribs.cc b/gcc/attribs.cc
index b219f878042..ff157dcf81c 100644
--- a/gcc/attribs.cc
+++ b/gcc/attribs.cc
@@ -700,6 +700,9 @@ decl_attributes (tree *node, tree attributes, int flags,
  in the same order as in the source.  */
   for (tree attr = attributes; attr; attr = TREE_CHAIN (attr))
 {
+  if (attr == error_mark_node)
+   continue;
+
   tree ns = get_attribute_namespace (attr);
   tree name = get_attribute_name (attr);
   tree args = TREE_VALUE (attr);
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index d2b29208ed5..c3ff1962a75 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -1537,6 +1537,8 @@ cp_check_const_attributes (tree attributes)
   /* As we implement alignas using gnu::aligned attribute and
 alignas argument is a constant expression, force manifestly
 constant evaluation of aligned attribute argument.  */
+  if (attr == error_mark_node)
+   continue;
   bool manifestly_const_eval
= is_attribute_p ("aligned", get_attribute_name (attr));
   for (arg = TREE_VALUE (attr); arg && TREE_CODE (arg) == TREE_LIST;
diff --git a/gcc/testsuite/g++.dg/parse/error64.C 
b/gcc/testsuite/g++.dg/parse/error64.C
new file mode 100644
index 000..87848a58c27
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/error64.C
@@ -0,0 +1,4 @@
+// PR c++/96637
+// { dg-do compile }
+
+void foo(int[] alignas[1] alignas(1)){} // { dg-error "" }

base-commit: 9ae8b993cd362e8aea4f65580aaf1453120207f2
-- 
2.35.1

[PATCH] c++: pedwarn for empty unnamed enum in decl [PR67048]

[Marek Polacek via Gcc-patches]

[dcl.dcl]/5 says that

  enum { };

is ill-formed, and since r197742 we issue a pedwarn.  However, the
pedwarn also fires for

   enum { } x;

which is well-formed.  So only warn when {} is followed by a ;.  This
should be correct since you can't have "enum {}, " -- that
produces "expected unqualified-id before ',' token".

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?  I think
this could go to 12.2 and 11.4 too.

PR c++/67048

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enum_specifier): Warn about empty unnamed enum
only when it's followed by a semicolon.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/enum42.C: New test.
---
 gcc/cp/parser.cc| 4 +++-
 gcc/testsuite/g++.dg/cpp0x/enum42.C | 7 +++
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/enum42.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 2235da10c7c..0fa37fdfb66 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -21007,7 +21007,9 @@ cp_parser_enum_specifier (cp_parser* parser)
   /* If the next token is not '}', then there are some enumerators.  */
   else if (cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_BRACE))
{
- if (is_unnamed && !scoped_enum_p)
+ if (is_unnamed && !scoped_enum_p
+ /* Don't warn for enum {} a; here.  */
+ && cp_lexer_nth_token_is (parser->lexer, 2, CPP_SEMICOLON))
pedwarn (type_start_token->location, OPT_Wpedantic,
 "ISO C++ forbids empty unnamed enum");
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum42.C 
b/gcc/testsuite/g++.dg/cpp0x/enum42.C
new file mode 100644
index 000..05b372a1947
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum42.C
@@ -0,0 +1,7 @@
+// PR c++/67048
+// { dg-do compile { target c++11 } }
+// { dg-options -Wpedantic }
+
+typedef enum {} X;
+enum {} x;
+enum {} y, z;

base-commit: 9ae8b993cd362e8aea4f65580aaf1453120207f2
-- 
2.35.1

[Bug tree-optimization/105432] New: [12 regression] bootstrap build error in mpc in stage2

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

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

Bug ID: 105432
   Summary: [12 regression] bootstrap build error in mpc in stage2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

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


I am still looking for the source.

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-04-29

--- Comment #3 from Martin Liška  ---
Confirmed with:

Repository : Main Repository (OSS)
Name   : gmp-devel
Version: 6.2.1-4.5

RE: Proposal to remove '--with-cuda-driver'

[Thomas Schwinge]

Hi Roger!

On 2022-04-05T19:46:08+0100, "Roger Sayle"  wrote:
> I apologise that it might complicate things

No worries; that's why I asked.  :-)

> one potential benefit of --with-cuda-driver
> (i.e. linking the compiler against proprietary libraries) is that it would 
> allow support for
> -march=native on nvptx (i.e. the gcc driver can figure out what sm_xx is 
> available on the
> GPU(s) of the current machine, and pass that to cc1.  Like with all the 
> microarchitectures
> on other platforms (x86_64), figuring this out is not a trivial task for many 
> end-users.

Ah, interesting idea!  (I suppose still not too relevant right now, but
once we've got GCC/nvptx multilibs making better use of modern PTX
features, I certainly do see the point.)

> Of course, ideally I'd love to be able to figure out the PTX hardware 
> specifications and
> driver versions without using a third-party library, but I've no idea how 
> this could be done
> (portably across the platforms that support libcuda).  Perhaps dlopen at 
> runtime?
> Or calling out to (executing) nvptx-tools?

Indeed I suppose I'd do this via 'dlopen', and not directly link GCC
against 'libcuda.so' etc.: so that the GCC build may also be used on a
system where no 'libcuda.so' is available.

So -- sorry ;-) -- that's not a show-stopper for removing the
'--with-cuda-driver' etc. 'configure'-time options.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

[Bug c++/83596] ['17] can't use member pointer result of a constexpr function as template argument

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

[pushed] c++: Add fixed test [PR83596]

[Marek Polacek via Gcc-patches]

This was fixed by r269078.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/83596

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype5.C: New test.
---
 gcc/testsuite/g++.dg/cpp1z/nontype5.C | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/nontype5.C

diff --git a/gcc/testsuite/g++.dg/cpp1z/nontype5.C 
b/gcc/testsuite/g++.dg/cpp1z/nontype5.C
new file mode 100644
index 000..7e6639dd175
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/nontype5.C
@@ -0,0 +1,11 @@
+// PR c++/83596
+// { dg-do compile { target c++17 } }
+
+struct X { int x; int y; };
+template  int get(X& x) { return x.*mp; }
+constexpr int X::* getMP() { return ::y; }
+constexpr int X::* mptr = getMP();
+int test() {
+X x{1, 2};
+return get(x);
+}

base-commit: bb7cf39b05a216431a431499d0c36a6034f6acc4
-- 
2.35.1

[Bug c++/83596] ['17] can't use member pointer result of a constexpr function as template argument

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1c798ab71e2b14cb60edeebc79e6a64f5aa88f4f

commit r13-46-g1c798ab71e2b14cb60edeebc79e6a64f5aa88f4f
Author: Marek Polacek 
Date:   Fri Apr 29 09:52:55 2022 -0400

c++: Add fixed test [PR83596]

This was fixed by r269078.

PR c++/83596

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype5.C: New test.

Re: Proposal to remove '--with-cuda-driver'

[Thomas Schwinge]

Hi Tom!

On 2022-04-06T11:57:57+0200, Tom de Vries  wrote:
> On 4/5/22 17:14, Thomas Schwinge wrote:
>> Regarding the following:
>>
>> On 2022-03-30T14:27:41+0200, Tom de Vries  wrote:
>>> The -mptx flag has been added to specify the PTX ISA 
>>> version
>>> for the generated code; permitted values are 3.1
>>> -  (default, matches previous GCC versions) and 6.3.
>>> +  (matches previous GCC versions), 6.0, 6.3,
>>> +  and 7.0. If not specified, the used version is the 
>>> minimal
>>> +  version required for -march but at least 
>>> 6.0.
>>> 
>>
>> For "the PTX ISA version [used is] at least '6.0'", per
>> ,
>> this means we now require "CUDA 9.0, driver r384" (or more recent).
>
> Well, that would be the case if there was no -mptx=3.1.

When considering *using* GCC/nvptx, the '-mptx-3.1' multilib may be used
with "old" hardware/CUDA Driver versions, correct.  When considering
*building* GCC/nvptx, we do require CUDA 9.0, as otherwise the default
multilib can't be built (unless you disable 'ptxas' verification).

>> Per :
>> "CUDA Toolkit 9.0 (Sept 2017)", so ~4.5 years old.
>> Per , I'm guessing a
>
> I just see a list with version numbers there, I'm not sure what
> information you're referring to.

I'd assumed that from that URL as well as structure of these version
numbers, you could tell these are Nvidia Driver releases (including
bundled CUDA Driver libraries).

>> similar timeframe for the imprecise "r384" Driver version stated in that
>> table.  That should all be fine (re not mandating use of all-too-recent
>> versions).
>
> I don't know what an imprecise driver is.

Not "imprecise driver" but "imprecise [...] version".  For example,

talks about "driver r384", but such a version doesn't exist; it's rather
384.130, or 384.111, or 384.98, etc.


>> Now, consider doing a GCC/nvptx offloading build with
>> '--with-cuda-driver' pointing to CUDA 9.0 (or more recent).  This means
>> that the libgomp nvptx plugin may now use CUDA Driver features of the
>> CUDA 9.0 distribution ("driver r384", etc.) -- because that's what it is
>> being 'configure'd and linked against.  (I say "may now use", because
>> we're currently not making a lot of effort to use "modern" CUDA Driver
>> features -- but we could, and probably should.  That's a separate
>> discussion, of course.)  It then follows that the libgomp nvptx plugin
>> has a hard dependency on CUDA Driver features of the CUDA 9.0
>> distribution ("driver r384", etc.).  That's dependency as in ABI: via
>> '*.so' symbol versions as well as internal CUDA interface configuration;
>> see  doing different '#define's for different
>> '__CUDA_API_VERSION' etc.)
>>
>> Now assume one such dependency on "modern" CUDA Driver were not
>> implemented by:
>
> Thanks for reminding me, I forgot about this configure option.

OK, good.  ;-)

>>> +  An mptx-3.1 multilib was added.  This allows using older
>>> +  drivers which do not support PTX ISA version 6.0.
>>
>> ... this "old" CUDA Driver.  Then you do have the '-mptx-3.1' multilib to
>> use with "old" CUDA Driver -- but you cannot actually use the libgomp
>> nvptx plugin, because that's been built against "modern" CUDA Driver.
>
> I remember the following problem: using -with-cuda-driver to specify
> what cuda driver interface (version) you want to link the libgomp plugin
> against, and then using an older driver in combination with that libgomp
> plugin.   We may run into trouble, typically at libgomp plugin load
> time, with an error mentioning an unresolved symbol or some abi symbol
> version being not sufficient.

Right.

> So, do I understand it correctly that your point is that using -mptx=3.1
> doesn't fix that problem?

Right.

>> Same problem, generally, for 'nvptx-run' of the nvptx-tools, which has
>> similar CUDA Driver dependencies.
>>
>> Now, that may currently be a latent problem only, because we're not
>> actually making use of "modern" CUDA Driver features.  But, I'd like to
>> resolve this "impedance mismatch", before we actually run into such
>> problems.
>
> It would be helpful for me if you would come up with an example of a
> modification to the libgomp plugin that would cause trouble in
> combination with mptx=3.1.

For example, something like the following scenario -- made up, so details
may be wrong.

Consider GCC's libgomp nvptx plugin is built with '--with-cuda-driver'
pointing to a modern CUDA release.  The 'configure' script finds the
'cuMemPrefetchAsync' function available (CUDA 8.0+?), enables respective
hypothetical code in the libgomp nvptx plugin, and thus
'libgomp-plugin-nvptx.so' now has a load-time dependency on 'libcuda.so'
providing 'cuMemPrefetchAsync': the plugin will fail to load if that's
not available.  If 

Re: [PATCH] libgompd: add OMPD support, libgompd initialization and global ICVs functions

[Jakub Jelinek via Gcc-patches]

On Sun, Mar 20, 2022 at 11:33:10AM +0200, Mohamed Atef via Gcc-patches wrote:
> hello,
>I know it's too much.
> we fixed the functions' names that are not part of the standard form ompd_
> * prefix to gompd_

Sorry for the delay, have been busy with GCC 12.  Now that it branched, I
can look at this again.  Will try to do timely reviews now that GCC 13 is in
stage1.

> > 2022-03-15  Mohamed Atef  

Note, you'll need to update the ChangeLog entry for the changes in the
patch.

> --- a/libgomp/Makefile.am
> +++ b/libgomp/Makefile.am
> @@ -32,13 +32,21 @@ libgomp.ver: $(top_srcdir)/libgomp.map
>   $(EGREP) -v '#(#| |$$)' $< | \
> $(PREPROCESS) -P -include config.h - > $@ || (rm -f $@ ; exit 1)
>  
> +libgompd.ver: $(top_srcdir)/libgompd.map
> + $(EGREP) -v '#(#| |$$)' $< | \
> + $(PREPROCESS) -P -include config.h - > $@ || (rm -f $@ ; exit 1)

Why the different indentation from the entry you've copied it from?
Better stay consistent.

> +libgompd.ver-sun : libgompd.ver \
> + $(top_srcdir)/../contrib/make_sunver.pl \
> + $(libgompd_la_OBJECTS) $(libgompd_la_LIBADD)
> + perl $(top_srcdir)/../contrib/make_sunver.pl \
> + libgompd.ver \
> + $(libgompd_la_OBJECTS:%.lo=.libs/%.o) \
> + `echo $(libgompd_la_LIBADD) | \
> + sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
> + > $@ || (rm -f $@ ; exit 1)

Likewise.

> --- a/libgomp/env.c
> +++ b/libgomp/env.c
> @@ -33,6 +33,7 @@
>  #ifndef LIBGOMP_OFFLOADED_ONLY
>  #include "libgomp_f.h"
>  #include "oacc-int.h"
> +#include "ompd-support.h"
>  #include 
>  #include 
>  #include 
> @@ -1483,6 +1484,7 @@ initialize_env (void)
>   = thread_limit_var > INT_MAX ? UINT_MAX : thread_limit_var;
>  }
>parse_int_secure ("GOMP_DEBUG", _debug_var, true);
> +  gompd_load ();

See below.

> +#ifndef _OMP_TOOLS_H
> +#define _OMP_TOOLS_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +extern const char **ompd_dll_locations;
> +
> +#ifdef __ELF__
> +#define ompd_dll_locations_valid() \
> +  __asm__ __volatile__ (".globl ompd_dll_locations_valid\n\t" \
> + "ompd_dll_locations_valid:")
> +#else
> +extern void ompd_dll_locations_valid (void);
> +#endif /* __ELF__ */

In the public omp-tools.h, ompd_dll_locations_valid should be declared
just as
extern void ompd_dll_locations_valid (void);
(well,
extern void ompd_dll_locations_valid (void) __GOMPD_NOTHROW;
and there should be
#ifdef __cplusplus
extern "C" {
# define __GOMPD_NOTHROW throw ()
#else
# define __GOMPD_NOTHROW __attribute__((__nothrow__))
#endif
earlier.  The fact that we want the former macro if possible is an
implementation detail we shouldn't expose to users in a public header.
So that #define belongs to some non-public header, ideally using some
helper macro because you use it many times later.

> +ompd_rc_t ompd_initialize (ompd_word_t, const ompd_callbacks_t *);

Similarly add __GOMPD_NOTHROW to this and other declarations.

> +  if (current + 1 >= gompd_last_icv_var || next_id == NULL
> +|| next_icv_name == NULL || next_scope == NULL || more == NULL)

The general formatting rule is if all the whole if/while condition
fits on one line, use just one line, otherwise put each ||/&& part
on a separate line.  So
  if (whatever || whatever2 || whatever3)
if short or
  if (whatever
  || whatever2
  || whatever3
  || whatever4
  || whatever5)
if too long.

> +void
> +gompd_load ()
> +{
> +  const char *ompd_env_var = getenv ("OMP_DEBUG");
> +  if (ompd_env_var == NULL || strcmp (ompd_env_var, "enabled"))
> +return;

If you look at other similar env var handling, you can notice that
we accept leading and/or trailing whitespace and use case insensitive
comparisons for strings.  See e.g. env.c (parse_target_offload).
IMHO the OMP_DEBUG env var parsing should be done in env.c too next
to other env vars in a similar way how other vars are handled and
gompd_load only called if OMPD is enabled.

> +#ifndef __ELF__
> +/* Dummy functions. they shoud not be optimized.  */
> +
> +void __attribute__ ((noinline))

noinline isn't strong enough, it should use noipa attribute
here and in the similar spots.

> +
> +void gompd_load ();

We want internal functions like this (note, (void) rather than (),
this is C) to be marked hidden if possible, libgomp.h uses
#ifdef HAVE_ATTRIBUTE_VISIBILITY
# pragma GCC visibility push(hidden)
#endif
...
#ifdef HAVE_ATTRIBUTE_VISIBILITY
# pragma GCC visibility pop
#endif

Jakub

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:621650f64fb6679c457c33abf27c925f28bddc62

commit r12-8321-g621650f64fb6679c457c33abf27c925f28bddc62
Author: Jonathan Wakely 
Date:   Fri Apr 29 12:17:13 2022 +0100

libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm
[PR105417]

The --with-long-double-abi=ibm build is missing some exports that are
present in the --with-long-double-abi=ieee build. Those symbols never
should have been exported at all, but now that they have been, they
should be exported consistently by both ibm and ieee.

This simply defines them as aliases for equivalent symbols that are
already present. The abi-tag on num_get::_M_extract_int isn't really
needed, because it only uses a std::string as a local variable, not in
the return type or function parameters, so it's safe to define the
_M_extract_int[abi:cxx11] symbols as aliases for the corresponding
function without the abi-tag.

This causes some new symbols to be added to the GLIBCXX_3.4.29 version
for the ibm long double build mode, but there is no advantage to adding
them to 3.4.30 for that build. That would just create more
inconsistencies.

libstdc++-v3/ChangeLog:

PR libstdc++/105417
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
Define __gnu_ieee128::num_get::_M_extract_int[abi:cxx11]
symbols as aliases for corresponding symbols without abi-tag.

(cherry picked from commit bb7cf39b05a216431a431499d0c36a6034f6acc4)

[committed] libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm [PR105417]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux (both long double ABIs, and also with old
glibc) and x86_64-linux.

Pushed to trunk, also needed for gcc-12 and gcc-11 branches.

-- >8 --

The --with-long-double-abi=ibm build is missing some exports that are
present in the --with-long-double-abi=ieee build. Those symbols never
should have been exported at all, but now that they have been, they
should be exported consistently by both ibm and ieee.

This simply defines them as aliases for equivalent symbols that are
already present. The abi-tag on num_get::_M_extract_int isn't really
needed, because it only uses a std::string as a local variable, not in
the return type or function parameters, so it's safe to define the
_M_extract_int[abi:cxx11] symbols as aliases for the corresponding
function without the abi-tag.

This causes some new symbols to be added to the GLIBCXX_3.4.29 version
for the ibm long double build mode, but there is no advantage to adding
them to 3.4.30 for that build. That would just create more
inconsistencies.

libstdc++-v3/ChangeLog:

PR libstdc++/105417
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
Define __gnu_ieee128::num_get::_M_extract_int[abi:cxx11]
symbols as aliases for corresponding symbols without abi-tag.
---
 .../powerpc64-linux-gnu/baseline_symbols.txt  | 12 +++
 .../src/c++11/compatibility-ldbl-alt128.cc| 36 +++
 2 files changed, 48 insertions(+)

diff --git 
a/libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt
index 773ee739ef7..5d54eda0e1d 100644
--- a/libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt
@@ -550,6 +550,12 @@ 
FUNC:_ZNKSt15basic_streambufIwSt11char_traitsIwEE6getlocEv@@GLIBCXX_3.4
 FUNC:_ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4
 FUNC:_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4
 FUNC:_ZNKSt16bad_array_length4whatEv@@CXXABI_1.3.8
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
@@ -581,6 +587,12 @@ 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traits
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES4_S4_RSt8ios_baseRSt12_Ios_IostateRy@@GLIBCXX_IEEE128_3.4.29
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE8__do_getES4_S4_RSt8ios_baseRSt12_Ios_IostateRd@@GLIBCXX_IEEE128_3.4.29
 
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE8__do_getES4_S4_RSt8ios_baseRSt12_Ios_IostateRg@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

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

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

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

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

commit r13-45-gbb7cf39b05a216431a431499d0c36a6034f6acc4
Author: Jonathan Wakely 
Date:   Fri Apr 29 12:17:13 2022 +0100

libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm
[PR105417]

The --with-long-double-abi=ibm build is missing some exports that are
present in the --with-long-double-abi=ieee build. Those symbols never
should have been exported at all, but now that they have been, they
should be exported consistently by both ibm and ieee.

This simply defines them as aliases for equivalent symbols that are
already present. The abi-tag on num_get::_M_extract_int isn't really
needed, because it only uses a std::string as a local variable, not in
the return type or function parameters, so it's safe to define the
_M_extract_int[abi:cxx11] symbols as aliases for the corresponding
function without the abi-tag.

This causes some new symbols to be added to the GLIBCXX_3.4.29 version
for the ibm long double build mode, but there is no advantage to adding
them to 3.4.30 for that build. That would just create more
inconsistencies.

libstdc++-v3/ChangeLog:

PR libstdc++/105417
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
Define __gnu_ieee128::num_get::_M_extract_int[abi:cxx11]
symbols as aliases for corresponding symbols without abi-tag.

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

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

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

Bug 78244 Summary: Narrowing conversion is accepted in a function template, but 
it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244

   What|Removed |Added

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

[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769

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

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

Bug 78244 Summary: Narrowing conversion is accepted in a function template, but 
it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244

   What|Removed |Added

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

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[pushed] c++: Add fixed test [PR78244]

[Marek Polacek via Gcc-patches]

This was finally fixed for GCC 11 by r11-434.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/78244

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wnarrowing20.C: New test.
---
 gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C | 26 +++
 1 file changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C

diff --git a/gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C 
b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C
new file mode 100644
index 000..17a6001266d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C
@@ -0,0 +1,26 @@
+// PR c++/78244
+// { dg-do compile { target c++11 } }
+
+struct S { S(int); int d; };
+
+template 
+auto f1() -> decltype(S{2.0}, void()) { } // { dg-error "narrowing conversion" 
}
+
+template 
+auto f2() -> decltype(S{2.0}, 1) { return 1; } // { dg-error "narrowing 
conversion" }
+
+template 
+auto f3() -> decltype(void(), S{2.0}, 1) { return 1; } // { dg-error 
"narrowing conversion" }
+
+template 
+auto f4() -> decltype((S{2.0}, 1)) { return 1; } // { dg-error "narrowing 
conversion" }
+
+// Test OVERLOAD in a template.
+int id(int v) { return v; }
+double id(double v) { return v; }
+
+template 
+auto f5(double v) -> decltype((S{id(v)}, 1)) { return 1; } // { dg-error 
"narrowing conversion" }
+
+template 
+auto f6(int v) -> decltype((S{id(v)}, 1)) { return 1; }

base-commit: e1115a4f1b4afb346341237355186949f8e568a8
-- 
2.35.1

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Fri, 2022-04-29 at 13:56 +0200, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote:
> > > This doesn't resolve the problem, unfortunately, because
> > > references to discarded comdat symbols are still kept in .rodata:
> > > 
> > > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced
> > > in
> > > section `.rodata' of ../lib/libgtest.a(gtest-all.cc.o): defined
> > > in
> > > discarded section
> > > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_[_ZN7testing15
> > > Asse
> > > rt
> > > ionResultlsIPKcEERS0_RKT_]' of ../lib/libgtest.a(gtest-all.cc.o)
> > > 
> > > (That's from building zlib-ng with ASan and your patch on s390).
> > > 
> > > So I was rather thinking about adding a reloc parameter to
> > > mergeable_constant_section () and slightly changing the section
> > > name when it's nonzero, e.g. from .cst to .cstrel.
> > 
> > After some experimenting, I don't think that what I propose here
> > is a good solution anymore, since it won't work with
> > -fno-merge-constants.
> > 
> > What do you think about something like this?
> > 
> > --- a/gcc/varasm.cc
> > +++ b/gcc/varasm.cc
> > @@ -7326,6 +7326,10 @@ default_elf_select_rtx_section (machine_mode
> > mode, rtx x,
> >     return get_named_section (NULL, ".data.rel.ro", 3);
> >  }
> >  
> > +  if (reloc)
> > +    return targetm.asm_out.function_rodata_section
> > (current_function_decl,
> > +   false);
> > +
> >    return mergeable_constant_section (mode, align, 0);
> >  }
> > 
> > This would put constants with relocations into .rodata..
> > default_function_rodata_section () already ensures that these
> > sections
> > are in the right comdat group.
> 
> We don't really know if the emitted constant is purely for the
> current
> function, or also other functions (say emitted in as constant pool
> constant
> where constant pool constants are shared across the whole TU).
> For the former, putting it into current function's comdat is fine,
> for the
> latter certainly isn't.

mergeable_constant_section (), that the existing code calls in the same
context, already relies on this being known and calls
function_rodata_section () with exactly the same arguments.  If
!current_function_decl && !relocatable, we get readonly_data_section.
Of course, mergeable_constant_section () does not handle comdat
currently, so this point might be moot.

However, looking at the callers of output_constant_pool_contents (), it
seems that !current_function_decl happens in and only in the
shared_constant_pool case, so it looks as if we know whether the
constant is tied to a single function or not.

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

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

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

--- Comment #15 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:19c62569ccf20d2744b63482a470474391d28c02

commit r13-44-g19c62569ccf20d2744b63482a470474391d28c02
Author: Marek Polacek 
Date:   Fri Apr 29 09:38:40 2022 -0400

c++: Add fixed test [PR78244]

This was finally fixed for GCC 11 by r11-434.

PR c++/78244

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wnarrowing20.C: New test.

[Bug c++/71424] std::initializer_list

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[pushed] c++: Add fixed test [PR71424]

[Marek Polacek via Gcc-patches]

This was fixed by r12-6329-g4f6bc28fc7dd86.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/71424

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array15.C: New test.
---
 gcc/testsuite/g++.dg/cpp0x/initlist-array15.C | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array15.C

diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array15.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-array15.C
new file mode 100644
index 000..67e30d8d93e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array15.C
@@ -0,0 +1,13 @@
+// PR c++/71424
+// { dg-do compile { target c++11 } }
+
+#include 
+
+void f(std::initializer_list list)
+{
+}
+
+int main()
+{
+   f({ { 1.0, 2.0 }, { 3.0, 4.0 } });
+}

base-commit: a0a2554d7c86c126de85fcbd5bd7e16dbb5a2693
-- 
2.35.1

[Bug c++/71424] std::initializer_list

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-43-ge1115a4f1b4afb346341237355186949f8e568a8
Author: Marek Polacek 
Date:   Fri Apr 29 09:33:08 2022 -0400

c++: Add fixed test [PR71424]

This was fixed by r12-6329-g4f6bc28fc7dd86.

PR c++/71424

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array15.C: New test.

[Bug c++/102987] [9/10/11 Regression] Segfault when error or warning should trigger with combination.

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

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

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

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

commit r13-42-ga0a2554d7c86c126de85fcbd5bd7e16dbb5a2693
Author: Jason Merrill 
Date:   Thu Apr 14 17:35:35 2022 -0400

c++: using in diagnostics [PR102987]

The decl pretty-printing code wasn't looking at the flags parameter, so we
were printing 'using' in the middle of an expression.

PR c++/102987

gcc/cp/ChangeLog:

* error.cc (dump_decl) [USING_DECL]: Respect flags.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/using1.C: Check pretty-printing.

[pushed] c++: using in diagnostics [PR102987]

[Jason Merrill via Gcc-patches]

The decl pretty-printing code wasn't looking at the flags parameter, so we
were printing 'using' in the middle of an expression.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/102987

gcc/cp/ChangeLog:

* error.cc (dump_decl) [USING_DECL]: Respect flags.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/using1.C: Check pretty-printing.
---
 gcc/cp/error.cc  | 18 +++---
 gcc/testsuite/g++.dg/diagnostic/using1.C |  1 +
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 2b07136b5ca..53a9073d99b 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -1439,16 +1439,20 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
 
 case USING_DECL:
   {
-   pp_cxx_ws_string (pp, "using");
-   tree scope = USING_DECL_SCOPE (t);
+   if (flags & TFF_DECL_SPECIFIERS)
+ pp_cxx_ws_string (pp, "using");
bool variadic = false;
-   if (PACK_EXPANSION_P (scope))
+   if (!(flags & TFF_UNQUALIFIED_NAME))
  {
-   scope = PACK_EXPANSION_PATTERN (scope);
-   variadic = true;
+   tree scope = USING_DECL_SCOPE (t);
+   if (PACK_EXPANSION_P (scope))
+ {
+   scope = PACK_EXPANSION_PATTERN (scope);
+   variadic = true;
+ }
+   dump_type (pp, scope, flags);
+   pp_cxx_colon_colon (pp);
  }
-   dump_type (pp, scope, flags);
-   pp_cxx_colon_colon (pp);
dump_decl (pp, DECL_NAME (t), flags);
if (variadic)
  pp_cxx_ws_string (pp, "...");
diff --git a/gcc/testsuite/g++.dg/diagnostic/using1.C 
b/gcc/testsuite/g++.dg/diagnostic/using1.C
index eb4f18d1d8b..4090dd24a60 100644
--- a/gcc/testsuite/g++.dg/diagnostic/using1.C
+++ b/gcc/testsuite/g++.dg/diagnostic/using1.C
@@ -7,6 +7,7 @@ struct a {
 template  struct d : c {
   using c::e;
   using f = d;
+  // { dg-message "decltype .c::e" "" { target *-*-* } 0 }
   constexpr int g(decltype(e.b())) { return buh; } // { dg-error "buh" }
 };
 struct h {

base-commit: a282da2243103d79262ca04f5e3a3cc7b9b06935
prerequisite-patch-id: 488a80b552cc74278a93c46df93c5dfe1e019e81
-- 
2.27.0

[pushed] c++: dump alias-declaration scope

[Jason Merrill via Gcc-patches]

An alias can't be declared with a qualified-id in actual code, but in
diagnostics we want to know which scope it belongs to, and I think a
nested-name-specifier is the best way to provide that.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

* error.cc (dump_decl): Check TFF_UNQUALIFIED_NAME.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-1.C: Expect qualified name.
---
 gcc/cp/error.cc   | 2 ++
 gcc/testsuite/g++.dg/cpp0x/alias-decl-1.C | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
index 1e944ca3f75..2b07136b5ca 100644
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -1246,6 +1246,8 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
  || flags & TFF_CLASS_KEY_OR_ENUM))
{
  pp_cxx_ws_string (pp, "using");
+ if (! (flags & TFF_UNQUALIFIED_NAME))
+   dump_scope (pp, CP_DECL_CONTEXT (t), flags);
  dump_decl (pp, DECL_NAME (t), flags);
  pp_cxx_whitespace (pp);
  pp_cxx_ws_string (pp, "=");
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-1.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-1.C
index 24b05209223..6dcb780e895 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-1.C
@@ -12,5 +12,5 @@ template struct Ptr {}; // { dg-error 
"specialization" }
 
 struct A {
 using A = int;  // { dg-error "11:ISO C\\+\\+ forbids nested type .A." }
-// { dg-error "11:.using A = int. has the same name as" "" { target c++11 } 
.-1 }  
+// { dg-error "11:.using A::A = int. has the same name as" "" { target c++11 } 
.-1 }  
 };

base-commit: a282da2243103d79262ca04f5e3a3cc7b9b06935
-- 
2.27.0

Re: GCC 12.0.1 Status Report (2022-04-28)

[LIU Hao via Gcc]

在 2022-04-28 22:59, Jakub Jelinek via Gcc 写道:

Status
==

We have reached zero P1 regressions today and releases/gcc-12 branch has
been created.  GCC 12.1-rc1 will be built likely tomorrow.
The branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval now.

If no show stoppers appear, we'd like to release 12.1 late next week,
or soon after that, if any important issues are discovered and
fixed, rc2 could be released next week.




Congrats. I have so far bootstrapped GCC 12.0 on {x86_64,i686}-w64-mingw32 and 
seen no problems.



--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

[Bug libstdc++/105417] [11/12/13 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #6)
> Shouldn't the #if 1 be wropped?

Yeah, that's gone in the real patch I'm testing.

> On the other side, perhaps wrap the wchar_t stuff in
> #ifdef _GLIBCXX_USE_WCHAR_T
> just for consistency?

Yes, I suppose it should. That macro should always be defined for
powerpc64le-*-linux-gnu because we know we have a Glibc that isn't from the
last millennium, but it's possible somebody wants to use --disable-wchar_t for
some reason.

[Bug target/105429] Unnecessary moves generated with _mm_crc32_u64

[kspalaiologos at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Palaiologos  ---
I have observed the same behaviour with and without `mov eax, eax`. CRC32 is a
32-bit checksum, so I'd presume that the high bits aren't considered by the
instruction.

To support my claim, Vol. 2A 3-257 of Intel Software Development Manual gives
the following operation for 2 REX.W 0F 38 F1 /r:

>>>
TEMP1[63-0] := BIT_REFLECT64 (SRC[63-0])
TEMP2[31-0] := BIT_REFLECT32 (DEST[31-0])
TEMP3[95-0] := TEMP1[63-0] « 32
TEMP4[95-0] := TEMP2[31-0] « 64
TEMP5[95-0] := TEMP3[95-0] XOR TEMP4[95-0]
TEMP6[31-0] := TEMP5[95-0] MOD2 11EDC6F41H
DEST[31-0] := BIT_REFLECT (TEMP6[31-0])
DEST[63-32] := H
<<<

[Bug target/105429] Unnecessary moves generated with _mm_crc32_u64

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
The intrinsic is defined as:

unsinged __int64 _mm_crc32_u64( unsinged __int64 crc, unsigned __int64 data )

and the unnecessary move is in fact zero-extend:

movl%eax, %eax  # 16[c=1 l=2]  *zero_extendsidi2/3

You probably want:

uint32_t crc(uint64_t current, const uint8_t *buffer, size_t size) {
for(size_t i = 0; i < size; i++)
current = _mm_crc32_u64(current, buffer[i]);
return current;
}

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to HaoChen Gui from comment #8)
> > (In reply to Jakub Jelinek from comment #7)
> > > Sure, but you don't want to do that at least if flag_trapping_math.
> > > Otherwise, the predicate would be tree_expr_signaling_nan_p and real_nan
> > > function with "", 1 as the middle 2 arguments can create it.  But note 
> > > that
> > > nothing in match.pd does that right now, so I don't think we should do it 
> > > in
> > > this case either.
> > 
> > If either of arguments is sNaN, fmin/max should return a qNaN. So I really
> > want to create a pattern in match.pd to do this. It needs to create a qNaN
> 
> A sNaN should primarily raise an exception or raise a signal when used.
> So better not to fold it.
> Given that we don't fold anything else with sNaN, starting from sNaN +
> whatever
> etc., just folding it for something so rare as fmin/fmax would be weird.

Agreed btw.  Iff then such propagation / simplification should belong in
a pass like forwprop or value-numbering which can do this in a cheaper way
than adding patterns for all kinds of operations with NaNs.  One might also
say that we should diagnose any arithmetic with known NaNs ...

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Rainer Orth :

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

commit r12-8320-gc733f40f87bdb414b3e99814d97946bad89db743
Author: Rainer Orth 
Date:   Fri Apr 29 13:56:09 2022 +0200

libstdc++: Update Solaris baselines for GCC 12.1

The following patch updates the Solaris baselines for GCC 12.1.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
and 11.4 in each case).

The only (expected) difference between the 11.3 and 11.4 versions is

--- baseline_symbols.txt.s113s  2022-04-28 10:37:11.464068450 +
+++ baseline_symbols.txt.s114s  2022-04-27 16:54:31.995636805 +
@@ -4070,3 +4070,3 @@
-FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.30
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.29

which is handled by the fix for PR libstdc++/103407.  I'm using the 11.4
version here.


2022-04-27  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote:
> > This doesn't resolve the problem, unfortunately, because
> > references to discarded comdat symbols are still kept in .rodata:
> > 
> > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced in
> > section `.rodata' of ../lib/libgtest.a(gtest-all.cc.o): defined in
> > discarded section
> > `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_[_ZN7testing15Asse
> > rt
> > ionResultlsIPKcEERS0_RKT_]' of ../lib/libgtest.a(gtest-all.cc.o)
> > 
> > (That's from building zlib-ng with ASan and your patch on s390).
> > 
> > So I was rather thinking about adding a reloc parameter to
> > mergeable_constant_section () and slightly changing the section
> > name when it's nonzero, e.g. from .cst to .cstrel.
> 
> After some experimenting, I don't think that what I propose here
> is a good solution anymore, since it won't work with
> -fno-merge-constants.
> 
> What do you think about something like this?
> 
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -7326,6 +7326,10 @@ default_elf_select_rtx_section (machine_mode
> mode, rtx x,
> return get_named_section (NULL, ".data.rel.ro", 3);
>  }
>  
> +  if (reloc)
> +return targetm.asm_out.function_rodata_section
> (current_function_decl,
> +   false);
> +
>return mergeable_constant_section (mode, align, 0);
>  }
> 
> This would put constants with relocations into .rodata..
> default_function_rodata_section () already ensures that these sections
> are in the right comdat group.

We don't really know if the emitted constant is purely for the current
function, or also other functions (say emitted in as constant pool constant
where constant pool constants are shared across the whole TU).
For the former, putting it into current function's comdat is fine, for the
latter certainly isn't.

Jakub

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Thu, 2022-04-28 at 14:05 +0200, Ilya Leoshkevich wrote:
> On Thu, 2022-04-28 at 13:27 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> > > This is determined by default_elf_select_rtx_section ().  If we
> > > don't
> > > want to mix non-reloc and reloc constants, we need to define a
> > > special
> > > section there.
> > > 
> > > It seems to me, however, that this all would be made purely for
> > > the
> > > sake of .LASANPC, which is quite special: it's local, but at the
> > > same
> > > time it might need to be comdat.  I don't think anything like
> > > this
> > > can
> > > appear from compiling C/C++ code.
> > > 
> > > Therefore I wonder if we could just drop it altogether like this?
> > > 
> > > @@ -1928,22 +1919,7 @@ asan_emit_stack_protection (rtx base, rtx
> > > pbase,
> > > unsigned int alignb,
> > > ...
> > > -  emit_move_insn (mem, expand_normal (build_fold_addr_expr
> > > (decl)));
> > > +  emit_move_insn (mem, expand_normal (build_fold_addr_expr
> > > (current_function_decl)));
> > > ...
> > > 
> > > That's what LLVM is already doing.  This will also solve the
> > > alignment
> > > problem I referred to earlier.
> > 
> > LLVM is doing a wrong thing here.  The global symbol can be
> > overridden by
> > a symbol in another shared library, that is definitely not what we
> > want,
> > because the ASAN record is for the particular implementation, not
> > the
> > other
> > one which could be quite different.
> 
> I see; this must be relevant when the overriding library calls
> the original one through dlsym (RTLD_NEXT).
> 
> > I think the right fix would be:
> > --- gcc/varasm.cc.jj2022-03-07 15:00:17.255592497 +0100
> > +++ gcc/varasm.cc   2022-04-28 13:22:44.463147066 +0200
> > @@ -7326,6 +7326,9 @@ default_elf_select_rtx_section (machine_
> > return get_named_section (NULL, ".data.rel.ro", 3);
> >  }
> >  
> > +  if (reloc)
> > +    return readonly_data_section;
> > +
> >    return mergeable_constant_section (mode, align, 0);
> >  }
> >  
> > which matches what we do in categorize_decl_for_section:
> >   else if (reloc & targetm.asm_out.reloc_rw_mask ())
> >     ret = reloc == 1 ? SECCAT_DATA_REL_RO_LOCAL :
> > SECCAT_DATA_REL_RO;
> >   else if (reloc || flag_merge_constants < 2
> > ...
> >     /* C and C++ don't allow different variables to share the
> > same
> >    location.  -fmerge-all-constants allows even that (at
> > the
> >    expense of not conforming).  */
> >     ret = SECCAT_RODATA;
> >   else if (DECL_INITIAL (decl)
> >    && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
> >     ret = SECCAT_RODATA_MERGE_STR_INIT;
> >   else
> >     ret = SECCAT_RODATA_MERGE_CONST;
> > i.e. if reloc is true, it goes into .data.rel.ro* for -fpic and
> > .rodata
> > for non-pic, and mergeable sections are only used if there are no
> > relocations.
> 
> This doesn't resolve the problem, unfortunately, because
> references to discarded comdat symbols are still kept in .rodata:
> 
> `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced in
> section `.rodata' of ../lib/libgtest.a(gtest-all.cc.o): defined in
> discarded section
> `.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_[_ZN7testing15Asse
> rt
> ionResultlsIPKcEERS0_RKT_]' of ../lib/libgtest.a(gtest-all.cc.o)
> 
> (That's from building zlib-ng with ASan and your patch on s390).
> 
> So I was rather thinking about adding a reloc parameter to
> mergeable_constant_section () and slightly changing the section
> name when it's nonzero, e.g. from .cst to .cstrel.

After some experimenting, I don't think that what I propose here
is a good solution anymore, since it won't work with
-fno-merge-constants.

What do you think about something like this?

--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -7326,6 +7326,10 @@ default_elf_select_rtx_section (machine_mode
mode, rtx x,
return get_named_section (NULL, ".data.rel.ro", 3);
 }
 
+  if (reloc)
+return targetm.asm_out.function_rodata_section
(current_function_decl,
+   false);
+
   return mergeable_constant_section (mode, align, 0);
 }

This would put constants with relocations into .rodata..
default_function_rodata_section () already ensures that these sections
are in the right comdat group.
> 

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed for GCC 13.

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

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

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

commit r13-40-ga282da2243103d79262ca04f5e3a3cc7b9b06935
Author: Jakub Jelinek 
Date:   Fri Apr 29 13:50:10 2022 +0200

c++: Improve diagnostics for template args terminated with >= or >>=
[PR104319]

As mentioned in the PR, for C++98 we have diagnostics that expect
>> terminating template arguments to be a mistake for > > (C++11
said it has to be treated that way), while if user trying to spare the
spacebar doesn't separate > from following = or >> from following =,
the diagnostics is confusing, while clang suggests adding space in between.

The following patch does that for >= and >>= too.

For some strange reason the error recovery emits further errors,
not really sure what's going on because I overwrite the token->type
like the code does for the C++11 >> case or for the C++98 >> cases,
but at least the first error is nicer (well, for the C++98 nested
template case and >>= I need to overwrite it to > and so the = is lost,
so perhaps some follow-up errors are needed for that case).

2022-04-29  Jakub Jelinek  

PR c++/104319
* parser.cc (cp_parser_template_argument): Treat >= like C++98 >>
after a type id by setting maybe_type_id and aborting tentative
parse.
(cp_parser_enclosed_template_argument_list): Handle
CPP_GREATER_EQ like misspelled CPP_GREATER CPP_RQ and
CPP_RSHIFT_EQ like misspelled CPP_GREATER CPP_GREATER_EQ
or CPP_RSHIFT CPP_EQ or CPP_GREATER CPP_GREATER CPP_EQ.
(cp_parser_next_token_ends_template_argument_p): Return true
also for CPP_GREATER_EQ and CPP_RSHIFT_EQ.

* g++.dg/parse/template28.C: Adjust expected diagnostics.
* g++.dg/parse/template30.C: New test.

[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:8c465ddd619bbb2949bc2bc31629c2a826a7c437

commit r13-39-g8c465ddd619bbb2949bc2bc31629c2a826a7c437
Author: Rainer Orth 
Date:   Fri Apr 29 13:44:49 2022 +0200

libstdc++: Update Solaris baselines for GCC 12.1

The following patch updates the Solaris baselines for GCC 12.1.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
and 11.4 in each case).

The only (expected) difference between the 11.3 and 11.4 versions is

--- baseline_symbols.txt.s113s  2022-04-28 10:37:11.464068450 +
+++ baseline_symbols.txt.s114s  2022-04-27 16:54:31.995636805 +
@@ -4070,3 +4070,3 @@
-FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.30
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.29

which is handled by the fix for PR libstdc++/103407.  I'm using the 11.4
version here.


2022-04-27  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

Re: [PATCH] Replace EVRP in DOM with ranger.

[Aldy Hernandez via Gcc-patches]

On Thu, Apr 28, 2022 at 8:43 PM Jeff Law  wrote:
>
>
>
> On 4/28/2022 10:30 AM, Aldy Hernandez wrote:
> > [Jeff, this is the same patch I sent you last week with minor tweaks
> > to the commit message.]
> And I just dropped it into the tester.  We should have the vast majority
> of targets tested by this time tomorrow.
>
> >
> > [Despite the verbosity of the message, this is actually a pretty
> > straightforward patch.  It should've gone in last cycle, but there
> > was a nagging regression I couldn't get to until after stage1
> > had closed.]
> You had other, non-work/gcc priorities.  No worries at missing gcc-12.

Ha.  I keep forgetting I have a permanent excuse going forward for any
delays... parenthood!

>
>
> >
> > There are 3 uses of EVRP in DOM that must be converted.
> > Unfortunately, they need to be converted in one go, so further
> > splitting of this patch would be problematic.
> ACK
>
>
> > There's nothing here earth shattering.  It's all pretty obvious in
> > retrospect, but I've added a short description of each use to aid in
> > reviewing:
> >
> > * Convert evrp use in cprop to ranger.
> >
> >This is easy, as cprop in DOM was converted to the ranger API last
> >cycle, so this is just a matter of using a ranger instead of an
> >evrp_range_analyzer.
> Yea.  We may have covered this before, but what does ranger do with a
> conditional equivalence?
>
> ie if we have something like
>
> if (a == b)
>{
>  blah blah
>}
>
> Within the true arm we know there's an equivalence.  *But* we don't want
> to just blindly replace a with b or vice-versa.  The equivalence is
> primarily useful for simplification rather than propagation.
>
> In fact, we every much do not want to cprop in these cases.   It rarely
> helps in a meaningful way and there's no good way to know which is the
> better value to use.  Canonicalization on SSA_NAMEs doesn't  really help
> due to SSA_NAME recycling.

Ranger only returns constants, not symbolics, so the call to
range_of_expr is guaranteed to be constant.  I verified that this
subtle change to range_of_expr didn't cause any problems in my
conversion to the value_query API in commit e1d01f4973 (last cyce):

There is one subtle change.  The call to vr_value's
op_with_constant_singleton_value_range can theoretically return
non-constants, unlike the range_query API which only returns constants.
In this particular case it doesn't matter because the symbolic stuff will
have been handled by the const_and_copies/avail_exprs read in the
SSA_NAME_VALUE copy immediately before.  I have verified this is the case
by asserting that all calls to op_with_constant_singleton_value_range at
this point return either NULL or an INTEGER_CST.

Just to be clear, even though ranger doesn't return a symbolic, it
does know about relations via the relation oracle the ranger uses.  So
on the TRUE arm, it will know that a==b, which it can leverage to fold
any statements.  This could be done with the statement folding API in
gimple-range-fold.h (or via range_of_stmt).  You could theoretically
query the relation oracle yourself with query_relation() which are
exported by the ranger (via the range_query class it inherits from).
But for the case above, we're calling range_of_expr which is
guaranteed to be a constant.

Since we're calling range_of_expr on operands, we shouldn't be folding
anything.  OTOH, if you were to call range_of_stmt on the conditional,
it could return  TRUE/FALSE based on how it would fold.  In
dom_opt_dom_walker::fold_cond() which I have provided in the patch, we
will fold conditionals with knowledge of relations, because it uses
range_of_stmt.

BTW, when frange and prange come live, there will be other attributes
that may be attached to a range.  For instance for prange, we'll have
a "points-to" attribute.   For example:

p_5 = 

The range of p_5 will be nonzero with a points-to attribute of  +
0 or some such.

So later this cycle we'll have symbolics of sorts, but never in the
range itself, but as an attribute say prange::get_points_to().

Similarly for floats.  We'll probably have not-NAN, not-INF, etc attributes.

>
>
> >
> > * Convert evrp use in threader to ranger.
> >
> >The idea here is to use the hybrid approach we used for the initial
> >VRP threader conversion last cycle.  The DOM threader will continue
> >using the forward threader infrastructure while continuing to query
> >DOM data structures, and only if the conditional does not relsolve,
> >using the ranger.  This gives us the best of both worlds, and is a
> >proven approach.
> >
> >Furthermore, as frange and prange come live in the next cycle, we
> >can move away from the forward threader altogether, and just add
> >another backward threader.  This will not only remove the last use
> >of the forward threader, but will allow us to remove at least 1 or 2
> >threader instances.
> Excellent.
>
> >
> > * Convert conditional 

[Bug tree-optimization/105420] Bogus -Warray-bounds with non-compile time-constant variable

[byteslice at airmail dot cc via Gcc-bugs]

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

--- Comment #2 from Liam White  ---
Created attachment 52906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52906=edit
Preprocessed source

The first attachment is automatically and manually reduced from the following
source:

ResultCode KThread::Initialize(KThreadFunction func, uintptr_t arg, VAddr
user_stack_top, s32 prio,
   s32 virt_core, KProcess* owner, ThreadType type)
{
// Assert parameters are valid.
ASSERT((type == ThreadType::Main) || (type == ThreadType::Dummy) ||
   (Svc::HighestThreadPriority <= prio && prio <=
Svc::LowestThreadPriority));
ASSERT((owner != nullptr) || (type != ThreadType::User));
ASSERT(0 <= virt_core && virt_core <
static_cast(Common::BitSize()));

// Convert the virtual core to a physical core.
const s32 phys_core = Core::Hardware::VirtualToPhysicalCoreMap[virt_core];
ASSERT(0 <= phys_core && phys_core <
static_cast(Core::Hardware::NUM_CPU_CORES));

// ...
}

And it produces this compiler error (compile this preprocessed source with -O2
-Werror=array-bounds -std=gnu++20):

In static member function ‘static constexpr _Tp& std::__array_traits<_Tp,
_Nm>::_S_ref(const _Tp (&)[_Nm], std::size_t) [with _Tp = int; long unsigned
int _Nm = 64]’,
inlined from ‘constexpr const std::array<_Tp, _Nm>::value_type&
std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = int; long
unsigned int _Nm = 64]’ at k_thread.cpp:59748:25,
inlined from ‘ResultCode
Kernel::KThread::Initialize(Kernel::KThreadFunction, uintptr_t, VAddr, s32,
s32, Kernel::KProcess*, Kernel::ThreadType)’ at k_thread.cpp:102280:77:
k_thread.cpp:59638:36: error: array subscript 64 is above array bounds of
‘std::__array_traits::_Type’ {aka ‘const int [64]’}
[-Werror=array-bounds]
59638 |   { return const_cast<_Tp&>(__t[__n]); }
  | ~~~^
k_thread.cpp: In member function ‘ResultCode
Kernel::KThread::Initialize(Kernel::KThreadFunction, uintptr_t, VAddr, s32,
s32, Kernel::KProcess*, Kernel::ThreadType)’:
k_thread.cpp:77557:51: note: while referencing
‘Core::Hardware::VirtualToPhysicalCoreMap’
77557 | constexpr std::array()>
VirtualToPhysicalCoreMap{
  |  
^~~~
cc1plus: some warnings being treated as errors

I generally believe that this is a bug in the compiler as the array is
similarly never accessed with the constant value 64.

[Bug target/105073] [meta bug]Patch pending for GCC13.

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug 51954 Summary: __int128_t (and long long on x86) negation can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51954

   What|Removed |Added

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

[Bug target/51954] __int128_t (and long long on x86) negation can be optimized

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
Implemented for gcc-13.

[PATCH] i386: Optimize double-word negation [PR51954]

[Uros Bizjak via Gcc-patches]

Introduce peephole2 pattern to convert from:

   mov %esi, %edx
   negl %eax
   adcl $0, %edx
   negl %edx
 to:
   xorl %edx, %edx
   negl %eax
   sbbl %esi, %edx

This conversion is profitable only when initial move is found.  Otherwise,
additional move to a temporary together with clearing xor is needed.

2022-04-29  Uroš Bizjak  

gcc/ChangeLog:

PR target/51954
* config/i386/i386.md (adcl/neg -> sbb peephole): New peephole2.
gcc/testsuite/ChangeLog:

PR target/51954
* gcc.target/i386/pr51954.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c74edd1aaef..b321cda1f22 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10929,6 +10929,50 @@ (define_insn_and_split "*neg2_doubleword"
  (clobber (reg:CC FLAGS_REG))])]
   "split_double_mode (mode, [0], 2, [0], 
[2]);")
 
+;; Convert:
+;;   mov %esi, %edx
+;;   negl %eax
+;;   adcl $0, %edx
+;;   negl %edx
+;; to:
+;;   xorl %edx, %edx
+;;   negl %eax
+;;   sbbl %esi, %edx
+
+(define_peephole2
+  [(set (match_operand:SWI48 0 "general_reg_operand")
+   (match_operand:SWI48 1 "nonimmediate_gr_operand"))
+   (parallel
+[(set (reg:CCC FLAGS_REG)
+ (ne:CCC (match_operand:SWI48 2 "general_reg_operand") (const_int 0)))
+ (set (match_dup 2) (neg:SWI48 (match_dup 2)))])
+   (parallel
+[(set (match_dup 0)
+ (plus:SWI48 (plus:SWI48
+   (ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0))
+   (match_dup 0))
+ (const_int 0)))
+ (clobber (reg:CC FLAGS_REG))])
+   (parallel
+[(set (match_dup 0)
+ (neg:SWI48 (match_dup 0)))
+ (clobber (reg:CC FLAGS_REG))])]
+  "REGNO (operands[0]) != REGNO (operands[2])
+   && !reg_mentioned_p (operands[0], operands[1])
+   && !reg_mentioned_p (operands[2], operands[1])"
+  [(parallel
+[(set (reg:CCC FLAGS_REG)
+ (ne:CCC (match_dup 2) (const_int 0)))
+ (set (match_dup 2) (neg:SWI48 (match_dup 2)))])
+   (parallel
+[(set (match_dup 0)
+ (minus:SWI48 (minus:SWI48
+(match_dup 0)
+(ltu:SWI48 (reg:CC FLAGS_REG) (const_int 0)))
+  (match_dup 1)))
+ (clobber (reg:CC FLAGS_REG))])]
+  "ix86_expand_clear (operands[0]);")
+
 (define_insn "*neg_1"
   [(set (match_operand:SWI 0 "nonimmediate_operand" "=m")
(neg:SWI (match_operand:SWI 1 "nonimmediate_operand" "0")))
diff --git a/gcc/testsuite/gcc.target/i386/pr51954.c 
b/gcc/testsuite/gcc.target/i386/pr51954.c
new file mode 100644
index 000..5e757de22f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr51954.c
@@ -0,0 +1,15 @@
+/* PR target/51954 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "adc" } } */
+
+#ifdef __x86_64__
+#define TYPE __int128
+#else
+#define TYPE long long
+#endif
+
+TYPE bar (TYPE x)
+{
+  return -x;
+}

[Bug target/51954] __int128_t (and long long on x86) negation can be optimized

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:59119253b3133b30114194a04171f9d353b5c7f7

commit r13-38-g59119253b3133b30114194a04171f9d353b5c7f7
Author: Uros Bizjak 
Date:   Fri Apr 29 13:27:48 2022 +0200

i386: Optimize double-word negation [PR51954]

Introduce peephole2 pattern to convert from:

   mov %esi, %edx
   negl %eax
   adcl $0, %edx
   negl %edx
 to:
   xorl %edx, %edx
   negl %eax
   sbbl %esi, %edx

This conversion is profitable only when initial move is found.  Otherwise,
additional move to a temporary together with clearing xor is needed.

2022-04-29  Uroš Bizjak  

gcc/ChangeLog:

PR target/51954
* config/i386/i386.md (adcl/neg -> sbb peephole): New peephole2.
gcc/testsuite/ChangeLog:

PR target/51954
* gcc.target/i386/pr51954.c: New test.

[Bug tree-optimization/105423] Bogus -Werror=maybe-uninitialized with definitely initialized variable

[byteslice at airmail dot cc via Gcc-bugs]

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

--- Comment #2 from Liam White  ---
My bad, use -std=c++20 as well for this example. Then you should reproduce the
issue.

Re: [PATCH] alias: Fix -fcompare-debug issues caused by compare_base_symbol_refs [PR105415]

[Richard Biener via Gcc-patches]

On Fri, 29 Apr 2022, Jakub Jelinek wrote:

> On Fri, Apr 29, 2022 at 01:11:31PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > Depends.  DECL_IN_CONSTANT_POOL decls can appear 2 ways, through
> > tree_output_constant_def which does create a varpool node for them
> > and is generally invoked during GIMPLE passes or so, and using
> > output_constant_def, which is called during expansion or later and doesn't
> > have varpool nodes created unless say alias.cc creates those for them.
> 
> Oh, and one thing I forgot.  The constant pool decls can be put into section
> anchors, so it is essential that we handle DECL_IN_CONSTANT_POOL decls
> there and don't just punt on those.

Ah, OK - that makes sense (maybe we should create varpool nodes at the
point we associate them with anchors, or alternatively use the varpool
node of the anchor?).

Richard.