[Bug c++/100197] New: g++ emits spurious Wstring-compare warnings on strcmp()

[jaf at meyersound dot com via Gcc-bugs]

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

Bug ID: 100197
   Summary: g++ emits spurious Wstring-compare warnings on
strcmp()
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaf at meyersound dot com
  Target Milestone: ---

Created attachment 50653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50653=edit
preprocessed file from teststring.cpp

Tested with g++ (Ubuntu 10.20-13ubuntu1) 10.2.0 (as installed via "sudp apt-get
install g++") on an Ubuntu 20.10 64-bit VM running inside VMWare Fusion on a
2018 Mac Mini.

To reproduce, compile the attached .cpp file, like this:

$ g++ -O2 -W -c teststring.cpp
In member function ‘bool String::operator==(const char*) const’,
inlined from ‘int main(int, char**)’ at teststring.cpp:52:21:
teststring.cpp:27:21: warning: ‘int strcmp(const char*, const char*)’ of a
string of length 10 and an array of size 8 evaluates to nonzero
[-Wstring-compare]
   27 |   return (strcmp(myStr, rhs) == 0);
  |   ~~^~~~
teststring.cpp: In function ‘int main(int, char**)’:
teststring.cpp:52:16: note: in this expression
   52 |if ((rand())&&(s == "1234567890")) printf("Mwahey!\n");
  |^

Note that the emitted warnings are (AFAICT) spurious, because in the example
program the two strings that get passed to strcmp() are both "1234567890".  The
8-byte array (_smallBuffer[8]) that the warning mentions is not actually used.

It seems like maybe the compiler is assuming that the
IsArrayDynamicallyAllocated() method in the example will always return false,
which is not a valid assumption.

The fault only happens when I specifed -O2 or -O3, it doesn't happen if I leave
optimization disabled or specify -O1.

[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

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

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

--- Comment #32 from CVS Commits  ---
The master branch has been updated by Michael Meissner :

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

commit r12-54-g3cf04d1afa8a4955a0a9a395dd21ce1b6484aa78
Author: Michael Meissner 
Date:   Wed Apr 21 23:02:07 2021 -0400

Fix Fortran rounding issues, PR fortran/96983.

I was looking at Fortran PR 96983, which fails on the PowerPC when trying
to
run the test PR96711.F90.  The compiler ICEs because the PowerPC does not
have
a floating point type with a type precision of 128.  The reason is that the
PowerPC has 3 different 128 bit floating point types (__float128/_Float128,
__ibm128, and long double).  Currently long double uses the IBM extended
double
type, but we would like to switch to using IEEE 128-bit long doubles in the
future.

In order to prevent the compiler from converting explicit __ibm128 types to
long double when long double uses the IEEE 128-bit representation, we have
set
up the precision for __ibm128 to be 128, long double to be 127, and
__float128/_Float128 to be 126.

Originally, I was trying to see if for Fortran, I could change the
precision of
long double to be 128 (Fortran doesn't access __ibm128), but it quickly
became
hard to get the changes to work.

I looked at the Fortran code in build_round_expr, and I came to the
conclusion
that there is no reason to promote the floating point type.  If you just do
a
normal round of the value using the current floating point format and then
convert it to the integer type.  We don't have an appropriate built-in
function
that provides the equivalent of llround for 128-bit integer types.

This patch fixes the compiler crash.

However, while with this patch, the PowerPC compiler will not crash when
building the test case, it will not run on the current default
installation.
The failure is because the test is explicitly expecting 128-bit floating
point
to handle 10384593717069655257060992658440192_16 (i.e. 2**113).

By default, the PowerPC uses IBM extended double used for 128-bit floating
point.  The IBM extended double format is a pair of doubles that provides
more
mantissa bits but does not grow the expoenent range.  The value in the test
is
fine for IEEE 128-bit floating point, but it is too large for the PowerPC
extended double setup.

I have built the following tests with this patch:

   * I have built a bootstrap compiler on a little endian power9 Linux
system
 with the default long double format (IBM extended double).  The
 pr96711.f90 test builds, but it does not run due to the range of the
 real*16 exponent.  There were no other regressions in the
C/C++/Fortran
 tests.

   * I have built a bootstrap compiler on a little endian power9 Linux
system
 with the default long double format set to IEEE 128-bit. I used the
 Advance Toolchain 14.0-2 to provide the IEEE 128-bits.  The compiler
was
 configured to build power9 code by default, so the test generated
native
 power9 IEEE 128-bit instructions.  The pr96711.f90 test builds and
runs
 correctly in this setup.

   * I have built a bootstrap compiler on a big endian power8 Linux system
with
 the default long double format (IBM extended double).  Like the first
 case, the pr96711.f90 test does not crash the compiler, but the test
fails
 due to the range of the real*16 exponent.There were no other
 regressions in the C/C++/Fortran tests.

   * I built a bootstrap compiler on my x86_64 laptop.  There were no
 regressions in the tests.

gcc/fortran/
2021-04-21  Michael Meissner  

PR fortran/96983
* trans-intrinsic.c (build_round_expr): If int type is larger than
long long, do the round and convert to the integer type.  Do not
try to find a floating point type the exact size of the integer
type.

[Bug target/100108] [10 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[rin at NetBSD dot org via Gcc-bugs]

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

--- Comment #11 from Rin Okuyama  ---
Segher, let me thank you again!

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #23 from lucier at math dot purdue.edu ---
With the mainline compiler

git log -1 --oneline
0c0bdcc60cf (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
libgomp.fortran/depobj-1.f90: Fix omp_depend_kind

the Gambit build runs to completion, makes all modules, passes "make check" and
does what's expected in lldb:

lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) target create "gsi/gsi"
Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64).
(lldb) settings set -- target.run-args 
"-:~~bin=./bin,~~lib=./lib,~~include=./include" "-v"
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r
Process 94836 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64)
v4.9.3-1376-gbb05af0a 20210421130354 x86_64-apple-darwin19.6.0 "./configure
'CC=/usr/local/gcc-mainline/bin/gcc -save-temps -g' '--enable-single-host'
'--enable-shared'"
Process 94836 exited with status = 0 (0x)

[Bug c++/99586] Use of class template identifier checked for CTAD before instantiation

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Johel Ernesto Guerrero Peña  ---
Thank you.

[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #10 from Patrick Palka  ---
This fix seems too risky to backport.

[Bug c++/88754] [8/9 Regression] Constructor call wrongly assumed to be a variable declaration

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
This fix doesn't seem to be worth backporting since there's a simple
workaround.

[Bug other/100175] ICE in cp_parser_lookup_name, at cp/parser.c:28265

[mkaracsony81 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Miklos Karacsony  ---
Commented too soon above, the ICE is back this time it happened when I've tried
to build Mesa:

[1775/2477] Compiling C++ object
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_singlesample.cpp.o'.
FAILED:
src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_singlesample.cpp.o
 
g++ -m64 -Isrc/gallium/drivers/swr/3eb908b@@swrAVX@sha
-Isrc/gallium/drivers/swr -I../src/gallium/drivers/swr
-Isrc/gallium/drivers/swr/rasterizer/codegen
-I../src/gallium/drivers/swr/rasterizer/codegen
-Isrc/gallium/drivers/swr/rasterizer/core
-I../src/gallium/drivers/swr/rasterizer/core
-Isrc/gallium/drivers/swr/rasterizer/jitter
-I../src/gallium/drivers/swr/rasterizer/jitter
-I../src/gallium/drivers/swr/rasterizer/archrast
-Isrc/gallium/drivers/swr/rasterizer -I../src/gallium/drivers/swr/rasterizer
-Isrc/gallium/drivers/swr/rasterizer/core/backends -I/usr/include
-fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -O3
-ffunction-sections -fdata-sections '-DPACKAGE_VERSION="20.3.5"'
'-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues;'
-DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DENABLE_SHADER_CACHE
-DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT
-DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT
-DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE
-DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT
-DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DUSE_SSE41
-DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DMAJOR_IN_SYSMACROS
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_EXECINFO_H
-DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET
-DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R
-DHAVE_GETRANDOM -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_POSIX_MEMALIGN
-DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR
-DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM
-DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="8.0.1"' -DLLVM_IS_SHARED=1
-DUSE_LIBGLVND=1 -DHAVE_LIBUNWIND -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED
-DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_GALLIUM_EXTRA_HUD=1
-DHAVE_LIBSENSORS=1 -Werror=return-type -Werror=empty-body
-Wno-non-virtual-dtor -Wno-missing-field-initializers -Wno-format-truncation
-fno-math-errno -fno-trapping-math -flifetime-dse=1 -Werror=format
-Wformat-security -O2 -mtune=generic -fPIC -pthread -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-Werror=pointer-arith -Werror=vla -fno-strict-aliasing -Wno-aligned-new -mavx
-DKNOB_ARCH=KNOB_ARCH_AVX -MD -MQ
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_singlesample.cpp.o'
-MF
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_singlesample.cpp.o.d'
-o
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_singlesample.cpp.o'
-c ../src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp
In file included from /usr/include/c++/10.3.1/ios:42,
 from /usr/include/c++/10.3.1/istream:38,
 from /usr/include/c++/10.3.1/sstream:38,
 from
../src/gallium/drivers/swr/rasterizer/common/rdtsc_buckets.h:35,
 from ../src/gallium/drivers/swr/rasterizer/core/state.h:34,
 from ../src/gallium/drivers/swr/rasterizer/core/api.h:39,
 from ../src/gallium/drivers/swr/rasterizer/core/context.h:37,
 from ../src/gallium/drivers/swr/rasterizer/core/backend.h:32,
 from
../src/gallium/drivers/swr/rasterizer/core/backend_singlesample.cpp:32:
/usr/include/c++/10.3.1/bits/ios_base.h: In function 'std::ios_base&
std::noskipws(std::ios_base&)':
/usr/include/c++/10.3.1/bits/ios_base.h:982:29: internal compiler error: in
cp_parser_lookup_name, at cp/parser.c:28265
  982 | __base.unsetf(ios_base::skipws);
  | ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[1776/2477] Compiling C++ object
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend_clear.cpp.o'.
[1777/2477] Compiling C++ object
'src/gallium/drivers/swr/3eb908b@@swrAVX@sha/rasterizer_core_backend.cpp.o'.

[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Cannot reproduce either with

GNU Fortran (SUSE Linux) 10.2.1 20200825 [revision
c0746a1beb1ba073c7981eb09f55b3d993b32e5c]

nor with

GNU Fortran (GCC) 10.3.1 20210420

May need narrowing down to affected versions.

[Bug c++/95468] [8/9 Regression] ICE in expression sfinae

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

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

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

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

commit r9-9456-g1b265d910f27743dc3ea8e4fde6c292df220fb9f
Author: Patrick Palka 
Date:   Tue Feb 23 09:40:09 2021 -0500

c++: Fix folding of non-dependent BASELINKs [PR95468]

Here, the problem ultimately seems to be that tsubst_copy_and_build,
when called with empty args as we do during non-dependent expression
folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
which then immediately exits early due to the empty args.  This means
that the CAST_EXPR int(1) in the BASELINK A::condition never
gets folded (as part of folding of the overall CALL_EXPR), which later
causes us to crash when performing overload resolution of the rebuilt
CALL_EXPR (which is still in terms of this templated BASELINK).

This doesn't happen when condition() is a namespace-scope function
because then condition is represented by a TEMPLATE_ID_EXPR
rather than by a BASELINK, which does get handled directly from
tsubst_copy_and_build.

This patch fixes this issue by having tsubst_copy_and_build handle
BASELINK directly rather than delegating to tsubst_copy, so that it
processes BASELINKs even when args is empty.

gcc/cp/ChangeLog:

PR c++/95468
* pt.c (tsubst_copy_and_build) : New case, copied
over from tsubst_copy.

gcc/testsuite/ChangeLog:

PR c++/95468
* g++.dg/template/non-dependent15.C: New test.

(cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)

[Bug c++/96282] [8/9 Regression] internal compiler error: in output_constructor_regular_field

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

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

commit r9-9455-gfef6ee0790de58f16128a0de87571ba7e04b8320
Author: Patrick Palka 
Date:   Wed Aug 5 15:05:30 2020 -0400

c++: cxx_eval_vec_init after zero-initialization [PR96282]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch fixes this issue by truncating a zero-initialized array
CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
elements to it.  We propagate its zeroed out state during evaluation by
clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're initializing a previously zero-initialized
array object.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.

Co-authored-by: Jason Merrill 
(cherry picked from commit d21252de6c81ed236d8981d47b9a57dc4f1c6d57)

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

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> Do you think the following is the right thing?

Correction:

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..e1ec1c610e8 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1055,6 +1055,13 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
  return true;
 }

+  /* F2018:R902: function reference having a data pointer result.  */
+  if (e->expr_type == EXPR_FUNCTION
+  && e->symtree->n.sym->attr.flavor == FL_PROCEDURE
+  && e->symtree->n.sym->attr.function
+  && e->symtree->n.sym->attr.pointer)
+return true;
+
   gfc_error ("%qs argument of %qs intrinsic at %L must be a variable",
 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
>where);

It's getting late...

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

--- Comment #22 from Iain Sandoe  ---
so it looks like the contents of r10 are being trashed by the call to
___UTF_8_put (the first call goes through the dylib lazy symbol resolution and
that leaves r10 with a value pointing to some mutex).

When we return from ___UTF_8_put there's a test for the loop iteration which is
expecting that to be the value in r10.  The test is for equality which fails
for the silly value now in r10 and we try a second loop iteration.

That starts with the "movl   (%rbp,%r10,4), %esi" - but r10 now has a value
that can't be used.

So  I don't know if this is a new problem or an old problem that has been
exposed by changes in the RA .. 

.. if there's any easy way to amend the build process to attempt modifications
of the build flags to that file - this could give you a work-around in the
short term.

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

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #4)
> as ptr_returning_func() (a function reference with data pointer result) is a
> variable in the sense of the Fortran standard (F2018:R902)?

Do you think the following is the right thing?

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..2c34c2b6786 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1055,6 +1055,12 @@ variable_check (gfc_expr *e, int n, bool allow_proc)
  return true;
 }

+  /* F2018:R902: function pointer having a data pointer result.  */
+  if (e->expr_type == EXPR_FUNCTION
+  && e->symtree->n.sym->attr.flavor == FL_PROCEDURE
+  && e->symtree->n.sym->attr.pointer)
+return true;
+
   gfc_error ("%qs argument of %qs intrinsic at %L must be a variable",
 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
>where);


That is sort of independent of the other parts of the patch, but would be
needed for a full fix.

[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 8.3.0, 9.2.0
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-04-21
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Sebor  ---
Confirmed with GCC 11 and test case in comment #1.  Attribute
warn_unused_result does the right thing here.

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

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #50651|0   |1
is obsolete||

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 50652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50652=edit
WIP patch (corrected)

Oops, I attached the pre-WIP version...  Fixed now.

[Bug fortran/100196] New: [9/10/11/12 Regression] ICE in reduce_binary_ca, at fortran/arith.c:1364

[gscfq--- via Gcc-bugs]

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

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

Started with r8 (before 20180525) :


$ cat z1.f90
program p
   real, parameter :: a(0) = 0
   real :: b = 1 + [a]
end


$ cat z5.f90
program p
   real, parameter :: a(0) = 0
   real, parameter :: b(1) = 1 + [a]
end


$ gfortran-7 -c z5.f90
$
$ gfortran-7 -c z1.f90
z1.f90:3:12:

real :: b = 1 + [a]
1
Error: Incompatible ranks 0 and 1 in assignment at (1)


$ gfortran-11-20210418 -c z1.f90
f951: internal compiler error: Segmentation fault
0xc0b22f crash_signal
../../gcc/toplev.c:327
0x65083f reduce_binary_ca
../../gcc/fortran/arith.c:1364
0x6508d2 reduce_binary_ca
../../gcc/fortran/arith.c:1351
0x650b45 reduce_binary
../../gcc/fortran/arith.c:1434
0x650ddb eval_intrinsic
../../gcc/fortran/arith.c:1612
0x68cfba simplify_intrinsic_op
../../gcc/fortran/expr.c:1184
0x68cfba gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2237
0x6f7589 resolve_operator
../../gcc/fortran/resolve.c:4431
0x6f3a6f gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7098
0x68c184 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3094
0x68f460 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3142
0x67aa44 variable_decl
../../gcc/fortran/decl.c:2892
0x67aa44 gfc_match_data_decl()
../../gcc/fortran/decl.c:6201
0x6de9c3 match_word
../../gcc/fortran/parse.c:65
0x6de9c3 decode_statement
../../gcc/fortran/parse.c:376
0x6e040c next_free
../../gcc/fortran/parse.c:1316
0x6e040c next_statement
../../gcc/fortran/parse.c:1548
0x6e1a7b parse_spec
../../gcc/fortran/parse.c:3967
0x6e484c parse_progunit
../../gcc/fortran/parse.c:5896
0x6e5f41 gfc_parse_file()
../../gcc/fortran/parse.c:6437

[Bug fortran/100195] New: ICE in gimplify_expr, at gimplify.c:15095

[gscfq--- via Gcc-bugs]

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

Bug ID: 100195
   Summary: ICE in gimplify_expr, at gimplify.c:15095
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10 (between 20191215 and 20200105) :


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: a(:)
   !$acc update host(a)
end


$ gfortran-10-20191215 -c z1.f90 -fopenacc
z1.f90:5:21:

5 |!$acc update host(a)
  | 1
Error: ALLOCATABLE object 'a' of polymorphic type in MAP clause at (1)


$ gfortran-11-20210418 -c z1.f90 -fopenacc
z1.f90:5:23:

5 |!$acc update host(a)
  |   ^
internal compiler error: in gimplify_expr, at gimplify.c:15095
0x9aa933 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:15095
0x9aa593 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14204
0x9a2651 gimplify_scan_omp_clauses
../../gcc/gimplify.c:9430
0x9a7bf3 gimplify_omp_target_update
../../gcc/gimplify.c:13413
0x9a7bf3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14623
0x9aa978 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6877
0x9a8d33 gimplify_statement_list
../../gcc/gimplify.c:1879
0x9a8d33 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14528
0x9aa978 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6877
0x9aaed1 gimplify_bind_expr
../../gcc/gimplify.c:1421
0x9a85f2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14284
0x9aa978 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6877
0x9ab99d gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15320
0x9abdff gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15474
0x8480f7 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x84aa47 analyze_functions
../../gcc/cgraphunit.c:1236
0x84b40d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2510

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

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Created attachment 50651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50651=edit
WIP patch

This patch reuses variable_check() and as a bonus fixes the declarations
of the subroutine versions.  It also checks the length of the character
argument if known at compile time - it must not be 0.

It does not accept the testcase in comment#4.  This is possibly something
that could be handled in variable_check().

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

--- Comment #21 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #19)
> (In reply to lucier from comment #18)
> > I can't see to build mainline on this machine, it fails with

> Yeah, there have been some patches pushed in early to GCC12 that have
> destabilised things - I haven't tried to build master since Saturday (which
> was OK).

master should be OK after r12-50-ga44895ce7ffbc26b4d765c40b5b346f8c9a9b762
let me know if you still see problems.

[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351

[gscfq--- via Gcc-bugs]

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

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

Compiles these variants :


$ cat z2.f90
subroutine s(x)
   real, contiguous :: x(..)
   call t(x)
contains
   subroutine t(y)
  real :: y(..)
   end
end


$ cat z3.f90
subroutine s(x)
   real, contiguous :: x(..)
   call t(x)
contains
   subroutine t(y)
  real, contiguous :: y(..)
   end
end

[Bug fortran/100194] New: [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351

[gscfq--- via Gcc-bugs]

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

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

Changed between 20190113 and 20190120 :


$ cat z1.f90
subroutine s(x)
   real :: x(..)
   call t(x)
contains
   subroutine t(y)
  real, contiguous :: y(..)
   end
end


$ gfortran-9-20190113 -c z1.f90
$
$ gfortran-11-20210418 -c z1.f90
z1.f90:3:12:

3 |call t(x)
  |1
internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:1351
0x73d26a gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*,
tree_node*, tree_node*, bool, bool, bool, locus*)
../../gcc/fortran/trans-array.c:1351
0x7475d2 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5309
0x76bcee gfc_conv_subref_array_arg(gfc_se*, gfc_expr*, int, sym_intent, bool,
gfc_symbol const*, char const*, gfc_symbol*, bool)
../../gcc/fortran/trans-expr.c:4929
0x773875 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6450
0x7a95e8 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:424
0x739ad8 trans_code
../../gcc/fortran/trans.c:2000
0x75fd34 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6884
0x6e66b6 translate_all_program_units
../../gcc/fortran/parse.c:6351
0x6e66b6 gfc_parse_file()
../../gcc/fortran/parse.c:6620
0x7329cf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/100193] New: [9/10/11/12 Regression] ICE in alloc_scalar_allocatable_for_assignment, at fortran/trans-expr.c:10837

[gscfq--- via Gcc-bugs]

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

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

Started with r6 (z%g= is invalid, r5 compiles it) :


$ cat z1.f90
module m
   implicit none
   type t
  procedure(f), pointer, nopass :: g
   end type
contains
   function f()
  character(:), allocatable :: f
  f = 'abc'
   end
   subroutine s
  type(t) :: z
  z%g = 'x'
  if ( z%g() /= 'abc' ) stop
   end
end
program p
   use m
   implicit none
   call s
end


$ gfortran-5 -c z1.f90
$
$ gfortran-11-20210418 -c z1.f90
z1.f90:13:15:

   13 |   z%g = 'x'
  |   1
internal compiler error: Segmentation fault
0xc0b22f crash_signal
../../gcc/toplev.c:327
0x778bf2 alloc_scalar_allocatable_for_assignment
../../gcc/fortran/trans-expr.c:10837
0x778bf2 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11497
0x739707 trans_code
../../gcc/fortran/trans.c:1932
0x75fd34 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6884
0x739f79 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2332
0x6e61b1 translate_all_program_units
../../gcc/fortran/parse.c:6338
0x6e61b1 gfc_parse_file()
../../gcc/fortran/parse.c:6620
0x7329cf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug testsuite/100192] New: Typos in testsuite files, dg-options etc.

[gscfq--- via Gcc-bugs]

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

Bug ID: 100192
   Summary: Typos in testsuite files, dg-options etc.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

More findings :


Wrong letter "a" (third) : s/paramater/parameter/

./gcc/testsuite/gcc.dg/Warray-bounds-64.c:10:   { dg-options "-O2 -Wall
-Warray-parameter -Wno-vla-paramater" } */
./gcc/testsuite/gcc.dg/Warray-parameter.c:8:   { dg-options "-Wall
-Warray-parameter -Wno-vla-paramater" } */

./gcc/builtins.c:9989:   back to a BUILT_IN_STRCMP. Remember to delete the
3rd paramater
./gcc/d/dmd/expressionsem.c:4932:// lazy paramaters can be
called without violating purity and safety
./gcc/dwarf2out.c:23541:  /* Generate child dies for template paramaters.  */
./gcc/dwarf2out.c:25470:  /* Generate child dies for template paramaters.  */



Missing letter "u" : s/unqoted/unquoted/

./gcc/testsuite/gcc.dg/format/gcc_diag-11.c:378:  cdiag ("unqoted x_y ident"); 
/* { dg-warning "unquoted identifier or keyword 'x_y'" } */



Trivial : s/intrnisic/intrinsic/

 ./gcc/testsuite/gfortran.dg/matmul_bounds_9.f90:3:! { dg-shouldfail "Fortran
runtime error: Incorrect extent in argument B in MATMUL intrnisic for dimension
2: is 1, should be 2" }



No comment before dg-error (should start here with "!") :

./gcc/testsuite/gfortran.dg/array_constructor_3.f90:4:print *, (//)  {
dg-error "Empty array constructor" }
---
./gcc/testsuite/gfortran.dg/array_constructor_3.f90:4:print *, (//) ! {
dg-error "Empty array constructor" }

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #10 from Martin Liška  ---
> Yes, we do, support back to 4.8.x was part of the switch to C++11 language
> decision.

Can you please document that requirement?
I really don't get it, we decided to move to a more recent C++ standard, but we
still support a compiler with partial (or incomplete) support of the C++
standard.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
I reverted the commit in g:0a18305ee11e139838771f96c5a037a29606236e.

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||f4bug at amsat dot org

--- Comment #10 from Andrew Pinski  ---
*** Bug 100190 has been marked as a duplicate of this bug. ***

[Bug c/100190] warning on s390x: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 99578.

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

[Bug inline-asm/85185] Wider-than-expected load for struct member used as operand of inline-asm with memory clobber at -Og

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #11 from Andrew Pinski  ---
as mentioned in another bug, this is more of a documentation issue and the
internal details on how inline-asm works.

[Bug c/100190] warning on s390x: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

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

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

--- Comment #1 from Andrew Pinski  ---
#define S390EP 0x10008

memset((char *)S390EP, 0, 6);

[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93383

--- Comment #7 from Patrick Palka  ---
It looks like the pending PR93383 patch fixes these testcases as well.

[Bug inline-asm/100178] Should the “short” be promoted to “int” when use inline asm？

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |inline-asm
   Keywords||documentation

--- Comment #2 from Andrew Pinski  ---
>It's expected to generate 'lh'(sign extend), but 'lhu' (zero extend) actually.

I don't see why, the mode used here is HI mode, so the upper 16bits of the
32bit (or 48bits of 64bits) is undefined.  This is just like doing a (subreg:SI
(reg:HI)).

This should be documented instead of changed.  It is useful sometimes not to
need the upper bits to be defined (mostly with bit inserts).

[Bug other/100175] ICE in cp_parser_lookup_name, at cp/parser.c:28265

[mkaracsony81 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Miklos Karacsony  ---
I've played around with this gcc version and it looks like the ICE was caused
by a faulty glibc commit. As soon I've replaced glibc with the version I've
used before the ICE was gone. Please close this bug as INVALID as I'm unable to
reproduce this anymore.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #7)
> > The fact that something is in C++11 doesn't mean we can assume it in GCC,
> > while GCC 4.8.x which we still want to support had roughly complete C++11 FE
> > support, I think the libstdc++ side wasn't there yet.
> 
> Do we really support it? https://gcc.gnu.org/install/prerequisites.html
> mentions that an 'ISO C++11 compiler' is required.

Yes, we do, support back to 4.8.x was part of the switch to C++11 language
decision.

[Bug c++/91241] [8/9/10 Regression] internal compiler error: symtab_node::verify failed

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||xavier at cremaschi dot fr

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

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #6 from Marek Polacek  ---
Dup I think.

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

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

--- Comment #20 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #17)
> (In reply to lucier from comment #16)
> > I have figured out how to build and then run the app in lldb to reliably
> > reproduce the error.

> I will try later on 10.15,

... which does reproduce the fail as you describe.

- now it's interesting that different compilers fail in different places, and
different OS versions fail with different symptoms.

have to try an find a pattern to this.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

--- Comment #19 from Iain Sandoe  ---
(In reply to lucier from comment #18)
> I can't see to build mainline on this machine, it fails with
> 
> ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier
> 'TARGET_ISA_64BIT'
>   && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD)
>  ^
> ../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro
> 'BITS_PER_WORD'
> #define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD)
>^
> ../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from
> macro 'UNITS_PER_WORD'
> #define UNITS_PER_WORD  (TARGET_64BIT ? 8 : 4)
>  ^
> ../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from
> macro 'TARGET_64BIT'
> #define TARGET_64BIT TARGET_ISA_64BIT
> 
> 54 warnings and 1 error generated.
> make[3]: *** [build/genpreds.o] Error 1
> make[2]: *** [all-stage1-gcc] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2

Yeah, there have been some patches pushed in early to GCC12 that have
destabilised things - I haven't tried to build master since Saturday (which was
OK).

11.1 branch should be OK.

in the meantime - let see see if I can figure out how to fix master :(

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #18 from lucier at math dot purdue.edu ---
I can't see to build mainline on this machine, it fails with

../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier
'TARGET_ISA_64BIT'
  && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD)
 ^
../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro
'BITS_PER_WORD'
#define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD)
   ^
../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from macro
'UNITS_PER_WORD'
#define UNITS_PER_WORD  (TARGET_64BIT ? 8 : 4)
 ^
../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from macro
'TARGET_64BIT'
#define TARGET_64BIT TARGET_ISA_64BIT

54 warnings and 1 error generated.
make[3]: *** [build/genpreds.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

This is with

[Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline
5445da1a94b (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
[libstdc++] Add missing _M_try_acquire() to __platform_semaphore


and configuring with

78  13:51   ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline
--enable-languages=c --disable-multilib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk


and then make.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

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

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

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

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

commit r12-48-ga63035ae262078cd70927b06a2bd3ee94cc6e56e
Author: Martin Liska 
Date:   Mon Jan 11 18:12:54 2021 +0100

Call toplev::finalize in CHECKING_P mode.

gcc/ChangeLog:

PR jit/98615
* main.c (main): Call toplev::finalize in CHECKING_P mode.
* ipa-modref.c (ipa_modref_c_finalize): summaries are NULL
when incremental LTO linking happens.

[Bug ipa/100191] New: missed optimization for dead code elimination at -O3 (vs. -O2)

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

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

Bug ID: 100191
   Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[538] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210421 (experimental) [master revision
7f9b7ccf0c1:344da81f015:5445da1a94bb4df752209e54f4aa21702609a20a] (GCC)
[539] %
[539] % gcctk -O2 -S -o O2.s small.c
[540] % gcctk -O3 -S -o O3.s small.c
[541] %
[541] % wc O2.s O3.s
  38   73  629 O2.s
  48   96  769 O3.s
  86  169 1398 total
[542] %
[542] % grep foo O2.s
[543] % grep foo O3.s
jmp foo
[544] %
[544] % cat small.c
extern void foo(void);
static int a, b, d, *e;
int c(int f) { return f < 0 || a || f; }
static int *g() {
  int *l[24], j = 0;
  for (; j < 6; j++)
l[j] = 
  return l[0];
}
static inline int k() {
  long c[48] = {9};
  while (1)
if (c[b])
  return 0;
}
static void i() {
  k();
  e = g();
}
static void h(int f) {
  i();
  if (!f)
foo();
}
int main() {
  int m = c(1);
  h(m);
  return 0;
}

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #7 from Martin Liška  ---
> The fact that something is in C++11 doesn't mean we can assume it in GCC,
> while GCC 4.8.x which we still want to support had roughly complete C++11 FE
> support, I think the libstdc++ side wasn't there yet.

Do we really support it? https://gcc.gnu.org/install/prerequisites.html
mentions that an 'ISO C++11 compiler' is required.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #6 from Martin Liška  ---
Mine.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

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

--- Comment #8 from Jonathan Wakely  ---
I can only fix the case where the target  (in the build tree) is found
first and then its #include_next finds the host  (installed on the
host).

But that seems to be the case that's breaking the canadian cross build.

[Bug c/100190] New: warning on s390x: writing 1 byte into a region of size 0 [-Wstringop-overflow=]

[f4bug at amsat dot org via Gcc-bugs]

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

Bug ID: 100190
   Summary: warning on s390x: writing 1 byte into a region of size
0 [-Wstringop-overflow=]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f4bug at amsat dot org
  Target Milestone: ---

Using GCC 11.0.0 20210210 (Red Hat 11.0.0-0) on s390x host,
the following code [*] ...:

 22 static inline void *memset(void *s, int c, size_t n)
 23 {
 24 size_t i;
 25 unsigned char *p = s;
 26 
 27 for (i = 0; i < n; i++) {
 28 p[i] = c;
 29 }
 30 
 31 return s;
 32 }

... generates the following warning:

$ make -C pc-bios/s390-ccw
  CCASstart.o
  CC  main.o
In file included from pc-bios/s390-ccw/main.c:11:
In function ‘memset’,
inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   28 | p[i] = c;
  | ~^~~

[*]
https://gitlab.com/qemu-project/qemu/-/blob/master/pc-bios/s390-ccw/libc.h#L22

[Bug c/44677] Warn for variables incremented but not used

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||eyalroz1 at gmx dot com

--- Comment #11 from Joseph S. Myers  ---
*** Bug 100184 has been marked as a duplicate of this bug. ***

[Bug c/100184] Detect variables which are only "used" in updating themselves

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See bug 44677.

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

[Bug c++/100189] New: rejects valid conditional operators involving conversions to arrays of unknown bound (P0388)

[leni536 at gmail dot com via Gcc-bugs]

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

Bug ID: 100189
   Summary: rejects valid conditional operators involving
conversions to arrays of unknown bound (P0388)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

Version: g++ (Compiler-Explorer-Build) 12.0.0 20210420 (experimental)
Flags: -std=c++20  -O2 -pedantic-errors

Consider the following snippet:

```
void foo() {
auto ptr = true
? (int (*)[]) nullptr
: (int (*)[42]) nullptr;
}
```

https://godbolt.org/z/nKbzvaY3h

Since the third argument is convertible to the second argument, but not the
other way around, this should be accepted.

https://timsong-cpp.github.io/cppwp/n4861/expr.cond#4.3.3

Also consider the following snippet:

```
template 
using pointer_to = T*;

template 
using array_of_ub = T[];

template 
using array_of = T[N];

void foo() {
using t1 =
pointer_to<
array_of_ub<
pointer_to<
array_of<10,
int
;
using t2 =
pointer_to<
array_of<10,
pointer_to<
array_of_ub<
int
;
auto ptr = true
? (t1)nullptr
: (t2)nullptr;
}
```

https://godbolt.org/z/s1rnher9G

This should also be accepted following
https://timsong-cpp.github.io/cppwp/n4861/expr.cond#7.3 and
https://timsong-cpp.github.io/cppwp/n4861/expr.type#3.5 . I am a bit less sure
about this one, but I believe the type of `ptr` in this case should be
`pointer_to>>>` after applying
https://timsong-cpp.github.io/cppwp/n4861/conv.qual#3 and removing a redundant
`const`.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #5 from David Edelsohn  ---
For example, in GCC 6:

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)

namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION

  /**
   * @defgroup threads Threads
   * @ingroup concurrency
   *
   * Classes for thread support.
   * @{
   */

  /// thread
  class thread
  {

If we are going to support bootstrap with releases of GCC back to GCC 6 or GCC
4.8, the source code cannot assume that std::thread exists.

However, it's probably reasonable to assume hardware_concurrency of 1 when
compiling in a mode without GTHREADS.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #4 from Jonathan Wakely  ---
And opinions differ on whether "define it but make it useless" or "don't define
it" is the right answer.

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yeah, only GCC 10 and later seems to define std::thread in 
unconditionally, older releases made it conditional on #ifdef
_GLIBCXX_HAS_GTHREADS or on #if defined(_GLIBCXX_HAS_GTHREADS) &&
defined(_GLIBCXX_USE_C99_STDINT_TR1)

The fact that something is in C++11 doesn't mean we can assume it in GCC,
while GCC 4.8.x which we still want to support had roughly complete C++11 FE
support, I think the libstdc++ side wasn't there yet.

[Bug c/100178] Should the “short” be promoted to “int” when use inline asm？

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

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson  ---
This looks similar to 85185.  Same problem with a short type not working
correctly as an operand to an asm, and RISC-V is not the only target that the
code fails for.  I would suggest avoiding using char/short with an asm until
someone figures out how to fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185

[Bug c++/84476] [[nodiscard]] ignored on virtual functions accessed through pointer

[martin.ankerl at gmail dot com via Gcc-bugs]

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

Martin Ankerl  changed:

   What|Removed |Added

 CC||martin.ankerl at gmail dot com

--- Comment #1 from Martin Ankerl  ---
I just "discovered" this bug as well. The warning works correctly in g++ 6.4,
but starting from 7.1 upwards it does not work any more.

My reproducer which is very similar: 

struct Foo {
[[nodiscard]] virtual bool foo() { return true; };
virtual ~Foo() = default;
};


void shouldEmitWarning() {
auto* f = new Foo();
f->foo(); // <-- why no warning here?
delete f;
}

Godbolt link: https://godbolt.org/z/xqaPrshYn

[Bug tree-optimization/100188] New: missed optimization for dead code elimination at -O3 (vs. -O1)

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

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

Bug ID: 100188
   Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[529] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210421 (experimental) [master revision
7f9b7ccf0c1:344da81f015:5445da1a94bb4df752209e54f4aa21702609a20a] (GCC) 
[530] % 
[530] % gcctk -O1 -S -o O1.s small.c
[531] % gcctk -O3 -S -o O3.s small.c
[532] % 
[532] % wc O1.s O3.s
 14  31 324 O1.s
 35  72 615 O3.s
 49 103 939 total
[533] % 
[533] % grep foo O1.s
[534] % grep foo O3.s
jmp foo
[535] % 
[535] % cat small.c
extern void foo(void);
static int b = 1, c, *f;
static int a() { return 0; }
static void d(int j) {
  int g, *h[36] = {, }, **i[1] = {[0]};
  if (!j) {
c = 0;
foo();
  }
}
int main() {
  int k[8];
  d(b);
  if (a())
f = [0];
  return 0;
}

[Bug libstdc++/100187] ranges::search_n helper lambda misses forwarding return type

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
Or more consistent, just -> bool.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
The target build is finding the host libstdc++'s  which has the same
_GLIBCXX_FENV_H include guard, so when the target  does:

#include_next 

it doesn't do anything.

It might be necessary to do something simialr to what's in :

// Need to ensure this finds the C library's  not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

where the libstdc++  wrapper does:

#if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS
# include_next 
#else

#ifndef _GLIBCXX_STDLIB_H
#define _GLIBCXX_STDLIB_H 1

That ensures that we eventually reach the libc  and not just another
libstdc++ wrapper.

[Bug libstdc++/100187] ranges::search_n helper lambda misses forwarding return type

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
Same with is_permutation helper lambda __comp_scan in ranges_algo.h#L807:

auto __comp_scan = [&]  (_Tp&& __arg) {
  return std::__invoke(__pred, __proj_scan,
  std::forward<_Tp>(__arg));
};

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

--- Comment #2 from David Edelsohn  ---
Created attachment 50650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50650=edit
pre-processed source for lto-wrapper.c

[Bug libstdc++/100187] New: ranges::search_n helper lambda misses forwarding return type

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 100187
   Summary: ranges::search_n helper lambda misses forwarding
return type
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

ranges_algo.h#L565:

auto __value_comp = [&]  (_Rp&& __arg) {
  return std::__invoke(__pred, std::forward<_Rp>(__arg), __value);
};

__value_comp misses forwarding the return type (-> decltype(auto)) which made
the following unnecessary failed:

#include 

struct Bool {
  operator bool() { return true; };
  Bool() = default;
  Bool(const Bool&) = delete;
};

int main() {
  Bool b;
  std::vector v{1, 0};
  std::ranges::search_n(v, 1, 1, [&](auto, auto) -> Bool& { return b; });
}

https://godbolt.org/z/zjn8Gz3c5

[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Apr 21, 2021 at 03:48:24PM +, brtnfld at hdfgroup dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149
> 
> --- Comment #3 from Scot Breitenfeld  ---
> For future reference, gfortran 10.3.0 does not have this issue. I've updated
> the Known to work.
> 
> The bug report can be closed.
> 

Thanks for checking 10.3.0.  Apologies about the inconvenience.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #18 from David Edelsohn  ---
Because the _M_try_acquire patch was not yet committed to trunk when I tested
and bootstrap on trunk now is broken due to other, unrelated patches.

[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 10.4/11.

[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails

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

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

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

https://gcc.gnu.org/g:0c89b88daa8dffb956c77b4f22e914f42757f707

commit r10-9745-g0c89b88daa8dffb956c77b4f22e914f42757f707
Author: Patrick Palka 
Date:   Sat Sep 19 11:17:41 2020 -0400

c++: std::is_constant_evaluated inside constraint [PR97051]

According to [expr.const]/14, the result of substitution into an atomic
constraint is manifestly constant-evaluated; this patch adjusts the call
to maybe_constant_value in satisfy_atom to that effect.

gcc/cp/ChangeLog:

PR c++/97051
* constraint.cc (satisfy_atom): Pass true as the
manifestly_const_eval argument to maybe_constant_value.

gcc/testsuite/ChangeLog:

PR c++/97051
* g++.dg/cpp2a/is-constant-evaluated11.C: New test.

(cherry picked from commit dea470d09155f2007bdd502c16614128cb6f9348)

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-21
   Target Milestone|--- |12.0

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk by Philippe's patch. This is worth backporting after some time
to bake, but I don't expect problems given that isl already uses this solution.

[Bug c++/100185] transparent_union fails when the union has a destructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think the error is right and desirable.  Types with non-trivial ctors or
dtors need to be passed by invisible reference, so can't be passed the same as
the first union member.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

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

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

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

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

commit r12-46-gc2fc1702cb3a3d5cc9c40de47f63b4c8f3f1d09c
Author: Philippe Blain 
Date:   Fri Mar 12 19:26:46 2021 -0500

libstdc++: Install libstdc++*-gdb.py more robustly [PR 99453]

In order for GDB to auto-load the pretty printers, they must be installed
as "libstdc++.$ext-gdb.py", where 'libstdc++.$ext' is the name of the
object file that is loaded by GDB [1], i.e. the libstdc++ shared library.

The approach taken in libstdc++-v3/python/Makefile.am is to loop over
files matching 'libstdc++*' in $(DESTDIR)$(toolexeclibdir) and choose
the last file matching that glob that is not a symlink, the Libtool
'*.la' file or a Python file.

That works fine for ELF targets where the matching names are:

  libstdc++.a
  libstdc++.so
  libstdc++.so.6
  libstdc++.so.6.0.29

But not for macOS with:

  libstdc++.6.dylib
  libstdc++.a

Or MinGW with:

  libstdc++-6.dll
  libstdc++.dll.a

Try to make a better job at installing the pretty printers with the
correct name by copying the approach taken by isl [2], that is, using
a sed invocation on the Libtool-generated 'libstdc++.la' to read the
correct name for the current platform.

[1]
https://sourceware.org/gdb/onlinedocs/gdb/objfile_002dgdbdotext-file.html
[2] https://repo.or.cz/isl.git/blob/HEAD:/Makefile.am#l611

libstdc++-v3/ChangeLog:

PR libstdc++/99453
* python/Makefile.am: Install libstdc++*-gdb.py more robustly.
* python/Makefile.in: Regenerate.

Co-authored-by: Jonathan Wakely 

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

David Edelsohn  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Last reconfirmed||2021-04-21
 CC||mliska at suse dot cz
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/100186] New: lto-wrapper.c assumes std::thread

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

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

Bug ID: 100186
   Summary: lto-wrapper.c assumes std::thread
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

lto-wrapper.c:1288:37: error 'std::thread' has not been declared

unsigned long nthreads_var = std::thread::hardware_concurrency ();

[Bug c++/100185] New: transparent_union fails when the union has a destructor

[gonzalobg88 at gmail dot com via Gcc-bugs]

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

Bug ID: 100185
   Summary: transparent_union fails when the union has a
destructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalobg88 at gmail dot com
  Target Milestone: ---

Example:

union  __attribute__((transparent_union)) U {
int* a;
~U() {}
};

fails with:

:1:43: error: type transparent 'union U' cannot be made transparent 
because the type of the first field has a different ABI from the class
overall
1 | union  __attribute__((transparent_union)) U {
  |   ^

I think this should be allowed with the following semantics:

void f(int*);
void g(U&);
void h(U);
void j(int);

{
U u;
f(u); // passes U as int*
g(u); // passes U as U&
h(u); // ERROR: U does not have a copy constructor
j(u); // ERROR: cannot convert U to int

//~U() called at the end of the scope
}

[Bug c/100184] New: Detect variables which are only "used" in updating themselves

[eyalroz1 at gmx dot com via Gcc-bugs]

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

Bug ID: 100184
   Summary: Detect variables which are only "used" in updating
themselves
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

Consider the following C function:
```
int bar() 
{
int pow = 1;
return 1;
}
```
If we compile this with -Wall , GCC will warn us of having an unused variable.
If we write:
```
int bar() 
{
int pow = 1;
pow = 2;
return 1;
}
```
a different warning: Variable set but not used.

Now, suppose we write:
```
int bar() 
{
int pow = 1;
pow++;
return 1;
}
```
we will no longer get any warning. I believe GCC should warn in this case; or
at least - there should be a flag which makes it warn when a variable is used
only in updating itself.

[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL

[brtnfld at hdfgroup dot org via Gcc-bugs]

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

Scot Breitenfeld  changed:

   What|Removed |Added

  Known to work||10.3.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Scot Breitenfeld  ---
For future reference, gfortran 10.3.0 does not have this issue. I've updated
the Known to work.

The bug report can be closed.

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

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

Untested patch for this particular peephole2.  But, 1) I'm not sure it is 100%
safe even for spill slots 2) I don't know what to do with the remaining 7
peephole2s
I'm afraid during peephole2 pass we don't have anything comparable to RTL DSE
infrastructure, and unfortunately the last RTL DSE2 pass is 5 passes before
peephole2.  So matching these insn sequences e.g. could be done in some machine
specific pass before RTL DSE2 instead of peephole2 and let RTL DSE2 optimize
away what seems unnecessary, or use some patterns that RTL DSE2 would recognize
on its own.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

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

--- Comment #6 from Jonathan Wakely  ---
>From IRC:

It works if I add -nostdinc++ manually to the compile line that fails then I
don't get the error

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

--- Comment #2 from Jakub Jelinek  ---
In addition to r7-1112 r8-3856 also added some similar peephole2s.
I'm afraid I'm getting lost in them, in several other peephole2s there the
store that is optimized away is an atomic store and that is quite certainly not
a spill slot.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #17 from Iain Sandoe  ---
(In reply to lucier from comment #16)
> I have figured out how to build and then run the app in lldb to reliably
> reproduce the error.

> To configure and build Gambit, the Scheme->C compiler:
> 
> 51  8:56mkdir gambit-test
> 52  8:56cd gambit-test
> 53  8:56git clone https://github.com/gambit/gambit.git

$ git log -1 --oneline
bb05af0a (HEAD -> master, origin/master, origin/HEAD) Fix missing return
address when using (declare (not optimize-dead-local-variables) (not
interrupts-enabled))

> 54  8:57cd gambit
> 55  9:00./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps
> -g' '--enable-single-host' '--enable-shared'

> Hope this helps.

[so far on Darwin16 / macOS 10.12 ]

Yes it does -  can confirm that a 10.2 build works and 10.3 fails but the error
I get is different:

$ DYLD_LIBRARY_PATH=lib:gsi:gsc gsi/gsi
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Bus error: 10

lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x1000a88f0)
frame #0: 0x0001000a3475
libgambit.dylib`___release_rc(ptr=0x0001000a8900) at mem.c:724
   721  {
   722___rc_header *h = ___CAST(___rc_header*,ptr) - 1;
   723  
-> 724if (--h->refcount == 0)
   725  {
   726___rc_header *prev = h->prev;

I will try later on 10.15,

[Bug target/98143] arm: missed vectorization with MVE compared to Neon

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

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

--- Comment #1 from Christophe Lyon  ---
Current trunk generates for MVE:

ldr r3, .L3+16  @ 5 [c=12 l=4]  *thumb2_movsi_vfp/5
vldr.64 d6, .L3 @ 7 [c=8 l=4]  *mve_movv8hi/8
vldr.64 d7, .L3+8
ldr r3, [r3]@ 14[c=12 l=4]  *thumb2_movsi_vfp/5
mov r2, r3  @ 17[c=4 l=2]  *thumb2_movsi_vfp/0
addsr3, r3, #16 @ 18[c=4 l=2]  *thumb2_addsi_short/1
vstrh.16q3, [r2]@ 8 [c=8 l=4] 
*movmisalignv8hi_mve_store
vstrh.16q3, [r3]@ 11[c=8 l=4] 
*movmisalignv8hi_mve_store
bx  lr  @ 45[c=8 l=4]  *thumb2_return
.L4:
.align  3
.L3:
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
r12-44 and r11-8275

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #16 from Thomas Rodgers  ---
The _M_try_acquire() change should be on master and gcc-11 now.

[Bug c++/96380] [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in tree check: expected |tree check: expected
   |integer_cst, have   |integer_cst, have
   |view_convert_expr in|view_convert_expr in
   |get_len, at tree.h:5954 |get_len, at tree.h:5954

--- Comment #8 from Marek Polacek  ---
Fixed on trunk (GCC 12) so far.  Will backport to 11.2 and 10.4.  Note: The
patch uses auto, needs tweaking before backporting to 10.

[Bug c++/96380] [10/11/12 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

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

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

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

https://gcc.gnu.org/g:001c63d15e31bc0a1545426d889a0b9f671b4961

commit r12-42-g001c63d15e31bc0a1545426d889a0b9f671b4961
Author: Marek Polacek 
Date:   Tue Apr 20 12:16:04 2021 -0400

c++: Don't allow defining types in enum-base [PR96380]

In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'.  That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.

When we have something sneaky like this, which is broken in multiple
ways:

  template 
  enum struct c : union enum struct c { e = b, f = a };

we parse the "enum struct c" part (that's OK) and then we see that
we have an enum-base, so we consume ':' and then parse the type-specifier
that follows the :.  "union enum" is clearly invalid, but we're still
parsing tentatively and we parse everything up to the ;, and then
throw away the underlying type.  We parsed everything because we were
tricked into parsing an enum-specifier in an enum-base of another
enum-specifier!  Not good.

Since the grammar for enum-base doesn't allow a defining-type-specifier,
only a type-specifier, we should set type_definition_forbidden_message
which fixes all the problems in this PR.

gcc/cp/ChangeLog:

PR c++/96380
* parser.c (cp_parser_enum_specifier): Don't allow defining
types in enum-base.

gcc/testsuite/ChangeLog:

PR c++/96380
* g++.dg/cpp0x/enum_base4.C: New test.
* g++.dg/cpp0x/enum_base5.C: New test.

[Bug c++/100172] ICE with "concept concept" keyword

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/99332] ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #1 from Alex Coplan  ---
Confirmed on trunk. I can't reproduce it on GCC 10.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Christophe Lyon from comment #2)
> On trunk, the error message is:
> FAIL: experimental/net/internet/address/v6/members.cc (test for excess
> errors)
> Excess errors:
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/
> thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:602:
> error: '__fdvec' is not a member of
> 'std::experimental::net::v1::io_context::__reactor'

Thanks, that's a completely different error (and must have been there since
February when the test was added).

That error will happen for any target without , and I would expect it
to also happen for all the other experimental/net/* tests too.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

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

https://gcc.gnu.org/g:34976f3bf8ff146e31b1ccee9351c5803604d7ae

commit r9-9454-g34976f3bf8ff146e31b1ccee9351c5803604d7ae
Author: Jonathan Wakely 
Date:   Wed Apr 21 15:48:02 2021 +0100

libstdc++: Disable test for non-gthreads targets [PR 100180]

The Networking TS code still requires std::mutex on this branch, so the
tests shouldn't run on targets without gthreads.

PR libstdc++/100180
* testsuite/experimental/net/internet/address/v6/members.cc:
Require gthreads.

(cherry picked from commit f0d22d31ceb1373f17045f2527ef2f2251d93be8)

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

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

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

commit r10-9744-gf0d22d31ceb1373f17045f2527ef2f2251d93be8
Author: Jonathan Wakely 
Date:   Wed Apr 21 15:48:02 2021 +0100

libstdc++: Disable test for non-gthreads targets [PR 100180]

The Networking TS code still requires std::mutex on this branch, so the
tests shouldn't run on targets without gthreads.

PR libstdc++/100180
* testsuite/experimental/net/internet/address/v6/members.cc:
Require gthreads.

[Bug c++/94475] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10+.  I reckon this isn't worth backporting since it's just an
error-recovery ICE.

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #9 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #8)
> (In reply to Tobias Burnus from comment #7)
> > (I could not reproduce the LLVM 9 issue in PR94278 back then.)
> 
> Hmm, but didn't you say in the LLVM issue
>  that you _did_ reproduce this 
> back then?

I partially mixed it up - I could not reproduce it with a self-build LLVM but
could do so with the distro LLVM ones.

Our/my LLVM bug 45887 is similar to
https://bugs.llvm.org/show_bug.cgi?id=41914, which was fixed by
https://reviews.llvm.org/D79943 and the latter adds the check which causes the
error message: "undefined label '.L33'"

However, the other bug (41914) and the the testcase in the fix (D79943) were
about a label which was truly missing as opposed to one which is just in a
differently named .section.

 * * *

Obviously, with D79943 at place (LLVM 11, 12, ...), I can reproduce the issue
with -O2 (with < -O0 there is only .text) as then 's_branch .L33' is in
.section .text but '.L33:' is in '.section .text.unlikely'.

Whether it is intended that cross-.section s_branch are no longer permitted or
whether it happened by chance by this patch or on purpose, I don't know.

Sections themselves are supported – and the  LVM testsuite for GCN has
testcases with '.section' (under llvm/test/MC/AMDGPU/*.s) – but in the
testsuite one at a time.

GCC guards the .text.unlikely generation by (→ varasm.c's
default_function_section) by

  if (!flag_reorder_functions
  || !targetm_common.have_named_sections)
return NULL;

while the patch in PR 94278 comment 3 uses
   flag_reorder_blocks_and_partition = 0

[Bug fortran/100183] New: Segmentation fault at runtime when passing an internal procedure as argument

[jellby at yahoo dot com via Gcc-bugs]

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

Bug ID: 100183
   Summary: Segmentation fault at runtime when passing an internal
procedure as argument
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jellby at yahoo dot com
  Target Milestone: ---

I've only been able to reproduce it with:

$ uname -a
Darwin minimac.moose.housegordon.com 20.3.0 Darwin Kernel Version 20.3.0: Thu
Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 arm64

$ gfortran -version
GNU Fortran (Homebrew GCC 10.2.0_4) 10.2.1 20201220


Compiling and running the following code works fine, but with -O1 it gives a
segmentation fault. Alternatively, undefining INTERNAL_PROC_ARG works with -O1.


$ cat test.F90
#define INTERNAL_PROC_ARG  
   
  [45/90681]

module sorting
implicit none
private
public :: argsort
real, pointer :: mod_rV(:)

interface
logical pure function compare_int_t(a, b)
integer, intent(in) :: a, b
end function
end interface

contains

logical pure function my_compare_rV(x, y)
integer, intent(in) :: x, y
my_compare_rV = mod_rV(x) <= mod_rV(y)
end function

function argsort(V) result(idx)
real, target, intent(inout) :: V(:)
integer :: idx(lbound(V, 1):ubound(V, 1)), i

idx = [(i, i = lbound(V, 1), ubound(V, 1))]

#   ifdef INTERNAL_PROC_ARG
call sort(idx, my_compare)
#   else
mod_rV => V
call sort(idx, my_compare_rV)
#   endif

contains
logical pure function my_compare(x, y)
integer, intent(in) :: x, y
my_compare = V(x) <= V(y)
end function
end function argsort

subroutine sort(A, compare)
integer, intent(inout) :: A(:)
procedure(compare_int_t) :: compare
integer :: i, j, t
do i = lbound(A, 1), ubound(A, 1)
  do j = i + 1, ubound(A, 1)
if (.not. compare(A(i), A(j))) then
t = A(i)
A(i) = A(j)
A(j) = t
end if
  end do
end do
end subroutine sort
end module sorting

program test
use sorting, only: argsort

implicit none
integer :: i
integer, parameter :: seed(50) = [(i, i = 1, size(seed))]
real :: lambdas(5)
integer :: idx(size(lambdas))

call random_seed(put=seed)
call random_number(lambdas)

write(6,*) 'Before sorting:'
write(6,*) lambdas(:)
idx(:) = argsort(lambdas)
write(6,*) 'Argsort:'
write(6,*) idx(:)
write(6,*) 'Sorted:'
write(6,*) lambdas(idx(:))
end program test


$ gfortran -O1 test.F90 -o test ; ./test   
 Before sorting:
  0.471070886  0.117344737  0.357547939  0.318134785 
0.696753800
zsh: segmentation fault  ./test


$ gfortran -O0 test.F90 -o test ; ./test
 Before sorting:
  0.471070886  0.117344737  0.357547939  0.318134785 
0.696753800
 Argsort:
   2   4   3   1   5
 Sorted:
  0.117344737  0.318134785  0.357547939  0.471070886 
0.696753800

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #2 from Christophe Lyon  ---
On trunk, the error message is:
FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:602:
error: '__fdvec' is not a member of
'std::experimental::net::v1::io_context::__reactor'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677:
error: 'struct std::experimental::net::v1::io_context::__reactor' has no member
named 'wait'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677:
error: '__fds' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:679:
error: '_S_retry' is not a member of
'std::experimental::net::v1::io_context::__reactor'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:682:
error: '_S_timeout' is not a member of
'std::experimental::net::v1::io_context::__reactor'
[...]

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|11.0|10.4

--- Comment #10 from Patrick Palka  ---
Fixed for GCC 10.4/11.

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:4806f9157a26cfd66c083bcc01596ff33009c0d6

commit r10-9743-g4806f9157a26cfd66c083bcc01596ff33009c0d6
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:41 2020 -0400

c++: alias_ctad_tweaks and constrained dguide [PR95486]

In the below testcase, we're ICEing from alias_ctad_tweaks ultimately
because the implied deduction guide for X's user-defined constructor
already has constraints associated with it.  We then carry over these
constraints to 'fprime', the overlying deduction guide for the alias
template Y, via tsubst_decl from alias_ctad_tweaks.  Later in
alias_ctad_tweaks we call get_constraints followed by set_constraints
without doing remove_constraints in between, which triggers the !found
assert in set_constraints.

This patch fixes this issue by adding an intervening call to
remove_constraints.

gcc/cp/ChangeLog:

PR c++/95486
* pt.c (alias_ctad_tweaks): Call remove_constraints before
calling set_constraints.

gcc/testsuite/ChangeLog:

PR c++/95486
* g++.dg/cpp2a/class-deduction-alias3.C: New test.

(cherry picked from commit 71141b1bd537cc516e485c834c2d36abba3f4544)

[Bug libstdc++/100179] [12 regression] xtreme-header-2_a.H fails on arm-eabi

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

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

--- Comment #2 from Jonathan Wakely  ---
I have a patch for this.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #1 from Jonathan Wakely  ---
I think I need to backport another piece.

This should not have happened on trunk though.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #15 from Thomas Rodgers  ---
>From the most recent patch -

+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+  for (;;)
+   {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+   continue;
+ else if (__err && (errno == EAGAIN))
+   return false;
+ else if (__err)
+   std::terminate();
+ else
+   break;
+   }
+  return true;
+}
+

You are correct it was never exercised. I saw then when I forced it in the test
case and then added the above. I don't understand why you are seeing this error
if you've applied the 0001-libstdc-Work-around-for-PR100164 patch. I don't see
it locally.

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

--- Comment #1 from Jakub Jelinek  ---
In this particular case it is the sync.md:398 peephole2:
(define_peephole2
  [(set (match_operand:DF 0 "memory_operand")
(match_operand:DF 1 "any_fp_register_operand"))
   (set (mem:BLK (scratch:SI))
(unspec:BLK [(mem:BLK (scratch:SI))] UNSPEC_MEMORY_BLOCKAGE))
   (set (match_operand:DF 2 "fp_register_operand")
(unspec:DF [(match_operand:DI 3 "memory_operand")]
   UNSPEC_FILD_ATOMIC))
   (set (match_operand:DI 4 "memory_operand")
(unspec:DI [(match_dup 2)]
   UNSPEC_FIST_ATOMIC))]
  "!TARGET_64BIT
   && peep2_reg_dead_p (4, operands[2])
   && rtx_equal_p (XEXP (operands[0], 0), XEXP (operands[3], 0))"
  [(const_int 0)]
{
  emit_insn (gen_memory_blockage ());
  emit_move_insn (gen_lowpart (DFmode, operands[4]), operands[1]);
  DONE;
})
that triggers here but from what I can read, all the r7-1112 peephole2s
optimize away stores to some memory on the assumption that the memory is read
only once (in another insn matched by the same peephole2).
I'm not 100% sure if we can rely for it on spill slots for which r7-112 seems
to have been written, but for other memory we'd need to prove that the memory
is dead.
Rather than removing those peephole2s altogether, I wonder if we just shouldn't
check that the memory_operand which we'd optimize away stores to aren't spill
slots.

[Bug libstdc++/97600] [ranges] satisfaction value of range affected by prior use of basic_istream_view::begin()

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |10.4
 Resolution|--- |FIXED

--- Comment #6 from Patrick Palka  ---
The library side workaround is in place for GCC 10.4 and 11, and GCC 11
additionally has a frontend optimization for ruling out unviable conversion ops
sooner which alone is sufficient to fix the PR.  I suppose we could revert the
library-side workaround for GCC 11/12 then, but it seems harmless to keep
around.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #14 from David Edelsohn  ---
Thanks for the patch. This now removes the failure that semaphore_impl is not
found.

Because the platform semaphore code never was exercised due to the bug in the
macro, there are more latent bugs.

/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/semaphore:74: error:
'using
 __semaphore_impl = struct std::__platform_semaphore' has no member named
'_M_tr
y_acquire'; did you mean '_M_acquire'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/semaphore:75: error:
'using
 __semaphore_impl = struct std::__platform_semaphore' has no member named
'_M_tr
y_acquire'; did you mean '_M_acquire'?

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

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

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

--- Comment #8 from Richard Biener  ---
The patch from comment#3 fixes the issue for me.  The tests still fail one or
another way (most not finding libgfortran.a - maybe an error on my side, and
a few with unresolved symbols).

[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions

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

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

--- Comment #4 from Alex Coplan  ---
Fixed on trunk. Keeping open for backports (once it's had some decent baking
time).