[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

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

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

--- Comment #23 from Michael Meissner  ---
This is one of those things where there is no right answer in part because we
need other things to flesh out the support.

The reason -mvsx was used is we need the VSX registers to build the IEEE
128-bit support in libgcc (KFmode values are passed in vector registers 32..63,
i.e. the traditional Altivec registers).

In theory, we need only Altivec, but I felt at the time when I implemented this
 that it opened up the door for lots of other things breaking due to the goofy
nature of Altivec addresses omitting the bottom bits and no direct move
support) and that VSX was the minimum ISA needed.

Now, from a practical matter, it should have been power8 as a minimum (due to
direct move) but at the time I did the initial work, we were still actively
supporting power7.

Then we have the issue that while the compiler can generate code on BE systems
for IEEE 128-bit (either with software emulation or with the power9 hardware
support) glibc only supports IEEE 128-bit on 64-bit LE.

So for a user it is useless to have IEEE 128-bit on BE systems.  But if
somebody wanted to go through and do the work to enable the GLIBC support and
other parts of the compiler/libraries that provide IEEE 128-bit.  But it is not
a windmill I want to charge and tilt at.  But hey, if somebody wants to do the
work to fix all of the support for this, go ahead.  I am not that person.

Note this is the classic catch 22 that we faced in the early days.  GCC has to
support the stuff to a minimal amount even though users can't use it.  But you
need that ability to generate the code to get glibc to do the support.

In terms of the immediate problem, you have several choices:

1) Ignore it and say to the users don't do that.

2) Prevent the IEEE 128-bit libgcc bits from being built on a BE or 32-bit LE
system unless some configure switch is used.  Or just kick the can down the
road, and don't provide a configure option in GCC 14, and if people are
interested do it in GCC 15.

3) Only build the IEEE 128-bit libgcc bits if the user configured the compiler
with --with-cpu=power7, --with-cpu=power8, --with-cpu=power9,
--with-cpu=power10 (and in the future --with-cpu=power11 or --with-cpu=future).
 This could be code that if __VSX__ is not defined, the libgcc support
functions won't get built.  We would then remove the -mvsx option from the
library support functions.

Though note, there is an issue in that if you don't use a --with-cpu= configure
option, it won't build the bits.  Thus for the brave person trying to enable
IEEE 128-bit for BE, they would have to configure with one of the IBM server
platforms, while the majority of users would be using the old Apple boards,
embedded platforms, or even AIX, etc.

Note, I will be on vacation from April 16th through the 23rd, and I probably
won't bring a work laptop, which will mean I won't be able to answer email in
that period.

[Bug c++/109323] No error when neither of return_value or return_void is defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug c++/114709] New: Incorrect handling of inactive union member access via pointer to member in constant evaluated context

[420 at zerberste dot es via Gcc-bugs]

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

Bug ID: 114709
   Summary: Incorrect handling of inactive union member access via
pointer to member in constant evaluated context
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 420 at zerberste dot es
  Target Milestone: ---

According to https://standards.pydong.org/c++/class.union#general-note-1 an
inactive union member may be used to inspect the initial sequence common with
the active union member, given both are struct types. Furthermore
https://standards.pydong.org/c++/class.mem#general-26 tells us the behavior of
reading a non-static member m of such a common initial sequence is _as if_ the
corresponding member were nominated. Since it is not expression-equivalent, we
are still accessing the wrong member as far as the abstract machine is
concerned. Hence https://standards.pydong.org/c++/expr.const#5.10 still
applies.

GCC implements this correctly for the simple case. To reuse the example from
[class.mem]/26 consider this code fragment:
```cpp
struct T1 { int a, b; };
struct T2 { int c; double d; };
union U { T1 t1; T2 t2; };

consteval int f() {
  U u = { { 1, 2 } }; // active member is t1
  return u.t2.c;  // access through t2
}

static constexpr auto foo = f();
```
https://godbolt.org/z/x14n47T45

GCC correctly errors with the diagnostic 
> accessing 'U::t2' member instead of initialized 'U::t1' member in constant 
> expression


However, consider the following code fragment:
```cpp
struct T1 { int a, b; };
struct T2 { int c; double d; };
union U { T1 t1; T2 t2; };

consteval int f() {
  U u = { { 1, 2 } };  // active member is t1
  return u.t2.*::c; // access through t2
}

static constexpr auto foo = f();
```
https://godbolt.org/z/dK95jEPjq

GCC 12 up until trunk accept this code. GCC 11 and Clang don't.

[Bug c++/114460] [C++26] P3106R1 - Clarifying rules for brace elision in aggregate initialization

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
This paper was intended to correct the specification of existing behavior, so
no compiler changes should be necessary, but we should verify that.

[Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |13.0
 Status|WAITING |RESOLVED

--- Comment #2 from Andrew Pinski  ---
So fixed.

[Bug ada/114708] New: Creating access to an incomplete formal in a generic package sometimes causes GNAT to crash

[jhb.chat at gmail dot com via Gcc-bugs]

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

Bug ID: 114708
   Summary: Creating access to an incomplete formal in a generic
package sometimes causes GNAT to crash
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jhb.chat at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57939=edit
incomplete formal example

When making a generic package that takes an incomplete formal as a parameter
and then creating an access type to that formal type inside the generic, GNAT
will crash if an actual incomplete type is supplied in the generic
instantiation.

This happens on gnat 13.0, on mwys2, Windows 10 Home, fully patched
GNATMAKE 13.2.0
Copyright (C) 1995-2023, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

Checked Godbolt and this happens on trunk there and the ICE appeared to start
with GNAT 12.1 as GNAT 11.4 did not trigger the crash (on Godbolt).

Example:
procedure Main is

   generic
  type Element_Type(<>);
   package Test_Incomplete_Formal is
  type Element_Access is access Element_Type;
   end Test_Incomplete_Formal;

   type Node;

   package P is new Test_Incomplete_Formal(Node);

   type Node is limited null record;

begin
   null;
end Main;


Output:
$ gnatmake.exe main.adb 
gcc -c main.adb
+===GNAT BUG DETECTED==+
| 13.2.0 (x86_64-w64-mingw32) Program_Error EXCEPTION_ACCESS_VIOLATION |
| Error detected at main.adb:6:7 [main.adb:11:4]   |
| Compiling main.adb   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

main.adb

compilation abandoned
gnatmake: "main.adb" compilation error

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED
   Target Milestone|--- |9.0

--- Comment #7 from Andrew Pinski  ---
(In reply to Richard Biener from comment #6)
> Note that GCC 8 is no longer maintained and you should be using the last
> release from this branch, GCC 8.5.  Can you check whether GCC 9.4 or later
> work correctly?

Since r9-1060-g31db0fe044cc9d, the code related to chkp (and
chkp_function_instrumented_p) is removed so I am going to assume this was fixed
for GCC 9.
Plus there is no testcase to prove it so just closing as invalid.

[Bug middle-end/104628] Error when bootstrapping CMake: Problem while running make

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #2 from Andrew Pinski  ---
No preprocesed source forthcoming since it has been asked over 2 years ago so
closing as invalid.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #8 from Andrew Pinski  ---
No preprocessed source forthcoming since it has been over 2 years since asking
so closing as invalid. It is hard to reproduce not using the preprocessed
source.

[Bug lto/102649] GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
This is hard to reproduce without a testcase and there does not seem like there
is a testcase forthcoming since it has been 2.5 years since this was filed.

[Bug target/90620] Microblaze: ICE similar to bug 16267

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
No feedback in 1.5 years and there is no way to reproduce it so closing as
invalid.

[Bug target/80419] rpmbuild with rpmrc file crashed httpd rebuild

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
No feedback in almost 7 years (1 day less).

[Bug target/114696] ICE: in extract_constrain_insn_cached, at recog.cc:2725 insn does not satisfy its constraints: {*anddi_1} with -mapxf -mx32

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #3 from H.J. Lu  ---
A patch is posted at

https://patchwork.sourceware.org/project/gcc/list/?series=32811

[Bug tree-optimization/114704] Missed optimization : eliminate store if the value is known in all predecessors

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 20999.

[Bug tree-optimization/114704] Missed optimization : eliminate store if the value is known in all predecessors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. A more general testcase:
```
void dummy();

void src(int *p, int a){
int t = *p;
if(t == a)
goto then;
else {
dummy();
t = *p;
if(t == a)
goto then;
else
return;
}

then:
*p = t; // *p is already a, it's dead now
}

```

[Bug tree-optimization/114704] Missed optimization : eliminate store if the value is known in all predecessors

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/114702] Missed optimization: fail to infer c - b != if a + b != c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Blocks||85316

--- Comment #1 from Andrew Pinski  ---
Confirmed. 

VRP does some of this but I am not sure if it can be expanded to be handle more
general value relations here


Folding statement: if (_2 == a_5(D))
 Registering value_relation (_2 == a_5(D)) on (3->4)
 Registering value_relation (_2 != a_5(D)) on (3->5)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug ipa/114703] Missed devirtualization in rather simple case

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ipa/110057] Missed devirtualization opportunities

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ipa/114703] Missed devirtualization in rather simple case

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
The problem I think is we don't realize that `operator new` can't touch the
other memory that was just allocated partly because the escape analysis is not
flow sensitive .

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

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

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

--- Comment #5 from Jakub Jelinek  ---
And does
extern void g( int);

void f( int mant, int sticky)
{
mant = mant >> 1 ;
mant = mant >> 1 | (mant & 1);
mant = mant >> 1 | (mant & 1) | (!!sticky);
mant = !!sticky;
mant = (mant & 1) | (!!sticky);
g( mant);
}
shut up those warnings?

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
I tried this code:

extern void g( int);

void f( int mant, int sticky)
{
mant = mant >> 1 ;
mant = mant >> 1 | (mant & 1);
mant = mant >> 1 | (mant & 1) | !!sticky;
mant = !!sticky;
mant = (mant & 1) | !!sticky;
g( mant);
}

Cppcheck says:

$ ~/cppcheck/trunk/cppcheck --enable=all apr12a.cc
apr12a.cc:8:32: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
 mant = mant >> 1 | (mant & 1) | !!sticky;
   ^
apr12a.cc:10:20: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
 mant = (mant & 1) | !!sticky;
   ^
so it appears to be the combination of bitwise operation (mant & 1) 
and the boolean result !!sticky.

[Bug c++/114707] Mark TARGET_EXPRs for function arguments eliding

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Mine for GCC 15.

[Bug c++/114707] New: Mark TARGET_EXPRs for function arguments eliding

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

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

Bug ID: 114707
   Summary: Mark TARGET_EXPRs for function arguments eliding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

>From : let's
do set_target_expr_eliding in convert_for_arg_passing.  Then the pset in
replace_placeholders_for_class_temp_r can go.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #28 from uecker at gcc dot gnu.org ---

I do not fully understand yet what happens for may_alias, but it if we later
complete the struct with the may_alias attribute it seems we would also need to
update the previously created pointer so that it has TYPE_REF_CAN_ALIAS_ALL. 
Setting TYPE_STRUCTURAL_EQUALITY for incomplete structs also for pre-C23 seems
to fix the assertion failure, but I am not sure if this fixes the underlying
bug.

[Bug other/85928] Misplaced references to some options in info page in Option Index

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/Option-Index.html#Option-Index

Most were fixed in GCC 9:
https://gcc.gnu.org/onlinedocs/gcc-9.5.0/gcc/Option-Index.html#Option-Index

All but 80387 was fixed by GCC 10 as seen by
https://gcc.gnu.org/onlinedocs/gcc-10.5.0/gcc/Option-Index.html .

Some more were added in GCC 12:
https://gcc.gnu.org/onlinedocs/gcc-12.3.0/gcc/Option-Index.html


But all were fixed in GCC 13:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Option-Index.html


80387 was fixed by r13-4020-g30348d30d9567c .
r13-4019-g9c19597c0d9181 fixed the ones which were introduced in GCC 12.



r13-4040-gd7971cf7625547 fixed a few ones not related to what is listed here.

r10-1344-gde80936dbf2ae4 fixed the scalar-storage-order ones.

r9-3920-ga28102f8cc84d0 fixed the ones which fixed during GCC 9.

[Bug fortran/113793] malloc abort on character allocate with source argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Priority|P3  |P4

[Bug fortran/113793] malloc abort on character allocate with source argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #57931|0   |1
is obsolete||

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

This version add checks for standard conformance and a runtime check for
equal length.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #21 from Peter Bergner  ---
Fixed on trunk.  I'll let it burn-in there for a bit before backporting to the
release branches.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #20 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r14-9949-gaa57af93ba22865be747f926e4e5f219e7f8758a
Author: Will Schmidt 
Date:   Fri Apr 12 14:55:16 2024 -0500

rs6000: Add OPTION_MASK_POWER8 [PR101865]

The bug in PR101865 is the _ARCH_PWR8 predefine macro is conditional upon
TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if
the
-mno-altivec or -mno-vsx options are used.  The solution here is to create
a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
Altivec or VSX enablement.

Unfortunately, the only way to create an OPTION_MASK_* mask is to create
a new option, which we have done here, but marked it as WarnRemoved since
we do not want users using it.  For stage1, we will look into how we can
create ISA mask flags for use in the compiler without the need for explicit
options.

