[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c

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

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

--- Comment #10 from Jan Hubicka  ---
I am testing
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index afd9222b5a2..c037668e7d8 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1112,6 +1112,10 @@ ipa_load_from_parm_agg (struct ipa_func_body_info *fbi,
   if (!base)
 return false;

+  /* We can not propagate across volatile loads.  */
+  if (TREE_THIS_VOLATILE (op))
+return false;
+
   if (DECL_P (base))
 {
   int index = ipa_get_param_decl_index_1 (descriptors, base);

[Bug libstdc++/105915] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

[heroxbd at sohu dot com via Gcc-bugs]

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

--- Comment #3 from Benda Xu  ---
(In reply to Jonathan Wakely from comment #2)
> 
> Only when compiling with clang, presumably.

Yes, that's true.  To be specific, we meet it in the AMD ROCm on Gentoo, where
the HIP compiler is based on llvm and our system compiler is gcc-11.3.0.

[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)

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

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

--- Comment #11 from Jakub Jelinek  ---
Some comments on the topic are in PR104702

[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)

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

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

--- Comment #12 from Eric Botcazou  ---
> Some comments on the topic are in PR104702

Indeed, thanks for the pointer.  I'll probably submit my fixlet though because
the current behavior of gimple_set_location is clearly broken.

[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c

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

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

--- Comment #9 from Jan Hubicka  ---
Indeed volatile checks seems to be missing across ipa-prop code. Here is
smaller testcase:

__attribute__((noinline))
static int
test2(int a)
{
if (__builtin_constant_p (a))
__builtin_abort ();
return a;
}
/*__attribute__((noinline))*/
static int
test(int *a)
{
int val = *(volatile int *)a;
if (__builtin_constant_p (val))
__builtin_abort ();
if (val)
  return test2(val);
return 0;
}
int a;
int
main()
{
a = 0;
return test ();
}

is optimized to
main:
.LFB2:
.cfi_startproc
movl$0, a(%rip)
movla(%rip), %eax
xorl%eax, %eax
ret
.cfi_endproc

which I don't think is correct. The volatile load can be non-0 and thus we can
return non-0.
It does not trigger unreachable as I hoped for since vrp and fab passes seems
to jump to same conclusion as ipa-cp.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

--- Comment #1 from Rainer Orth  ---
Also known as gccrs Issue #1229.

[Bug libstdc++/105915] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

[heroxbd at sohu dot com via Gcc-bugs]

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

--- Comment #1 from Benda Xu  ---
Hi Jonathan, I am involving you in the Cc thinking that you will have a better
idea on this issue.  Thanks!

[Bug libstdc++/105915] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Benda Xu from comment #0)
> With a MWE of
> 
> ```c++
> #include 
> 
> int main(){}
> ```
> would produce
> ```
> /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/
> fs_path.h:1209:9: error: 'begin' is missing exception specification
> 'noexcept'
>   path::begin() const
> ^
> /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/
> fs_path.h:428:14: note: previous declaration is here
> iterator begin() const noexcept;
>  ^
> 
> ```
> on a Gentoo system.

Only when compiling with clang, presumably.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

Thomas Schwinge  changed:

   What|Removed |Added

Version|13.0|rust/master
   See Also||https://github.com/Rust-GCC
   ||/gccrs/issues/1229
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-10
 Status|UNCONFIRMED |NEW
 CC||tschwinge at gcc dot gnu.org

[Bug libstdc++/105915] New: commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

[heroxbd at sohu dot com via Gcc-bugs]

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

Bug ID: 105915
   Summary: commit 42eff613 should be backported to gcc-11 for
bits/fs_path.h consistency
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heroxbd at sohu dot com
  Target Milestone: ---

Hi, comments 42eff613d0 is followed by 944da70a5d to add 'noexcept' to
path::iterator members.  But in the gcc-11.3.0 release, only 944da70a5d was
applied.

With a MWE of

```c++
#include 

int main(){}
```
would produce
```
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/fs_path.h:1209:9:
error: 'begin' is missing exception specification 'noexcept'
  path::begin() const
^
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/fs_path.h:428:14:
note: previous declaration is here
iterator begin() const noexcept;
 ^

```
on a Gentoo system.

After applying 42eff613d0 to gcc-11.3.0, the bug disappears.

Please see also:

1. https://bugs.gentoo.org/842405
2. https://github.com/gentoo/gentoo/pull/25313

[Bug ipa/105917] New: Missed passthru jump function

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

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

Bug ID: 105917
   Summary: Missed passthru jump function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

In this testcase:
struct a {int a;};
struct b {int b; struct a a;};

__attribute__ ((noinline))
static int
reta (struct a a)
{
return a.a;
}
__attribute__ ((noinline))
static int 
retba (struct b b)
{
  struct a *a = 
  return reta(*a);
}
int
main()
{
  struct b b = {1, {0}};
  return retba (b);
}

There is aggregat passthru from retba to reta but we get:

  _2 = reta (MEM[(struct a *) + 4B]);

Analyzing function: retba/1
  function  retba/1 parameter descriptors:
param #0 b used undescribed_use
  Jump functions of caller  retba/1:
callsite  retba/1 -> reta/0 :
   param 0: UNKNOWN
 Unknown bits
 Unknown VR

I constructed this to check dubious check for MEM_REF requiring offset to be 0.
However surprisingly we miss the following too:

struct a {int a;};
struct b {int b; struct a a;};

__attribute__ ((noinline))
static int
reta (struct a a)
{
return a.a;
}
__attribute__ ((noinline))
static int 
retba (struct b b)
{
  //struct a *a = 
  //return reta(*a);
  return reta (b.a);
}
int
main()
{
  struct b b = {1, {0}};
  return retba (b);
}

  Jump functions of caller  retba/1:
callsite  retba/1 -> reta/0 :
   param 0: UNKNOWN
 Unknown bits
 Unknown VR

I wonder which cases actually works :)

[Bug c++/105908] [12/13 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Summary|out-of-class definition of  |[12/13 Regression]
   |templated method with   |out-of-class definition of
   |decltype in trailing return |templated method with
   |type fails to compile   |decltype in trailing return
   ||type fails to compile
   Last reconfirmed||2022-06-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91706
  Known to fail||13.0
   Target Milestone|--- |12.2
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Started with r12-1273.

[Bug rust/105913] New: gccrs doesn't compile on 32-bit targets

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

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

Bug ID: 105913
   Summary: gccrs doesn't compile on 32-bit targets
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, i686-pc-linux-gnu

Created attachment 53115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53115=edit
hacky patch

I recently tried bootstrapping the devel/rust/master branch as of
9d81164aa0447c738fe0435de14ec9666a03d5da
on Solaris/x86 and Linux/i686, but unlike Linux/x86_64 the build failed for
several instances of the same issue:

/vol/gcc/src/git/rust/gcc/rust/lex/rust-lex.cc: In member function
'std::pair Rust::Lexer::parse_partial_unicode_escape()':
/vol/gcc/src/git/rust/gcc/rust/lex/rust-lex.cc:1574:43: error: format '%lu'
expects argument of type 'long unsigned int', but argument 3 has type
'std::__cxx11::basic_string::size_type' {aka 'unsigned int'}
[-Werror=format=]
 1574 |  "characters; it is %lu",
  | ~~^
  |   |
  |   long unsigned int
  | %u
 1575 |  num_str.length ());
  |  ~
  | |
  |
std::__cxx11::basic_string::size_type {aka unsigned int}

It's always trying to print size_t (unsigned int) with a %ld or %lu format.

The attached hacky patch casts the arguments accordingly, and allows the
bootstrap
to finish and the testsuite (both 32 and 64-bit) to run successfully.

[Bug fortran/105916] New: gfortran -fdiagnostics-format=json yields incorrect output

[gnikit at duck dot com via Gcc-bugs]

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

Bug ID: 105916
   Summary: gfortran -fdiagnostics-format=json yields incorrect
output
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnikit at duck dot com
  Target Milestone: ---

Using the option `-fdiagnostics-format=json` with gfortran yields unexpected
and erroneous output.

Consider the trivial MWE

tmp.f90
```fortran
program main
implicit none
print*, "Hello World!"
end program main
```

One would expect when compiled the json output to be empty, but 

gfortran -fdiagnostics-format=json tmp.f90


results to (formatted to be human readable)

```json
[
  {
"kind": "error",
"column-origin": 1,
"children": [
  {
"kind": "error",
"escape-source": false,
"locations": [
  {
"caret": {
  "byte-column": 13,
  "display-column": 13,
  "line": 2,
  "file": "tmp.f90",
  "column": 13
}
  }
],
"message": "Function ‘implicit’ requires an argument list at (1)"
  },
  {
"kind": "error",
"escape-source": false,
"locations": [
  {
"caret": {
  "byte-column": 13,
  "display-column": 13,
  "line": 2,
  "file": "tmp.f90",
  "column": 13
}
  }
],
"message": "Syntax error in IMPLICIT statement at (1)"
  },
  {
"kind": "error",
"escape-source": false,
"locations": [
  {
"caret": {
  "byte-column": 10,
  "display-column": 10,
  "line": 3,
  "file": "tmp.f90",
  "column": 10
}
  }
],
"message": "Function ‘print’ requires an argument list at (1)"
  },
  {
"kind": "error",
"escape-source": false,
"locations": [
  {
"caret": {
  "byte-column": 4,
  "display-column": 4,
  "line": 4,
  "file": "tmp.f90",
  "column": 4
}
  }
],
"message": "Function ‘end’ requires an argument list at (1)"
  }
],
"escape-source": false,
"locations": [
  {
"caret": {
  "byte-column": 8,
  "display-column": 8,
  "line": 1,
  "file": "tmp.f90",
  "column": 8
}
  }
],
"message": "Function ‘program’ requires an argument list at (1)"
  }
]

```

[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Benda Xu from comment #0)
> 2. https://github.com/gentoo/gentoo/pull/25313

N.B. I'm fixing it like this instead of backporting 42eff613d0, so that pull
request might want to use the same patch:

commit 60c84707034f025de3c8821cc5d6f27ff59143b0 (HEAD -> gcc-11)
Author: Jonathan Wakely 
Date:   Fri Jun 10 13:01:16 2022 +0100

libstdc++: Partially revert r11-9772-g6f8133689f4397 [PR105915]

The r11-9772-g6f8133689f4397 backport made two changes, but only one was
needed on the gcc-11 branch. The other should not have been backported,
and causes errors with clang. This removes the unwanted part.

libstdc++-v3/ChangeLog:

PR libstdc++/105915
* include/experimental/bits/fs_path.h (path::begin, path::end):
Remove noexcept from declarations.

diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h
b/libstdc++-v3/include/experimental/bits/fs_path.h
index 1cc1b3bf686..a2bc931c696 100644
--- a/libstdc++-v3/include/experimental/bits/fs_path.h
+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
@@ -425,8 +425,8 @@ namespace __detail
 class iterator;
 typedef iterator const_iterator;

-iterator begin() const noexcept;
-iterator end() const noexcept;
+iterator begin() const;
+iterator end() const;

 /// @cond undocumented
 // Create a basic_string by reading until a null character.

[Bug target/105911] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (error: unrecognizable insn)

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53114=edit
gcc13-pr105911.patch

Untested fix.

[Bug rust/105914] New: gccrs setting warn_unused_variable breaks thousands of non-Rust tests

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

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

Bug ID: 105914
   Summary: gccrs setting warn_unused_variable breaks thousands of
non-Rust tests
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

I've just finished bootstrapping the devel/rust/master branch on all of
Linux/x86_64,
Linux/i686, Solaris/x86_64, and Solaris/x86 with --enable-languages=rust.

The rust testresults are fine everywhere, but one change badly breaks C and C++
tests like this:

FAIL: gcc.c-torture/compile/pr99787-1.c   -O0  (test for excess errors)
Excess errors:
/vol/gcc/src/git/rust/gcc/testsuite/gcc.c-torture/compile/pr99787-1.c:10:12:
warning: unused variable 'f' [-Wunused-variable]

There are several thousand failures like this, all over the place (gcc, g++,
libgomp, libitm, libstdc++).  I'm pretty certain this is due to this snippet
in gcc/rust/lang.opt:

Wunused-variable
Rust Var(warn_unused_variable) Init(1) Warning
; documented in common.opt

Obviously this causes the warning to default to on for every language, not just
for Rust.  I haven't tried looking how to avoid this.

[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-10
   Priority|P3  |P2
  Known to fail||11.3.0
   Target Milestone|--- |11.4
 Status|UNCONFIRMED |ASSIGNED
  Known to work||11.2.0, 12.1.0
 Ever confirmed|0   |1
Summary|commit 42eff613 should be   |[11 Regression] commit
   |backported to gcc-11 for|42eff613 should be
   |bits/fs_path.h consistency  |backported to gcc-11 for
   ||bits/fs_path.h consistency
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug analyzer/105906] fanalyzer strdup false positive leak in loop

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-06-10
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed, and it still affects trunk: reproducer here:
  https://godbolt.org/z/P43bbMMW7

[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests

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

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

Thomas Schwinge  changed:

   What|Removed |Added

Version|13.0|rust/master
 CC||tschwinge at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-06-10

--- Comment #1 from Thomas Schwinge  ---
Right, I've run into this, too.  (Bootstrap failure even, with Ada enabled.)

I have half-finished patches to address this, and also patches to improve GCC's
options machinery, to make it unlikely that similar breakage happens in the
future.  :-)

[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

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

https://gcc.gnu.org/g:60c84707034f025de3c8821cc5d6f27ff59143b0

commit r11-10058-g60c84707034f025de3c8821cc5d6f27ff59143b0
Author: Jonathan Wakely 
Date:   Fri Jun 10 13:01:16 2022 +0100

libstdc++: Partially revert r11-9772-g6f8133689f4397 [PR105915]

The r11-9772-g6f8133689f4397 backport made two changes, but only one was
needed on the gcc-11 branch. The other should not have been backported,
and causes errors with clang. This removes the unwanted part.

libstdc++-v3/ChangeLog:

PR libstdc++/105915
* include/experimental/bits/fs_path.h (path::begin, path::end):
Remove noexcept from declarations.

[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||rejects-valid
 Resolution|--- |FIXED

--- Comment #7 from Jonathan Wakely  ---
Fixed - thanks for the report.

[Bug middle-end/101926] [meta-bug] struct/complex argument passing and return should be improved

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Bug 95126 Summary: [10/11/12/13 Regression] Missed opportunity to turn static 
variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126

   What|Removed |Added

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

[Bug middle-end/95126] [10/11/12/13 Regression] Missed opportunity to turn static variables into immediates

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #9 from Roger Sayle  ---
This should now be fixed on mainline.

[Bug rtl-optimization/7061] Access of bytes in struct parameters

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

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

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

https://gcc.gnu.org/g:1753a7120109c1d3b682f9487d6cca64fb2f0929

commit r13-1038-g1753a7120109c1d3b682f9487d6cca64fb2f0929
Author: Roger Sayle 
Date:   Fri Jun 10 15:14:23 2022 +0100

PR rtl-optimization/7061: Complex number arguments on x86_64-like ABIs.

This patch addresses the issue in comment #6 of PR rtl-optimization/7061
(a four digit PR number) from 2006 where on x86_64 complex number arguments
are unconditionally spilled to the stack.

For the test cases below:
float re(float _Complex a) { return __real__ a; }
float im(float _Complex a) { return __imag__ a; }

GCC with -O2 currently generates:

re: movq%xmm0, -8(%rsp)
movss   -8(%rsp), %xmm0
ret
im: movq%xmm0, -8(%rsp)
movss   -4(%rsp), %xmm0
ret

with this patch we now generate:

re: ret
im: movq%xmm0, %rax
shrq$32, %rax
movd%eax, %xmm0
ret

[Technically, this shift can be performed on %xmm0 in a single
instruction, but the backend needs to be taught to do that, the
important bit is that the SCmode argument isn't written to the
stack].

The patch itself is to emit_group_store where just before RTL
expansion commits to writing to the stack, we check if the store
group consists of a single scalar integer register that holds
a complex mode value; on x86_64 SCmode arguments are passed in
DImode registers.  If this is the case, we can use a SUBREG to
"view_convert" the integer to the equivalent complex mode.

An interesting corner case that showed up during testing is that
x86_64 also passes HCmode arguments in DImode registers(!), i.e.
using modes of different sizes.  This is easily handled/supported
by first converting to an integer mode of the correct size, and
then generating a complex mode SUBREG of this.  This is similar
in concept to the patch I proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html

2020-06-10  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/7061
* expr.cc (emit_group_store): For groups that consist of a single
scalar integer register that hold a complex mode value, use
gen_lowpart to generate a SUBREG to "view_convert" to the complex
mode.  For modes of different sizes, first convert to an integer
mode of the appropriate size.

gcc/testsuite/ChangeLog
PR rtl-optimization/7061
* gcc.target/i386/pr7061-1.c: New test case.
* gcc.target/i386/pr7061-2.c: New test case.

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #17 from Michael_S  ---
(In reply to Jakub Jelinek from comment #15)
> From what I can see, it is mostly integral implementation and we already
> have one  such in GCC, so the question is if we just shouldn't use it (most
> of the sources
> are in libgcc/soft-fp/ , then configuration files in libgcc/config/*/sfp-*
> and
> the simple *.c file that uses the soft-fp macros is in glibc in
> sysdeps/ieee754/soft-fp/s_fsqrtl.c ).

If you have good implementation, what was the reasoning behind shipping bad
implementation?

[Bug libstdc++/105915] [11 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

[heroxbd at sohu dot com via Gcc-bugs]

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

--- Comment #5 from Benda Xu  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Benda Xu from comment #0)
> > 2. https://github.com/gentoo/gentoo/pull/25313
> 
> N.B. I'm fixing it like this instead of backporting 42eff613d0, so that pull
> request might want to use the same patch:
> 
> commit 60c84707034f025de3c8821cc5d6f27ff59143b0 (HEAD -> gcc-11)
> Author: Jonathan Wakely 
> Date:   Fri Jun 10 13:01:16 2022 +0100
> 
> libstdc++: Partially revert r11-9772-g6f8133689f4397 [PR105915]
> 
> The r11-9772-g6f8133689f4397 backport made two changes, but only one was
> needed on the gcc-11 branch. The other should not have been backported,
> and causes errors with clang. This removes the unwanted part.
> 
> libstdc++-v3/ChangeLog:
> 
> PR libstdc++/105915
> * include/experimental/bits/fs_path.h (path::begin, path::end):
> Remove noexcept from declarations.
> 
> diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h
> b/libstdc++-v3/include/experimental/bits/fs_path.h
> index 1cc1b3bf686..a2bc931c696 100644
> --- a/libstdc++-v3/include/experimental/bits/fs_path.h
> +++ b/libstdc++-v3/include/experimental/bits/fs_path.h
> b/libstdc++-v3/include/experimental/bits/fs_path.h
> index 1cc1b3bf686..a2bc931c696 100644
> --- a/libstdc++-v3/include/experimental/bits/fs_path.h
> +++ b/libstdc++-v3/include/experimental/bits/fs_path.h
> @@ -425,8 +425,8 @@ namespace __detail
>  class iterator;
>  typedef iterator const_iterator;
>  
> -iterator begin() const noexcept;
> -iterator end() const noexcept;
> +iterator begin() const;
> +iterator end() const;
>  
>  /// @cond undocumented
>  // Create a basic_string by reading until a null character.

> @@ -425,8 +425,8 @@ namespace __detail
>  class iterator;
>  typedef iterator const_iterator;
>  
> -iterator begin() const noexcept;
> -iterator end() const noexcept;
> +iterator begin() const;
> +iterator end() const;
>  
>  /// @cond undocumented
>  // Create a basic_string by reading until a null character.

Thank you Jonathan! We have confirmed in the same environment that the patch
works great.

[Bug c/105919] New: Internal compiler error when using -fanalyzer on php-src

[girgias at php dot net via Gcc-bugs]

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

Bug ID: 105919
   Summary: Internal compiler error when using -fanalyzer on
php-src
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: girgias at php dot net
  Target Milestone: ---

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

I tried to compile php-src with CFLAGS="-fanalyzer" and I got an internal
compiler segfault:

/bin/sh /home/girgias/dev/php-src/libtool --silent --preserve-dup-deps --tag CC
--mode=compile cc -Iext/date/ -I/home/girgias/dev/php-src/ext/date/
-I/home/girgias/dev/php-src/include -I/home/girgias/dev/php-src/main
-I/home/girgias/dev/php-src -I/home/girgias/dev/php-src/ext/date/lib
-I/home/girgias/dev/php-src/TSRM -I/home/girgias/dev/php-src/Zend 
-D_GNU_SOURCE  -fno-common -Wformat-truncation -Wlogical-op -Wduplicated-cond
-Wno-clobbered -Wall -Wextra -Wno-strict-aliasing -Wno-unused-parameter
-Wno-sign-compare -DPROFITABILITY_CHECKS=0 -DZEND_RC_DEBUG=1
-DZEND_VERIFY_FUNC_INFO=1 -fanalyzer -fvisibility=hidden -O0
-Wimplicit-fallthrough=1 -g -DZEND_SIGNALS -fsanitize=address
-DZEND_TRACK_ARENA_ALLOC -fsanitize=undefined -fno-sanitize-recover=undefined
-fno-sanitize=object-size -fno-omit-frame-pointer   -Wno-implicit-fallthrough
-Iext/date/lib -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -DHAVE_TIMELIB_CONFIG_H=1 -c
/home/girgias/dev/php-src/ext/date/php_date.c -o ext/date/php_date.lo  -MMD -MF
ext/date/php_date.dep -MT ext/date/php_date.lo
during IPA pass: analyzer
/home/girgias/dev/php-src/ext/opcache/zend_accelerator_blacklist.c:305:67:
internal compiler error: Segmentation fault
  305 | blacklist->entries[blacklist->pos].path = (char
*)malloc(path_length + 1);
  |  
^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc6yHzr0.out file, please attach this to
your bugreport.

GCC Version:
gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2)
Copyright (C) 2021 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.

OS: Fedora 35
CPU: AMD® Ryzen 7 4700u with radeon graphics × 8

Build instructions:
Clone the PHP engine: https://github.com/php/php-src
./buildconf
./configure -C CFLAGS="-DPROFITABILITY_CHECKS=0 -DZEND_RC_DEBUG=1
-DZEND_VERIFY_FUNC_INFO=1 -fanalyzer" --disable-all --enable-debug
--enable-opcache --enable-zend-test --enable-address-sanitizer
--enable-undefined-sanitizer
make

I would imagine that not all of the configure flags will produce the error but
that's the build I've run

The file in question is:
https://github.com/php/php-src/blob/master/ext/opcache/zend_accelerator_blacklist.c#L305

Please let me know if you need any more details

[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
This should be fixed now, please reopen if not.

[Bug libstdc++/105915] [10 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Jonathan Wakely  ---
Fixed for 11.4 and also 10.4 now.

[Bug libstdc++/105915] [10 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

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

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

commit r10-10824-gf2385d1fe9f9ee0b5940ba27b41b79c9db051104
Author: Jonathan Wakely 
Date:   Fri Jun 10 13:01:16 2022 +0100

libstdc++: Partially revert r11-9772-g6f8133689f4397 [PR105915]

The r11-9772-g6f8133689f4397 backport made two changes, but only one was
needed on the gcc-11 branch. The other should not have been backported,
and causes errors with clang. This removes the unwanted part.

libstdc++-v3/ChangeLog:

PR libstdc++/105915
* include/experimental/bits/fs_path.h (path::begin, path::end):
Remove noexcept from declarations.

(cherry picked from commit 60c84707034f025de3c8821cc5d6f27ff59143b0)

[Bug libgcc/105920] New: __builtin_cpu_supports ("f16c") should check AVX

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

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

Bug ID: 105920
   Summary: __builtin_cpu_supports ("f16c") should check AVX
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

libgcc has

  if (ecx & bit_F16C)
set_feature (FEATURE_F16C);
  if (ecx & bit_RDRND)
set_feature (FEATURE_RDRND);
  if (ecx & bit_XSAVE)
set_feature (FEATURE_XSAVE);
  if (avx_usable)
{
  if (ecx & bit_AVX)
set_feature (FEATURE_AVX);
  if (ecx & bit_FMA)
set_feature (FEATURE_FMA);
}

F16C should be enabled only if AVX is usable since F16C requires AVX.

[Bug libstdc++/105915] [10 Regression] commit 42eff613 should be backported to gcc-11 for bits/fs_path.h consistency

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[11 Regression] commit  |[10 Regression] commit
   |42eff613 should be  |42eff613 should be
   |backported to gcc-11 for|backported to gcc-11 for
   |bits/fs_path.h consistency  |bits/fs_path.h consistency
  Known to work||10.3.0
 Status|RESOLVED|REOPENED
  Known to fail||10.3.1
   Target Milestone|11.4|10.4
 Resolution|FIXED   |---

--- Comment #8 from Jonathan Wakely  ---
Actually I need to backport it to gcc-10 as well.

[Bug libstdc++/105907] unordered containers should cache result of std::hash

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

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

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

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

commit r13-1037-gb370ed0bf93ecf0ff51d29e7fc132c433b2aa1be
Author: Jonathan Wakely 
Date:   Thu Jun 9 12:07:15 2022 +0100

libstdc++: Make std::hash> allocator-agnostic (LWG 3705)

This new library issue was recently moved to Tentatively Ready by an LWG
poll, so I'm making the change on trunk.

As noted in PR libstc++/105907 the std::hash specializations for PMR
strings were not treated as slow hashes by the unordered containers, so
this change preserves that. The new specializations for custom
allocators are also not treated as slow, for the same reason. For the
versioned namespace (i.e. unstable ABI) we don't have to worry about
that, so can enable hash code caching for all basic_string
specializations.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (__hash_str_base): New class
template.
(hash, A>>): Define partial
specialization for each of the standard character types.
(hash, hash, hash, hash)
(hash): Remove explicit specializations.
* include/std/string (__hash_string_base): Remove class
template.
(hash, hash, hash)
(hash, hash): Remove explicit
specializations.
* testsuite/21_strings/basic_string/hash/hash.cc: Test with
custom allocators.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc:
Likewise.

[Bug libstdc++/92978] std::gcd mishandles mixed-signedness

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

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

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

https://gcc.gnu.org/g:671970a5621e18e7079b4ca113e56434c858db66

commit r13-1040-g671970a5621e18e7079b4ca113e56434c858db66
Author: Jonathan Wakely 
Date:   Fri Jun 10 14:39:13 2022 +0100

libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]

When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.

To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(50u, 49u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.

[Bug libstdc++/105844] [10/11/12/13 Regression] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned

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

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

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

https://gcc.gnu.org/g:671970a5621e18e7079b4ca113e56434c858db66

commit r13-1040-g671970a5621e18e7079b4ca113e56434c858db66
Author: Jonathan Wakely 
Date:   Fri Jun 10 14:39:13 2022 +0100

libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]

When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.

To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(50u, 49u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.

[Bug ipa/105917] [10/11/12/13 regression] Missed passthru jump function

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|Missed passthru jump|[10/11/12/13 regression]
   |function|Missed passthru jump
   ||function

--- Comment #1 from Jan Hubicka  ---
Looking at the compiler explorer, the both testcases actually works up to gcc
9.5:

reta(a) [clone .constprop.0]:
xorl%eax, %eax
ret
retba(b) [clone .isra.0] [clone .constprop.0]:
jmp reta(a) [clone .constprop.0]
main:
xorl%edi, %edi
jmp retba(b) [clone .isra.0] [clone .constprop.0]

Clang optimizes main to return 0 which we don't due to lack of return
functions.
Also ISRA may trigger on reta+retb and break out the integer rather than
substructure but doesn't.

[Bug c++/105918] New: Spurious Warray-bounds in std::to_chars

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 105918
   Summary: Spurious Warray-bounds in std::to_chars
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

#include 
template
std::to_chars_result toChars(char (& buf)[N], int number) {
char temp[N];
std::to_chars_result result = std::to_chars(temp, temp + N, number);
if (result.ec != std::errc())
return result;
char* it = temp;
char* end = result.ptr;
std::size_t i = 0u;
while (i != N && it != end)
buf[i++] = *it++;
if (i != N)
buf[i] = '\0';
return std::to_chars_result{.ptr = buf + (result.ptr - temp), .ec =
std::errc()};
}
#include 
struct ar {
struct V { bool value; } value;
std::unique_ptr s;
};
void f(...);
ar g();
ar evaluate(bool value) {
ar res{value};
if (res.value.value)
return res;
return g();
}
#define CHECK(P) f(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, evaluate(P), 0, 0, 0, 0, 0, 0,
0, 0, 0 );
int main() {
char s3[3];
auto res3 = toChars(s3, 12);
CHECK((res3.ec == std::errc()));
CHECK((s3[0] == '1'));
CHECK((s3[1] == '2'));
CHECK((s3[2] == '\0'));
char s1[1];
auto res1 = toChars(s1, 12);
CHECK((res1.ec != std::errc()));
}

Compiled at -O3 -Warray-bounds:

In file included from include/c++/12.1.0/charconv:42,
 from :1:
In function 'void std::__detail::__to_chars_10_impl(char*, unsigned int, _Tp)
[with _Tp = unsigned int]',
inlined from 'std::__detail::__integer_to_chars_result_type<_Tp>
std::__detail::__to_chars_10(char*, char*, _Tp) [with _Tp = unsigned int]' at
include/c++/12.1.0/charconv:225:35,
inlined from 'std::__detail::__integer_to_chars_result_type<_Tp>
std::__to_chars_i(char*, char*, _Tp, int) [with _Tp = int]' at
include/c++/12.1.0/charconv:351:32,
inlined from 'std::to_chars_result std::to_chars(char*, char*, int, int)'
at include/c++/12.1.0/charconv:370:1,
inlined from 'std::to_chars_result toChars(char (&)[N], int) [with int N =
1]' at :7:48:
include/c++/12.1.0/bits/charconv.h:95:22: warning: array subscript 1 is outside
array bounds of 'char [1]' [-Warray-bounds]
   95 |   __first[1] = __digits[__num + 1];
  |   ~~~^~~
: In function 'std::to_chars_result toChars(char (&)[N], int) [with int
N = 1]':
:6:10: note: at offset 1 into object 'temp' of size 1
6 | char temp[N];
  |  ^~~~
:6:10: note: at offset 2 into object 'temp' of size 1
Compiler returned: 0

[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false

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

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

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

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

commit r13-1039-g1e65f2ed99024f23c56f7b6a961898bcaa882a92
Author: Jonathan Wakely 
Date:   Wed Jun 8 10:43:57 2022 +0100

libstdc++: Fix lifetime bugs for non-TLS eh_globals [PR105880]

This ensures that the single-threaded fallback buffer eh_globals is not
destroyed during program termination, using the same immortalization
technique used for error category objects.

Also ensure that init._M_init can still be read after init has been
destroyed, by making it a static data member.

libstdc++-v3/ChangeLog:

PR libstdc++/105880
* libsupc++/eh_globals.cc (eh_globals): Ensure constant init and
prevent destruction during termination.
(__eh_globals_init::_M_init): Replace with static member _S_init.
(__cxxabiv1::__cxa_get_globals_fast): Update.
(__cxxabiv1::__cxa_get_globals): Likewise.

[Bug ipa/105690] -Warray-bounds sensitive false positive with -O2

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

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

--- Comment #3 from Franz Sirl  ---
I managed to minimize the testcase a bit more:

unsigned int gvar1;
void fun1(int);
void fun2(unsigned int, char *);
int fun2_maxlen;
typedef struct {
  int exist;
  int mode;
} table_t;
table_t gtable[20];

void fun3(unsigned int idx)
{
  char buffer[257];
  if (idx >= 20)
return;
  fun2(idx, buffer);
  if (gtable[idx].mode)
fun2(idx, buffer);
}

void fun4()
{
  unsigned int idx = gvar1;
  fun3(idx);
}

void fun2(unsigned int idx, char * text)
{
  if (!(idx >= 20 || gtable[idx].exist == 0))
fun1(fun2_maxlen);
}

and this is the resulting code modeled after the 085i.inline dump:

unsigned int gvar1;
void fun1(unsigned int);
int fun2_maxlen;
typedef struct {
  int exist;
  int mode;
} table_t;
table_t gtable[20];

__attribute__((noinline))
static void fun3_part_0(unsigned int idx)
{
  if (idx >= 20)
goto lab1;
  if (gtable[idx].exist != 0)
fun1(fun2_maxlen);
lab1:
  if (gtable[idx].mode != 0) {
if (idx >= 20)
  return;
if (gtable[idx].exist != 0)
  fun1(fun2_maxlen);
  }
}

void fun3(unsigned int idx)
{
  if (idx >= 20)
return;
  fun3_part_0(idx);
}

void fun4()
{
  unsigned int idx = gvar1;
  if (idx >= 20)
return;
  fun3_part_0(idx);
}

And so I wonder why the duplicated "if (idx >= 20) return" wasn't moved to
fun3.part.0?
If the reason is conflicting optimization goals, could something like an
"incoming range" be attached to the parameter of fun3.part.0? That would
probably help both the warning code and the following optimization passes.

BTW, is there a way to dump more details between 084i.fnsummary and
085i.inline?

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #16 from Michael_S  ---
(In reply to Thomas Koenig from comment #14)
> @Michael: Now that gcc 12 is out of the door, I would suggest we try to get
> your code into the gcc tree for gcc 13.
> 
> It should follow the gcc style guidelines, which is quite trivial to do:
> Comments should be in /* - */ format, and clang-format --style=gnu does the
> rest.
> (If you prefer, I can also handle that).
> 
> Regarding copyright, you can either assign it to the FSF (which would take
> a bit) or, probably easier, you can use the Signed-off-by: tag as per
> https://gcc.gnu.org/contribute.html#legal .
> 
> You would then submit the patch to gcc-patc...@gcc.gnu.org; if you prefer,
> I can also help a bit with the style issues (ChangeLog etc) for that.
> It would then be reviewed and, if any problems identified are fixed,
> applied - which I can also do.
> 
> How does that sound?

Sounds not bad except I would want to have a copy of my own part of the work in
my public github repo to share it with world under MIT or BSD or plain giveaway
license.
Is it a problem?

Also, if we start than it makes sense to replace more common routines (add, mul
and esp. fma) as well.

Also, I suspect that transcendental, esp trigs, can be improved by quite a lot
if they are currently done in the style, similar to sqrt() and fma().



Also the code will be cleaner and marginally better performance-wise if we base
it on clang-style add_carry64(). 
According to my understanding, gcc is going to implement it in the future
anyway, so why not now?

As to this specific routines, the variants posted here still contain one bug in 
handling of sub-normal inputs (a corner case of lowest non-zero).
Also, for square root I have variant that is a little simple and performs
somewhat better. And commented better.

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||maik.urbannek at cattatech dot 
de

--- Comment #2 from Lewis Hyatt  ---
*** Bug 104640 has been marked as a duplicate of this bug. ***

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

--- Comment #3 from Lewis Hyatt  ---
I can look into that.

[Bug c++/104642] Add __builtin_trap() for missing return at -O0

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

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

--- Comment #5 from Jason Merrill  ---
The suggested -funreachable-traps seems to have a lot of overlap with
-fsanitize-undefined-trap-on-error; I wonder about combining them, and having
it by itself imply -fsanitize=unreachable.

[Bug c++/105921] internal compiler error: in cp_parser_template_id, at cp/parser.cc:18362

[orbisvicis+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Yclept Nemo  ---
AFAICT, the attachment includes everything needed in a bug report. Inlining the
code here for convenience:

#include 

template 
auto a = (struct A {
template 
using Temp = T1;

template 
auto get(std::index_sequence){
return (int (*)( Temp... ))nullptr;
}
}){}.get(std::make_index_sequence{});

int main () {
a;
}

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

[linux_dr at yahoo dot com via Gcc-bugs]

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

--- Comment #18 from Loren Osborn  ---
It appears this fix has already been merged into trunk. Is there a reason this
isn't marked "Resolved"? Is that usually not updated until the next release?

[Bug libquadmath/105101] incorrect rounding for sqrtq

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #18 from joseph at codesourcery dot com  ---
libquadmath is essentially legacy code.  People working directly in C 
should be using the C23 _Float128 interfaces and *f128 functions, as in 
current glibc, rather than libquadmath interfaces (unless their code needs 
to support old glibc or non-glibc C libraries that don't support _Float128 
in C23 Annex H).  It would be desirable to make GCC generate *f128 calls 
when appropriate from Fortran code using this format as well; see 
 for 
more discussion of the different cases involved.

Most of libquadmath is derived from code in glibc - some of it can now be 
updated from the glibc code automatically (see update-quadmath.py), other 
parts can't (although it would certainly be desirable to extend 
update-quadmath.py to cover that other code as well).  See the commit 
message for commit 4239f144ce50c94f2c6cc232028f167b6ebfd506 for a more 
detailed discussion of what code comes from glibc and what is / is not 
automatically handled by update-quadmath.py.  Since update-quadmath.py 
hasn't been run for a while, it might need changes to work with more 
recent changes to the glibc code.

sqrtq.c is one of the files not based on glibc code.  That's probably 
because glibc didn't have a convenient generic implementation of binary128 
sqrt to use when libquadmath was added - it has soft-fp implementations 
used for various architectures, but those require sfp-machine.h for each 
architecture (which maybe we do in fact have in libgcc for each relevant 
architecture, but it's an extra complication).  Certainly making it 
possible to use code from glibc for binary128 sqrt would be a good idea, 
but while we aren't doing that, it should also be OK to improve sqrtq 
locally in libquadmath.

The glibc functions for this format are generally *not* optimized for 
speed yet (this includes the soft-fp-based versions of sqrt).  Note that 
what's best for speed may depend a lot on whether the architecture has 
hardware support for binary128 arithmetic; if it has such support, it's 
more likely an implementation based on binary128 floating-point operations 
is efficient; if it doesn't, direct use of integer arithmetic, without 
lots of intermediate packing / unpacking into the binary128 format, is 
likely to be more efficient.  See the discussion starting at 
 
for more on this - glibc is a better place for working on most optimized 
function implementations than GCC.  See also 
 - those functions are aiming to 
be correctly rounding, which is *not* a goal for most glibc libm 
functions, but are still quite likely to be faster than the existing 
non-optimized functions in glibc.

fma is a particularly tricky case because it *is* required to be correctly 
rounding, in all rounding modes, and correct rounding implies correct 
exceptions, *and* correct exceptions for fma includes getting right the 
architecture-specific choice of whether tininess is detected before or 
after rounding.

Correct exceptions for sqrt are simpler, but to be correct for glibc it 
still needs to avoid spurious "inexact" exceptions - for example, from the 
use of double in intermediate computations in your version (see the 
optimized feholdexcept / fesetenv operations used in glibc for cases where 
exceptions from intermediate computations are to be discarded).

For functions that aren't required to be correctly rounding, the glibc 
manual discusses the accuracy goals (including on exceptions, e.g. 
avoiding spurious "underflow" exceptions from intermediate computations 
for results where the rounded result returned is not consistent with 
rounding a tiny, inexact value).

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com via Gcc-bugs]

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

--- Comment #10 from Bill Long  ---
The original issue seems fixed in 12.1.  However, the wording of the ERROR
message (objecting that something is not a DATA entity when it really is) could
still be improved.  Can we either convert this bug to that purpose or open a
new one?

[Bug c++/65328] GCC perf issue when compiling templates - 120x slower than Clang

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

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

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

https://gcc.gnu.org/g:343d83c7a89d0c7a78139e685395228115a28f6e

commit r13-1047-g343d83c7a89d0c7a78139e685395228115a28f6e
Author: Patrick Palka 
Date:   Fri Jun 10 16:10:02 2022 -0400

c++: improve TYPENAME_TYPE hashing [PR65328]

For the testcase in this PR, compilation takes very long ultimately due
to our poor hashing of TYPENAME_TYPE causing a huge number of collisions
in the spec_hasher and typename_hasher tables.

In spec_hasher, we don't hash the components of TYPENAME_TYPE, which
means most TYPENAME_TYPE arguments end up contributing the same hash.
This is the safe thing to do uniformly since structural_comptypes may
try resolving a TYPENAME_TYPE via the current instantiation.  But this
behavior of structural_comptypes is suppressed from spec_hasher::equal
via the comparing_specializations flag, which means spec_hasher::hash
can assume it's disabled too.  To that end, this patch makes
spec_hasher::hash set the flag, and teaches iterative_hash_template_arg
to hash the relevant components of TYPENAME_TYPE when the flag is set.

And in typename_hasher, the hash function considers TYPE_IDENTIFIER
instead of the more informative TYPENAME_TYPE_FULLNAME, which this patch
fixes accordingly.

After this patch, compile time for the testcase in the PR falls to
around 30 seconds on my machine (down from dozens of minutes).

PR c++/65328

gcc/cp/ChangeLog:

* decl.cc (typename_hasher::hash): Add extra overloads.
Use iterative_hash_object instead of htab_hash_pointer.
Hash TYPENAME_TYPE_FULLNAME instead of TYPE_IDENTIFIER.
(build_typename_type): Use typename_hasher::hash.
* pt.cc (spec_hasher::hash): Add two-parameter overload.
Set comparing_specializations around the call to
hash_tmpl_and_args.
(iterative_hash_template_arg) :
When comparing_specializations, hash the TYPE_CONTEXT
and TYPENAME_TYPE_FULLNAME.
(tsubst_function_decl): Use spec_hasher::hash instead of
hash_tmpl_and_args.
(tsubst_template_decl): Likewise.
(tsubst_decl): Likewise.

[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING

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

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

--- Comment #19 from Jakub Jelinek  ---
It hasn't been fixed on 11 and 10 branches yet, that is why it is kept open but
12/13 has been removed from the Summary.

[Bug libgcc/105920] __builtin_cpu_supports ("f16c") should check AVX

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
VAES has the same issue.

[Bug c++/105921] New: internal compiler error: in cp_parser_template_id, at cp/parser.cc:18362

[orbisvicis+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 105921
   Summary: internal compiler error: in cp_parser_template_id, at
cp/parser.cc:18362
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orbisvicis+gcc at gmail dot com
  Target Milestone: ---

Created attachment 53117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53117=edit
bug.cxx.i

[Bug preprocessor/104640] incomplete unicode support for User-defined literals

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lhyatt at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Lewis Hyatt  ---
Dup of PR103902. I'll take a look.

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

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
the following patch will fix the issue with this testing case:

[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 5ca87ae3504..7df092346b9 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -604,9 +604,8 @@ addr_object_size (struct object_size_info *osi, const_tree
ptr,
  else if (var != pt_var && TREE_CODE (pt_var) == MEM_REF)
{
  tree v = var;
- /* For >fld, compute object size only if fld isn't the last
-field, as struct { int i; char c[1]; } is often used instead
-of flexible array member.  */
+ /* For >fld, compute object size if fld isn't a flexible array
+member.  */
  while (v && v != pt_var)
switch (TREE_CODE (v))
  {
@@ -645,12 +644,19 @@ addr_object_size (struct object_size_info *osi,
const_tree ptr,
&& TREE_CODE (TREE_TYPE (TREE_OPERAND (v, 0)))
   == RECORD_TYPE)
  {
-   tree fld_chain = DECL_CHAIN (TREE_OPERAND (v, 1));
-   for (; fld_chain; fld_chain = DECL_CHAIN (fld_chain))
- if (TREE_CODE (fld_chain) == FIELD_DECL)
-   break;
-
-   if (fld_chain)
+   bool is_flexible_array = false;
+   /* Set for accesses to special trailing arrays.  */
+   special_array_member sam{ };
+
+   tree refsize = component_ref_size (v, );
+   /* if the array is a special trailing array, don't
compute
+* its size, otherwise, treat it as a normal array.  */
+   if (sam == special_array_member::trail_0
+   || sam == special_array_member::trail_1
+   || flexible_array_type_p (TREE_TYPE (TREE_OPERAND
(v,0
+ is_flexible_array = true;
+
+   if (!is_flexible_array)
  {
v = NULL_TREE;

[Bug target/105923] New: unsupported return type ‘complex double’ for simd

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

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

Bug ID: 105923
   Summary: unsupported return type ‘complex double’ for simd
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-tgl-3 tmp]$ cat c.c 
__attribute__ ((__simd__ ("notinbranch")))
double _Complex foo (double _Complex __x) __attribute__ ((__nothrow__ ,
__leaf__));
double _Complex foo (double _Complex __x) __attribute__ ((__nothrow__ ,
__leaf__));

int N = 3200;
double _Complex b[3200];
double _Complex a[3200];

void
bar (void)
{
  int i;

  for (i = 0; i < N; i += 1)
b[i] = foo (a[i]);
}
[hjl@gnu-tgl-3 tmp]$ gcc -S -Ofast c.c
c.c:3:17: warning: unsupported return type ‘complex double’ for simd
3 | double _Complex foo (double _Complex __x) __attribute__ ((__nothrow__ ,
__leaf__));
  | ^~~
[hjl@gnu-tgl-3 tmp]$

[Bug c/105923] unsupported return type ‘complex double’ for simd

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |c
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I think that is correct. Gcc does not support a vector of complex types yet.

Note this is not just a target issue as it  fails generically.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #16 from qinzhao at gcc dot gnu.org ---
additional work are needed in order to make this task complete:

1. add one more new gcc option:

-fstrict-flex-arrays

when it's on, only treat the following cases as flexing array:

trailing array with size 0;
trailing array with size 1;
trailing flexible array;

all other trailing arrays with size > 1 will be treated as normal arrays. 


2. there a lot of places in GCC that currently assume all trailing arrays as
flexible array, we might need to update all these places altogether to make GCC
behavior consistently. 

As I checked, most of the places used an old routine array_at_struct_end_p, we
might need to replace all the usage of "array_at_struct_end_p" with the new
option + the more strict checking on flexing trailing array. 

let me know if you have any comments and suggestions.

[Bug c/105922] New: AArch64 SVE instruction generated with all SIMD lane active and zero-divide exception flag raised

[kawakami.k at fujitsu dot com via Gcc-bugs]

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

Bug ID: 105922
   Summary: AArch64 SVE instruction generated with all SIMD lane
active and zero-divide exception flag raised
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kawakami.k at fujitsu dot com
  Target Milestone: ---

Created attachment 53118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53118=edit
preprocessed file

FDIV SVE instruction is generated with the predicate register whose all bits
are active. This FDIV sets the divide-by-zero flag (the bit 1 (DZC) of FPSR
register) unnecessarily. Should this instruction be executed with the
appropriate predicate bits? 

In addition to FDIV, there may be other flags in the FPSR(IOC, OFC, UFC, IXC,
etc.) that could be set by performing operations on SIMD lanes that do not
contain the intended values in FADD/FSUB/FMUL as well.

/*
float a[7];
float b[7];

for(int i=0; i<7; i++) {
  a[i] = some_initial\values;
}

for(int i=0; i<7; i++) {
  b[i] = COEF / a[i];
}
*/

(p0 = {0x11, 0x11, 0x11, 0x1,  0x0,  0x0,  0x0, 0x0}
(p1 = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff}
(z1.s = {3, 3.2995, 3.599, 3.901, 4.1981, 4.5, 4.8019, 0,
0, 0, 0, 0, 0, 0, 0, 0}
add x0, sp, 64
fdivz0.s, p0/m, z0.s, z1.s  # divide-by-zero exception raised
st1wz0.s, p1, [x0]


% gcc -v -save-temps -O3 -g -march=armv8.2-a+sve main.c

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/causal/gcc-12.1.0_gcc-11.3.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-g' '-march=armv8.2-a+sve'
'-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a-'

/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1
-E -quiet -v main.c -march=armv8.2-a+sve -mlittle-endian -mabi=lp64 -g
-fworking-directory -O3 -fpch-preprocess -o a-main.i
ignoring nonexistent directory
"/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../aarch64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/include
 /usr/local/include
 /opt/causal/gcc-12.1.0_gcc-11.3.0/include

/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-g' '-march=armv8.2-a+sve'
'-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a-'

/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1
-fpreprocessed a-main.i -quiet -dumpdir a- -dumpbase main.c -dumpbase-ext .c
-march=armv8.2-a+sve -mlittle-endian -mabi=lp64 -g -O3 -version -o a-main.s
GNU C17 (GCC) version 12.1.0 (aarch64-unknown-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.1.2, MPFR version
3.1.6-p2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.1.0 (aarch64-unknown-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.1.2, MPFR version
3.1.6-p2, MPC version 1.0.2, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 44e79a65ea64887de47cdc9a11ff4739
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-g' '-march=armv8.2-a+sve'
'-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a-'
 as -v --gdwarf-5 -EL -march=armv8.2-a+sve -mabi=lp64 -o a-main.o a-main.s
GNU assembler version 2.38 (aarch64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/:/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/:/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/:/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/:/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/
LIBRARY_PATH=/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/:/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/causal/gcc-12.1.0_gcc-11.3.0/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-g' '-march=armv8.2-a+sve'
'-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a.'

/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/collect2
-plugin
/opt/causal/gcc-12.1.0_gcc-11.3.0/libexec/gcc/aarch64-unknown-linux-gnu/12.1.0/liblto_plugin.so

[Bug c++/105756] [12 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #4 from Sam James  ---
Thanks! Could you consider backporting to 12.x soonish, if possible? I ask
because with this, the 12.x branch is then in a pretty good state for more
widespread testing.

(Unfortunately, I got a bit unlucky and kept hitting ICEs when trying to build
a bunch of common packages.)

[Bug c++/65328] GCC perf issue when compiling templates - 120x slower than Clang

[juchem at gmail dot com via Gcc-bugs]

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

--- Comment #11 from juchem at gmail dot com ---
great job

[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #3 from James Y Knight  ---
This is a mess.

Clang gets it "right" only through a really awful hack, which breaks
std::rethrow_exception, and which I'm now proposing to remove.
See https://github.com/llvm/llvm-project/issues/55340#issuecomment-1152755112

I don't believe there's a way to actually get this correct in the Itanium ABI
as it stands.