[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #19 from Alexander Monakov  ---
(In reply to rguent...@suse.de from comment #18)
> True - but does that catch the cases people are interested and are
> allowed by the FP contraction rules?  I'm thinking of
> 
>  x = a*b + c*d + e + f;
> 
> with -fassociative-math we can form two FMAs here?

Yes; it might be reasonable to limit the match.pd rule to
-fno-associative-math, leaving mul/adds as-is for tree-ssa-math-opts to
recombine otherwise.

>  Of course with
> strict IEEE compliance but allowed FP contraction we can only
> do FMA (a, b, c*d) + e + f, right?

I think so.

>  Does that mean -ffp-contract=on
> only makes sense in absence of any other -ffast-math flags?

Well, the proposal was to make -ffp-contract=fast an '-ffast-math' flag, not
=on. I don't want to judge if '-ffp-contract=on -ffast-math' combination is
reasonable or not, because -ffast-math by itself quite nonsensical already.

[Bug libstdc++/107092] New: std::for_each_n and its friends incorrectly accept size parameters that are not convertible to an integer type

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 107092
   Summary: std::for_each_n and its friends incorrectly accept
size parameters that are not convertible to an integer
type
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

This program shouldn't compile due to [alg.foreach]/16:

> Mandates: The type Size is convertible to an integral type ([conv.integral], 
> [class.conv]).

It's obvious that BadFrom can't be converted to any integral type.

#include 
#include 

struct BadFrom {
template D>
operator D() const
{
return 42.0;
}
};


int main()
{
int arr[42]{};
std::for_each_n(arr, BadFrom{}, [](int){});
}

However, this is accepted by libstdc++, because the conversion is done by
__size_to_integer overloads in stl_algobase.h (added via PR 87982), and
overloads for floating-point types are (probably) incorrectly provided.

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

While I believe the current "is convertible to an integral type" requirement is
defective (as ambiguity is not considered at all), I think libstdc++ should
reject using BadFrom as Size.

[Bug preprocessor/107089] Line-terminating '\' leaves the characters when the next-line is a multi-line comment

[wcs84014 at xcoxc dot com via Gcc-bugs]

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

--- Comment #2 from JohnDoe  ---
>Andrew Pinski 
Thank you for your reply.

That's right. Therefore, I am currently using my own parser.
Nobody needs fix, so you can close this topic.

However, the cause of the bug seems to be a mistake in the pointer count as:
while(++p) <-> while(p++)

I already read the document:
https://gcc.gnu.org/onlineDocscpp

I have used a little M4 in Autotools. Certainly POSIX, portable, real macro,
but minor. I tried to provide a mechanism to customize to ordinary users using
the CPP.

[Bug ipa/96503] attribute alloc_size effect lost after inlining

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

 CC||kees at outflux dot net

--- Comment #1 from Kees Cook  ---
Created attachment 53643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53643&action=edit
PoC showing unexpected __bdos results across inlines

Fixing this is needed for the Linux kernel to do much useful with alloc_size.
Most of the allocators are inline wrappers, for example.

This can be additionally shown to break __builtin_dynamic_object_size(), which
means all FORTIFY_SOURCE of alloc_size-marked inlines is broken. :(
https://godbolt.org/z/jTKjY3s1j

[Bug preprocessor/107089] Line-terminating '\' leaves the characters when the next-line is a multi-line comment

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

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

--- Comment #1 from Andrew Pinski  ---
>I found it when I tried to use the CPP as a general-purpose macro.

Well it is not designed to be a general purpose macro processor.
You might want to try something like m4 instead.

https://en.wikipedia.org/wiki/M4_(computer_language)

Or any other that are already general-purpose macro processors:

https://en.wikipedia.org/wiki/General-purpose_macro_processor

[Bug tree-optimization/102892] [12/13 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:845ee38e9b40230fbb1b9825fb62146fd858cd96

commit r13-2970-g845ee38e9b40230fbb1b9825fb62146fd858cd96
Author: Andrew MacLeod 
Date:   Tue Sep 27 18:42:33 2022 -0400

Remove undefined behaviour from testscase.

There was a patch posted to remove the undefined behaviour from this
testcase, but it appear to never have been applied.

gcc/teststuite/
PR tree-optimization/102892
* gcc.dg/pr102892-1.c: Remove undefined behaviour.

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-29
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
A few issues.
First is:

  if (_26 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  ht_15 = ht_13 + 4294967296;

   [local count: 1073741824]:
  # ht_2 = PHI 

This should be done as:
tmp_ = _26 != 0
tmp1_ = (unsigned long) tmp_
tmp2_ = tmp1_ << 32;
ht_2 = ht_13 + tmp2_;

And then there is huge pattern matching with respect to doing widening multiple
here.

[Bug c++/106649] [C++23] P2448 - Relaxing some constexpr restrictions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/85611] Suboptimal code generation for (potentially) redundant atomic loads

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

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

--- Comment #2 from AK  ---
Don't remember what I was expecting.

[Bug c/107091] Misleading error message "incompatible types when returning ..."

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
clang produces:
:3:12: error: returning 'void *' from a function with incompatible
result type 'double'
return (void *)0;
   ^

MSVC produces:

(3): error C2440: 'return': cannot convert from 'void *' to 'double'

ICC Produces:
(3): error: return value type does not match the function type
  return (void *)0;
 ^

cproc (https://github.com/michaelforney/cproc) produces:
:2:22: error: assignment to arithmetic type must be from arithmetic
type


MSVC seems similar to what is produced for GCC's C++ front-end.
I don't know the best wording here really because convert might even be wrong.

[Bug fortran/107075] ICE in get, at cgraph.h:461

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
> (In reply to Richard Biener from comment #2)
> > 
> > But maybe 'z' shouldn't be of static storage duration ...
> 
> No, I think it shouldn't.  A should be static, and Z should not.

Well, I think the declaration

  integer, pointer :: z => a(2)

makes pointer z IMPLICIT_SAVE.  At least I couldn't find anything in the
standard that makes an exception for declarations in a BLOCK construct.

This is confirmed by Intel and Cray and by replacing 'program p'
by 'subroutine p'.  And in line with gfortran...

Error: Pointer initialization target at (1) must have the SAVE attribute

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #12 from Steve Kargl  ---
On Thu, Sep 29, 2022 at 08:10:14PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #11 from Steve Kargl  ---
> On Thu, Sep 29, 2022 at 07:57:24PM +, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> > 
> > --- Comment #10 from anlauf at gcc dot gnu.org ---
> > (In reply to kargl from comment #9)
> > > This catches the parenthesis.
> > 
> > ... but it is still not sufficient to handle ugly stuff like:
> > 
> >   print *, [real :: 1, +(+(.true.))] * 2
> > 
> 
> Hmmm, there is gfc_resolve_expr().  I don't know if it
> is too early in the parsing to use it.

gfc_resolve_expr() does not help. :(

[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 107033, which changed state.

Bug 107033 Summary: [13 Regression] [modules] Variable template of type trait 
via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107033

   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 107033, which changed state.

Bug 107033 Summary: [13 Regression] [modules] Variable template of type trait 
via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107033

   What|Removed |Added

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

[Bug c++/107033] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
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 100616, which changed state.

Bug 100616 Summary: [modules] ICE when a variable of class taking a non-type 
template argument is defined both inside and outside the module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100616

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |13.0
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Patrick Palka  ---
Fixed

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #9 from Sebastian Pop  ---
Hi, is somebody working on fixing this on arm64?  If not I will be working on
it.

The linux kernel needs this fixed for systemtap and perf probe.

[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 102576, which changed state.

Bug 102576 Summary: [modules] Importing  doesn't permit 
implicit uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102576

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[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 102576, which changed state.

Bug 102576 Summary: [modules] Importing  doesn't permit 
implicit uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102576

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/102576] [modules] Importing doesn't permit implicit uses

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |13.0

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 13

[Bug c++/102576] [modules] Importing doesn't permit implicit uses

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-2969-gc2ee70f20de8133a88553270073226b0f3f55f62
Author: Patrick Palka 
Date:   Thu Sep 29 16:27:30 2022 -0400

c++: implicit lookup of std::initializer_list [PR102576]

Here the lookup for the implicit use of std::initializer_list fails
because we do it using get_namespace_binding, which isn't import aware.
Fix this by using lookup_qualified_name instead.

PR c++/102576

gcc/cp/ChangeLog:

* pt.cc (listify): Use lookup_qualified_name instead of
get_namespace_binding.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr102576_a.H: New test.
* g++.dg/modules/pr102576_b.C: New test.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #11 from Steve Kargl  ---
On Thu, Sep 29, 2022 at 07:57:24PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #9)
> > This catches the parenthesis.
> 
> ... but it is still not sufficient to handle ugly stuff like:
> 
>   print *, [real :: 1, +(+(.true.))] * 2
> 

Hmmm, there is gfc_resolve_expr().  I don't know if it
is too early in the parsing to use it.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #9)
> This catches the parenthesis.

... but it is still not sufficient to handle ugly stuff like:

  print *, [real :: 1, +(+(.true.))] * 2

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

--- Comment #4 from Richard Biener  ---
  /* Skip BImode.  FIXME: BImode probably shouldn't be MODE_INT.  */
  if (m->boolean)
continue;

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-29
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
#3  0x00cbc4a3 in new_cselib_val (hash=6, mode=E_BImode, 
x=0x77170a98) at /home/rguenther/src/gcc2/gcc/cselib.cc:1579
1579  FOR_EACH_MODE_UNTIL (narrow_mode_iter, int_mode)
(gdb) p int_mode
$2 = BImode


but class_narrowest_mode is QImode, so we iterate until OImode which
doesn't have a wider mode (so VOIDmode) but never reach BImode.

Somehow BImode is MODE_INT but declared BOOL_MODE which means we skip it here.
Not sure if that's an error in genmodes - I suspect other places
wouldn't expect to iterate over BImode in FOR_EACH_MODE_UNTIL.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 53642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53642&action=edit
gcc13-pr107065.patch

I'd say it is wrong to fold this already during parsing, we should do such
optimizations only during cp_fold* and later.

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #2 from Richard Biener  ---
I think you have to go with debugging a cross cc1

[Bug target/107061] ENCODEKEY128 clobbers xmm4-xmm6

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11.4, 12.3 and 13.

[Bug target/107061] ENCODEKEY128 clobbers xmm4-xmm6

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-10279-gf8204b10e6bae0721ab74ad77a80b3761ebaf501
Author: H.J. Lu 
Date:   Tue Sep 27 16:19:11 2022 -0700

i386: Mark XMM4-XMM6 as clobbered by encodekey128/encodekey256

encodekey128 and encodekey256 operations clear XMM4-XMM6.  But it is
documented that XMM4-XMM6 are reserved for future usages and software
should not rely upon them being zeroed.  Change encodekey128 and
encodekey256 to clobber XMM4-XMM6.

gcc/

PR target/107061
* config/i386/predicates.md (encodekey128_operation): Check
XMM4-XMM6 as clobbered.
(encodekey256_operation): Likewise.
* config/i386/sse.md (encodekey128u32): Clobber XMM4-XMM6.
(encodekey256u32): Likewise.

gcc/testsuite/

PR target/107061
* gcc.target/i386/keylocker-encodekey128.c: Don't check
XMM4-XMM6.
* gcc.target/i386/keylocker-encodekey256.c: Likewise.

(cherry picked from commit db288230db55dc1ff626f46c708b555847013a41)

[Bug fortran/106985] ICE in gfc_simplify_expr, at fortran/expr.cc:2290

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

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

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

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

commit r12-8796-g2e81790f45c9b7ced4d8c70c3122404854aa5be5
Author: Harald Anlauf 
Date:   Tue Sep 20 22:23:43 2022 +0200

Fortran: NULL pointer dereference in invalid simplification [PR106985]

gcc/fortran/ChangeLog:

PR fortran/106985
* expr.cc (gfc_simplify_expr): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

PR fortran/106985
* gfortran.dg/pr106985.f90: New test.

(cherry picked from commit 8dbb15bc2d019488240c1e69d93121b0347ac092)

[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461

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

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

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

https://gcc.gnu.org/g:2773a90c0f4f323e8ace0593893bc8fcbd2266cf

commit r12-8798-g2773a90c0f4f323e8ace0593893bc8fcbd2266cf
Author: Harald Anlauf 
Date:   Tue Sep 27 20:54:28 2022 +0200

Fortran: error recovery while simplifying intrinsic UNPACK [PR107054]

gcc/fortran/ChangeLog:

PR fortran/107054
* simplify.cc (gfc_simplify_unpack): Replace assert by condition
that terminates simplification when there are not enough elements
in the constructor of argument VECTOR.

gcc/testsuite/ChangeLog:

PR fortran/107054
* gfortran.dg/pr107054.f90: New test.

(cherry picked from commit 78bc6497fc61bbdacfb416ee0246a775360d9af6)

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

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

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

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

https://gcc.gnu.org/g:22c2658a8b6ae9ece8b33bc483c04a767168b5f4

commit r12-8797-g22c2658a8b6ae9ece8b33bc483c04a767168b5f4
Author: Harald Anlauf 
Date:   Wed Sep 21 19:55:30 2022 +0200

Fortran: fix ICE in generate_coarray_sym_init [PR82868]

gcc/fortran/ChangeLog:

PR fortran/82868
* trans-decl.cc (generate_coarray_sym_init): Skip symbol
if attr.associate_var.

gcc/testsuite/ChangeLog:

PR fortran/82868
* gfortran.dg/associate_26a.f90: New test.

(cherry picked from commit bc71318a91286b5f00e88f07aab818ac82510692)

[Bug middle-end/107088] [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
The patch introduces

scalar_int_mode int_mode;
if (REG_P (x) && is_int_mode (mode, &int_mode)
&& REG_VALUES (REGNO (x)) != NULL
&& (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
  {
rtx copy = shallow_copy_rtx (x);
scalar_int_mode narrow_mode_iter;
FOR_EACH_MODE_UNTIL (narrow_mode_iter, int_mode)   // <
  {
PUT_MODE_RAW (copy, narrow_mode_iter);
cselib_val *v = cselib_lookup (copy, narrow_mode_iter, 0, VOIDmode);
if (v)
  {
rtx sub = lowpart_subreg (narrow_mode_iter, e->val_rtx, int_mode);
if (sub)
  new_elt_loc_list (v, sub);
  }
  }
  }

The failing assert is at the for-loop which is supposed to iterate only over
integer modes up to int_mode. I'm not familiar with ia64; is there any machine
which I could use for debugging?

The failing assert is

gcc_checking_assert (m_mode != E_VOIDmode);

which is triggered by get_known_wider. Would be interesting to see the initial
value of int_mode and if/how FOR_EACH_MODE_UNTIL actually ends up with
E_VOIDmode.

[Bug target/107061] ENCODEKEY128 clobbers xmm4-xmm6

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-12 branch has been updated by H.J. Lu :

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

commit r12-8795-gf1454a75c9a165c0ba30833f23f799044fd7a7fe
Author: H.J. Lu 
Date:   Tue Sep 27 16:19:11 2022 -0700

i386: Mark XMM4-XMM6 as clobbered by encodekey128/encodekey256

encodekey128 and encodekey256 operations clear XMM4-XMM6.  But it is
documented that XMM4-XMM6 are reserved for future usages and software
should not rely upon them being zeroed.  Change encodekey128 and
encodekey256 to clobber XMM4-XMM6.

gcc/

PR target/107061
* config/i386/predicates.md (encodekey128_operation): Check
XMM4-XMM6 as clobbered.
(encodekey256_operation): Likewise.
* config/i386/sse.md (encodekey128u32): Clobber XMM4-XMM6.
(encodekey256u32): Likewise.

gcc/testsuite/

PR target/107061
* gcc.target/i386/keylocker-encodekey128.c: Don't check
XMM4-XMM6.
* gcc.target/i386/keylocker-encodekey256.c: Likewise.

(cherry picked from commit db288230db55dc1ff626f46c708b555847013a41)

[Bug c/107091] New: Misleading error message "incompatible types when returning ..."

[Keith.S.Thompson at gmail dot com via Gcc-bugs]

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

Bug ID: 107091
   Summary: Misleading error message "incompatible types when
returning ..."
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

When I compile this source file:

double bad(void) {
return (void*)0;
}

double good(void) {
return 42;
}

I get this output from gcc 12.2.0 (and from earlier versions):

c.c: In function ‘bad’:
c.c:2:12: error: incompatible types when returning type ‘void *’ but ‘double’
was expected
2 | return (void*)0;
  |^

It's true that it's a constraint violation, and it's true that void* and double
are incompatible, but type compatibility is not required here. The problem is
that there is no implicit conversion from void* to double.

In the "good" function, int and double are also incompatible types, but there
is an implicit conversion so the statement is valid.

Note that g++ produces this correct message for the equivalent C++ code:

c.cpp: In function ‘double bad()’:
c.cpp:2:19: error: cannot convert ‘void*’ to ‘double’ in return
2 | return (void*)0;
  |  

This was brought to my attention by this post on Stack Overflow:
https://stackoverflow.com/q/73899947/827263

Reference for compatible types: C11 (or N1570) 6.2.7.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #8 from Marc Glisse  ---
(simplify
  (bit_not (bit_not @0))
  @0)

while in an other place we have

(simplify
 (bit_and @0 integer_all_onesp)
  (non_lvalue @0))

[Bug libstdc++/105505] P1951R1 (Default Arguments for pair's Forwarding Constructor) is unimplemented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/97930] pair is not a structural type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||12.1.0
 Blocks||88322
  Known to fail||11.3.0
   Target Milestone|--- |11.4


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
[Bug 88322] Implement C++20 library features.

[Bug middle-end/107090] [aarch64] sequence logic should be combined with mul and umulh

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/93046] [10 Regression] ICE in cp_gimplify_init_expr

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

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

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

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

commit r13-2964-gbbdb5612f6661f2c64b0c0f1d2291cb59fde2b40
Author: Jason Merrill 
Date:   Fri Sep 23 09:07:22 2022 -0400

c++: fix class-valued ?: extension

When the gimplifier encounters the same TARGET_EXPR twice, it evaluates
TARGET_EXPR_INITIAL the first time and clears it so that the later
evaluation is just the temporary.  With this testcase, using the extension
to treat an omitted middle operand as repeating the first operand, that led
to doing a bitwise copy of the S(1) temporary on return rather than
properly
calling the copy constructor.

We can't use S(1) to initialize the return value here anyway, because we
need to materialize it into a temporary so we can convert it to bool and
determine which arm we're evaluating.  So let's just treat the middle
operand as an xvalue.

PR c++/93046

gcc/cp/ChangeLog:

* call.cc (build_conditional_expr): For a?:c extension, treat
a reused class prvalue as an xvalue.

gcc/testsuite/ChangeLog:

* g++.dg/ext/cond4.C: Add runtime test.

[Bug c/107090] New: [aarch64] sequence logic should be combined with mul and umulh

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 107090
   Summary: [aarch64] sequence logic should be combined with mul
and umulh
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* test case: https://godbolt.org/z/x5jMhqW8s
```
#  define BN_BITS432
#  define BN_MASK2(0xL)
#  define BN_MASK2l   (0xL)
#  define BN_MASK2h   (0xL)
#  define BN_MASK2h1  (0x8000L)
#  define LBITS(a)((a)&BN_MASK2l)
#  define HBITS(a)(((a)>>BN_BITS4)&BN_MASK2l)
#  define L2HBITS(a)  (((a)<

[Bug preprocessor/107089] New: Line-terminating '\' leaves the characters when the next-line is a multi-line comment

[wcs84014 at xcoxc dot com via Gcc-bugs]

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

Bug ID: 107089
   Summary: Line-terminating '\' leaves the characters when the
next-line is a multi-line comment
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wcs84014 at xcoxc dot com
  Target Milestone: ---

I found it when I tried to use the CPP as a general-purpose macro.

~$ gcc -v
Target: x86_64-linux-gnu /gcc version 11.2.0 (Debian 11.2.0-13)

~$ cat a.c
1=\
//xyz
ok*/

2=\
/*xyz
NG*/

3=\(sp)(nl)
/*xyz
NG*/

4=\
//*xyz
ok:gcc NG:-traditional*/


~$ cat a.c | cpp -P -C -nostdinc  #-traditional-cpp
1=//xyz
ok*/
2=/*xyz
z
NG*/
:9:3: warning: backslash and newline separated by space
3=/*xyz
yz
NG*/
4=//*xyz
ok:gcc NG:-traditional*/

[Bug middle-end/107088] New: [13 Regression] cselib ICE building __trunctfxf2 on ia64

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

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

Bug ID: 107088
   Summary: [13 Regression] cselib ICE building __trunctfxf2 on
ia64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: stefansf at linux dot ibm.com
  Target Milestone: ---
Target: ia64-*-*

Created attachment 53641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53641&action=edit
preprocessed source

commit d0b00b63a39108311f2e6f9cbe9072579f57df7c, "cselib: Keep track of further
subvalue relations", introduced an ICE building libgcc for ia64-linux-gnu.
Compile with attached testcase with -O2.

/scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c: In function
'__trunctfxf2':
/scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c:52:1: internal
compiler error: in require, at machmode.h:297
   52 | }
  | ^
0x876576 opt_mode::require() const
/scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:297
0x876576 void mode_iterator::get_known_wider(scalar_int_mode*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:1124
0x876576 new_cselib_val
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1579
0x873e4e cselib_lookup_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2315
0x873e4e cselib_lookup(rtx_def*, machine_mode, int, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431
0x876aff cselib_hash_rtx
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1308
0x876e69 cselib_hash_rtx
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1505
0x873c5f cselib_lookup_1
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2375
0x873c5f cselib_lookup(rtx_def*, machine_mode, int, machine_mode)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431
0x877a6a cselib_record_sets
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2932
0x87867d cselib_process_insn(rtx_insn*)
/scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:3159
0x1661d1c dse_step1
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:2771
0x1661d1c rest_of_handle_dse
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3687
0x1661d1c execute
/scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3803
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 middle-end/107028] [13 Regression][OpenACC] ICE in install_var_field, at omp-low.cc:797

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Tobias Burnus  ---
Close as FIXED - thanks for the patch!

[Bug c++/107084] Program does not link with Standard Library Header Unit but with correspoding #include

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of bug 99377.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

--- Comment #7 from Francois-Xavier Coudert  ---
@Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
checking that the floating-point modes (rounding mode, underflow mode, and
halting modes) can be set and restored. It is not actually performing any FP
operation at all.

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

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

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

Bug 107069 Summary: string assignment triggers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107069

   What|Removed |Added

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

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||joerg.rich...@pdv-fs.de

--- Comment #23 from Martin Sebor  ---
*** Bug 107069 has been marked as a duplicate of this bug. ***

[Bug c++/107069] string assignment triggers warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2022-9-29
 Resolution|--- |DUPLICATE
  Known to work||13.0
  Known to fail||12.2.0

--- Comment #2 from Martin Sebor  ---
The warning doesn't show up on trunk (GCC 13) with the fix in r13-2618 so let's
mark it a duplicate of pr105329.

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

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

--- Comment #6 from Richard Earnshaw  ---
Whilst the patch is probably fine and a better way of doing this, it won't fix
the test failure.  I think your problem is that you're assuming that an
exception will cause a trap in hardware.  That's not how IEEE says FP
exceptions have to work.  On aarch64, for most implementations the exceptions
are accumulated in a status register and you have to read that register to see
if an FP exception occurred.

[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Keywords||ra

--- Comment #3 from Uroš Bizjak  ---
RA issue.

[Bug libstdc++/78530] std::copy of volatile array triggers invalid conversion error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.0
   Keywords|wrong-code  |rejects-valid
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
This was fixed for GCC 9.1 by commit r9-1943-g20a0c4e3dc9948

It was then broken again by r10-530-gbe9e458d8bed98 (which was PR 94013) and
fixed again by r10-6999-g462f6c2041fad0

[Bug middle-end/107087] New: bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of size 4 [-Wstringop-ove

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

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

Bug ID: 107087
   Summary: bits/stl_algobase.h:431: warning: 'void*
__builtin_memcpy(void*, const void*, unsigned int)'
reading between 8 and 2147483644 bytes from a region
of size 4 [-Wstringop-overread]
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-pc-linux-gnu

Created attachment 53640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53640&action=edit
Gzipped preprocessed output

There are bogus warnings when compiling the attached file using:

g++ -O2 3.ii -m32 -c

/usr/include/c++/12/bits/stl_algobase.h:431:30: warning: ‘void*
__builtin_memcpy(void*, const void*, unsigned int)’ reading between 8 and
2147483644 bytes from a region of size 4 [-Wstringop-overread]
  431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
/usr/include/c++/12/bits/stl_algobase.h:431:30: warning: ‘void*
__builtin_memcpy(void*, const void*, unsigned int)’ reading between 8 and
2147483644 bytes from a region of size 4 [-Wstringop-overread]
  431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~


The warnings are still there on trunk, but -Warray-bounds instead of
-Wstringop-overread.

[Bug c++/107079] [10/11/12/13 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-29
Summary|ICE initializing|[10/11/12/13 Regression]
   |lifetime-extended constexpr |ICE initializing
   |variable that stores its|lifetime-extended constexpr
   |this pointer|variable that stores its
   ||this pointer
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r269003:

commit e8b3c1bc3ba22dcf59b9c743f11d4cb2bc5d7792
Author: Jason Merrill 
Date:   Mon Feb 18 20:01:50 2019 -0500

PR c++/89336 - multiple stores in constexpr stmt.

[Bug middle-end/107028] [13 Regression][OpenACC] ICE in install_var_field, at omp-low.cc:797

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

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

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

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

commit r13-2957-g8ace67ddb97698709a622b2f8ba2718524aa5eeb
Author: Julian Brown 
Date:   Tue Sep 27 17:39:59 2022 +

OpenACC: whole struct vs. component mappings (PR107028)

This patch fixes an ICE when both a complete struct variable and
components of that struct are mapped on the same directive for OpenACC,
using a modified version of the scheme used for OpenMP in the following
patch:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html

A new function has been added to make sure that the mapping kinds of
the whole struct and the member access are compatible -- conservatively,
so as not to copy more to/from the device than the user expects.

This version of the patch uses a different method to detect duplicate
clauses for OpenACC in oacc_resolve_clause_dependencies, and removes
the now-redundant check in omp_accumulate_sibling_lists.  (The latter
check would no longer trigger when we map the whole struct on the same
directive because the component-mapping clauses are now deleted before
the check is executed.)

2022-09-28  Julian Brown  

gcc/
PR middle-end/107028
* gimplify.cc (omp_check_mapping_compatibility,
oacc_resolve_clause_dependencies): New functions.
(omp_accumulate_sibling_list): Remove redundant duplicate clause
detection for OpenACC.
(build_struct_sibling_lists): Skip deleted groups.  Don't build
sibling
list for struct variables that are fully mapped on the same
directive
for OpenACC.
(gimplify_scan_omp_clauses): Call oacc_resolve_clause_dependencies.

gcc/testsuite/
PR middle-end/107028
* c-c++-common/goacc/struct-component-kind-1.c: New test.
* g++.dg/goacc/pr107028-1.C: New test.
* g++.dg/goacc/pr107028-2.C: New test.
* gfortran.dg/goacc/mapping-tests-5.f90: New test.

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #18 from rguenther at suse dot de  ---
On Thu, 29 Sep 2022, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
> 
> --- Comment #17 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #16)
> > I do think that since the only way to
> > preserve expression boundaries is by PAREN_EXPR
> 
> Yes, but...
> 
> >  that the middle-end
> > shouldn't care about FAST vs. ON (well, it cannot), but the language
> > frontends need to ensure to emit PAREN_EXPRs for =ON and omit them for
> > =FAST.
> 
> this will also prevent reassociation across statements too. Doing FMA
> contraction in the frontends via a match.pd rule doesn't have this drawback.

True - but does that catch the cases people are interested and are
allowed by the FP contraction rules?  I'm thinking of

 x = a*b + c*d + e + f;

with -fassociative-math we can form two FMAs here?  Of course with
strict IEEE compliance but allowed FP contraction we can only
do FMA (a, b, c*d) + e + f, right?  Does that mean -ffp-contract=on
only makes sense in absence of any other -ffast-math flags?

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

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

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

--- Comment #19 from Jonathan Wakely  ---
Dunno yet, I need to remind myself what that old patch did, and decide if it's
the right approach. I'm busy with other things for now so haven't looked at it
yet.

[Bug target/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Reload starts with:

(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
(vec_concat:V2DF (reg:DF 182)
(reg:DF 182))) "pr107057.c":7:10 5952 {vec_concatv2df}
 (expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
])
(nil)))

And reloads the insn with:

(insn 392 67 393 5 (set (reg:DI 0 ax [330])
(symbol_ref/u:DI ("*.LC0") [flags 0x2])) "pr107057.c":7:10 82
{*movdi_internal}
 (nil))
(insn 407 393 76 5 (set (reg:DI 4 si [331])
(reg:DI 0 ax [330])) "pr107057.c":7:10 82 {*movdi_internal}
 (nil))
(insn 76 407 101 5 (set (reg/v:V2DF 24 xmm4 [orig:108 x ] [108])
(vec_concat:V2DF (mem/u/c:DF (reg:DI 0 ax [330]) [0  S8 A64])
(mem/u/c:DF (reg:DI 4 si [331]) [0  S8 A64]))) "pr107057.c":7:10
5952 {vec_concatv2df}
 (expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF 1.0e+0 [0x0.8p+1]) repeated x2
])
(nil)))

Non-matching mem RTXes violate the candidate (x,m,1) constraint (and also insn
constraint):

(define_insn "vec_concatv2df"
  [(set (match_operand:V2DF 0 "register_operand" "=x,x,v,x,v,x,x, v,x,x")
(vec_concat:V2DF
  (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,vm,0,0")
  (match_operand:DF 2 "nonimm_or_0_operand"  " x,x,v,1,1,m,m,
C,x,m")))]
  "TARGET_SSE
   && (!(MEM_P (operands[1]) && MEM_P (operands[2]))
   || (TARGET_SSE3 && rtx_equal_p (operands[1], operands[2])))"

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Mine then.

[Bug sanitizer/107086] gcc trunkc at -O1 failed to detect a stack-use-after-return

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can't reproduce it locally for some reason.
Anyway, it's a use-after-scope where an address of a function argument is
taken. I'm not sure, but it's something we don't currently support.

Note clang catches that only with -O1+.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Thibaut M.  ---
Jonathan, it looks like you have a good idea of what could be the patch, could
you detail it please? :) Or are you referring to the one you already suggested
here https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html ?

Thanks for pointing out the thread about exception optimization, very
instructive.

[Bug sanitizer/107086] New: gcc trunkc at -O1 failed to detect a stack-use-after-return

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107086
   Summary: gcc trunkc at -O1 failed to detect a
stack-use-after-return
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
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: ---

%gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-519196a27cf534e94f158733b25a4f9d10737031/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-519196a27cf534e94f158733b25a4f9d10737031
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220921 (experimental) (GCC)
%
%cat a.c
int a, b;
int *c;
int d() { return 0; }
static int e(int f) {
  int h[144];
  for (; b;)
h;
  for (; a >= 0; a = -2)
c = &f;
  return f;
}
int main() {
  e(0);
  *c = 0;
  if (d()) {
int g[28];
g;
  }
}
%
%
%gcc-tk -O1 -w -fsanitize=address a.c && ./a.out
%
%gcc-tk -O2 -w -fsanitize=address a.c && ./a.out
=
==491884==ERROR: AddressSanitizer: stack-use-after-return on address
0x7f9cd120 at pc 0x004010e1 bp 0x7ffe4ecb6150 sp 0x7ffe4ecb6148
WRITE of size 4 at 0x7f9cd120 thread T0
#0 0x4010e0 in main
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:14
#1 0x7f9cd3a71082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40114d in _start
(/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.out+0x40114d)

Address 0x7f9cd120 is located in stack of thread T0 at offset 32 in frame
#0 0x40121f in e
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:4

  This frame has 1 object(s):
[32, 36) 'f' (line 4) <== Memory access at offset 32 is inside this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:14
in main
Shadow bytes around the buggy address:
  0x0ff41a1f7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff41a1f8000: f5 f5 f5 f5[f5]f5 f5 f5 00 00 00 00 00 00 00 00
  0x0ff41a1f8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff41a1f8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==491884==ABORTING
%

Compiler explorer: https://godbolt.org/z/rn9qjrb5K

>From the assembly code, we can see that the reason probably is the function
`e()` got inlined so that the stack variable didn't get instrumented.

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Ever confirmed|0   |1
   Keywords||wrong-code
Version|unknown |13.0
   Last reconfirmed||2022-09-29
 Resolution|INVALID |---
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
Yes, I think that's a bug.

[Bug middle-end/106982] [10/11/12/13 Regression][OpenACC] ICE incorrect sharing of tree nodes with nested reduction / .GOACC_REDUCTION

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Tobias Burnus
:

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

commit r12-8793-gafea1ae84f0c3e64137289c44c756195babe1845
Author: Tobias Burnus 
Date:   Mon Sep 26 12:45:28 2022 +0200

OpenACC: Fix reduction tree-sharing issue [PR106982]

The tree for var == incoming == outgound was
'MEM  [(double *)&reduced]' which caused the ICE
"incorrect sharing of tree nodes".

PR middle-end/106982

gcc/ChangeLog:

* omp-low.cc (lower_oacc_reductions): Add some unshare_expr.

gcc/testsuite/ChangeLog:

* c-c++-common/goacc/reduction-7.c: New test.
* c-c++-common/goacc/reduction-8.c: New test.

(cherry picked from commit d3df98807b58df186061ad52ff87cc09ba593e9b)

[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r13-2953-ga1f7f9541c2b20eb44750b9c15cd831c62d67f21
Author: Nathan Sidwell 
Date:   Wed Sep 28 09:21:14 2022 -0700

c++: import/export NTTP objects

This adds smarts to the module machinery to handle NTTP object
VAR_DECLs.  Like typeinfo objects, these must be ignored in the symbol
table, streamed specially and recreated on stream in.

gcc/cp/
PR c++/100616
* module.cc (enum tree_tag): Add tt_nttp_var.
(trees_out::decl_node): Handle NTTP objects.
(trees_in::tree_node): Handle tt_nttp_var.
(depset::hash::add_binding_entry): Skip NTTP objects.

gcc/testsuite/
PR c++/100616
* g++.dg/modules/100616_a.H: New.
* g++.dg/modules/100616_b.C: New.
* g++.dg/modules/100616_c.C: New.
* g++.dg/modules/100616_d.C: New.

[Bug target/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with r10-1982-g4eb503965ac70e74 which only exposed it I guess.

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602475.html

[Bug target/107076] ICE in gen_untyped_call, at config/i386/i386.md:15992

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-09-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, it's been there since the introduction of target_clones attribute in
r6-4443-g3b1661a9b93fe800.
I may want to take a look.

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #17 from Alexander Monakov  ---
(In reply to Richard Biener from comment #16)
> I do think that since the only way to
> preserve expression boundaries is by PAREN_EXPR

Yes, but...

>  that the middle-end
> shouldn't care about FAST vs. ON (well, it cannot), but the language
> frontends need to ensure to emit PAREN_EXPRs for =ON and omit them for
> =FAST.

this will also prevent reassociation across statements too. Doing FMA
contraction in the frontends via a match.pd rule doesn't have this drawback.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Tomasz Kłoczko  ---
Tested -O2 + LTO + -flifetime-dse=1 and it crashes.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Tomasz Kłoczko  ---
Tested -O2 + LTO + -flifetime-dse=1 and it crashes.

[Bug middle-end/25521] change semantics of const volatile variables

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jose E. Marchesi :

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

commit r13-2952-ga0aafbc324aa90421f0ce99c6f5bbf64ed163da6
Author: Jose E. Marchesi 
Date:   Thu Aug 4 21:16:10 2022 +0200

place `const volatile' objects in read-only sections

It is common for C BPF programs to use variables that are implicitly
set by the BPF loader and run-time.  It is also necessary for these
variables to be stored in read-only storage so the BPF verifier
recognizes them as such.  This leads to declarations using both
`const' and `volatile' qualifiers, like this:

  const volatile unsigned char is_allow_list = 0;

Where `volatile' is used to avoid the compiler to optimize out the
variable, or turn it into a constant, and `const' to make sure it is
placed in .rodata.

Now, it happens that:

- GCC places `const volatile' objects in the .data section, under the
  assumption that `volatile' somehow voids the `const'.

- LLVM places `const volatile' objects in .rodata, under the
  assumption that `volatile' is orthogonal to `const'.

So there is a divergence, that has practical consequences: it makes
BPF programs compiled with GCC to not work properly.

When looking into this, I found this bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
  "change semantics of const volatile variables"

which was filed back in 2005, long ago.  This report was already
asking to put `const volatile' objects in .rodata, questioning the
current behavior.

While discussing this in the #gcc IRC channel I was pointed out to the
following excerpt from the C18 spec:

   6.7.3 Type qualifiers / 5 The properties associated with qualified
 types are meaningful only for expressions that are
 lval-values [note 135]

   135) The implementation may place a const object that is not
volatile in a read-only region of storage. Moreover, the
implementation need not allocate storage for such an object if
its $ address is never used.

This footnote may be interpreted as if const objects that are volatile
shouldn't be put in read-only storage.  Even if I personally was not
very convinced of that interpretation (see my earlier comment in BZ
25521) I filed the following issue in the LLVM tracker in order to
discuss the matter:

  https://github.com/llvm/llvm-project/issues/56468

As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14
reflectors about this.  He reported that the reflectors don't think
footnote 135 has any normative value.

So, not having a normative mandate on either direction, there are two
options:

a) To change GCC to place `const volatile' objects in .rodata instead
   of .data.

b) To change LLVM to place `const volatile' objects in .data instead
   of .rodata.

Considering that:

- One target (bpf-unknown-none) breaks with the current GCC behavior.

- No target/platform relies on the GCC behavior, that we know.

- Changing the LLVM behavior at this point would be very severely
  traumatic for the BPF people and their users.

I think the right thing to do at this point is a).
Therefore this patch.

Regtested in x86_64-linux-gnu and bpf-unknown-none.
No regressions observed.

gcc/ChangeLog:

PR middle-end/25521
* varasm.cc (categorize_decl_for_section): Place `const volatile'
objects in read-only sections.
(default_select_section): Likewise.

gcc/testsuite/ChangeLog:

PR middle-end/25521
* lib/target-supports.exp (check_effective_target_elf): Define.
* gcc.dg/pr25521.c: New test.

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Roy Jacobson  ---
Thanks! But a Base const& is still not detected:

static_assert(__reference_constructs_from_temporary(Base const&, Derived));

And in this case I think it _is_ a bug that this doesn't compile?

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Tomasz Kłoczko  ---
(In reply to Jakub Jelinek from comment #7)
> Then as documented, -fno-lifetime-dse or -flifetime-dse=1 can be a temporary
> workaround, but as has been said, such code is undefined behavior and should
> be fixed in the application.
> See
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flifetime-dse

I just realised that +year ago working on my packages I've started removing all
hardcodes in source tree warnig and optimisation flags to be able to controll
that on rpm build layer and when I've removed in mesa -flifetime-dse=1 it
started crashing as well.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Tomasz Kłoczko  ---
(In reply to Andrew Pinski from comment #6)
[..]
> Then almost certainly -fno-lifetime-dse will help.

Tested -O2 + LTO + -fno-lifetime-dse and it crashes.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

--- Comment #7 from Jakub Jelinek  ---
Then as documented, -fno-lifetime-dse or -flifetime-dse=1 can be a temporary
workaround, but as has been said, such code is undefined behavior and should be
fixed in the application.
See
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flifetime-dse

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Tomasz Kłoczko from comment #5)
> FWD of the firebird developer from
> https://github.com/FirebirdSQL/firebird/issues/7308#issuecomment-1262043660
> 
> "Firebird (that code left from interbase times) traditionally zeroes
> memory when allocating a lot of internal data structures using function
> like calloc(). When moving from C to C++ it was wrapped into operator
> new of some base class in order to avoid type casts, be able to use
> ctors and a lot of other c++ features. 20 years ago it was fine. Some
> years ago an optimization removing any data initalization in new (data
> returned by it is not initialized according to standard). By itself it
> did not affect the code - our calloc() is placed into separate file,
> it's not inline. But together with cross-file optimization... we get
> what you've seen.
> 
> Certainly correct fix is to move memory initialization into ctor - but
> that was not done yet.
> 
> May be there some more issues with LTO, I did not learn it deeper."

Then almost certainly -fno-lifetime-dse will help.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Tomasz Kłoczko  ---
FWD of the firebird developer from
https://github.com/FirebirdSQL/firebird/issues/7308#issuecomment-1262043660

"Firebird (that code left from interbase times) traditionally zeroes
memory when allocating a lot of internal data structures using function
like calloc(). When moving from C to C++ it was wrapped into operator
new of some base class in order to avoid type casts, be able to use
ctors and a lot of other c++ features. 20 years ago it was fine. Some
years ago an optimization removing any data initalization in new (data
returned by it is not initialized according to standard). By itself it
did not affect the code - our calloc() is placed into separate file,
it's not inline. But together with cross-file optimization... we get
what you've seen.

Certainly correct fix is to move memory initialization into ctor - but
that was not done yet.

May be there some more issues with LTO, I did not learn it deeper."

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
#include 
using namespace std;
struct Base {};
struct Derived : Base {};
static_assert( conjunction_v, is_constructible> );

This fails (as expected) and so the reference_constructs_from_temporary is
required to be false.

[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Btw. started with r12-4278-g74ccca380cde5e79.

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

--- Comment #1 from Jonathan Wakely  ---
You can't bind a non-const Base& to a Derived prvalue, so this seems correct.
The reference doesn't bind to it at all, so it doesn't bind to a temporary.

[Bug target/107025] gas doesn't accept code produced by -mcpu=thunderx3t110

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r13-2940-g0f244d848cffeda68f0eb4c5bb9c7e629bf2e957
Author: Richard Sandiford 
Date:   Thu Sep 29 11:32:53 2022 +0100

aarch64: Remove AARCH64_FL_RCPC8_4 [PR107025]

AARCH64_FL_RCPC8_4 is an odd-one-out in that it has no associated
entry in aarch64-option-extensions.def.  This means that, although
it is internally separated from AARCH64_FL_V8_4A, there is no
mechanism for turning it on and off individually, independently
of armv8.4-a.

The only place that the flag was used independently was in the
entry for thunderx3t110, which enabled it alongside V8_3A.
As noted in PR107025, this means that any use of the extension
will fail to assemble.

In the PR trail, Andrew suggested removing the core entry.
That might be best long-term, but since the barrier for removing
command-line options without a deprecation period is very high,
this patch instead just drops the flag from the core entry.
We'll still produce correct code.

gcc/
PR target/107025
* config/aarch64/aarch64.h (oAARCH64_FL_RCPC8_4): Delete.
(AARCH64_FL_FOR_V8_4A): Update accordingly.
(AARCH64_ISA_RCPC8_4): Use AARCH64_FL_V8_4A directly.
* config/aarch64/aarch64-cores.def (thunderx3t110): Remove
AARCH64_FL_RCPC8_4.

[Bug c++/107085] New: __reference_constructs_from_temporary does not detect static up-cast

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

Bug ID: 107085
   Summary: __reference_constructs_from_temporary does not detect
static up-cast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roi.jacobson1 at gmail dot com
  Target Milestone: ---

This example:

struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base&, Derived));

fails to compile, but according to p2255r1 it seems correct to me.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
It may be related to -fno-lifetime-dse, can you please try this option if it
helps?

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #29 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html
still awaits review, the rest should be fixed.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

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

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

commit r13-2932-ga5a9237e2a78a9854f1f87e63ef5619cf8ba7360
Author: Jakub Jelinek 
Date:   Thu Sep 29 12:04:24 2022 +0200

driver, cppdefault: Unbreak bootstrap on Debian/Ubuntu [PR107059]

My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
apparently broke bootstrap on some Debian/Ubuntu setups.
Those multiarch targets put some headers into
/usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
/usr/include/bits/.
This is handled by
/* /usr/include comes dead last.  */
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2
},
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0
},
in cppdefault.cc, where the 2 in the last element of the first initializer
means the entry is ignored on non-multiarch and suffixed by the multiarch
dir otherwise, so installed gcc has search path like:

/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include

/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
(when installed with DESTDIR=/home/jakub/gcc/obj01inst).
Now, when fixincludes is run, it is processing the whole /usr/include dir
and all its subdirectories, so floatn{,-common.h} actually go into
.../include-fixed/x86_64-linux-gnu/bits/floatn{,-common.h}
because that is where they appear in /usr/include too.
In some setups, /usr/include also contains /usr/include/bits ->
x86_64-linux-gnu/bits
symlink and after the r13-2896 tweak it works.
In other setups there is no /usr/include/bits symlink and when one
 #include 
given the above search path, it doesn't find the fixincluded header,
as
   
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/bits/floatn.h
doesn't exist and
   
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu/bits/floatn.h
isn't searched and so
/usr/include/x86_64-linux-gnu/bits/floatn.h
wins and we fail because of typedef whatever _Float128; and similar.
The following patch ought to fix this.  The first hunk by arranging that
the installed search path actually looks like:

/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include

/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu

/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
and thus for include-fixed it treats it the same as /usr/include.
The second FIXED_INCLUDE_DIR entry there is:
 { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
   /* A multilib suffix needs adding if different multilibs use
  different headers.  */
 #ifdef SYSROOT_HEADERS_SUFFIX_SPEC
   1
 #else
   0
 #endif
 },
where SYSROOT_HEADERS_SUFFIX_SPEC is defined only on vxworks or
mips*-mti-linux
and arranges for multilib path to be appended there.  Neither of those
systems is multiarch.
This isn't enough, because when using the -B option, the driver adds
-isystem .../include-fixed in another place, so the second hunk modifies
that spot the same.
/home/jakub/gcc/obj01/gcc/xgcc -B /home/jakub/gcc/obj01/gcc/
then has search path:
 /home/jakub/gcc/obj01/gcc/include
 /home/jakub/gcc/obj01/gcc/include-fixed/x86_64-linux-gnu
 /home/jakub/gcc/obj01/gcc/include-fixed
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
which again is what I think we want to achieve.

2022-09-29  Jakub Jelinek  

PR bootstrap/107059
* cppdefault.cc (cpp_include_defaults): If
SYSROOT_HEADERS_SUFFIX_SPEC
isn't defined, add FIXED_INCLUDE_DIR entry with multilib flag 2
before FIXED_INCLUDE_DIR entry with multilib flag 0.
* gcc.cc (do_spec_1): If multiarch_dir, add
include-fixed/multiarch_dir paths before include-fixed paths.

[Bug c++/107084] New: Program does not link with Standard Library Header Unit but with correspoding #include

[karl.weber99 at gmx dot net via Gcc-bugs]

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

Bug ID: 107084
   Summary: Program does not link with Standard Library Header
Unit but with correspoding #include
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karl.weber99 at gmx dot net
  Target Milestone: ---

When I compile iostream with 

g++ -fmodules-ts -std=c++20 -c -x c++-system-header iostream

and use "import ;" the program does not link. When I use "#include
" instead, it does link and run.

Commands:

=
g++ -fmodules-ts -std=c++20 -c -x c++ employee.cppm
g++ -fmodules-ts -std=c++20 -c structtest_fmt.cpp
g++ -o structtest structtest_fmt.o employee.o -lfmt
/usr/bin/ld: structtest_fmt.o: in function `main':
structtest_fmt.cpp:(.text+0xfb): undefined reference to
`fmt::v9::vformat(fmt::v9::basic_string_view,
fmt::v9::basic_format_args >)'
/usr/bin/ld: structtest_fmt.cpp:(.text+0x1ae): undefined reference to
`fmt::v9::vformat(fmt::v9::basic_string_view,
fmt::v9::basic_format_args >)'
/usr/bin/ld: structtest_fmt.cpp:(.text+0x261): undefined reference to
`fmt::v9::vformat(fmt::v9::basic_string_view,
fmt::v9::basic_format_args >)'
/usr/bin/ld: structtest_fmt.o: in function
`std::allocator_traits
>::deallocate(std::allocator&, char*, unsigned long)':
structtest_fmt.cpp:(.text._ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm[_ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm]+0x2d):
undefined reference to `std::__is_constant_evaluated()'
collect2: error: ld returned 1 exit status
=

employee.cppm
=
export module employee;

export struct Employee {
char firstInitial;
char lastInitial;
int  employeeNumber;
int  salary;
};
=

structtest_fmt.cpp
=
#include 
import ;
import employee;

using namespace std;

int main()
{
// create and populate an employee
Employee anEmployee;
anEmployee.firstInitial = 'J';
anEmployee.lastInitial = 'D';
anEmployee.employeeNumber = 42;
anEmployee.salary = 8;

// output the values of an employee
cout << fmt::format("Employee: {}{}", anEmployee.firstInitial, 
anEmployee.lastInitial) << endl;
cout << fmt::format("Number: {}", anEmployee.employeeNumber) << endl;
cout << fmt::format("Salary: ${}", anEmployee.salary) << endl;
}
=

When I replace the import iostream by the corresponding include statement (and
delete iostream.gcm, then is compiles, links and runs successfully.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

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

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #16)
> Any such solution would also be OK to backport I think.

Yeah, it would have no effect unless you explicitly enable the new option.

[Bug driver/106897] driver: support -gz=zstd

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Implemented for GCC 13.

[Bug driver/106897] driver: support -gz=zstd

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

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

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

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

commit r13-2931-gb7723e135334df95597c8c744276b9de5a88214a
Author: Martin Liska 
Date:   Thu Sep 22 14:30:44 2022 +0200

support -gz=zstd for both linker and assembler

PR driver/106897

gcc/ChangeLog:

* common.opt: Add -gz=zstd value.
* configure.ac: Detect --compress-debug-sections=zstd
for both linker and assembler.
* configure: Regenerate.
* gcc.cc (LINK_COMPRESS_DEBUG_SPEC): Handle -gz=zstd.
(ASM_COMPRESS_DEBUG_SPEC): Likewise.

[Bug c++/107083] New: internal compiler error: in core_vals, at cp/module.cc:6127

[karl.weber99 at gmx dot net via Gcc-bugs]

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

Bug ID: 107083
   Summary: internal compiler error: in core_vals, at
cp/module.cc:6127
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karl.weber99 at gmx dot net
  Target Milestone: ---

Created attachment 53639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53639&action=edit
Output of compiler due to option -freport-bug

Environment: openSUSE 15.3 linux system.

I downloaded fmt::format from https://github.com/fmtlib/fmt/ and tried to
compile the header file fmt/core.h of this package with

g++ -freport-bug -fmodules-ts -std=c++20 -c -x c++-system-header fmt/core.h

The output of the compiler is

/usr/local/include/fmt/core.h: internal compiler error: in core_vals, at
cp/module.cc:6127
0x407d0d trees_out::core_vals(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:6127
0x54143b trees_out::tree_node_vals(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:7073
0x54143b trees_out::tree_value(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:8910
0x53a43c trees_out::tree_node(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:9108
0x53ddf5 trees_out::core_vals(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:6036
0x53e460 trees_out::tree_node_vals(tree_node*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:7073
0x53f35b trees_out::decl_value(tree_node*, depset*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:7652
0x53f9f1 depset::hash::find_dependencies(module_state*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:13139
0x53ff86 module_state::write(elf_out*, cpp_reader*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:17629
0x541290 finish_module_processing(cpp_reader*)
../../gcc_12.2/gcc-12.2.0/gcc/cp/module.cc:19886
0x4ed14b c_parse_final_cleanups()
../../gcc_12.2/gcc-12.2.0/gcc/cp/decl2.cc:5342
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cc9Z23Fg.out file, please attach this to
your bugreport.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

--- Comment #5 from Francois-Xavier Coudert  ---
Right now the code to test support is indeed like this for glibc targets except
x86/x86_64 (libgfortran/config/fpu-glibc.h):


int
support_fpu_rounding_mode (int mode)
{
  switch (mode)
{
  case GFC_FPE_TONEAREST:
#ifdef FE_TONEAREST
return 1;
#else
return 0;
#endif
…


so the correct code would be instead:


int
support_fpu_rounding_mode (int mode)
{
  int oldmode, res;

  switch (mode)
{
  case GFC_FPE_TONEAREST:
#ifdef FE_TONEAREST
oldmode = fegetround ();
res = fesetround (FE_TONEAREST);
fesetround (oldmode);
return res ? 0 : 1;
#else
return 0;
#endif
…



Does that seem correct to you?
Also, looking at the doc, I think this file may need to have this line
somewhere at the top:

#pragma STDC FENV_ACCESS ON

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
The problem is that set_fpu_trap_exceptions does not check if feenableexcept
was successful.  Just because FE_* are defined does not mean that the hardware
supports fpu exceptions of that kind (it may depend on the actual flavor of the
hardware).

[Bug fortran/107075] ICE in get, at cgraph.h:461

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
(In reply to anlauf from comment #1)
> 
> Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic .

... as does adding an initializer to A.
That's something I noticed just a few days ago: variables from main program
without initializer don't get (implicitly) the SAVE attribute.

(In reply to Richard Biener from comment #2)
> 
> But maybe 'z' shouldn't be of static storage duration ...

No, I think it shouldn't.  A should be static, and Z should not.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 105646 Summary: g++ does not raise "xxx may be used uninitialized" warning 
on dead code when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105646

   What|Removed |Added

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

[Bug tree-optimization/105646] g++ does not raise "xxx may be used uninitialized" warning on dead code when optimizing

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||13.0
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/105646] g++ does not raise "xxx may be used uninitialized" warning on dead code when optimizing

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

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

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

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

commit r13-2926-ga1cd4d52d6ef90b977fb2d80c1cf17f3efa5b01d
Author: Richard Biener 
Date:   Fri Aug 19 15:11:14 2022 +0200

tree-optimization/105646 - re-interpret always executed in uninit diag

The following fixes PR105646, not diagnosing

int f1();
int f3(){
auto const & a = f1();
bool v3{v3};
return a;
}

with optimization because the early uninit diagnostic pass only
diagnoses always executed cases.  The patch does this by
re-interpreting what always executed means and choosing to
ignore exceptional and abnormal control flow for this.  At the
same time it improves things as suggested in a comment - when
the value-numbering run done without optimizing figures there's
a fallthru path, consider blocks on it as always executed.

PR tree-optimization/105646
* tree-ssa-uninit.cc (warn_uninitialized_vars): Pre-compute
the set of fallthru reachable blocks from function entry
and use that to determine wlims.always_executed.

* g++.dg/uninit-pr105646.C: New testcase.

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
Still STOP 3.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

--- Comment #3 from Richard Biener  ---
IIRC there are also unfixed devirt issues (and some not backported yet?)