2024-04-12  Will Schmidt  
Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported):
Use
TARGET_POWER8.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Use
OPTION_MASK_POWER8.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add
OPTION_MASK_POWER8.
(ISA_2_7_MASKS_SERVER): Likewise.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Update
comment.  Use OPTION_MASK_POWER8 and TARGET_POWER8.
* config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
* config/rs6000/rs6000.md (define_attr "isa"): Add p8.
(define_attr "enabled"): Handle it.
(define_insn "prefetch"): Use TARGET_POWER8.
* config/rs6000/rs6000.opt (mpower8-internal): New.

gcc/testsuite/
PR target/101865
* gcc.target/powerpc/predefine-p7-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec.c: New test.
* gcc.target/powerpc/predefine-p8-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-pragma-vsx.c: New test.
* gcc.target/powerpc/predefine-p9-novsx.c: New test.

[Bug c++/114706] ICE - std::bit_cast in consteval function involving array of union

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE - std::bit_cast in  |ICE - std::bit_cast in
   |consteval function  |consteval function
   |involving union |involving array of union

--- Comment #2 from Andrew Pinski  ---
Looks like check_bit_cast_type does not check ARRAY_TYPE recusively ...

[Bug c++/114706] ICE - std::bit_cast in consteval function involving union

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
   Keywords||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization

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

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

--- Comment #10 from Patrick Palka  ---
The master branch has been updated by Jason Merrill :

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

commit r14-9947-df7bfdb7dbf2d46aa5768a0280d4dcfcc868b7f9
Author: Jason Merrill 
Date:   Wed Apr 10 15:12:26 2024 -0400

c++: reference cast, conversion fn [PR113141]

The second testcase in 113141 is a separate issue: we first decide that the
conversion is ill-formed, but then when recalculating the special c_cast_p
handling makes us think it's OK.  We don't want that, it should continue to
fall back to the reinterpret_cast interpretation.  And while we're here,
let's warn that we're not using the conversion function.

Note that the standard seems to say that in this case we should
treat (Matrix &) as const_cast(static_cast(X)),
which would use the conversion operator, but that doesn't match existing
practice, so let's resolve that another day.  I've raised this issue with
CWG; at the moment I lean toward never binding a temporary in a C-style
cast
to reference type, which would also be a change from existing practice.

PR c++/113141

gcc/c-family/ChangeLog:

* c.opt: Add -Wcast-user-defined.

gcc/ChangeLog:

* doc/invoke.texi: Document -Wcast-user-defined.

gcc/cp/ChangeLog:

* call.cc (reference_binding): For an invalid cast, warn and don't
recalculate.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref12.C: New test.

Co-authored-by: Patrick Palka 

[Bug c++/113141] [13/14 Regression] ICE on conversion to reference in aggregate initialization

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

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

--- Comment #9 from Patrick Palka  ---
The master branch has been updated by Jason Merrill :

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

commit r14-9946-gd435571b54b02946c97b5b24f20e5a7058fd96a1
Author: Jason Merrill 
Date:   Fri Apr 12 13:24:44 2024 -0400

c++: reference list-init, conversion fn [PR113141]

The original testcase in PR113141 is an instance of CWG1996; the standard
fails to consider conversion functions when initializing a reference
directly from an initializer-list of one element, but then does consider
them when initializing a temporary.  I have a proposed fix for this defect,
which is implemented here.

DR 1996
PR c++/113141

gcc/cp/ChangeLog:

* call.cc (reference_binding): Check direct binding from
a single-element list.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-ref1.C: New test.
* g++.dg/cpp0x/initlist-ref2.C: New test.
* g++.dg/cpp0x/initlist-ref3.C: New test.

Co-authored-by: Patrick Palka 

[Bug c++/114706] New: ICE - std::bit_cast in consteval function involving union

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 114706
   Summary: ICE - std::bit_cast in consteval function involving
union
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

ICE in a consteval function bit_casting an array of unions.  The code isn't
valid due to the union, but the compiler is not handling it properly (since
gcc11...trunk).  Reduced to the following program:

CODE

#include 
union U { int u; };
consteval void f() {
U result[]{0, 0};   
auto x = std::bit_cast(result);
}
int main() { f(); }

LIVE:
https://godbolt.org/z/Y943bc5zK


OUTPUT

/opt/compiler-explorer/gcc-trunk-20240412/include/c++/14.0.1/bit:94:33:
internal compiler error: in native_encode_initializer, at fold-const.cc:8468
   94 |   return __builtin_bit_cast(_To, __from);
  | ^~~
