[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g

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

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

--- Comment #2 from Sam James  ---
Created attachment 54955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54955=edit
a-FetchTypes.ii.xz

I noticed the filename was 'Unified...' so I tried out
https://firefox-source-docs.mozilla.org/build/buildsystem/unified-builds.html
to disable unified builds and got something a *little bit* smaller
(a-FetchTypes.ii).

I'm going to try reduce this one instead, but let pinskia carry on with the
original. It might well reduce to 2 quite different things.

[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction

--- Comment #1 from Andrew Pinski  ---
Confirmed, reducing it too.

[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
   Keywords||ice-on-valid-code

[Bug c++/109677] [11/12/13/14 Regression] Access control bypass for function template default argument brace initialization of private default constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Access control bypass for   |[11/12/13/14 Regression]
   |function template default   |Access control bypass for
   |argument brace  |function template default
   |initialization of private   |argument brace
   |default constructor |initialization of private
   ||default constructor
   Target Milestone|--- |11.4
  Known to work||10.1.0, 10.4.0, 7.1.0,
   ||8.1.0, 9.1.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-29
  Known to fail||11.1.0

--- Comment #1 from Andrew Pinski  ---
Confirmed a regression from GCC 10.x.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Adelson Oliveira  ---
I'm a linux user and gfortran comes with my distro. I mean, I did not compile
gcc.
Is this patch still to be tested? Am I expected to do something to test it? Or
I just wait until a new gfortran version is released?

Thanks for the attention in the bug.

[Bug c++/109677] New: Access control bypass for function template default argument brace initialization of private default constructor

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 109677
   Summary: Access control bypass for function template default
argument brace initialization of private default
constructor
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

gcc accepts-invalid:

struct B { private: B(); };
template int f(T = {});
int i = f();

This is mostly a curiosity, but it came up while trying to understand why a
misuse of the passkey pattern was seemingly working.

[Bug rtl-optimization/109676] New: [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g

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

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

Bug ID: 109676
   Summary: [13/14 regression] ICE in simplify_subreg, at
simplify-rtx.cc:7426 when building firefox with -O2
-march=alderlake -g
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Originally reported downstream in Gentoo at https://bugs.gentoo.org/905262.

Unfortunately, the original reproducer is too big even compressed, so it's at
http://dev.gentoo.org/~sam/bugs/gcc/gcc-firefox-alderlake-x86/Unified_cpp_dom_fetch1.ii.xz.
I'm working on a reduction now.

```
$ g++-13 -march=alderlake -O2 -g -c Unified_cpp_dom_fetch1.ii
[...]
during RTL pass: vartrack
Unified_cpp_dom_fetch1.ii: In static member function ‘static
mozilla::Maybe
IPC::ParamTraits::Read(IPC::MessageReader*)’:
Unified_cpp_dom_fetch1.ii:183311:1: internal compiler error: in
simplify_subreg, at simplify-rtx.cc:7426
183311 | }
   | ^
0xb99b70 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/simplify-rtx.cc:7426
0x1f4e111 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/simplify-rtx.cc:7715
0x20c4a01 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<1u, unsigned long>)
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/rtl.h:3535
0x20c4a01 vt_expand_loc_callback
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8524
0x208b8b1 cselib_expand_value_rtx_1
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1953
0x20c3b4b vt_expand_var_loc_chain
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1836
0x20c459b vt_expand_loc_callback
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8583
0x208b4ec cselib_expand_value_rtx_1
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1988
0x20c3b4b vt_expand_var_loc_chain
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1836
0x20c459b vt_expand_loc_callback
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8583
0x20c3b4b vt_expand_var_loc_chain
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1836
0x20c459b vt_expand_loc_callback
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8583
0x208b4ec cselib_expand_value_rtx_1
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1988
0x20c3b4b vt_expand_var_loc_chain
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/cselib.cc:1836
0x20c2f94 vt_expand_1pvar
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8696
0x20c2f94 emit_note_insn_var_location(variable**, emit_note_data*)
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:8750
0x20804fc void hash_table::traverse_noresize(emit_note_data*)
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/hash-table.h:1173
0x20804fc void hash_table::traverse(emit_note_data*)
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/hash-table.h:1194
0x20804fc emit_notes_for_changes
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:9110
0x207e49d emit_notes_in_bb
   
/usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/var-tracking.cc:9544
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug modula2/109675] New: GCC 13.1: the Modula-2 front-end fails to build on some platforms

[gr.audio at gmail dot com via Gcc-bugs]

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

Bug ID: 109675
   Summary: GCC 13.1: the Modula-2 front-end fails to build on
some platforms
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gr.audio at gmail dot com
  Target Milestone: ---

Happens on any platform on which the 'long unsigned int' type can't hold
a pointer (for instance: Windows/mingw64).

The culprit is this:

../../gcc-13.1.0/gcc/m2/mc-boot/GDynamicStrings.cc: In function 'void
writeAddress(void*)':
../../gcc-13.1.0/gcc/m2/mc-boot/GDynamicStrings.cc:909:18: error: cast from
'void*' to 'long unsigned int' loses precision [-fpermissive]
  909 |   writeLongcard ((long unsigned int ) (a));
  |  ^~~~

Casting a pointer to a 'long unsigned int' is not exactly portable.

[Bug tree-optimization/107087] [12 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz

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

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

--- Comment #15 from Sam James  ---
(In reply to Jonathan Wakely from comment #14)
> I think it should be fine. I would prefer to wait until 12.4 so it has more
> bake time, but that would just mean another few months of duplicate reports
> for this issue.

After chatting with jwakely, this is now on releases/gcc-12 as
r12-9486-g47880309516fd5 and we're rolling it out (the latest 12 snap) in
Gentoo. I expect everything will be fine but if it's not, you'll obviously hear
:)

[Bug target/109657] (a ? -1 : 0) | b could be optimized better for aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-April/6
   ||17108.html
   Keywords||patch

--- Comment #2 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617108.html

[Bug sanitizer/109674] [14 Regression] linking with libhwasan is now broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug sanitizer/109674] New: [14 Regression] linking with libhwasan is now broken

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

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

Bug ID: 109674
   Summary: [14 Regression] linking with libhwasan is now broken
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

After the sanitizer merge, all of the hwsasan testcases are failing with a link
failure:

/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::HasReportedLeaks()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::DoLeakCheck()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::DisableInThisThread()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::DisabledInThisThread()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::DoRecoverableLeakCheckVoid()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::EnableInThisThread()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::Flags::SetDefaults()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::InitCommonLsan()'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::RegisterLsanFlags(__sanitizer::FlagParser*,
__lsan::Flags*)'^M
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/aarch64-unknown-linux-gnu/./libsanitizer/hwasan/.libs/libhwasan.so:
undefined reference to `__lsan::lsan_flags'^M

[Bug c/109673] warn_unused_result warnings are incorrect (and/or missing) and vary when -Os is specified

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Parke from comment #2)
> 
> I compile my code with -Wall -Wextra and -Werror.  Consequently, in order to
> get my code to compile (on Ubuntu), I have to write the following:
> 
> void * discard = getcwd ( s, sizeof s );
> (void) discard;
> 
> Instead of the more readable:
> 
> (void) getcwd ( s, sizeof s );
> 
> Your thoughts?  Thanks!

That is PR 66425 but really you should not avoiding the return value here
because getcwd will return NULL on failure as defined by POSIX.

[Bug c/109673] warn_unused_result warnings are incorrect (and/or missing) and vary when -Os is specified

[parke.nexus at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Parke  ---
Thank you for the explanation.

It seems to me that it would (should?) be possible for -Os to detect the
cast-to-void and therefore suppress the second warning (line 5).

It also seems to me the above change, if implemented, would be an improvement
from the user's point of view (i.e. from my point of view).

I compile my code with -Wall -Wextra and -Werror.  Consequently, in order to
get my code to compile (on Ubuntu), I have to write the following:

void * discard = getcwd ( s, sizeof s );
(void) discard;

Instead of the more readable:

(void) getcwd ( s, sizeof s );

Your thoughts?  Thanks!

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #11 from Jeffrey A. Law  ---
Coming back to this.

WRT extension elimination.  I've been pondering if we want a late pass to do a
bit of this that can't be handled by REE.

So let's take the case of a Zbs instruction operating on a variable bit in
RV64.

I think we can probably agree that in the absence of additional information we
can't do those kind of bit manipulations because we could potentially change
bit 31 and have the result escape as a parameter to a function call, return
value or get used in a compare type instruction.


So to make use of the Zbs instructions that manipulate a variable bit we could
could emit a suitable sign extension after each such operation.  That, of
course, has the potential to be expensive.

But if we chase down the uses we can probably eliminate a lot of these
extensions.  Essentially we need to know if the extension reaches a comparison,
one of the ABI escape points or a real 64bit operation.  If not, then the
extension is unnecessary and can be dropped.

Ideally we'd find that a significant number of extensions could be dropped.

We're not actively working on this, but it is something rattling around in the
empty space between my ears.

[Bug c/109673] warn_unused_result warnings are incorrect (and/or missing) and vary when -Os is specified

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
So __wur is defined based on if there are optimizations turned on or not based
on if you also define _FORTIFY_SOURCE (ubuntu compilers default to defining
_FORTIFY_SOURCE).

So from a GCC point of view, this is not a GCC bug.

[Bug c/109673] New: warn_unused_result warnings are incorrect (and/or missing) and vary when -Os is specified

[parke.nexus at gmail dot com via Gcc-bugs]

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

Bug ID: 109673
   Summary: warn_unused_result warnings are incorrect (and/or
missing) and vary when -Os is specified
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: parke.nexus at gmail dot com
  Target Milestone: ---

When I compile the below sample program without -Os, I expect one warning but
receive zero warnings.

When I compile the below sample program with -Os, I expect one warning but
receive two warnings.

#include  
char  s[80];
int  main  ()  {
  ;   getcwd ( s, sizeof s );//  I expect a warning.
  (void)  getcwd ( s, sizeof s );//  I expect no warning.   
  return  0;  }

Compilation output:

$ gcc -o /tmp/getcwd test.c
[Compilation succeeds without any output.]

$ gcc -Wall -Wextra -o /tmp/getcwd test.c
[Compilation succeeds without any output.]

$ gcc -Wunused-result -o /tmp/getcwd test.c
[Compilation succeeds without any output.]

$  gcc -Os -o /tmp/getcwd test.c
test.c: In function ‘main’:
test.c:4:11: warning: ignoring return value of ‘getcwd’ declared with attribute
‘warn_unused_result’ [-Wunused-result]
4 |   ;   getcwd ( s, sizeof s );//  I expect a warning.
  |   ^~
test.c:5:11: warning: ignoring return value of ‘getcwd’ declared with attribute
‘warn_unused_result’ [-Wunused-result]
5 |   (void)  getcwd ( s, sizeof s );//  I expect no warning.
  |   ^~


Possibly related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389

Tested on Ubuntu 23.04 with gcc 12.2.0.  I believe Ubuntu 22.04 with gcc 11.3.0
behaves identically.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.2.0-17ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-Pa930Z/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-Pa930Z/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Ubuntu 12.2.0-17ubuntu1)

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 108219 Summary: [12 Regression] requirement fails on a valid expression 
since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219

   What|Removed |Added

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

[Bug c++/108219] [12 Regression] requirement fails on a valid expression since r12-5253-g4df7f8c79835d569

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 12.3+, thanks for the bug report.

[Bug c++/106969] [12 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 12.3+, thanks for the bug report.

[Bug c++/106969] [12 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

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

https://gcc.gnu.org/g:458bda5432d352469e258f1c0e4c2a37c853575a

commit r12-9493-g458bda5432d352469e258f1c0e4c2a37c853575a
Author: Patrick Palka 
Date:   Fri Mar 24 14:51:24 2023 -0400

c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype() wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

PR c++/106969

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
C++98 mode.
* g++.dg/lookup/this2.C: New test.

(cherry picked from commit bbf2424c57c2e13d1a972c4ef4e871c3119b9cb4)

[Bug c++/108218] [12/13/14 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569

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

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

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

https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672

commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka 
Date:   Wed Mar 1 14:09:37 2023 -0500

c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a difference
here since the array sizes are constant literals, except they're expressed
as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which
used to get stripped as part of constant evaluation and now no longer do.
Moreover it means build_vec_init can't constant fold the MINUS_EXPR
'maxindex' passed from build_new_1 when in an unevaluated context (since
it tries reducing it via maybe_constant_value called with mce_unknown).

This patch fixes these issues by making maybe_constant_value (and
fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant
operand via fold(), as long as it simplifies to a simple constant, rather
than doing no simplification at all.  This covers e.g. simple arithmetic
and casts including stripping of location wrappers around INTEGER_CST.

In passing, this patch also fixes maybe_constant_value to avoid constant
evaluating an unevaluated operand when called with mce_false, by adjusting
the early exit test appropriately.

Co-authored-by: Jason Merrill 

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (fold_to_constant): Define.
(maybe_constant_value): Move up early exit test for unevaluated
operands.  Try reducing an unevaluated operand to a constant via
fold_to_constant.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
to a constant via fold_to_constant.
* cp-tree.h (fold_to_constant): Declare.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.

(cherry picked from commit 096f034a8f5df41f610e62c1592fb90a3f551cd5)

[Bug c++/108219] [12 Regression] requirement fails on a valid expression since r12-5253-g4df7f8c79835d569

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

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

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

https://gcc.gnu.org/g:73e86b6766cc92aa8c18cc987bf95929c4ea0672

commit r12-9492-g73e86b6766cc92aa8c18cc987bf95929c4ea0672
Author: Patrick Palka 
Date:   Wed Mar 1 14:09:37 2023 -0500

c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a difference
here since the array sizes are constant literals, except they're expressed
as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which
used to get stripped as part of constant evaluation and now no longer do.
Moreover it means build_vec_init can't constant fold the MINUS_EXPR
'maxindex' passed from build_new_1 when in an unevaluated context (since
it tries reducing it via maybe_constant_value called with mce_unknown).

This patch fixes these issues by making maybe_constant_value (and
fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant
operand via fold(), as long as it simplifies to a simple constant, rather
than doing no simplification at all.  This covers e.g. simple arithmetic
and casts including stripping of location wrappers around INTEGER_CST.

In passing, this patch also fixes maybe_constant_value to avoid constant
evaluating an unevaluated operand when called with mce_false, by adjusting
the early exit test appropriately.

Co-authored-by: Jason Merrill 

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (fold_to_constant): Define.
(maybe_constant_value): Move up early exit test for unevaluated
operands.  Try reducing an unevaluated operand to a constant via
fold_to_constant.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
to a constant via fold_to_constant.
* cp-tree.h (fold_to_constant): Declare.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.

(cherry picked from commit 096f034a8f5df41f610e62c1592fb90a3f551cd5)

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[romain.geissler at amadeus dot com via Gcc-bugs]

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

--- Comment #31 from Romain Geissler  ---
Ok thanks for confirming. I was about to ask for a deployment one of our
gcc-based toolchain in production containing the current gcc 13.1.1, I will
wait a bit that this patch lands in the gcc 13 branch then. And in the future I
will pay more attention to newly added symbols/gnu versions in minor version of
libstdc++ why deploying new toolchains then ;)

[Bug libfortran/109662] bad namelist input but gfortran accepted it

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
   Last reconfirmed||2023-04-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
I also interpret F2018:13.11.3.1 that a value-separator may follow only
a name-value subsequence but not immediately the namelist-group-name.
This is also what other brands (NAG, Intel, Nvidia) accept.

Thus confirmed.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

--- Comment #30 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #28)
> In other words, in general, is there any guarantee that something built
> using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ?

No. There have been several times where that was not possible:
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++/manual/manual/abi.html#abi.versioning.history

e.g. 7.2.0 had new symbols not present in 7.1.0, and 9.2.0 and 9.3.0 both
introduced new symbols compared to the previous release.

[Bug c++/109654] unnecessary "cannot bind packed field to reference" error when referenced type has aligned(1) attribute

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

--- Comment #2 from Richard Smith  ---
Hm, that doesn't explain why the second example I gave is accepted. But I
suppose what's happening there is probably just that the `packed` attribute is
ignored entirely for fields with alignment 1, so this behaves the same as

```
packed_int i;
int  = i;
```

... which indeed doesn't produce an error or even a warning, presumably for the
same reason (the alignment isn't part of the canonical type of i).

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 54954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54954=edit
Patch (2nd try)

This one works and regtests ok.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[romain.geissler at amadeus dot com via Gcc-bugs]

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

--- Comment #29 from Romain Geissler  ---
Typo: If yes, given that you also maintain the gcc package in fedora 38
(https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that
something built in some future up to date Fedora 38 won't run on an old
"unpatched"/"not up to date" fedora 38 ?

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #28 from Romain Geissler  ---
Hi,

Sorry to jump here, but I wish to clarify something.

If I understood the commit message/diff correctly, I expect that this commit
will eventually land in the gcc 13 branch, not just in master, right ? So let's
imagine gcc 13.2.0 is released with this, it will mean that a binary (including
) built with gcc 13.2.0 won't be runnable with the runtime of gcc
13.1.0 ? If yes, given that you also maintain the gcc package in fedora 38
(https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that
something build in some future up to date Fedora 38 won't build on an old
"unpatched" fedora 38 ?

In other words, in general, is there any guarantee that something built using
gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ? (I am not
speaking about mixing gcc 13 with gcc 12, but point releases of gcc 13).

Cheers,
Romain

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866 since r14-295-gd89e23f27215fc

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

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

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Richard Biener from comment #6)
> Should be fixed now.

I confirm it fixed valgrind-3.20.0 build as well. Thank you!

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Christoph Reiter  ---
Everything seems to be dynamically linked to libgcc, I'm out of ideas.

[Bug c++/109651] [13/14 Regression] ICE in lookup_template_class

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension

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

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

--- Comment #4 from Jeffrey A. Law  ---
If we need to handle subregs here, I would suggest something like this

if (SUBREG_P (XEXP (op0, 0))
&& subreg_lowpart_p (op0)
... other tests ...

That way we know we're extracting the low word of the subreg.  But I'm not sure
at all why we need to handle them in this code.  I would expect generic
optimizers to strip away the subregs in the result if they are extraneous.

It's not clear why you check the size of the subreg modes.  It seems like this
optimization should work even for a paradoxical subreg (bitsize of inner will
be smaller than bitsize of outer).  

In general if you only have one statement in an arm of an IF-THEN-ELSE, then it
need not be inside a { } block.

Rather than using magic numbers like

INTVAL (op1) + 8 == 32

Instead use mode information.

INTVAL (op) + GET_MODE_BITSIZE (QImode) == GET_MODE_BITSIZE (SImode)
// code for QI->SI expansion

Then repeat for the other mode combinations.

Note that we probably should go ahead and support QI->HI.  While it doesn't
happen for RISC-V, it could likely happen on other architectures.  So you end
up wanting to supprot

QI->HI, QI->SI QI->DI
HI->SI, HI->DI
SI->DI

I don't know if it happens in practice, so check first to see what we do for a
zero extension variant of your original test.  If we need to handle that too,
it can be easily done by changing the shifts we recognize.

Anyway, it looks like you're on the right track.  I would suggest further
discussions happen on gcc-patches.


Anyway, it definitely looks like you're on the right track.

[Bug c++/109671] Spurious dangling reference warning in GCC 13

[lopresti at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Patrick J. LoPresti  ---
Um... OK...

So I have to "correct" my code like so:

const Foo (bool x)
{
  const std::string s = (x ? "x" : "y");
  const Foo  = get_foo_by_name(s);
  return f;
}

But if get_foo_by_name() has the problem GCC is worried about, this does not
even fix it.

This warning seems silly to me. "I cannot tell if you are managing lifetimes
properly, so I will just recommend you do not use temporaries"?

Const references have always bound to temporaries. This warning seems to be
discouraging that (?)

[Bug other/109672] [14 regression] many ICEs after r14-323-g977a43f5ba778b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|[143 regression] many ICEs  |[14 regression] many ICEs
   |after   |after
   |r14-323-g977a43f5ba778b |r14-323-g977a43f5ba778b

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Christoph Reiter  ---
This looks very much like bug 108202 though, so I'll see if I can find
something.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christoph Reiter  ---
(In reply to Christoph Reiter from comment #1)
> [...] I'll try building without that.

That didn't make a difference sadly.

[Bug other/109672] New: [143 regression] many ICEs after r14-323-g977a43f5ba778b

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

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

Bug ID: 109672
   Summary: [143 regression] many ICEs after
r14-323-g977a43f5ba778b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:977a43f5ba778b5c5cf9c56ba04ed4fde5d1ae78, r14-323-g977a43f5ba778b

FAIL: gcc.dg/vect/bb-slp-layout-17.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/vect/bb-slp-layout-17.c (test for excess errors)
FAIL: gcc.dg/vect/bb-slp-layout-17.c -flto -ffat-lto-objects  3 blank line(s)
in output
FAIL: gcc.dg/vect/bb-slp-layout-17.c -flto -ffat-lto-objects (internal compiler
error: verify_gimple failed)
FAIL: gcc.dg/vect/bb-slp-layout-17.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/bb-slp-layout-17.c 3 blank line(s) in output
FAIL: gcc.dg/vect/pr103864.c (internal compiler error: verify_gimple failed)
FAIL: gcc.dg/vect/pr103864.c (test for excess errors)
FAIL: gcc.dg/vect/pr103864.c -flto -ffat-lto-objects  15 blank line(s) in
output
FAIL: gcc.dg/vect/pr103864.c -flto -ffat-lto-objects (internal compiler error:
verify_gimple failed)
FAIL: gcc.dg/vect/pr103864.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/pr103864.c 15 blank line(s) in output
FAIL: gcc.dg/vect/pr52252-ld.c (internal compiler error: verify_gimple failed)
FAIL: gcc.dg/vect/pr52252-ld.c (test for excess errors)
FAIL: gcc.dg/vect/pr52252-ld.c -flto -ffat-lto-objects  6 blank line(s) in
output
FAIL: gcc.dg/vect/pr52252-ld.c -flto -ffat-lto-objects (internal compiler
error: verify_gimple failed)
FAIL: gcc.dg/vect/pr52252-ld.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/pr52252-ld.c 6 blank line(s) in output
FAIL: gcc.dg/vect/slp-perm-9.c (internal compiler error: verify_gimple failed)
FAIL: gcc.dg/vect/slp-perm-9.c (test for excess errors)
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects  2 blank line(s) in
output
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects (internal compiler
error: verify_gimple failed)
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/slp-perm-9.c 2 blank line(s) in output
FAIL: gcc.dg/vect/vect-alias-check-10.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/vect/vect-alias-check-10.c (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects  4 blank
line(s) in output
FAIL: gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects (internal
compiler error: verify_gimple failed)
FAIL: gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects (test for
excess errors)
FAIL: gcc.dg/vect/vect-alias-check-10.c 4 blank line(s) in output
FAIL: gcc.dg/vect/vect-alias-check-11.c (internal compiler error: verify_gimple
failed)
FAIL: gcc.dg/vect/vect-alias-check-11.c (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  4 blank
line(s) in output
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 2[)]* is outside
\\(-4, 4\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 2[)]* is outside
\\(-6, 6\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 2[)]* is outside
\\(-8, 8\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 4[)]* is outside
\\(-12, 12\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 4[)]* is outside
\\(-16, 16\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 4[)]* is outside
\\(-8, 8\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 8[)]* is outside
\\(-16, 16\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 8[)]* is outside
\\(-24, 24\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "no alias between [^\\n]* when [^\\n]* step[^ ]* \\* 8[)]* is outside
\\(-32, 32\\)"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "run-time check [^\\n]* abs \\([^*]* \\* 2[)]* >= 8"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  scan-tree-dump
vect "run-time check [^\\n]* abs \\([^*]* \\* 4[)]* >= 16"
FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects  

[Bug c++/109671] Spurious dangling reference warning in GCC 13

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

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

--- Comment #1 from Andrew Pinski  ---
There is no way for GCC to know that get_foo_by_name does not store the
argument into what is returned so it warns about this case ...

[Bug c++/109671] New: Spurious dangling reference warning in GCC 13

[lopresti at gmail dot com via Gcc-bugs]

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

Bug ID: 109671
   Summary: Spurious dangling reference warning in GCC 13
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com
  Target Milestone: ---

#include 

struct Foo;

extern Foo _foo_by_name(const std::string );

const Foo (bool x)
{
  const Foo  = get_foo_by_name(x ? "x" : "y");
  return f;
}

---

Compile with "-O2 -Wall" to get the incorrect warning:

: In function 'const Foo& bug(bool)':
:9:14: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
9 |   const Foo  = get_foo_by_name(x ? "x" : "y");
  |  ^
:9:33: note: the temporary was destroyed at the end of the full
expression 'get_foo_by_name(std::__cxx11::basic_string(((const char*)(x ?
"x" : "y")), std::allocator()))'
9 |   const Foo  = get_foo_by_name(x ? "x" : "y");
  |  ~~~^~~

--

Godbolt: https://godbolt.org/z/cn4W7ohGb

The code is fine. (And no other compiler warns about this, including earlier
GCC versions.)

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617071.html

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Reiter  ---
Could this be another case of exceptions being broken, as indicated here
https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ?
I see some "-static-libgcc" in the ada Makefile.in. I'll try building without
that.

[Bug target/105525] some targets don't define __INTPTR_TYPE__ breaking libgcov-driver.c

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
The issue issue remains in gcc-13.1.0 but is no longer limited to gcov, i.e. a
vax build with --disable-gcov using gcc-13.1.0 now fails with

In file included from
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde-dip.c:579:
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:45:9: error:
unknown type name '__UINTPTR_TYPE__'
   45 | typedef __UINTPTR_TYPE__ uintptr_type;
  | ^~~~
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c: In function
'classify_object_over_fdes':
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:777:28: warning:
comparison of integer expressions of different signedness: '_Unwind_Ptr' {aka
'unsigned int'} and 'uintptr_type' {aka 'int'} [-Wsign-compare]
  777 |   if (pc_begin < range[0])
  |^
/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/unwind-dw2-fde.c:779:26: warning:
comparison of integer expressions of different signedness: '_Unwind_Ptr' {aka
'unsigned int'} and 'uintptr_type' {aka 'int'} [-Wsign-compare]
  779 |   if (pc_end > range[1])
  |  ^
make[2]: *** [/mnt/scratch/cross/sources/gcc-13.1.0/libgcc/static-object.mk:17:
unwind-dw2-fde-dip.o] Error 1
make[2]: Leaving directory '/tmp/objdir-gcc-vax/vax-unknown-linux/libgcc'
make[1]: *** [Makefile:12865: all-target-libgcc] Error 2
make[1]: Leaving directory '/tmp/objdir-gcc-vax'
make: *** [Makefile:1020: all] Error 2

lm32 is similar.

I will submit a patch shortly.

[Bug ada/109670] New: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 109670
   Summary: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES
compilation error on 32bit Windows starting with GCC
13
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Updating from 12.2.0 to 13.1.0 we are encountering build errors for all ada
packages on 32bit Windows, all failing with something like:

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error

I've reduced one ada example that fails down to:

```
with GNAT.Spitbol.Patterns;
procedure Broken is
   M : GNAT.Spitbol.Patterns.Match_Result;
   type Header_Symbol is (None, Name, Attr, Conv, Prag);
begin
   null;
end Broken;
```

With GCC 12.2.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb
gnatbind -x broken.ali
gnatlink broken.ali

```

With GCC 13.1.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error
```

If there is any more info that I can provide or things I can try out please let
me know.

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #12 from Marek Polacek  ---
I suppose we should add a porting_to.html note about this (in light of Bug
109663).

[Bug other/109650] avr-gcc incorrect code with -Os

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|target  |other

--- Comment #4 from Georg-Johann Lay  ---
Set component to "other" until we know what component actually causes this bug.

[Bug target/109650] avr-gcc incorrect code with -Os

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-04-28
 Status|UNCONFIRMED |NEW

--- Comment #3 from Georg-Johann Lay  ---
Confirmed with "gcc version 14.0.0 20230420 (experimental) (GCC)"

[Bug target/109650] avr-gcc incorrect code with -Os

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 54953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54953=edit
Full C test case that doesn't require hardware like UART.

This testcase tests against the code as generated by avr-gcc-8.5 -Os. It should
work for all AVR devices including reduced tiny like ATtiny40, thus eligible
for

testsuite/gcc.target/avr/torture

Pairs that produce different results with avr-gcc v14 (current master). are:

p1,p2 = 3,6;  4,6;  5,4;  6,4  and  7,2.

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

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

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

--- Comment #9 from Jonathan Wakely  ---
Oh sorry, it showed as FIXED here but I must have changed it myself by
accident.

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
> Please don't close bugs as FIXED

I did choose INVALID, was that not correct?

[Bug libstdc++/67791] [10 Regression] Crash using std::thread and iostream with dynamic loading of a shared library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
Fixed for 10.5 and up.

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||carlosgalvezp at gmail dot com

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

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Carlos Galvez from comment #0)
> > getting a handful of errors in this type of code compiling in C++14 mode:
> 
> But the Eigen example has been rejected since r13-6765
> 
>  c++: explicit ctor and list-initialization [PR109159]

Which means this is a dup of bug 109247.

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

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Jonathan Wakely  ---
N.B. Please don't close bugs as FIXED when nothing was fixed in GCC. There are
other resolutions to use when the bug report is invalid, e.g. INVALID.

But in this case I'm not actually sure what the right behaviour is, maybe Marek
can take a look.

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed fully at r14-337-gc43819a9b4cdaa7359e55 .

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Carlos Galvez from comment #0)
> getting a handful of errors in this type of code compiling in C++14 mode:

But the Eigen example has been rejected since r13-6765

 c++: explicit ctor and list-initialization [PR109159]

[Bug tree-optimization/100958] two_value_replacement should move to match.pd

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |14.0
   Keywords||internal-improvement
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Andrew Pinski  ---
Fixed.

[Bug target/109636] [14 Regression] ICE: in paradoxical_subreg_p, at rtl.h:3205 with -O -mcpu=a64fx

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

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> Ugh.  I guess we've got no option but to force the original
> subreg into a fresh register, but that's going to pessimise
> cases where arithmetic is done on tuple types.
> 
> Perhaps we should just expose the SVE operation as a native
> V2DI one.  Handling predicated ops would be a bit more challenging
> though.

I did try a copy_to_mode_reg to a fresh V2DI register for non-REG_P arguments
and that did progress, but (surprisingly?) still ICEd during fwprop:
during RTL pass: fwprop1
mulice.c: In function 'foom':
mulice.c:17:1: internal compiler error: in paradoxical_subreg_p, at rtl.h:3205
   17 | }
  | ^
0xe903b9 paradoxical_subreg_p(machine_mode, machine_mode)
$SRC/gcc/rtl.h:3205
0xe903b9 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
$SRC/gcc/simplify-rtx.cc:7533
0xe1b5f7 insn_propagation::apply_to_rvalue_1(rtx_def**)
$SRC/gcc/recog.cc:1176
0xe1b3d8 insn_propagation::apply_to_rvalue_1(rtx_def**)
$SRC/gcc/recog.cc:1118
0xe1b7b7 insn_propagation::apply_to_rvalue_1(rtx_def**)
$SRC/gcc/recog.cc:1254
0xe1babf insn_propagation::apply_to_pattern_1(rtx_def**)
$SRC/gcc/recog.cc:1361
0xe1bae4 insn_propagation::apply_to_pattern(rtx_def**)
$SRC/gcc/recog.cc:1383
0x1c22e5b try_fwprop_subst_pattern
$SRC/gcc/fwprop.cc:454
0x1c22e5b try_fwprop_subst
$SRC/gcc/fwprop.cc:627
0x1c239a9 forward_propagate_and_simplify
$SRC/gcc/fwprop.cc:823
0x1c239a9 forward_propagate_into
$SRC/gcc/fwprop.cc:886
0x1c23bc1 fwprop_insn
$SRC/gcc/fwprop.cc:943
0x1c23d98 fwprop
$SRC/gcc/fwprop.cc:995
0x1c240e1 execute
$SRC/gcc/fwprop.cc:1033
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

fwprop ended up creating:
(mult:VNx2DI (subreg:VNx2DI (reg/v:V2DI 95 [ v ]) 0)
(subreg:VNx2DI (subreg:V2DI (reg/v:OI 97 [ w ]) 16) 0))

and something blew up anyway, so it seems the RTL passes *really* don't like
these kind of subregs ;)
I'll look into expressing these ops as native V2DI patterns. I guess for the
unpredicated SVE2 mul that's easy, but for the predicated forms perhaps we can
have them consume a predicate register, generated at expand time, similar to
the  aarch64-sve.md expanders. Not super-pretty but maybe it'll be enough

[Bug tree-optimization/100958] two_value_replacement should move to match.pd

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-338-g1dd154f6407658d46faa4d21bfec04fc2551506a
Author: Andrew Pinski 
Date:   Tue Apr 25 19:46:40 2023 -0700

PHIOPT: Move two_value_replacement to match.pd

This patch converts two_value_replacement function
into a match.pd pattern.
It is a direct translation with only one minor change,
does not check for the {0,+-1} case as that is handled
before in match.pd so there is no reason to do the extra
check for it.

OK? Bootstrapped and tested on x86_64-linux-gnu with
no regressions.

gcc/ChangeLog:

PR tree-optimization/100958
* tree-ssa-phiopt.cc (two_value_replacement): Remove.
(pass_phiopt::execute): Don't call two_value_replacement.
* match.pd (a !=/== CST1 ? CST2 : CST3): Add pattern to
handle what two_value_replacement did.

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Another test:

#include 

template 
struct Point
{
 private:
T value_[n]{};
};

struct Edge
{
Point start{};
Point end{};
};

template 
class StaticVector
{
 public:
static StaticVector create()
{
StaticVector output;
return output;
}

 private:
std::array data{};
};

class Polygon
{
 public:
using Edges = StaticVector;
Edges edges() const
{
auto edges = Edges::create();
return edges;
}
};

void foo()
{
Polygon polygon{};
auto const edges = polygon.edges();
}

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||carlosgalvezp at gmail dot com

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

[Bug c++/109669] Internal Compiler Error when zero-initializing std::array

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with 

commit 041a164ec9b467f9ac2f15980f83f17e3f8ea150
Author: Jason Merrill 
Date:   Sat Mar 18 08:27:26 2023 -0400

c++: DMI in template with virtual base [PR106890]

so I think it's a dup.

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

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Carlos Galvez  ---
Sounds great, thanks for the quick response! I believe "-Wall -Wextra" is the
"bare minimum" set of warnings for most projects so I'm afraid people might
still need to disable it via "-Wno*".

Adding some [[gcc::whatever]] attribute sounds like a very interesting
approach, I believe Clang has a similar thing.

It's not really a blocker since we can just disable it, I'm just sad to have to
do it since I believe it's a really good warning to have!

[Bug c++/109669] New: Internal Compiler Error when zero-initializing std::array

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 109669
   Summary: Internal Compiler Error when zero-initializing
std::array
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi,

We are getting an ICE when bumping from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
cc035c5d8672f87dc8c2756d9f8367903aa72d93 (GCC 13.1.0 release) on the following
reduced example:

#include 

template 
struct Point
{
 private:
T value_[n]{};
};

struct Edge
{
Point start{};
Point end{};
};

template 
class StaticVector
{
 public:
static StaticVector create()
{
StaticVector output;
return output;
}

 private:
std::array data{};
};

class Polygon
{
 public:
using Edges = StaticVector;
Edges edges() const
{
auto edges = Edges::create();
return edges;
}
};

void foo()
{
Polygon polygon{};
auto const edges = polygon.edges();
}

Godbolt: https://godbolt.org/z/183zv1xrK

Error:
: In instantiation of 'constexpr StaticVector::StaticVector()':
:22:22:   required from 'static StaticVector StaticVector::create() [with T = Edge; long unsigned int n = 3]'
:36:35:   required from here
:27:22: internal compiler error: Segmentation fault
   27 | std::array data{};
  |  ^~~~
0x234da0e internal_error(char const*, ...)
???:0
0xccea48 finish_for_cond(tree_node*, tree_node*, bool, unsigned short)
???:0
0xb7bad3 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int,
vec**)
???:0
0xce5cfb expand_vec_init_expr(tree_node*, tree_node*, int, vec**)
???:0
0xd200c1 digest_nsdmi_init(tree_node*, tree_node*, int)
???:0
0xb813b7 maybe_instantiate_nsdmi_init(tree_node*, int)
???:0
0xb819f9 get_nsdmi(tree_node*, bool, int)
???:0
0xba932d get_defaulted_eh_spec(tree_node*, int)
???:0
0xc76d4a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xc76b5a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xb5c2b3 mark_used(tree_node*, int)
???:0
0xa9931e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xa9a4c7 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xb7d468 build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0xb4c768 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0xc80395 instantiate_decl(tree_node*, bool, bool)
???:0
0xcab7fb instantiate_pending_templates(int)
???:0
0xb5f735 c_parse_final_cleanups()
???:0
0xd8f918 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

I tried to reduce it with creduce but creduce itself crashed :/

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Carlos Galvez  changed:

   What|Removed |Added

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

--- Comment #4 from Carlos Galvez  ---
Thanks, I wasn't aware of that! Then it seems GCC is doing the right thing and
I can close this bug, appreciate the quick responses!

[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:650c36ec461a722d9c65e82512b4c3aeec2ffee1

commit r14-335-g650c36ec461a722d9c65e82512b4c3aeec2ffee1
Author: Roger Sayle 
Date:   Fri Apr 28 14:21:53 2023 +0100

PR rtl-optimization/109476: Use ZERO_EXTEND instead of zeroing a SUBREG.

This patch fixes PR rtl-optimization/109476, which is a code quality
regression affecting AVR.  The cause is that the lower-subreg pass is
sometimes overly aggressive, lowering the LSHIFTRT below:

(insn 7 4 8 2 (set (reg:HI 51)
(lshiftrt:HI (reg/v:HI 49 [ b ])
(const_int 8 [0x8]))) "t.ii":4:36 557 {lshrhi3}
 (nil))

into a pair of QImode SUBREG assignments:

(insn 19 4 20 2 (set (subreg:QI (reg:HI 51) 0)
(reg:QI 54 [ b+1 ])) "t.ii":4:36 86 {movqi_insn_split}
 (nil))
(insn 20 19 8 2 (set (subreg:QI (reg:HI 51) 1)
(const_int 0 [0])) "t.ii":4:36 86 {movqi_insn_split}
 (nil))

but this idiom, SETs of SUBREGs, interferes with combine's ability
to associate/fuse instructions.  The solution, on targets that
have a suitable ZERO_EXTEND (i.e. where the lower-subreg pass
wouldn't itself split a ZERO_EXTEND, so "splitting_zext" is false),
is to split/lower LSHIFTRT to a ZERO_EXTEND.

To answer Richard's question in comment #10 of the bugzilla PR,
the function resolve_shift_zext is called with one of four RTX
codes, ASHIFTRT, LSHIFTRT, ZERO_EXTEND and ASHIFT, but only with
LSHIFTRT can the setting of low_part and high_part SUBREGs be
replaced by a ZERO_EXTEND.  For ASHIFTRT, we require a sign
extension, so don't set the high_part to zero; if we're splitting
a ZERO_EXTEND then it doesn't make sense to replace it with a
ZERO_EXTEND, and for ASHIFT we've played games to swap the
high_part and low_part SUBREGs, so that we assign the low_part
to zero (for double word shifts by greater than word size bits).

2023-04-28  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/109476
* lower-subreg.cc: Include explow.h for force_reg.
(find_decomposable_shift_zext): Pass an additional SPEED_P
argument.
If decomposing a suitable LSHIFTRT and we're not splitting
ZERO_EXTEND (based on the current SPEED_P), then use a ZERO_EXTEND
instead of setting a high part SUBREG to zero, which helps combine.
(decompose_multiword_subregs): Update call to resolve_shift_zext.

gcc/testsuite/ChangeLog
PR rtl-optimization/109476
* gcc.target/avr/mmcu/pr109476.c: New test case.

[Bug libstdc++/40380] class documentation should mention include file to use

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

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

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

https://gcc.gnu.org/g:7bd8a81f39e084d43c6701afb6203510b5fe69a2

commit r13-7264-g7bd8a81f39e084d43c6701afb6203510b5fe69a2
Author: Jonathan Wakely 
Date:   Wed Apr 26 22:48:35 2023 +0100

libstdc++: Add @headerfile and @since to doxygen comments [PR40380]

libstdc++-v3/ChangeLog:

PR libstdc++/40380
* include/bits/basic_string.h: Improve doxygen comments.
* include/bits/cow_string.h: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/fs_dir.h: Likewise.
* include/bits/fs_path.h: Likewise.
* include/bits/quoted_string.h: Likewise.
* include/bits/stl_bvector.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_multimap.h: Likewise.
* include/bits/stl_multiset.h: Likewise.
* include/bits/stl_set.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* include/bits/unordered_map.h: Likewise.
* include/bits/unordered_set.h: Likewise.
* include/std/filesystem: Likewise.
* include/std/iomanip: Likewise.

(cherry picked from commit 865869dc6943eb5dee855bc1ea88b09b7dabc641)

[Bug libgomp/109646] OpenACC attach directive fails with "pointer target not mapped for attach"

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109622
 Status|UNCONFIRMED |WAITING
 CC||burnus at gcc dot gnu.org,
   ||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Last reconfirmed||2023-04-28

--- Comment #2 from Thomas Schwinge  ---
This sounds as if it may've been fixed (for GCC master branch) via today's
PR109622 "[OpenACC] internal compiler error: in omp_group_base, at
gimplify.cc:9412 if -fopenacc is set" commit
r14-325-gcacf65d74463600815773255e8b82b4043432bd7 "OpenACC: Stand-alone
attach/detach clause fixes for Fortran [PR109622]"?  Please check.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2023-04-28
 Status|UNCONFIRMED |ASSIGNED

--- Comment #5 from Marek Polacek  ---
(In reply to Carlos Galvez from comment #4)
> While I can do that on my own code, I cannot add that suppression on
> third-party code, like Eigen (which I also get a lot of false positives in
> similar code), even if I include the header via -isystem - since the
> warnings are on the client side.
> 
> Is this really the expected behavior of a warning belonging to -Wall? Has
> this warning been tested on large projects to evaluate the false positive
> rate?

Yes, we've compiled a whole distro and the false positive rate was actually
surprisingly low, except now that GCC 13 was released it seems the
std::span-like false positives are actually a big deal.  :(  So...

> Would you consider perhaps reducing the scope of the warning in order to
> reduce the false positive rate, alternatively move it out of Wall?

...I think I'll have to move it to -Wextra (for GCC 13.2).  Considering any
class with a T* member a std::span-like class would probably diminish the
warning too much.  Maybe we need a [[gcc::whatever]] attribute to mark a class
as a reference-wrapper-like.

> It's sad that a lot of work and effort was put into creating this warning
> and it will just probably be disabled on most projects. When a tool produces
> a lot of false positives, there is high risk that developers stop trusting
> the tool and true positives are ignored.

Indeed.  I'm sorry about the trouble you've had with the warning.  I can
certainly understand why it's frustrating.

[Bug ipa/108040] -fdevirtualize causes part of function to be missing in output

[alvin at alvinhc dot com via Gcc-bugs]

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

--- Comment #2 from Alvin Wong  ---
Thanks for trying to look into the issue. The error you got looks like an
effect of
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=87235f1e5c740de9c6f72a5dd7d7eb9cb7df2e1d
that is not in GCC 12. I guess I can retest with GCC 13 but I don't have it
yet, so it will have to wait.

On simplifying the test case, I'm guessing I probably can't do much about that,
but, uh, I can maybe give it a try some time (no promises).

[Bug other/109668] New: 'python' vs. 'python3'

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

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

Bug ID: 109668
   Summary: 'python' vs. 'python3'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

In GCC sources, there exist a number of Python scripts that invoke 'python'
(for example, 'contrib/dg-extract-results.sh'), or '/usr/bin/python' (for
example, 'contrib/dg-extract-results.py').

Now, in my new Ubuntu 22.04 "jammy" installation, '/usr/bin/python' doesn't
exist anymore, but only '/usr/bin/python3'.

Do we intend to adjust all GCC's Python scripts to handle this scenario in some
generic way, or do we continue to require 'python' for GCC?

The latter may, for example, be achieved with Debian/Ubuntu package
python-is-python3:

[...]
Description: symlinks /usr/bin/python to python3
 Starting with the Debian 11 (bullseye) and Ubuntu 20.04 LTS (focal)
 releases, all python packages use explicit python3 or python2
 interpreter and do not use unversioned /usr/bin/python at all. Some
 third-party code is now predominantly python3 based, yet may use
 /usr/bin/python.
[...]

Conversely, the already exist a number of explicitly 'python3' instances in GCC
sources, too.

---

I noticed this via the shell version 'contrib/dg-extract-results.sh' producing
different results than the Python version 'contrib/dg-extract-results.py' that
I had been using before (via 'contrib/dg-extract-results.sh' invoking it), but
no longer due to no 'python' executable being available anymore.

[Bug libstdc++/67791] [10 Regression] Crash using std::thread and iostream with dynamic loading of a shared library

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

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

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

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

commit r10-11325-ge2babb0540cfa66752214f3f111461e1da4b26ce
Author: Jonathan Wakely 
Date:   Tue Nov 24 12:48:31 2020 +

libstdc++: Throw instead of segfaulting in std::thread constructor [PR
67791]

This turns a mysterious segfault into an exception with a more useful
message. If the exception isn't caught, the user sees this instead of
just a segfault:

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not
permitted
Aborted (core dumped)

libstdc++-v3/ChangeLog:

PR libstdc++/67791
* src/c++11/thread.cc (thread::_M_start_thread(_State_ptr, void
(*)())):
Check that gthreads is available before calling __gthread_create.

(cherry picked from commit 4bbd5d0c5fb2b7527938ad44a6d8a2f2ef8bbe12)

[Bug tree-optimization/109667] [12/13/14 Regression] Unnecessary temporary storage used for 32-byte struct

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-28
   Priority|P3  |P2

--- Comment #1 from Richard Biener  ---
Confirmed.  We end up with

void assign (struct i256 * v, long int z)
{
  struct i256 r;

   [local count: 536870913]:
  MEM  [(struct i256 *) + 8B] = {};
  r.v[0] = z_8(D);
  *v_5(D) = r;
  r ={v} {CLOBBER(eol)};
  return;
}

and I think the issue is that DSE trims the zero-initialization.  -fno-tree-dse
fixes it - not doing DSE enables SRA:

  r = {};
  r.v[0] = z_8(D);
  *v_5(D) = r;
  r ={v} {CLOBBER(eol)};

can SRA while

  MEM  [(struct i256 *) + 8B] = {};
  r.v[0] = z_8(D);
  *v_5(D) = r;
  r ={v} {CLOBBER(eol)};

FAILs:

Candidate (2756): r
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
...
  MEM  [(struct i256 *) + 8B] = {};
  r$v$0_13 = z_8(D);
  r.v[0] = r$v$0_13;
  *v_5(D) = r;

that was pointless - compared to

Candidate (2756): r
Will attempt to totally scalarize r (UID: 2756):
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
Created a replacement for r offset: 64, size: 64: r$v$1D.2767
Created a replacement for r offset: 128, size: 64: r$v$2D.2768
Created a replacement for r offset: 192, size: 64: r$v$3D.2769
...
  r$v$0_13 = 0;
  r$v$1_2 = 0;
  r$v$2_1 = 0;
  r$v$3_11 = 0;
  r$v$0_10 = z_8(D);
  v_5(D)->v[0] = r$v$0_10;
  v_5(D)->v[1] = r$v$1_2;
  v_5(D)->v[2] = r$v$2_1;
  v_5(D)->v[3] = r$v$3_11;

possibly SRA is confused by the char[24] type.  It's going to be difficult
to do better though.

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Carlos Galvez from comment #2)
> I could reduce it to a simpler self-contained example:

That example has been rejected since r9-283-gd86d6e27db4520

CWG 2267 - list-initialization of reference temporary

* call.c (reference_binding): List-initializing a reference
temporary is copy-list-initialization.

[Bug target/109665] Incorrect code generation for s390/s390x try-catch (__cxa_begin_catch), causing SIGSEGV

[paul.groke at dynatrace dot com via Gcc-bugs]

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

--- Comment #3 from Paul Groke  ---
Created attachment 54952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54952=edit
Minimal repro

Added minimal repro

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started with r13-6788 "c++: DMI in template with virtual base [PR106890]"

[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||13.1.0, 14.0
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Target Milestone|--- |13.2
Summary|Segmentation fault with |[13/14 Regression]
   |std::array using gcc 13 |Segmentation fault with
   ||std::array using gcc 13
   Last reconfirmed||2023-04-28
  Known to work||12.2.0

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

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

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

--- Comment #4 from Jonathan Wakely  ---
Could the testsuite be finding an older libstdc++.so somewhere in the
LD_LIBRARY_PATH?

[Bug testsuite/109656] [14 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
It failed on just the one power 8 system where it fails every time.

configure --enable-languages=c,fortran,c++ --enable-secureplt --with-cpu=power8
--disable-bootstrap --disable-multilib

I will experiment a bit.

[Bug target/109665] Incorrect code generation for s390/s390x try-catch (__cxa_begin_catch), causing SIGSEGV

[paul.groke at dynatrace dot com via Gcc-bugs]

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

--- Comment #2 from Paul Groke  ---
-fno-schedule-insns and/or -fno-schedule-insns2 don't change the instruction
sequence for calling __cxa_begin_catch.

BTW: for compiler versions present there, it's super easy to check this with
godbolt.org. Just enter the compiler switches into the text-field next to the
compiler selection control.

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Galvez  ---
I could reduce it to a simpler self-contained example:

struct Foo;

Foo const& foo_maker();

struct Bar
{
explicit Bar(Foo const&);
};

void baz()
{
Bar const& b{foo_maker()};
}

Godbolt: https://godbolt.org/z/1q45Ebexz

Here it's clear that we are initializing a reference from a temporary, but
since it's a const reference, shouldn't it extend the lifetime of the
temporary? Clang does not complain in this case (it does when the reference is
non-const).

[Bug tree-optimization/109667] New: [12/13/14 Regression] Unnecessary temporary storage used for 32-byte struct

[chfast at gmail dot com via Gcc-bugs]

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

Bug ID: 109667
   Summary: [12/13/14 Regression] Unnecessary temporary storage
used for 32-byte struct
   Product: gcc
   Version: 12.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

Reduced reproducer:

struct i256 {
long v[4];
};
void assign(struct i256 *v, long z) {
struct i256 r = {};
for (int i = 0; i < 1; ++i) 
r.v[i] = z;
*v = r;
}

https://godbolt.org/z/avM74o3r6

The compiler allocates temporary storage on stack for `r`:

assign:
pxorxmm0, xmm0
mov QWORD PTR [rsp-40], rsi
movups  XMMWORD PTR [rsp-32], xmm0
movdqa  xmm1, XMMWORD PTR [rsp-40]
mov QWORD PTR [rsp-16], 0
movdqa  xmm2, XMMWORD PTR [rsp-24]
movups  XMMWORD PTR [rdi], xmm1
movups  XMMWORD PTR [rdi+16], xmm2
ret

Regression since 12. The 11 compiles nicely to:

assign:
mov QWORD PTR [rdi], rsi
mov QWORD PTR [rdi+8], 0
mov QWORD PTR [rdi+16], 0
mov QWORD PTR [rdi+24], 0
ret

[Bug target/109665] Incorrect code generation for s390/s390x try-catch (__cxa_begin_catch), causing SIGSEGV

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||s390x
  Component|c++ |target

--- Comment #1 from Richard Biener  ---
can you try if -fno-schedule-insns -fno-schedule-insns2 helps?

[Bug c++/109666] New: Segmentation fault with std::array using gcc 13

[john.viklund at effnet dot com via Gcc-bugs]

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

Bug ID: 109666
   Summary: Segmentation fault with std::array using gcc 13
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.viklund at effnet dot com
  Target Milestone: ---

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

gcc (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) running on Fedora 38

Compiled with:
/usr/bin/gcc -std=c++20 -O3 -c foo.cc

Gives the following output:
foo.cc: In instantiation of ‘Bar::Bar() [with T = Foo]’:
foo.cc:19:23:   required from here
foo.cc:14:20: internal compiler error: Segmentation fault
   14 |   std::array a_{};
  |^~
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/cci1GNGP.out file, please attach this to
your bugreport.

Was also able to reproduce it using godbolt on gcc 13.1:
https://godbolt.org/z/7nK446P34

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866 since r14-295-gd89e23f27215fc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Should be fixed now.

[Bug ipa/109652] [14 Regression] ICE on valgrind-3.20.0: in modify_expression, at ipa-param-manipulation.cc:1866 since r14-295-gd89e23f27215fc

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

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

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

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

commit r14-326-ga94dcac59ee4c99b523ae593cb1c0ad43d4a110b
Author: Richard Biener 
Date:   Fri Apr 28 08:40:07 2023 +0200

ipa/109652 - ICE in modification phase of IPA SRA

There's another questionable IL transform by IPA SRA, replacing
foo (p_1(D)->x) with foo (VIEW_CONVERT  (ISRA.PARM.1))
where ISRA.PARM.1 is a register.  Conversion of a register to
an aggregate type is questionable but not entirely unreasonable
and not within the set of IL I am rejecting when fixing PR109644.

The following lets this slip through in IPA SRA transform by
restricting re-gimplification to the case of register type
results.  To not break the previous testcase again we need to
optimize the BIT_FIELD_REF , ...> case
to elide the conversion.

PR ipa/109652
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::modify_expression): Allow
conversion of a register to a non-register type.  Elide
conversions inside BIT_FIELD_REFs.

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

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Julian Brown :

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

commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7
Author: Julian Brown 
Date:   Wed Apr 26 14:31:53 2023 +

OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]

This patch fixes several cases where multiple attach or detach mapping
nodes were being created for stand-alone attach or detach clauses
in Fortran.  After the introduction of stricter checking later during
compilation, these extra nodes could cause ICEs, as seen in the PR.

The patch also fixes cases that "happened to work" previously where
the user attaches/detaches a pointer to array using a descriptor, and
(I think!) the "_data" field has offset zero, hence the same address as
the descriptor as a whole.

2023-04-27  Julian Brown  

PR fortran/109622

gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Attach/detach clause
fixes.

gcc/testsuite/
* gfortran.dg/goacc/attach-descriptor.f90: Adjust expected output.

libgomp/
* testsuite/libgomp.fortran/pr109622.f90: New test.
* testsuite/libgomp.fortran/pr109622-2.f90: New test.
* testsuite/libgomp.fortran/pr109622-3.f90: New test.

[Bug ipa/108040] -fdevirtualize causes part of function to be missing in output

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

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

--- Comment #1 from Martin Jambor  ---
It is probably me not being able to build the necessary cross compiler
properly, but I cannot build the provided testcase, I always get errors like
the following and then some more:

: note:   initializing argument 2 of ‘__vector(4) float
__builtin_ia32_dpbf16ps_v4sf(__vector(4) float, __vector(8) __bf16, __vector(8)
__bf16)’
C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/avx512bf16vlintrin.h:
In function ‘__m128 _mm_mask_dpbf16_ps(__m128, __mmask8, __m128bh, __m128bh)’:
C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/avx512bf16vlintrin.h:169:57:
error: cannot convert ‘__m128bh’ to ‘__vector(8) __bf16’


It would be great if you could simplify the testcase (and also the necessary
command line) somewhat - and ideally reproduce it with pristine GCC.  Otherwise
you may want to report the issue to
https://github.com/msys2/MINGW-packages/issues

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

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

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

--- Comment #9 from Tobias Burnus  ---
Julian submitted a patch for this (approved but not yet committed):
  https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html

Patrick: Can you check whether it also fixes your program?

[Bug libgomp/109664] Deadlocks with gomp_fatal called from libgomp/plugins/

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

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

--- Comment #1 from Tobias Burnus  ---
Once done, we might want to change some error propagation from a chain of
boolean-returning functions to just GOMP_PLUGIN_fatal – or not.

Cf. for instance:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616992.html

[Bug c++/109665] New: Incorrect code generation for s390/s390x try-catch (__cxa_begin_catch), causing SIGSEGV

[paul.groke at dynatrace dot com via Gcc-bugs]

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

Bug ID: 109665
   Summary: Incorrect code generation for s390/s390x try-catch
(__cxa_begin_catch), causing SIGSEGV
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.groke at dynatrace dot com
  Target Milestone: ---

In certain situations, GCC generates incorrect s390x code for calling
`__cxa_begin_catch`. The bogus code contains a `lghi %r2,0` right before
calling `__cxa_begin_catch`. r2 is the register for the first and only argument
of `__cxa_begin_catch`, which is a pointer to some struct related to the
exception. And when called with a nullptr, `__cxa_begin_catch` will crash
(SIGSEGV). s390 (`-m31`) is also affected.

To reproduce, compile the following on Linux/s390x with at least `-O1`:

```
void f2(int, int, int, int, int);

void f1() {
try {
f2(42, 42, 42, 42, 0); // SIGSEGV
} catch (...) {
}
}

```

The resulting code with GCC 12.2.0 is this:

```
f1():
  stmg %r6,%r15,48(%r15)
  lghi %r5,42
  aghi %r15,-160
  lghi %r6,0
  lghi %r4,42
  lghi %r3,42
  lghi %r2,42
  brasl %r14,_Z2f2i@PLT
  lg %r4,272(%r15)
  lmg %r6,%r15,208(%r15)
  br %r4
  lghi %r2,0
  brasl %r14,__cxa_begin_catch@PLT
  lmg %r6,%r15,208(%r15)
  jg __cxa_end_catch@PLT
```

See https://godbolt.org/z/TTYr63oM3

The correct code has an `lgr %r2,%r6` instead of the `lghi %r2,0`.

The bug seems to be dependent on several factors:

- The last thing in the try-catch is a function call with at least 5 parameters
  (Note that I only tested with parameter types that each fit into a general
purpose register though)
- The 5th argument must be a zero constant (0, false, ...)
- The try-catch contains a "catch (...)" handler
- At least `-O1` is used
- The function call is not inlined/no constant propagation happens

I found the bug with GCC 9.5.0 but it also happens with at least 11.2.0, 12.1.0
and 12.2.0 (tested with godbolt.org). I don't have newer GCC versions for s390x
handy, so I didn't test with those.

[Bug libgomp/109664] New: Deadlocks with gomp_fatal called from libgomp/plugins/

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

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

Bug ID: 109664
   Summary: Deadlocks with gomp_fatal called from libgomp/plugins/
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

See thread starting at:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603616.html


Issue:

Fatal errors inside mutex-locked regions (i.e. basically anything in the
plugin) will cause it to hang up trying to take the lock to clean everything
up.


Possible solutions:

would be not use gomp_fatal from within the
plugins, but use gomp_error instead and through possibly adjusted plugin
APIs tell libgomp that there was a fatal error and let libgomp unlock
anything that needs unlocking and exit (EXIT_FAILURE); afterwards.


another possibility would be not use gomp_fatal from within the
plugins, but use gomp_error instead and through possibly adjusted plugin
APIs tell libgomp that there was a fatal error and let libgomp unlock
anything that needs unlocking and exit (EXIT_FAILURE); afterwards.

[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Carlos Galvez  ---
I forgot to write the actual error I'm getting:

: In function 'int main()':
:11:41: error: converting to 'const MyVector' {aka 'const
Eigen::Matrix'} from initializer list would use explicit
constructor 'Eigen::Matrix<_Scalar, _Rows, _Cols, _Options, _MaxRows,
_MaxCols>::Matrix(const T&) [with T = Eigen::Block,
4, 1, true>; _Scalar = float; int _Rows = 4; int _Cols = 1; int _Options = 0;
int _MaxRows = 4; int _MaxCols = 1]'
   11 | MyVector const& my_col{matrix.col(0)};
  | ^

[Bug c++/109663] New: False positive? Converting from initializer list would use explicit constructor

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 109663
   Summary: False positive? Converting from initializer list would
use explicit constructor
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

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

Hi!

We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
cc035c5d8672f87dc8c2756d9f8367903aa72d93 (GCC 13.1 release), and are now
getting a handful of errors in this type of code compiling in C++14 mode:

#include 

int main()
{
constexpr std::size_t kColumns{4};
constexpr std::size_t kRows{4};
using MyVector = Eigen::Matrix;
using MyMatrix = Eigen::Matrix;

MyMatrix matrix{MyMatrix::Zero()};
MyVector const& my_col{matrix.col(0)};
}

Godbolt: https://godbolt.org/z/rx6EY4qbY

Preprocessed source attached.

I am wondering if this is a False Positive or a real error that should be
fixed?

[Bug middle-end/109644] Missing GIMPLE IL verification

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
The desired IL verification is now implemented.  I'm going to watch the
inevitable fireworks.

[Bug middle-end/109644] Missing GIMPLE IL verification

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

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

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

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

commit r14-324-g6e6f86f22873aab7059e083fd0c9905bd58e5efa
Author: Richard Biener 
Date:   Mon Apr 24 13:20:25 2023 +0200

tree-optimization/109644 - missing IL checking

We fail to verify the constraints under which we allow handled
components to wrap registers.  The gcc.dg/pr70022.c testcase shows
that we happily end up with

  _2 = VIEW_CONVERT_EXPR(v_1(D))

as produced by SSA rewrite and update_address_taken.  But the intent
was that we wrap registers with at most a single level of handled
components and specifically only allow __real, __imag, BIT_FIELD_REF
and VIEW_CONVERT_EXPR on them, but not ARRAY_REF or COMPONENT_REF.

The following makes IL verification stricter which catches the
problem.

PR tree-optimization/109644
* tree-cfg.cc (verify_types_in_gimple_reference): Check
register constraints on the outermost VIEW_CONVERT_EXPR
only.  Do not allow register or invariant bases on
multi-level or possibly variable index handled components.

[Bug tree-optimization/108752] word_mode vectorization is pessimized by hard limit on nunits

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/108752] word_mode vectorization is pessimized by hard limit on nunits

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

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

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

https://gcc.gnu.org/g:821ef93976e750c118d42a2ad33b96dbd1b9f3a5

commit r14-322-g821ef93976e750c118d42a2ad33b96dbd1b9f3a5
Author: Richard Biener 
Date:   Fri Feb 10 13:09:10 2023 +0100

tree-optimization/108752 - vectorize emulated vectors in lowered form

The following makes sure to emit operations lowered to bit operations
when vectorizing using emulated vectors.  This avoids relying on
the vector lowering pass adhering to the exact same cost considerations
as the vectorizer.

PR tree-optimization/108752
* tree-vect-generic.cc (build_replicated_const): Rename
to build_replicated_int_cst and move to tree.{h,cc}.
(do_plus_minus): Adjust.
(do_negate): Likewise.
* tree-vect-stmts.cc (vectorizable_operation): Emit emulated
arithmetic vector operations in lowered form.
* tree.h (build_replicated_int_cst): Declare.
* tree.cc (build_replicated_int_cst): Moved from
tree-vect-generic.cc build_replicated_const.

[Bug target/109661] [13/14 Regression] ICE in aarch64_function_arg_alignment when building erlang

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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