0x267826c internal_error(char const*, ...)
???:0
0xa58c63 fancy_abort(char const*, int, char const*)
???:0
0xfa0eaf native_encode_initializer(tree_node*, unsigned char*, int, int,
unsigned char*)
???:0
0xacf0f0 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0xd3a75f store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xb474fe cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc5c81a c_parse_file()
???:0
0xdb1489 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 <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/114303] [11/12/13 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE with constexpr if and   |with constexpr if and
   |accessing captures across   |accessing captures across
   |nested generic lambdas  |nested generic lambdas

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 14 so far

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 99426 Summary: [modules] failed to read compiled module cluster 1186: Bad 
file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426

   What|Removed |Added

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 99426 Summary: [modules] failed to read compiled module cluster 1186: Bad 
file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426

   What|Removed |Added

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

[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Palka  ---
Fixed for GCC 14 (although PR114630 remains at large).

[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data

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

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

--- Comment #11 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:716af95fd454871473c4b118b8412b6a68459b75

commit r14-9948-716af95fd454871473c4b118b8412b6a68459b75
Author: Patrick Palka 

c++/modules: local type merging [PR99426]

One known missing piece in the modules implementation is merging of a
streamed-in local type (class or enum) with the corresponding in-TU
version of the local type.  This missing piece turns out to cause a
hard-to-reduce use-after-free GC issue due to the entity_ary not being
marked as a GC root (deliberately), and manifests as a serialization
error on stream-in as in PR99426 (see comment #6 for a reduction).  It's
also reproducible on trunk when running the xtreme-header tests without
-fno-module-lazy.

This patch implements this missing piece, making us merge such local
types according to their position within the containing function's
definition, analogous to how we merge FIELD_DECLs of a class according
to their index in the TYPE_FIELDS list.

PR c++/99426

gcc/cp/ChangeLog:

* module.cc (merge_kind::MK_local_type): New enumerator.
(merge_kind_name): Update.
(trees_out::chained_decls): Move BLOCK-specific handling
of DECL_LOCAL_DECL_P decls to ...
(trees_out::core_vals) : ... here.  Stream
BLOCK_VARS manually.
(trees_in::core_vals) : Stream BLOCK_VARS
manually.  Handle deduplicated local types..
(trees_out::key_local_type): Define.
(trees_in::key_local_type): Define.
(trees_out::get_merge_kind) : Return
MK_local_type for a local type.
(trees_out::key_mergeable) : Use
key_local_type.
(trees_in::key_mergeable) : Likewise.
(trees_in::is_matching_decl): Be flexible with type mismatches
for local entities.
(trees_in::register_duplicate): Also register the
DECL_TEMPLATE_RESULT of a TEMPLATE_DECL as a duplicate.
(depset_cmp): Return 0 for equal IDENTIFIER_HASH_VALUEs.

gcc/testsuite/ChangeLog:

* g++.dg/modules/merge-17.h: New test.
* g++.dg/modules/merge-17_a.H: New test.
* g++.dg/modules/merge-17_b.C: New test.
* g++.dg/modules/xtreme-header-7_a.H: New test.
* g++.dg/modules/xtreme-header-7_b.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 93595 Summary: [c++20] function call, substitution failure of template 
parameter with a lambda default in template context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595

   What|Removed |Added

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

[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context

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

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

--- Comment #10 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917

commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917
Author: Patrick Palka 

c++: templated substitution into lambda-expr [PR114393]

The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty which causes push_template_decl
to return error_mark_node from the call to begin_lambda_type.  Were it
not for the sanity check this silent error_mark_node result leads to
nonsensical errors down the line, or silent breakage.

In the first testcase, we hit this assert during instantiation of the
dependent alias template-id c1_t<_Data> from instantiate_template, which
clears current_template_parms via push_to_top_level.  Similar story for
the second testcase.  For the third testcase we hit the assert during
partial instantiation of the member template from instantiate_class_template
which similarly calls push_to_top_level.

These testcases illustrate that templated substitution into a lambda-expr
is not always possible, in particular when we lost the relevant template
context.  I experimented with recovering the template context by making
tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if
current_template_parms is empty which worked but seemed like a hack.  I
also experimented with preserving the template context by keeping
current_template_parms set during instantiate_template for a dependent
specialization which also worked but it's at odds with the fact that we
cache dependent specializations (and so they should be independent of
the template context).

So instead of trying to make such substitution work, this patch uses the
extra-args mechanism to defer templated substitution into a lambda-expr
when we lost the relevant template context.

PR c++/114393
PR c++/107457
PR c++/93595

gcc/cp/ChangeLog:

* cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define.
(tree_lambda_expr::extra_args): New field.
* module.cc (trees_out::core_vals) : Stream
LAMBDA_EXPR_EXTRA_ARGS.
(trees_in::core_vals) : Likewise.
* pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR.
(tree_extra_args): Handle LAMBDA_EXPR.
(tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated
substitution into a lambda-expr if we lost the template context.
Add sanity check for error_mark_node result from begin_lambda_type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ2.C: New test.
* g++.dg/cpp2a/lambda-targ3.C: New test.
* g++.dg/cpp2a/lambda-targ4.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/107457] ICE when template lambda alias used as default template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.

[Bug c++/107430] [meta-bug] lambda in decltype

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

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

Bug 107457 Summary: ICE when template lambda alias used as default template 
argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107457

   What|Removed |Added

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

[Bug c++/107457] ICE when template lambda alias used as default template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917

commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917
Author: Patrick Palka 

c++: templated substitution into lambda-expr [PR114393]

The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty which causes push_template_decl
to return error_mark_node from the call to begin_lambda_type.  Were it
not for the sanity check this silent error_mark_node result leads to
nonsensical errors down the line, or silent breakage.

In the first testcase, we hit this assert during instantiation of the
dependent alias template-id c1_t<_Data> from instantiate_template, which
clears current_template_parms via push_to_top_level.  Similar story for
the second testcase.  For the third testcase we hit the assert during
partial instantiation of the member template from instantiate_class_template
which similarly calls push_to_top_level.

These testcases illustrate that templated substitution into a lambda-expr
is not always possible, in particular when we lost the relevant template
context.  I experimented with recovering the template context by making
tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if
current_template_parms is empty which worked but seemed like a hack.  I
also experimented with preserving the template context by keeping
current_template_parms set during instantiate_template for a dependent
specialization which also worked but it's at odds with the fact that we
cache dependent specializations (and so they should be independent of
the template context).

So instead of trying to make such substitution work, this patch uses the
extra-args mechanism to defer templated substitution into a lambda-expr
when we lost the relevant template context.

PR c++/114393
PR c++/107457
PR c++/93595

gcc/cp/ChangeLog:

* cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define.
(tree_lambda_expr::extra_args): New field.
* module.cc (trees_out::core_vals) : Stream
LAMBDA_EXPR_EXTRA_ARGS.
(trees_in::core_vals) : Likewise.
* pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR.
(tree_extra_args): Handle LAMBDA_EXPR.
(tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated
substitution into a lambda-expr if we lost the template context.
Add sanity check for error_mark_node result from begin_lambda_type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ2.C: New test.
* g++.dg/cpp2a/lambda-targ3.C: New test.
* g++.dg/cpp2a/lambda-targ4.C: New test.

Reviewed-by: Jason Merrill 

[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'

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

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

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

Here's a testcase derived from comment#0.

Feel free to adapt it to your meet your needs, and push it.

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed, GCC trunk should now happily compile stdexec trunk, and our support for
lambdas as template arguments should be more robust to boot. thanks for the bug
report

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

--- Comment #7 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

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

commit r14-9943-d74fe10b13336b9de2e025ced4af00a25ff1d3e7
Author: Patrick Palka 

c++: templated substitution into lambda-expr, cont [PR114393]

The original PR114393 testcase is unfortunately still not accepted after
r14-9938-g081c1e93d56d35 due to return type deduction confusion when a
lambda-expr is used as a default template argument.

The below reduced testcase demonstrates the bug.  Here when forming the
dependent specialization b_v we substitute the default argument of F,
a lambda-expr, with _Descriptor=U.  (In this case in_template_context is
true since we're in the context of the template c_v, so we don't defer.)
This substitution in turn lowers the level of the lambda's auto return
type from 2 to 1 and so later, when instantiating c_v we wrongly
substitute this auto with the template argument at level=0,index=0, i.e.
int, instead of going through do_auto_deduction which would yield char.

One way to fix this would be to use a level-less auto to represent a
deduced return type of a lambda, but that might be too invasive of a
change at this stage, and it might be better to do this across the board
for all deduced return types.

Another way would be to pass tf_partial from coerce_template_parms during
dependent substitution into a default template argument so that the
substitution doesn't do any level-lowering, but that wouldn't do the right
thing in this case due to the tf_partial early exit in the LAMBDA_EXPR
case of tsubst_expr.

Yet another way, and the approach that this patch takes, is to just
defer all dependent substitution into a lambda-expr, building upon the
logic added in r14-9938-g081c1e93d56d35.  This also helps ensure
LAMBDA_EXPR_REGEN_INFO consists only of the concrete template arguments
that were ultimately substituted into the most general lambda.

PR c++/114393

gcc/cp/ChangeLog:

* pt.cc (tsubst_lambda_expr): Also defer all dependent
substitution.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ2a.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

--- Comment #6 from Patrick Palka  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:081c1e93d56d35c7314ed68e6d87628b430de917

commit r14-9938-081c1e93d56d35c7314ed68e6d87628b430de917
Author: Patrick Palka 

c++: templated substitution into lambda-expr [PR114393]

The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty which causes push_template_decl
to return error_mark_node from the call to begin_lambda_type.  Were it
not for the sanity check this silent error_mark_node result leads to
nonsensical errors down the line, or silent breakage.

In the first testcase, we hit this assert during instantiation of the
dependent alias template-id c1_t<_Data> from instantiate_template, which
clears current_template_parms via push_to_top_level.  Similar story for
the second testcase.  For the third testcase we hit the assert during
partial instantiation of the member template from instantiate_class_template
which similarly calls push_to_top_level.

These testcases illustrate that templated substitution into a lambda-expr
is not always possible, in particular when we lost the relevant template
context.  I experimented with recovering the template context by making
tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if
current_template_parms is empty which worked but seemed like a hack.  I
also experimented with preserving the template context by keeping
current_template_parms set during instantiate_template for a dependent
specialization which also worked but it's at odds with the fact that we
cache dependent specializations (and so they should be independent of
the template context).

So instead of trying to make such substitution work, this patch uses the
extra-args mechanism to defer templated substitution into a lambda-expr
when we lost the relevant template context.

PR c++/114393
PR c++/107457
PR c++/93595

gcc/cp/ChangeLog:

* cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define.
(tree_lambda_expr::extra_args): New field.
* module.cc (trees_out::core_vals) : Stream
LAMBDA_EXPR_EXTRA_ARGS.
(trees_in::core_vals) : Likewise.
* pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR.
(tree_extra_args): Handle LAMBDA_EXPR.
(tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated
substitution into a lambda-expr if we lost the template context.
Add sanity check for error_mark_node result from begin_lambda_type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-targ2.C: New test.
* g++.dg/cpp2a/lambda-targ3.C: New test.
* g++.dg/cpp2a/lambda-targ4.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114691] [11/12/13 Regression] Bogus ignoring loop annotation warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Bogus
   |Bogus ignoring loop |ignoring loop annotation
   |annotation warning  |warning

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/114691] [11/12/13/14 Regression] Bogus ignoring loop annotation warning

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:91146346f57cc54dfeb2669347edd0eb3d13af7f

commit r14-9944-g91146346f57cc54dfeb2669347edd0eb3d13af7f
Author: Jakub Jelinek 
Date:   Fri Apr 12 20:53:10 2024 +0200

c++: Fix bogus warnings about ignored annotations [PR114691]

The middle-end warns about the ANNOTATE_EXPR added for while/for loops
if they declare a var inside of the loop condition.
This is because the assumption is that ANNOTATE_EXPR argument is used
immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond
wraps the ANNOTATE_EXPR inside of a TRUTH_NOT_EXPR, so it no longer
holds.

The following patch fixes that by adding the TRUTH_NOT_EXPR inside of the
ANNOTATE_EXPR argument if any.

2024-04-12  Jakub Jelinek  

PR c++/114691
* semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op
with
TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if any) rather than
ANNOTATE_EXPR itself.

* g++.dg/ext/pr114691.C: New test.

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

Sam James  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #12 from Sam James  ---
P1->P2 after IRC discussion (we released with it & unclear what the intrinsic
behaviour is even supposed to be wrt tbaa).

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

[carlos.seo at linaro dot org via Gcc-bugs]

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

--- Comment #17 from Carlos Eduardo Seo  ---
Noted. Thanks!

[Bug c++/114705] New: [DR 2763] Warn about [[noreturn]] that returns during constant evaluation

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

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

Bug ID: 114705
   Summary: [DR 2763] Warn about [[noreturn]] that returns during
constant evaluation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

clang++ warns here:

```
[[noreturn]] constexpr void f() {}
constexpr int x = (f(), 0);
```

l.C:1:36: warning: function declared 'noreturn' should not return
[-Winvalid-noreturn]
1 |   [[noreturn]] constexpr void f() {}
  |^

but we don't.

Related to https://cplusplus.github.io/CWG/issues/2763.html

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Carlos Eduardo Seo from comment #15)
> I see some failures after this patch on aarch64-linux-gnu:
> 
> FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
> FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
> FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i
> 
> Could you please take a look?

I suspect it is similar to what was already discussed here: 

https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649347.html

[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba

[carlos.seo at linaro dot org via Gcc-bugs]

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

Carlos Eduardo Seo  changed:

   What|Removed |Added

 CC||carlos.seo at linaro dot org

--- Comment #15 from Carlos Eduardo Seo  ---
I see some failures after this patch on aarch64-linux-gnu:

FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i

Could you please take a look?

[Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

[carlos.seo at linaro dot org via Gcc-bugs]

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

Carlos Eduardo Seo  changed:

   What|Removed |Added

 CC||carlos.seo at linaro dot org

--- Comment #23 from Carlos Eduardo Seo  ---
FYI, the new test is failing on aarch64-linux-gnu.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #7 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > Re-confirmed.  Can be reproduced both on a glibc 2.31 and glibc 2.38 system
> > with
> 
> It does work with glibc 2.38, so only glibc 2.31 fails this (and possibly
> other OS).

In Glibc 2.34 libdl was merged into libc, thus it only fails with Glibc < 2.34.

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

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

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

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

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

commit r14-9942-g0fd824d717ca901319864a5eeba4e62b278f8329
Author: Jakub Jelinek 
Date:   Fri Apr 12 19:57:04 2024 +0200

c++: Diagnose or avoid constexpr dtors in classes with virtual bases
[PR114426]

I had another look at this P1 PR today.
You said in the "c++: fix in-charge parm in constexpr" mail back in
December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually
a need for an in-charge parameter in a destructor" but the ICE is because
the destructor is marked implicitly constexpr.
https://eel.is/c++draft/dcl.constexpr#3.2 says that a destructor of a class
with virtual bases is not constexpr-suitable, but we were actually
implementing this just for constructors, so clearly my fault from the
https://wg21.link/P0784R7 implementation.  That paper clearly added that
sentence in there and removed similar sentence just from the constructor
case.

So, the following patch makes sure the
  else if (CLASSTYPE_VBASECLASSES (DECL_CONTEXT (fun)))
{
  ret = false;
  if (complain)
error ("%q#T has virtual base classes", DECL_CONTEXT (fun));
}
hunk is done no just for DECL_CONSTRUCTOR_P (fun), but also
DECL_DESTRUCTOR_P (fun) - in that case just for cxx_dialect >= cxx20,
as for cxx_dialect < cxx20 we already set ret = false; and diagnose
a different error, so no need to diagnose two.

2024-04-12  Jakub Jelinek  

PR c++/114426
* constexpr.cc (is_valid_constexpr_fn): Return false/diagnose with
complain destructors in classes with virtual bases.

* g++.dg/cpp2a/pr114426.C: New test.
* g++.dg/cpp2a/constexpr-dtor16.C: New test.

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/114666] [14 Regression] Signed single bit comparison miscompile at -O2

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

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

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:245595d72818526e2ca857848831e8afa87ae2de

commit r14-9941-g245595d72818526e2ca857848831e8afa87ae2de
Author: Andrew Pinski 
Date:   Wed Apr 10 13:39:01 2024 -0700

match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

The problem is `!a?b:c` pattern will create a COND_EXPR with an 1bit signed
integer
which breaks patterns like `a?~t:t`. This rejects when we have a signed
operand for
both patterns.

Note for GCC 15, I am going to look at the canonicalization of `a?~t:t`
where t
was a constant since I think keeping it a COND_EXPR might be more canonical
and
is what VPR produces from the same IR; if anything expand should handle
which one
is better.

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

PR tree-optimization/114666

gcc/ChangeLog:

* match.pd (`!a?b:c`): Reject signed types for the condition.
(`a?~t:t`): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/bitfld-signed1-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #27 from Jakub Jelinek  ---
(In reply to uecker from comment #26)
> Note that not updating the types seems wrong also pre C23. PR114493 could be
> an example of this:
> 
> typedef struct a a;
> int c;
> int f(a **);
> struct __attribute__((__may_alias__)) a {};

That should be the same type, not different, no?

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #26 from uecker at gcc dot gnu.org ---

Note that not updating the types seems wrong also pre C23. PR114493 could be an
example of this:

typedef struct a a;
int c;
int f(a **);
struct __attribute__((__may_alias__)) a {};

[Bug c++/114634] [11/12/13/14 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

--- Comment #25 from Jakub Jelinek  ---
Created attachment 57935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57935=edit
gcc14-pr114574.patch

What about this patch then?  So far just make check-gcc -j32 checked (though in
a version that did it for !flag_isoc23 as well).
I've talked to Richi on IRC and he prefers not to tweak build_qualified_type,
build_pointer_type_for_mode, build_array_type_1, ... etc. to compute
TYPE_CANONICAL if the base type changed from structural identity to non-NULL
TYPE_CANONICAL, so the patch just updates the most common things (qualified
types and pointers, recursively) and will leave function types, array types and
other derived types created before the type is completed with structural
identity forever.

[Bug target/114696] ICE: in extract_constrain_insn_cached, at recog.cc:2725 insn does not satisfy its constraints: {*anddi_1} with -mapxf -mx32

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

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #2 from H.J. Lu  ---
Created attachment 57934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57934=edit
A patch

I am testing this.

[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin

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

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

--- Comment #6 from Arthur Cohen  ---
(In reply to Richard Biener from comment #5)
> (In reply to Thomas Schwinge from comment #4)
> > If I understood Arthur correctly, GCC/Rust is going to effectively require
> > 'dlopen' (and therefore '--enable-plugin'?), so that means, if the latter's
> > not available we have to auto-disable Rust language front end if enabled
> > '--enable-languages=all' vs. raise a 'configure'-time error if enabled via
> > explicit '--enable-languages=rust'?
> 
> Not sure - --enable-plugin is not about dlopen, it's about exporting all
> GCCs internal symbols for use by a dlopened shared module.  Is the
> macro processing requiring this or is it rather self-contained?
> 
> Being able to dlopen() is something different.

No, it does not require this and is rather self contained. Macro expansion
needs to be able to dlopen() compiled Rust libraries, which contain a specific
type of function our frontend calls as a macro. So we always need to dlopen().

Is there anything similar in other frontends? If so, how does it work on such
platforms which do not support dlopen()?

[Bug tree-optimization/114704] New: Missed optimization : eliminate store if the value is known in all predecessors

[xxs_chy at outlook dot com via Gcc-bugs]

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

Bug ID: 114704
   Summary: Missed optimization : eliminate store if the value is
known in all predecessors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xxs_chy at outlook dot com
  Target Milestone: ---

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

For code like:
```
void src(int *p){
if(*p == 0)
goto then;
else {
dummy();
if(*p == 0)
goto then;
else
return;
}

then:
*p = 0; // *p is already 0, it's dead now
}

```
In then basic block, *p is known to be 0 in all predecessors, thus the store
"*p = 0" is redundant.

[Bug c++/114634] [11/12/13/14 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
   |Crash Issue Encountered in  |Crash Issue Encountered in
   |GCC Compilation of Template |GCC Compilation of Template
   |Code with Aligned Attribute |Code with Aligned Attribute
   ||since r9-1745
 CC||jakub at gcc dot gnu.org
   Priority|P1  |P2

--- Comment #3 from Jakub Jelinek  ---
Started with r9-1745-gbffc62707f731f20ded6993e734a361945684955
I don't think 5+ years old ice-on-invalid-code should be P1.

[Bug target/112914] ~7-9% exec time regression of 436.cactusADM on AMD Zen2

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

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

Filip Kastl  changed:

   What|Removed |Added

Summary|[14 Regression] ~7-9% exec  |~7-9% exec time regression
   |time regression of  |of 436.cactusADM on AMD
   |436.cactusADM on AMD Zen2   |Zen2

--- Comment #2 from Filip Kastl  ---
Looking at a graph comparing trunk to GCC13 and GCC12, I think this isn't a 14
Regression.

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.6=752.100.0=920.100.0=292.100.0;

[Bug ipa/114703] New: Missed devirtualization in rather simple case

[konstantin.vladimirov at gmail dot com via Gcc-bugs]

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

Bug ID: 114703
   Summary: Missed devirtualization in rather simple case
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

See code here:

https://godbolt.org/z/T9Ma7qe3E

struct A {
  virtual int foo() { return 1; }
};

struct B : A {
  int foo() override { return 2; }
  virtual int foo(int i) { return i + 1; }
};

int use(int, int, int);

int main() {
  B *p = new B;
#if 0
  A* q = p;
#else
  A* q = new B;
#endif  
  int result1 = p->foo(1);
  int result2 = p->foo();
  int result3 = q->foo();
  use(result1, result2, result3);
}

clang devirtualizes just fine, gcc lacks this one.

Interesting that if you flip preprocessor switch, everything works with gcc
either.

[Bug tree-optimization/114702] New: Missed optimization: fail to infer c - b != if a + b != c

[xxs_chy at outlook dot com via Gcc-bugs]

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

Bug ID: 114702
   Summary: Missed optimization: fail to infer c - b != if a + b
!= c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xxs_chy at outlook dot com
  Target Milestone: ---

Godbolt link: https://godbolt.org/z/58rxGaabW

```
void src(int a, int b){
if(b + a == 32){
return;
}else{
if(32 - b == a)
dummy();
else
dummy1();
}
}
```

Obviously, "32 - b == a" is false. We can get:

```
void tgt(int a, int b){
if(b + a == 32){
return;
}else{
dummy1();
}
}
```


This is a real-world dead code after inlining functions in QEMU.

[Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #6 from Jakub Jelinek  ---
A 13 years old ICE on an obscure testcase isn't P1, nobody is using hundreds of
megabytes of TLS data, typically one uses hundreds of bytes at most, these
problems are only when one needs more than 2GB of TLS data.

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
   Priority|P3  |P2

[Bug debug/114608] [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Should be fixed on the trunk.

[Bug target/114621] [11/12/13/14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn) with -O -fpie and _Thread_local with large offset

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug c++/114634] [11/12/13/14 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-12

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #29 from Richard Earnshaw  ---
Sorry, I was looking at the wrong pair of insns.  The earlier store to that
location was insn 111.

111: [r212:SI (1 MEM[(struct Vec128 *)_179]+0 S4 A64)] = {r0:SI..r3:SI}

It appears that the problem is a disagreement between alias_set_subset_of ()
and alias_sets_conflict_p().  The former thinks sets 1 and 2 have a permissible
subset relationship (2 is a subset of 1), so removes the later store during
postreload.  The latter is then used by alias_sets_conflict_p which thinks
there is no conflict between the two sets and fails to add a scheduling
dependency before sched2.

[Bug tree-optimization/114701] Missed optimization of loop invariant

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-12
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
There were similar bugs reported already, if not exact dups (b + d being
invariant).  As with the others this depends on store motion.  As with
the others the SCCP pass could compute the overall increment to 'a'.
SCEV would be required to detect that b + d is invariant and to hoist that.

[Bug target/114696] ICE: in extract_constrain_insn_cached, at recog.cc:2725 insn does not satisfy its constraints: {*anddi_1} with -mapxf -mx32

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
The problem is that the APX encoding length for AND exceeds 15 bytes with
-mx32.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #27 from Richard Biener  ---
I think that adjusting an existing upper bound by -1 because of gap peeling
is wrong when that upper bound may not apply to the IV exit.  Because gap
peeling only affects the IV exit test and not the early exit test.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #28 from Richard Biener  ---
(In reply to Richard Earnshaw from comment #27)
> (In reply to Richard Earnshaw from comment #26)
> > (In reply to Richard Biener from comment #25)
> > > I think it's more interesting why
> > > 
> > > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> > > {r0:SI..r3:SI}
> > > 
> > > isn't considered as dependence?  Why does the earlier insn even come into
> > > play?  What's the breaking transform?  I guess insn 119 and 120 are
> > > exchanged?
> > 
> > Because 119 was deleted by postreload.  Doh! I should have spotted that.
> 
> But that ought to be ok, insn 115 is a store in alias set 0, so is picked up
> by later alias analysis.  It's just that the compiler then digs deeper and
> decides that that isn't an addressable object (at the gimple level) so there
> can't really be a dependency.

>   112: r214:SI=r109:SI-0x60
>   115: [r214:SI (0 MEM  [(char * {ref-all})]+0 S4
> A64)] = {r0:SI..r3:SI}
> ; _179 = D.33805
>   117: r217:SI=r109:SI-0x60
>   118: {r0:SI..r3:SI} = [r217:SI (2 D.33805+0 S4 A64)]
>   116: r216:SI=r109:SI-0x10
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> ; r218 = _179
> * 120: r218:V8HI=[r109:SI-0x10 (3 MEM  [(short int
> *)_179]+0 S16 A64)]

but 115 doesn't store at the same address as 119?  Yes, it has the same
value.

So it doesn't seem to be stack-slot sharing.  When we'd share D.33805
with *_179 then we'd have made D.33805 TREE_ADDRESSABLE and adjusted
points-to sets accordingly in update_alias_info_with_stack_vars.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #26 from Tamar Christina  ---
(In reply to Richard Biener from comment #25)
> That means, when the loop takes the early exit we _must_ take that during
> the vector iterations.  Peeling for gaps means if we would take the early
> exit during one of the gap peeled iterations this is a conflicting
> requirement.
> Now - the current analysis guarantees that the early exit conditions can
> be safely evaluated even for the gap iterations, but not the following
> code when the early exit is _not_ taken.
> 
> So peeling for gaps and early exit vect are not compatible?

I don't see why not, as my email explains for the early exits we always go
to the scalar loop, which already adheres to the condition of peeling for
gaps.

I just think that peeling for gaps should not force it to exit from the main
exit.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #27 from Richard Earnshaw  ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> > 
> > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> > {r0:SI..r3:SI}
> > 
> > isn't considered as dependence?  Why does the earlier insn even come into
> > play?  What's the breaking transform?  I guess insn 119 and 120 are
> > exchanged?
> 
> Because 119 was deleted by postreload.  Doh! I should have spotted that.

But that ought to be ok, insn 115 is a store in alias set 0, so is picked up by
later alias analysis.  It's just that the compiler then digs deeper and decides
that that isn't an addressable object (at the gimple level) so there can't
really be a dependency.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #25 from Richard Biener  ---
That means, when the loop takes the early exit we _must_ take that during
the vector iterations.  Peeling for gaps means if we would take the early
exit during one of the gap peeled iterations this is a conflicting requirement.
Now - the current analysis guarantees that the early exit conditions can
be safely evaluated even for the gap iterations, but not the following
code when the early exit is _not_ taken.

So peeling for gaps and early exit vect are not compatible?

[Bug middle-end/114700] middle-end optimization generates wrong code with -fsanitize=undefined

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

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Hu Lin from comment #11)
> I think it doesn't mean that's not a bug with -ftrapv, it should preserve
> all overflow traps. Because it doesn't work, we use -fsanitize=undefined
> instead of it.
> 
> refer: Gcc's trapv is known not always to work correctly.

No, -ftrapv isn't a debugging tool.  There is no overflow in the expression
that GCC actually evaluates (into which the expression has been optimized).
If you have overflow in an expression that is never used, GCC with -ftrapv will
also
eliminate it as unused and won't diagnose the trap.
-fsanitize=undefined behaves in that case actually the same with -O1 and higher
(intentionally, to decrease the cost of the sanitization).  So, one needs to
use -O0 -fsanitize=undefined to get as many cases of UB in the program
diagnosed as possible.

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

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

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

--- Comment #3 from Jakub Jelinek  ---
But guess that won't shut up cppcheck, I'd think it wants | (!!sticky) instead
of
| !!sticky.  Haven't tried though.

[Bug middle-end/114700] middle-end optimization generates wrong code with -fsanitize=undefined

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
(In reply to Hu Lin from comment #14)
> Created attachment 57933 [details]
> Untested fix.

When a pattern already has one if, can't you just add that to the preexisting
if rather than adding yet another one.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #24 from Tamar Christina  ---
(In reply to Richard Biener from comment #23)
> Maybe easier to understand testcase:
> 
> with -O3 -msse4.1 -fno-vect-cost-model we return 20 instead of 8.  Adding
> -fdisable-tree-cunroll avoids the issue.  The upper bound we set on the
> vector loop causes us to force taking the IV exit which continues
> with i == (niter - 1) / VF * VF, but 'niter' is 20 here.

yes,indeed, that's what my patch was arguing last time, but I didn't explain it
well enough.

I'm about to send out v2 (waiting for regtest to finish) which hopefully
articulates this better.

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
Nevertheless it's better for clarity to parentize >> inside |.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #23 from Richard Biener  ---
Maybe easier to understand testcase:

long x[9];
long a[20];
struct { long x; long b[40]; } b;
int __attribute__((noipa))
foo (int n)
{
  int i = 0;
  int k = 0;
  do
{
  if (x[k++])  // early exit, loop upper bound is 8 because of this
break;
  a[i] = b.b[2*i]; // the misaligned 2*i access causes peeling for gaps
}
  while (++i < n);
  return i;
}

int main()
{
  x[8] = 1;
  if (foo (20) != 8)
__builtin_abort ();
  return 0;
}

with -O3 -msse4.1 -fno-vect-cost-model we return 20 instead of 8.  Adding
-fdisable-tree-cunroll avoids the issue.  The upper bound we set on the
vector loop causes us to force taking the IV exit which continues
with i == (niter - 1) / VF * VF, but 'niter' is 20 here.

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

--- Comment #26 from Richard Earnshaw  ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
> 
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
> 
> isn't considered as dependence?  Why does the earlier insn even come into
> play?  What's the breaking transform?  I guess insn 119 and 120 are
> exchanged?

Because 119 was deleted by postreload.  Doh! I should have spotted that.

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

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

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

--- Comment #11 from Jakub Jelinek  ---
Actually I had another look.
Jason said in the c++: fix in-charge parm in constexpr mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually a
need for an in-charge parameter in a destructor"
but the ICE is because the destructor is marked implicitly constexpr.
https://eel.is/c++draft/dcl.constexpr#3.2 says that a destructor of a class
with virtual bases is not constexpr-suitable, but we were actually implementing
this just for constructors, so clearly my fault from the
https://wg21.link/P0784R7 implementation.  That paper clearly added that
sentence in there and removed similar sentence just from the constructor case.
--- gcc/cp/constexpr.cc.jj  2024-04-09 09:29:04.708521907 +0200
+++ gcc/cp/constexpr.cc 2024-04-12 11:45:08.845476718 +0200
@@ -262,18 +262,15 @@ is_valid_constexpr_fn (tree fun, bool co
inform (DECL_SOURCE_LOCATION (fun),
"lambdas are implicitly % only in C++17 and
later");
 }
-  else if (DECL_DESTRUCTOR_P (fun))
+  else if (DECL_DESTRUCTOR_P (fun) && cxx_dialect < cxx20)
 {
-  if (cxx_dialect < cxx20)
-   {
- ret = false;
- if (complain)
-   error_at (DECL_SOURCE_LOCATION (fun),
- "% destructors only available"
- " with %<-std=c++20%> or %<-std=gnu++20%>");
-   }
+  ret = false;
+  if (complain)
+   error_at (DECL_SOURCE_LOCATION (fun),
+ "% destructors only available with "
+ "%<-std=c++20%> or %<-std=gnu++20%>");
 }
-  else if (!DECL_CONSTRUCTOR_P (fun))
+  else if (!DECL_CONSTRUCTOR_P (fun) && !DECL_DESTRUCTOR_P (fun))
 {
   tree rettype = TREE_TYPE (TREE_TYPE (fun));
   if (!literal_type_p (rettype))
patch fixes the ICE too, just will need to add testcase coverage and see what
regresses in the testsuite...

[Bug c++/114695] Template argument deduction and defaulted template template parameters

[vin.piquet at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vincent Piquet  ---
Note that MSVC latest now also fails this last sample regardless of the
language version (but the error differs from C++17 to C++20). Clang (>= 5.0.0)
still happily accepts it, on both versions.

[Bug c++/114695] Template argument deduction and defaulted template template parameters

[vin.piquet at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vincent Piquet  ---
Interesting. Now I think the issue may actually be caused by pack expansion on
the call site. The issue also happens when Foo only has one base class, albeit
with a different error that at least has concise types on both sides.

 test.cpp 
template  struct Bar {
void accept(X value) { }
};

template  struct Foo;

template 
struct Foo...> : Bar... {
template  typename B = Bar>
constexpr static B* slice_by_type(B* self) {
return self;
}

template 
void accept(Us... values) {
(slice_by_type(this)->accept(values), ...);
}
};

int main() {
Foo> foo;
foo.accept(3.14f);
}
 test.cpp 

 GCC 13.2 
test.cpp: In instantiation of 'void Foo...>::accept(Us ...) [with Us =
{float}; Ts = {float}]':
test.cpp:22:15:   required from here
test.cpp:16:27: error: no matching function for call to 'Foo
>::slice_by_type(Foo >*)'
   16 | (slice_by_type(this)->accept(values), ...);
  |  ~^~
test.cpp:10:28: note: candidate: 'template class B>
static constexpr B* Foo...>::slice_by_type(B*) [with B = T; Ts =
{float}]'
   10 | constexpr static B* slice_by_type(B* self) {
  |^
test.cpp:10:28: note:   template argument deduction/substitution failed:
test.cpp:16:27: note:   deduced conflicting types for parameter 'T' ('float'
and 'Bar')
   16 | (slice_by_type(this)->accept(values), ...);
  |  ~^~
 GCC 13.2 

This may however be simplified so much that it becomes another bug. I'm unsure.

[Bug sanitizer/114687] [13 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE: in  |[13 Regression] ICE: in
   |edge_before_returns_twice_c |edge_before_returns_twice_c
   |all, at |all, at
   |gimple-iterator.cc:981  |gimple-iterator.cc:981

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.