[Bug target/107731] loongarch Operand Modifiers are not documented

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #7 from chenglulu  ---
(In reply to Andrew Pinski from comment #3)
> MIPS nor RISCV does not define a %c either.

These two architectures can also fail under the following conditions:

void
test(void)
{
  asm (".long %c0"
   ::"i"(0x12345678));
}

[Bug tree-optimization/107686] [12 Regression] ICE: verify_gimple failed (invalid types in nop conversion) with _Decimal64 vector

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|13.0|
Summary|[12/13 Regression] ICE: |[12 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(invalid types in nop   |(invalid types in nop
   |conversion) with _Decimal64 |conversion) with _Decimal64
   |vector  |vector
  Known to work||13.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/107731] loongarch Operand Modifiers are not documented

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from chenglulu  ---
(In reply to Andrew Pinski from comment #1)
> %c does not mean anything in loongarch.
> 
> The codes are not documented in the documentation for loonarch though but
> they currently only documented in loongarch.cc:
>'A'  Print a _DB suffix if the memory model requires a release.
>'b'  Print the address of a memory operand, without offset.
>'C'  Print the integer branch condition for comparison OP.
>'d'  Print CONST_INT OP in decimal.
>'F'  Print the FPU branch condition for comparison OP.
>'G'  Print a DBAR insn if the memory model requires a release.
>'H'  Print address 52-61bit relocation associated with OP.
>'h'  Print the high-part relocation associated with OP.
>'i'  Print i if the operand is not a register.
>'L'  Print the low-part relocation associated with OP.
>'m'  Print one less than CONST_INT OP in decimal.
>'N'  Print the inverse of the integer branch condition for comparison OP.
>'r'  Print address 12-31bit relocation associated with OP.
>'R'  Print address 32-51bit relocation associated with OP.
>'T'  Print 'f' for (eq:CC ...), 't' for (ne:CC ...),
>   'z' for (eq:?I ...), 'n' for (ne:?I ...).
>'t'  Like 'T', but with the EQ/NE cases reversed
>'V'  Print exact log2 of CONST_INT OP element 0 of a replicated
>   CONST_VECTOR in decimal.
>'W'  Print the inverse of the FPU branch condition for comparison OP.
>'X'  Print CONST_INT OP in hexadecimal format.
>'x'  Print the low 16 bits of CONST_INT OP in hexadecimal format.
>'Y'  Print loongarch_fp_conditions[INTVAL (OP)]
>'y'  Print exact log2 of CONST_INT OP in decimal.
>'Z'  Print OP and a comma for 8CC, otherwise print nothing.
>'z'  Print $0 if OP is zero, otherwise print OP normally.  */

Sorry, I'll put the ones that will be used in the document.(In reply to Xi
Ruoyao from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > %c does not mean anything in loongarch.
> > 
> > The codes are not documented in the documentation for loonarch though but
> > they currently only documented in loongarch.cc:
> >'A'  Print a _DB suffix if the memory model requires a release.
> >'b'  Print the address of a memory operand, without offset.
> >'C'  Print the integer branch condition for comparison OP.
> >'d'  Print CONST_INT OP in decimal.
> >'F'  Print the FPU branch condition for comparison OP.
> >'G'  Print a DBAR insn if the memory model requires a release.
> >'H'  Print address 52-61bit relocation associated with OP.
> >'h'  Print the high-part relocation associated with OP.
> >'i'  Print i if the operand is not a register.
> >'L'  Print the low-part relocation associated with OP.
> >'m'  Print one less than CONST_INT OP in decimal.
> >'N'  Print the inverse of the integer branch condition for comparison OP.
> >'r'  Print address 12-31bit relocation associated with OP.
> >'R'  Print address 32-51bit relocation associated with OP.
> >'T'  Print 'f' for (eq:CC ...), 't' for (ne:CC ...),
> >   'z' for (eq:?I ...), 'n' for (ne:?I ...).
> >'t'  Like 'T', but with the EQ/NE cases reversed
> >'V'  Print exact log2 of CONST_INT OP element 0 of a replicated
> >   CONST_VECTOR in decimal.
> >'W'  Print the inverse of the FPU branch condition for comparison OP.
> >'X'  Print CONST_INT OP in hexadecimal format.
> >'x'  Print the low 16 bits of CONST_INT OP in hexadecimal format.
> >'Y'  Print loongarch_fp_conditions[INTVAL (OP)]
> >'y'  Print exact log2 of CONST_INT OP in decimal.
> >'Z'  Print OP and a comma for 8CC, otherwise print nothing.
> >'z'  Print $0 if OP is zero, otherwise print OP normally.  */
> 
> Interestingly it "worked" with GCC 12.2...

(In reply to Xi Ruoyao from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Xi Ruoyao from comment #2)
> > > Interestingly it "worked" with GCC 12.2...
> 
> No it does not work.  I guess I typed the test command in a wrong SSH
> session...

I have found the error cause, I will push patch later

[Bug middle-end/107679] [13 Regression] ICE in maybe_register_def, at tree-into-ssa.cc:1914

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug target/107731] loongarch Operand Modifiers are not documented

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

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

--- Comment #5 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Xi Ruoyao from comment #2)
> > Interestingly it "worked" with GCC 12.2...

No it does not work.  I guess I typed the test command in a wrong SSH
session...

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> 
> Andrew Macleod  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>Assignee|unassigned at gcc dot gnu.org  |amacleod at redhat 
> dot com
> 
> --- Comment #14 from Andrew Macleod  ---
> Created attachment 53910
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53910=edit
> patch to fix the problem
> 
> This patch fixes the PR, but exposes issues in other passes.  They introduce
> undefined behaviour by hoisting POINTER_PLUS expressions into blocks in which
> the operand is not known to be non-null.   (See PR 107709)
> Until this can be audited fully, we put this patch on hold.

In fact the patch doesnt 'exploit the fact that the result of
pointer addition can not be nullptr' but it exploits that if
ptr + CST is performed then 'ptr' cannot be nullptr(?)

That is, it assumes that there is a zero sized object at nullptr and
thus the pointer increment to outside (but not one after it) invokes UB.

That's much more aggressive than optimizing

  ptr + 4 != nullptr

to true and I'm not sure the reasoning follows.  I think at 'nullptr'
there is _no_ object and thus the restriction to pointer addition
doesn't apply at all - if a pointer does not refer to an object then
the rule that increment to outside of the object invokes UB doesn't 
apply.

[Bug target/107731] loongarch Operand Modifiers are not documented

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Xi Ruoyao from comment #2)
> Interestingly it "worked" with GCC 12.2...

I don't see how it could work though.
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4499) default:
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4500)   switch (code)
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4501){
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4502)case REG:
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4503)  {
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4504)unsigned
int regno = REGNO (op);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4505)if (letter
&& letter != 'z')
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4506) 
output_operand_lossage ("invalid use of '%%%c'", letter);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4507)fprintf
(file, "%s", reg_names[regno]);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4508)  }
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4509)  break;
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4510)
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4511)case MEM:
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4512)  if (letter ==
'D')
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4513)   
output_address (GET_MODE (op),
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4514)   
plus_constant (Pmode, XEXP (op, 0), 4));
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4515)  else if
(letter == 'b')
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4516){
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4517) 
gcc_assert (REG_P (XEXP (op, 0)));
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4518) 
loongarch_print_operand (file, XEXP (op, 0), 0);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4519)}
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4520)  else if
(letter && letter != 'z')
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4521)   
output_operand_lossage ("invalid use of '%%%c'", letter);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4522)  else
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4523)   
output_address (GET_MODE (op), XEXP (op, 0));
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4524)  break;
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4525)
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4526)default:
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4527)  if (letter ==
'z' && op == CONST0_RTX (GET_MODE (op)))
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4528)fputs
(reg_names[GP_REG_FIRST], file);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4529)  else if
(letter && letter != 'z')
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4530)   
output_operand_lossage ("invalid use of '%%%c'", letter);
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4531)  else
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4532)   
output_addr_const (file, loongarch_strip_unspec_address (op));
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4533)  break;
62ec3b5352b3 (chenglulu  2021-11-27 14:58:21 +0800 4534)}

[Bug target/107731] loongarch Operand Modifiers are not documented

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

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

--- Comment #3 from Andrew Pinski  ---
MIPS nor RISCV does not define a %c either.

[Bug target/107731] loongarch Operand Modifiers are not documented

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

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

--- Comment #2 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #1)
> %c does not mean anything in loongarch.
> 
> The codes are not documented in the documentation for loonarch though but
> they currently only documented in loongarch.cc:
>'A'  Print a _DB suffix if the memory model requires a release.
>'b'  Print the address of a memory operand, without offset.
>'C'  Print the integer branch condition for comparison OP.
>'d'  Print CONST_INT OP in decimal.
>'F'  Print the FPU branch condition for comparison OP.
>'G'  Print a DBAR insn if the memory model requires a release.
>'H'  Print address 52-61bit relocation associated with OP.
>'h'  Print the high-part relocation associated with OP.
>'i'  Print i if the operand is not a register.
>'L'  Print the low-part relocation associated with OP.
>'m'  Print one less than CONST_INT OP in decimal.
>'N'  Print the inverse of the integer branch condition for comparison OP.
>'r'  Print address 12-31bit relocation associated with OP.
>'R'  Print address 32-51bit relocation associated with OP.
>'T'  Print 'f' for (eq:CC ...), 't' for (ne:CC ...),
>   'z' for (eq:?I ...), 'n' for (ne:?I ...).
>'t'  Like 'T', but with the EQ/NE cases reversed
>'V'  Print exact log2 of CONST_INT OP element 0 of a replicated
>   CONST_VECTOR in decimal.
>'W'  Print the inverse of the FPU branch condition for comparison OP.
>'X'  Print CONST_INT OP in hexadecimal format.
>'x'  Print the low 16 bits of CONST_INT OP in hexadecimal format.
>'Y'  Print loongarch_fp_conditions[INTVAL (OP)]
>'y'  Print exact log2 of CONST_INT OP in decimal.
>'Z'  Print OP and a comma for 8CC, otherwise print nothing.
>'z'  Print $0 if OP is zero, otherwise print OP normally.  */

Interestingly it "worked" with GCC 12.2...

[Bug target/107731] loongarch Operand Modifiers are not documented

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-17
   Keywords||documentation
 Ever confirmed|0   |1
Summary|error: invalid 'asm':   |loongarch Operand Modifiers
   |invalid use of '%c' |are not documented

--- Comment #1 from Andrew Pinski  ---
%c does not mean anything in loongarch.

The codes are not documented in the documentation for loonarch though but they
currently only documented in loongarch.cc:
   'A'  Print a _DB suffix if the memory model requires a release.
   'b'  Print the address of a memory operand, without offset.
   'C'  Print the integer branch condition for comparison OP.
   'd'  Print CONST_INT OP in decimal.
   'F'  Print the FPU branch condition for comparison OP.
   'G'  Print a DBAR insn if the memory model requires a release.
   'H'  Print address 52-61bit relocation associated with OP.
   'h'  Print the high-part relocation associated with OP.
   'i'  Print i if the operand is not a register.
   'L'  Print the low-part relocation associated with OP.
   'm'  Print one less than CONST_INT OP in decimal.
   'N'  Print the inverse of the integer branch condition for comparison OP.
   'r'  Print address 12-31bit relocation associated with OP.
   'R'  Print address 32-51bit relocation associated with OP.
   'T'  Print 'f' for (eq:CC ...), 't' for (ne:CC ...),
  'z' for (eq:?I ...), 'n' for (ne:?I ...).
   't'  Like 'T', but with the EQ/NE cases reversed
   'V'  Print exact log2 of CONST_INT OP element 0 of a replicated
  CONST_VECTOR in decimal.
   'W'  Print the inverse of the FPU branch condition for comparison OP.
   'X'  Print CONST_INT OP in hexadecimal format.
   'x'  Print the low 16 bits of CONST_INT OP in hexadecimal format.
   'Y'  Print loongarch_fp_conditions[INTVAL (OP)]
   'y'  Print exact log2 of CONST_INT OP in decimal.
   'Z'  Print OP and a comma for 8CC, otherwise print nothing.
   'z'  Print $0 if OP is zero, otherwise print OP normally.  */

[Bug target/107731] New: error: invalid 'asm': invalid use of '%c'

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 107731
   Summary: error: invalid 'asm': invalid use of '%c'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
CC: paulhua at gcc dot gnu.org, xry111 at gcc dot gnu.org
  Target Milestone: ---
Target: loongarch64-linux-gnu

void
test(void)
{
  asm (".long %c0"
   ::"i"(10));
}
Compiling this test case under loongarch64 failed with the following
information:

test1.c: In function 'test':
test1.c:3:3: error: invalid 'asm': invalid use of '%c'
3 |   asm (".long %c0"
  |   ^~~

[Bug analyzer/107711] [13 Regression] ICE with "-fanalyzer -Wunused-macros" since r13-4073-gd8aba860b34203

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

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|WAITING

--- Comment #10 from David Malcolm  ---
Patch posted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606488.html

[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)

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

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

Kewen Lin  changed:

   What|Removed |Added

 Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #9 from Kewen Lin  ---
Should be fixed on trunk, we don't want to backport this as Richi's comment in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606441.html.

[Bug c/107730] Trivial -Wreturn-type false positive when function marked static

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Sam James  ---
hm, wait, sorry. It should still emit the warning even without static? Or am I
missing something?

[Bug c/107730] Trivial -Wreturn-type false positive when function marked static

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
oh, duh, I'd missed the *.

[Bug c/107730] Trivial -Wreturn-type false positive when function marked static

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
Note that if I drop 'static', the warning goes away. Clang does not warn at
all.

[Bug c/107730] New: Trivial -Wreturn-type false positive when function marked static

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 107730
   Summary: Trivial -Wreturn-type false positive when function
marked static
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---

Created attachment 53915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53915=edit
foo.i

```
#include 

static void *poll_logfiles(int n) {
for (;;) {
sleep(1);
}
}

int main() {
poll_logfiles(0);
}
```

```
$ gcc-9.5.0 /tmp/foo.c -Wreturn-type
/tmp/foo.c: In function 'poll_logfiles':
/tmp/foo.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
7 | }
  | ^

# 10.4.1_p20221110
$ gcc-10 /tmp/foo.c -Wreturn-type
/tmp/foo.c: In function 'poll_logfiles':
/tmp/foo.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
7 | }
  | ^

# 11.3.1_p2022
$ gcc-11 /tmp/foo.c -Wreturn-type
/tmp/foo.c: In function 'poll_logfiles':
/tmp/foo.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
7 | }
  | ^

# 12.2.1_p20221112
$ gcc-12 /tmp/foo.c -Wreturn-type
/tmp/foo.c: In function ‘poll_logfiles’:
/tmp/foo.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
7 | }
  | ^

# 13.0.0_pre20221113
$ gcc-13 /tmp/foo.c -Wreturn-type
/tmp/foo.c: In function 'poll_logfiles':
/tmp/foo.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
7 | }
  | ^
```

[Bug target/107704] [13 Regression] Testsuite regression after recent DCE changes

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

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

--- Comment #2 from Jeffrey A. Law  ---
ACK.  And as I mentioned, the RTL form looks like it ought to be caught by the
SH specific code to optimize T reg handling.  I don't care enough about the SH
to try and debug a missed optimization though.

[Bug libstdc++/107649] New std::complex specializations are never used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/107720] [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
This should be fixed now.

[Bug libstdc++/107720] [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

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

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

commit r13-4117-gf69a8299c1d95548e1539227fb7b8f5581aeb29b
Author: Jonathan Wakely 
Date:   Wed Nov 16 20:47:39 2022 +

libstdc++: Ensure std::to_chars overloads all declared in 
[PR107720]

For powerpc64le we need to be able to format both of __ieee128 and
__ibm128, so we need the std::to_chars overloads for both types to be
visible at once. The __ieee128 overloads are always visible in C++23
mode, because they're used to implement the _Float128 overloads. The
__ibm128 overloads are only visible when long double is __ibm128.

libstdc++-v3/ChangeLog:

PR libstdc++/107720
* include/std/format [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT]:
Declare overloads of std::to_chars for the alternative long
double type.

[Bug fortran/104630] module subroutine not accessible from submodule

[jwmwalrus at gmail dot com via Gcc-bugs]

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

--- Comment #2 from John  ---
This issue is still in v12.2.0.

[Bug analyzer/107711] [13 Regression] ICE with "-fanalyzer -Wunused-macros" since r13-4073-gd8aba860b34203

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

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

--- Comment #9 from David Malcolm  ---
It's a use-after-free of the ident_hash hash_table.  Testing a fix...

[Bug c++/105278] -Wliteral-range vs -Wfloat-equal

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|no warning for precise  |-Wliteral-range vs
   |literals compared with  |-Wfloat-equal
   |floats  |

--- Comment #6 from Andrew Pinski  ---
I don't think clang implements -Wfloat-equal at all, at least they didn't at
the last time I looked a few years back.

[Bug c++/105278] no warning for precise literals compared with floats

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

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

--- Comment #5 from Andrew Pinski  ---
Note I think GCC's -Wfloat-equal is more reasonible than Clang's
-Wliteral-range really. The reason is because even if something can be
represented exactly in floating point (e.g. 3.0 or even 0.0), you could in
theory still get a few precision mismatch due to FMA or some other slight
differences in HW implementation.

[Bug bootstrap/107728] with -O0, libgcc in the first stage compiler has reference to libc functions

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #3 from Thomas Petazzoni  ---
Thanks for the super quick feedback. Could you clarify "Move over, the
functions are not optimized out at -O2 but rather they don't get pulled in
glibc building because another function is referenced." ?

For the record, we are able to work around this issue by passing -O1 in
CFLAGS_FOR_TARGET/CXXFLAGS_FOR_TARGET when building the first stage gcc.

[Bug analyzer/107711] [13 Regression] ICE with "-fanalyzer -Wunused-macros" since r13-4073-gd8aba860b34203

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-4114-g6e4962810fe5de95b807d1ac675df45a725e31a2
Author: David Malcolm 
Date:   Wed Nov 16 17:38:24 2022 -0500

analyzer: log the stashing of named constants [PR107711]

PR analyzer/107711 seems to be a bug in how named constants are looked up
by the analyzer in the C frontend.

To help debug this, this patch extends -fdump-analyzer and
-fdump-analyzer-stderr so that they dump this part of the analyzer's
startup.

gcc/analyzer/ChangeLog:
PR analyzer/107711
* analyzer-language.cc: Include "diagnostic.h".
(maybe_stash_named_constant): Add logger param and use it to log
the name being looked up, and the result.
(stash_named_constants): New, splitting out from...
(on_finish_translation_unit): ...this function.  Call
get_or_create_logfile and use the result to create a logger
instance, passing it to stash_named_constants.
* analyzer.h (get_or_create_any_logfile): New decl.
* engine.cc (dump_fout, owns_dump_fout): New globals, split out
from run_checkers.
(get_or_create_any_logfile): New function, split out from...
(run_checkers): ...here, so that the logfile can be opened by
on_finish_translation_unit.  Clear the globals when closing the
dump file.

gcc/testsuite/ChangeLog:
PR analyzer/107711
* gcc.dg/analyzer/fdump-analyzer-1.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/107729] unhelpful handling for PMF on Itanium ABI for inline asm

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
GCC does have an extension to do something you want already I think:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Bound-member-functions.html#Bound-member-functions

[Bug c++/107729] unhelpful handling for PMF on Itanium ABI for inline asm

[compnerd at compnerd dot org via Gcc-bugs]

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

--- Comment #3 from Saleem Abdulrasool  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > :6:1: warning: unsupported size for integer register
> 
> I get that when I use:
> #%0 %1

This totally makes sense - the value is a pointer pair, so it does detect that
will overflow.  IMO that is a positive and hopefully will deter people from
doing this in practice at least.

[Bug c++/107729] unhelpful handling for PMF on Itanium ABI for inline asm

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> :6:1: warning: unsupported size for integer register

I get that when I use:
#%0 %1

[Bug c++/107729] unhelpful handling for PMF on Itanium ABI for inline asm

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

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

--- Comment #1 from Andrew Pinski  ---
:6:1: warning: unsupported size for integer register

[Bug c++/107729] New: unhelpful handling for PMF on Itanium ABI for inline asm

[compnerd at compnerd dot org via Gcc-bugs]

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

Bug ID: 107729
   Summary: unhelpful handling for PMF on Itanium ABI for inline
asm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: compnerd at compnerd dot org
  Target Milestone: ---

It seems that the GCC handling for inline assembly with PMF references seems to
generate something would possibly work but is not entirely helpful in all
cases.  The correctness of the code is most-definitely questionable at the very
least, if not flat out invalid.

Consider the following:
```c++
template 
void f() {
  decltype(_::operator()) p;
  __asm__ __volatile__("__compnerd_was_here__" : [output] "=r" (p) : [input]
"r" (_::operator()));
}

auto L = [](){};
template void f();
```

When built with (x86_64) `-momit-leaf-frame-pointer -std=c++11 -g0
-fno-exceptions -fno-unwind-tables` the interesting (undecorated) output is:

```asm
void f():
.LFB4:
movl$L::{lambda()#1}::operator()() const, %eax; note truncation
of `ptr`
movl$0, %edx  ; note truncation
of `adj`
__compnerd_was_here__
movq%rax, -24(%rsp)   ; `ptr``
movq%rdx, -16(%rsp)   ; `adj`
nop
ret
.LFE4:
```

Adding in `-fpic` is slightly helpful as it _does_ happen to avoid the pointer
truncation:

```asm
void f():
.LFB4:
movqL::{lambda()#1}::operator()() const@GOTPCREL(%rip), %rcx  ;
note not-truncated `ptr`
movq%rcx, %rax; eh?
movl$0, %edx  ;
untruncated `adj`
__compnerd_was_here__
movq%rax, -24(%rsp)   ;
`ptr`
movq%rdx, -16(%rsp)   ;
`adj`
nop
ret
.LFE4:
```

The secondary one seems nearly correct, however, at that point a secondary
issue is exposed: the register allocation is irretrievable - your parameters
are `%0` and `%1` (or `%[input]` and `%[output]`.  The inability to destructure
the input and output as well as being unable to name the register pair makes
this rather unhelpful.

In the particular case, the PMF is a lambda without captures and thus is
reasonable as the adjustment is `0` and thus will happen to work.

There is a secondary question of the code quality itself - `r` as a constraint
for a PMF is unreasonable as per the ABI.  I don't think that there is a good
reason to permit that in the first place, but definitely not with the inability
to de-structure the parameters.

it is interesting to also note that GCC somehow does manage to de-structure and
re-structure the PMF, which is shockingly impressive.

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

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

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

--- Comment #4 from David Malcolm  ---
Aha thanks: presumably "Ep 350 - The Right Way to Write C++ Code in 2022"?  
I'm watching it now.

[Bug libstdc++/107712] std::format does not work for clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #2)
> Should be fixed now.

Question about toupper or any functions in ctype.h

These functions are not thread-safe and they do incur a very high cost due to
calling into shared libraries even for a very simple task. Plus it is undefined
behavior if the character value is above 127. They do not deal with
-fexec-charset correctly either.

Why not just write your own function which is simpler, faster, and more
versatile??

[Bug bootstrap/107728] with -O0, libgcc in the first stage compiler has reference to libc functions

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

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

--- Comment #2 from Andrew Pinski  ---
Move over, the functions are not optimized out at -O2 but rather they don't get
pulled in glibc building because another function is referenced.

Either libgcc should be built with -fdata-sections -ffunction-sections or glibc
builds needs to be fixed such that it does not reference the function in the
unwinder at -O0.  You need to look at the linker map to figure why the object
file is being pulled into glibc at -O0 and not at -O2.
But it is still a bug in glibc's ld.so really.

[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Harald Anlauf :
> 
> https://gcc.gnu.org/g:bdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
> 
> commit r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
> Author: Steve Kargl 
> Date:   Wed Nov 16 22:46:55 2022 +0100
> 
> Fortran: ICE on procedure arguments with non-integer length [PR107707]
> 
> gcc/fortran/ChangeLog:
> 
> PR fortran/107707
> * interface.cc (gfc_compare_actual_formal): Check that we
> actually
> have integer values before asking gmp_* to use them.
> 
> gcc/testsuite/ChangeLog:
> 
> PR fortran/107707
> * gfortran.dg/pr107707.f90: New test.

Thanks Harald.  Closing.

[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Joseph S. Myers  ---
The following test produces the same ICE without any prior errors. I'm not sure
if a statement expression should be considered valid in this context, or if
that indicates that an earlier error is needed. Compile this test with
-fimplicit-constexpr (thus, needs GCC 12 or later, so this test does not show a
regression, unlike the ICE-on-invalid regression in the original bug report).

int f(int);
class A {
public:
  A(int);
};
class C {
  C() : m(f(({ int x = 1; x; }))) {}
  A m;
};

Alternatively, not needing -fimplicit-constexpr (rejected by GCC 10 and before;
GCC 11 and later ICE; so again not showing a regression):

int f(int);
class A {
public:
  A(int);
};
class C {
  constexpr C() : m(f(({ int x = 1; x; }))) {}
  A m;
};

The failing assertion is

  gcc_assert (VAR_P (*p) && DECL_ARTIFICIAL (*p) && !TREE_STATIC (*p));

where *p is the variable x in the statement expression, so fails
DECL_ARTIFICIAL. If this test is valid, I don't know if it should reach the
code with this assertion (or what additional issues might arise if the variable
in the statement expression were declared static).

[Bug bootstrap/107728] with -O0, libgcc in the first stage compiler has reference to libc functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This is not a GCC issue as __register_frame_table is declared as extern.
This is almost definitely a glibc issue really.
But I doubt glibc can be compiled at -O0 because of these issues.

[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
Author: Steve Kargl 
Date:   Wed Nov 16 22:46:55 2022 +0100

Fortran: ICE on procedure arguments with non-integer length [PR107707]

gcc/fortran/ChangeLog:

PR fortran/107707
* interface.cc (gfc_compare_actual_formal): Check that we actually
have integer values before asking gmp_* to use them.

gcc/testsuite/ChangeLog:

PR fortran/107707
* gfortran.dg/pr107707.f90: New test.

[Bug middle-end/107727] error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to cqwrteur from comment #2)
> BTW. how could i detect this feature being available? I think
> 
> #if __has_cpp_attribute(__gnu__::__target__)
> 
> #endif
> 
> should not be true on targets that do not support it.

That is related to PR 93419 .

[Bug middle-end/107727] error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Build|x86_64-linux-gnu|
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Target|x86_64-w64-mingw32  |ones which don't support
   ||ifunc
   Last reconfirmed||2022-11-16
   Host|x86_64-linux-gnu|
  Component|target  |middle-end

--- Comment #4 from Andrew Pinski  ---
What they do is basically have the resolver always called:
callq   __cpu_indicator_init
movl__cpu_model+12(%rip), %eax
andl$1024, %eax # imm = 0x400
cmpl$1024, %eax # imm = 0x400
sete%al
andb$1, %al
testb   $1, %al
jne .LBB1_1
jmp .LBB1_2
.LBB1_1:
addq$40, %rsp
jmp _Z3foov.avx2# TAILCALL
.LBB1_2:
nop
addq$40, %rsp
jmp _Z3foov # TAILCALL

Not the fastest way of implementing this either.
A faster way to caching the result of the resolver.

Anyways we currently don't support multiversioning for non-ifuncs supported
targets. Someone will need to program up that support but it might be years
unless you pay someone to do it.

[Bug target/107727] error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

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

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

--- Comment #3 from Andrew Pinski  ---
What they do is basically have the resolver always called:
callq   __cpu_indicator_init
movl__cpu_model+12(%rip), %eax
andl$1024, %eax # imm = 0x400
cmpl$1024, %eax # imm = 0x400
sete%al
andb$1, %al
testb   $1, %al
jne .LBB1_1
jmp .LBB1_2
.LBB1_1:
addq$40, %rsp
jmp _Z3foov.avx2# TAILCALL
.LBB1_2:
nop
addq$40, %rsp
jmp _Z3foov # TAILCALL

Not the fastest way of implementing this either.
A faster way to caching the result of the resolver.

Anyways we currently don't support multiversioning for non-ifuncs supported
targets. Someone will need to program up that support but it might be years
unless you pay someone to do it.

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Chris Uzdavinis  ---
Ah, sorry I didn't realize that.  Its use was suggested by Jason Turner in his
most recent C++ Weekly so I started to give it a try.  Perhaps there will be an
influx of such premature reports since it was put on the radar.

[Bug target/107726] Multiple bugs related to __gnu__::__target__

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Andrew Pinski from comment #2)
> We have tests for multiversioning and they are passing with BFD ld.
> 
> Also multiversioning requires ifunc support which is not implemented for
> Windows (I don't know how clang implements theirs, maybe they do a check at
> the beginging of the function to see if a function pointer was assigned).
> 
> For 1, can you provide a full testcase which is failing?

https://sourceware.org/bugzilla/show_bug.cgi?id=29797(In reply to Andrew Pinski
from comment #3)

> Also please file an different issue for the non-ifunc case since it is a new
> feature.

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

[Bug bootstrap/107728] New: with -O0, libgcc in the first stage compiler has reference to libc functions

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 107728
   Summary: with -O0, libgcc in the first stage compiler has
reference to libc functions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

We've started doing builds with -O0 in Buildroot, and we get build failures in
glibc that look like this:


/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__register_frame':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:138:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__register_frame_table':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:186:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__deregister_frame_info_bases':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:246:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__deregister_frame':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:260:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `start_fde_sort':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:449:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:449:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `end_fde_sort':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:629:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `abort':
(.text+0x2345c): undefined reference to `__pthread_mutex_lock'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
(.text+0x23464): undefined reference to `__pthread_mutex_unlock'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
(.text+0x2346c): undefined reference to `__pthread_mutex_lock'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:1339:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/ld.so]
Error 1

See
http://autobuild.buildroot.net/results/7df/7df2d0648dd666dd07845614b34f59d6afba96c1/build-end.log
for a more complete build log.

The reason is that a number of 

[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

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

--- Comment #2 from Marek Polacek  ---
Done for GCC 13.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106649 Summary: [C++23] P2448 - Relaxing some constexpr restrictions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106649

   What|Removed |Added

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

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

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

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-4112-gc85f8dbb173f45053f6d8849d27adc98d9668769
Author: Marek Polacek 
Date:   Wed Nov 2 13:11:02 2022 -0400

c++: P2448 - Relaxing some constexpr restrictions [PR106649]

This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword.  It's effectively going the way of being just a hint
(hello, inline!).

This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression.  For example,

  void f(int& i); // not constexpr

  constexpr void g(int& i) {
f(i); // unconditionally calls a non-constexpr function
  }

is now OK, even though there isn't an invocation of 'g' that would be
a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar.  The patch is
unfortunately not that trivial.  The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.

Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)

While working on this I think I found a bug, see constexpr-nonlit15.C
and .  This patch doesn't address that.

This patch includes changes to diagnose the problem if the user doesn't
use -Winvalid-constexpr and calls a constexpr function that in fact isn't
constexpr-ready yet: maybe_save_constexpr_fundef registers the function
if warn_invalid_constexpr is 0 and explain_invalid_constexpr_fn then
gives the diagnostic.

PR c++/106649

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr
for
C++23.
* c-opts.cc (c_common_post_options): Set warn_invalid_constexpr
depending on cxx_dialect.
* c.opt (Winvalid-constexpr): New option.

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_error): New function.
(is_valid_constexpr_fn): Use constexpr_error.
(maybe_save_constexpr_fundef): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.  Register the
function if -Wno-invalid-constexpr was specified.
(explain_invalid_constexpr_fn): Don't return early if a function
marked
'constexpr' that isn't actually a constant expression was called.
(non_const_var_error): Add a bool parameter.  Use constexpr_error.
(inline_asm_in_constexpr_error): Likewise.
(cxx_eval_constant_expression): Adjust calls to non_const_var_error
and inline_asm_in_constexpr_error.
(potential_constant_expression_1): Add a bool parameter.  Use
constexpr_error.
(require_potential_rvalue_constant_expression_fncheck): New
function.
* cp-tree.h (require_potential_rvalue_constant_expression_fncheck):
Declare.
* method.cc (struct comp_info): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.

gcc/ChangeLog:

* doc/invoke.texi: Document -Winvalid-constexpr.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down
only.
* g++.dg/cpp0x/constexpr-default-ctor.C: Likewise.
* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
* g++.dg/cpp0x/constexpr-ex1.C: Likewise.
* g++.dg/cpp0x/constexpr-friend.C: Likewise.
* g++.dg/cpp0x/constexpr-generated1.C: Likewise.
* g++.dg/cpp0x/constexpr-ice5.C: Likewise.
* g++.dg/cpp0x/constexpr-ice6.C: Likewise.
* g++.dg/cpp0x/constexpr-memfn1.C: Likewise.
* g++.dg/cpp0x/constexpr-neg2.C: Likewise.
* 

[Bug rtl-optimization/107455] Suboptimal codegen for some branch-on-zero cases

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Jeffrey A. Law  ---
This looks like the problem I was chasing down a month or so ago.  I've
actually got all the review comments addressed and just need to resubmit.

Basically what we need is to take advantage of conditional equivalences
post-reload.

[Bug target/107727] error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
BTW. how could i detect this feature being available? I think

#if __has_cpp_attribute(__gnu__::__target__)

#endif

should not be true on targets that do not support it.

[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284

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

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

--- Comment #3 from Steve Kargl  ---
On Wed, Nov 16, 2022 at 09:16:17PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107707
> 
> anlauf at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||anlauf at gcc dot gnu.org
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > Fixed by
> > 
> > diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
> 
> Simple and obvious.
> 
> If you don't object, I can commit it for you.
> 

Unfortunately, committing patches requires knowledge
of git and going through some prelim setting up of 
an environment.

[Bug target/107727] error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Here is how clang deals with it on x86_64-windows-gnu (it is how clang calls
x86_64-w64-mingw32)

https://godbolt.org/z/z5cexGEMK

[Bug target/107727] New: error: multiversioning needs 'ifunc' which is not supported on this target (x86_64-w64-mingw32 target)

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 107727
   Summary: error: multiversioning needs 'ifunc' which is not
supported on this target (x86_64-w64-mingw32 target)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

#include

[[__gnu__::__target__("avx2")]]
inline void foo()
{
puts("avx2\n");
}

[[__gnu__::__target__("default")]]
inline void foo()
{
puts("default\n");
}

int main()
{
foo();
}

$ clang++ -o a a.cc --target=x86_64-windows-gnu -s -flto=thin -fuse-ld=lld
$ wine a.exe
avx2


$ x86_64-w64-mingw32-g++ -o a a.cc -s -flto
a.cc: In function 'int main()':
a.cc:10:13: error: multiversioning needs 'ifunc' which is not supported on this
target
   10 | inline void foo()
  | ^~~
a.cc:18:1: error: use of multiversioned function without a default
   18 | }
  | ^

[Bug target/107726] Multiple bugs related to __gnu__::__target__

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Andrew Pinski from comment #3)
> Also please file an different issue for the non-ifunc case since it is a new
> feature.

https://godbolt.org/z/z5cexGEMK

[Bug fortran/107707] ICE in gfc_compare_actual_formal, at fortran/interface.cc:3284

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Fixed by
> 
> diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc

Simple and obvious.

If you don't object, I can commit it for you.

[Bug analyzer/107711] ICE with -fanalyzer with -Wunused-macros since r13-4073-gd8aba860b34203

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|internal compiler error:|ICE with -fanalyzer with
   |Segmentation fault  |-Wunused-macros since
   ||r13-4073-gd8aba860b34203
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-11-16
 Ever confirmed|0   |1

--- Comment #7 from David Malcolm  ---
Thanks!  That's really helpful; I can reproduce it now, using just:

  gcc/testsuite/gcc.dg/analyzer/named-constants-via-macros.c

with:

  -fanalyzer -Wunused-macros

Presumably started with r13-4073-gd8aba860b34203.

Debugging it now...

[Bug target/107726] Multiple bugs related to __gnu__::__target__

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-w64-mingw32, |x86_64-linux-gnu
   |x86_64-linux-gnu|
  Component|c++ |target

--- Comment #3 from Andrew Pinski  ---
Also please file an different issue for the non-ifunc case since it is a new
feature.

[Bug c++/107726] Multiple bugs related to __gnu__::__target__

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-16

--- Comment #2 from Andrew Pinski  ---
We have tests for multiversioning and they are passing with BFD ld.

Also multiversioning requires ifunc support which is not implemented for
Windows (I don't know how clang implements theirs, maybe they do a check at the
beginging of the function to see if a function pointer was assigned).

For 1, can you provide a full testcase which is failing?

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-16
 Ever confirmed|0   |1

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||97110

--- Comment #2 from David Malcolm  ---
C++ isn't supported by the analyzer yet.  I hope to address this in GCC 14, but
it's not going to give useful results on C++ before then.

Sorry about this.

Marked as NEW and added to the analyzer-c++ tracker, to tackle in GCC 14.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer

[Bug libstdc++/107712] std::format does not work for clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Should be fixed now.

[Bug c++/107726] Multiple bugs related to __gnu__::__target__

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
#if __has_cpp_attribute(__gnu__::__target__) && defined(__SSE2__) &&
!defined(__AVX2__)
[[__gnu__::__target__("default")]]
#elif __has_cpp_attribute(__gnu__::__flatten__)
[[__gnu__::__flatten__]]
#endif
inline void sha512_runtime_routine(std::uint_least64_t* __restrict
state,std::byte const* __restrict blocks_start,std::byte const* __restrict
blocks_last) noexcept;

#if __has_cpp_attribute(__gnu__::__target__) && defined(__SSE2__) &&
!defined(__AVX2__)
[[__gnu__::__target__("avx2")]]
#elif __has_cpp_attribute(__gnu__::__flatten__)
[[__gnu__::__flatten__]]
#endif
inline void sha512_runtime_routine(std::uint_least64_t* __restrict
state,std::byte const* __restrict blocks_start,std::byte const* __restrict
blocks_last) noexcept;

Something like this.

[Bug c++/107726] New: Multiple bugs related to __gnu__::__target__

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 107726
   Summary: Multiple bugs related to __gnu__::__target__
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

1. On Linux. the ld linker does not work. Only gold linker would work. (Sounds
like a linker bug) 
./sha512 a_file
./sha512: error while loading shared libraries: unexpected PLT reloc type 0x00


2. On x86_64-w64-mingw32 target.
../../include/fast_io_crypto/hash/sha512_simd16.h:68:13: error: multiversioning
needs 'ifunc' which is not supported on this target

And I tried clang with lld and yes it works even on windows.

[Bug libstdc++/107720] [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

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

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

commit r13-4111-gdbdce6adb748b95be219f2f5fb97f844a0f9b840
Author: Jonathan Wakely 
Date:   Wed Nov 16 20:47:39 2022 +

libstdc++: Fix dumb typos in ALT128 support in  [PR107720]

This is only a partial fix for the PR.

libstdc++-v3/ChangeLog:

PR libstdc++/107720
* include/std/format (__format::_Arg_t): Fix typo in enumerator
name.
(_Arg_value::_S_get): Fix missing semi-colons.

[Bug libstdc++/107712] std::format does not work for clang

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

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

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

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

commit r13-4109-g2f5c071860ba3f8ef67d0b9d8291a73766ce0a44
Author: Jonathan Wakely 
Date:   Wed Nov 16 13:48:39 2022 +

libstdc++: Adjust  for Clang compatibility [PR107712]

Clang doesn't define __builtin_toupper, so use std::toupper.

Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.

libstdc++-v3/ChangeLog:

PR libstdc++/107712
* include/std/format (__format::__formatter_int::format): Use
std::toupper when __builtin_toupper isn't available.
(basic_format_arg::handle): Add 'typename'.
* include/std/complex (complex): Add 'typename'.

[Bug fortran/107444] ICE on character, value, optional dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.

[Bug fortran/107659] C procedure with no global scope is seen as global

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-16
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

NAG accepts the code just fine.

[Bug fortran/107681] [13 Regression] ICE in gfc_type_is_extensible, at fortran/resolve.cc:9018

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed.

Thanks for the report!

[Bug libstdc++/107720] [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to seurer from comment #0)
> g:1d9454aba615eadd0d85c93713dd848227345f67, r13-3936-g1d9454aba615ea
> 
> This was on a make check of a simple (non-bootstrap) built compiler.  I only
> see this on one system.

It's specific to systems using _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT which means
LE systems with a new-enough glibc to support IEEE128.

> FAIL: 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
> Excess errors:
> /home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-
> v3/include/format:2566: error: '_Args_next_value_' was not declared in this
> scope; did you mean '_Arg_next_value_'?

Doh, that's what I get for making changes after testing on a powerpc64le
machine with a recent glibc, and then not re-testing.

[Bug middle-end/107723] lround/ceil/floor with -fno-fp-int-builtin-inexact

[kevinl at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Kevin Lee  ---
aarch64 also produces

ceil1:
fcvtps  x0, d0
ret

Since it has been changed to middle-end, I'll delete riscv as the target

[Bug fortran/107681] [13 Regression] ICE in gfc_type_is_extensible, at fortran/resolve.cc:9018

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:96e4244ef3ccf4867ca4e37fbc6800e64ef30af6

commit r13-4107-g96e4244ef3ccf4867ca4e37fbc6800e64ef30af6
Author: Harald Anlauf 
Date:   Wed Nov 16 21:41:19 2022 +0100

Fortran: error recovery after reference to bad CLASS variable [PR107681]

gcc/fortran/ChangeLog:

PR fortran/107681
* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
dereference with reference to bad CLASS variable.

gcc/testsuite/ChangeLog:

PR fortran/107681
* gfortran.dg/pr107681.f90: New test.

[Bug analyzer/107725] Spurious warning: use of uninitialized value with std::any

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Chris Uzdavinis  ---
I get a similar warning with this code.  Unsure if it's the same underlying
issue.  Also does not warn with g++10 or g++11, but does with newer versions.

#include 
#include 

std::string create() {
std::ostringstream oss;
return oss.str();
}


https://godbolt.org/z/cz66zhKn5

:6:20: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 | return oss.str();
  |^
  'std::string create()': events 1-2
|
|4 | std::string create() {
|  |^
|  ||
|  |(1) region created on stack here
|5 | std::ostringstream oss;
|6 | return oss.str();
|  |~
|  ||
|  |(2) use of uninitialized value '' here

[Bug analyzer/107725] New: Spurious warning: use of uninitialized value with std::any

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 107725
   Summary: Spurious warning: use of uninitialized value with
std::any
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

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

With the analyzer (-fanalyzer), this built cleanly with GCC10 and GCC11, but
starting with GCC 12 (still occurring in trunk) in either C++17 or c++20 mode,
I see this warning (x86 linux):

:4:13: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
4 | return {};
  | ^
  'std::any create()': events 1-2
|
|3 | std::any create() {
|  | ^
|  | |
|  | (1) region created on stack here
|4 | return {};
|  | ~
|  | |
|  | (2) use of uninitialized value '' here
|
Compiler returned: 0


This is the code in its entirety:

#include 
std::any create() {
return {};
}

https://godbolt.org/z/TWPcaW4Kn

[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:713dcfc85ebbabaf74a1bcbac4ba1143519b31d6

commit r13-4106-g713dcfc85ebbabaf74a1bcbac4ba1143519b31d6
Author: Harald Anlauf 
Date:   Tue Nov 15 21:20:20 2022 +0100

Fortran: ICE in simplification of array expression involving power
[PR107680]

gcc/fortran/ChangeLog:

PR fortran/107680
* arith.cc (arith_power): Check that operands are properly
converted
before attempting to simplify.

gcc/testsuite/ChangeLog:

PR fortran/107680
* gfortran.dg/pr107680.f90: New test.

[Bug target/105192] ICE: in gen_reg_rtx, at emit-rtl.cc:1167 (during RTL pass: ce3) with -O -fno-if-conversion -fharden-compares

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Something like this might fix the issue:
apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git diff config/mips/mips.md
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index e0f0a582732..3419f4df307 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -1217,7 +1217,7 @@ (define_expand "ctrap4"
[(match_operand:GPR 1 "reg_or_0_operand")
 (match_operand:GPR 2 "arith_operand")])
(match_operand 3 "const_0_operand"))]
-  "ISA_HAS_COND_TRAPI || ISA_HAS_COND_TRAP"
+  "can_create_pseudo_p () && (ISA_HAS_COND_TRAPI || ISA_HAS_COND_TRAP")
 {
   mips_expand_conditional_trap (operands[0]);
   DONE;

I have no way to test it though.
But what is happening from the backtrace and where the assert is:
* the post-reload ifcvt is detecting a conditional trap and the mips backend
didn't expect any post-reload (really !can_create_pseudo_p ()) detection of a
condtional trap happening so it thought it could use force_reg (which might
create a new pseudo register).

[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> This might fix/improve that:
> diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
> index 22f7b0b6d6e..5764ce672ec 100644
> --- a/gcc/diagnostic.cc
> +++ b/gcc/diagnostic.cc
> @@ -470,7 +470,7 @@ diagnostic_get_location_text (diagnostic_context
> *context,
>const char *file = s.file ? s.file : progname;
>int line = 0;
>int col = -1;
> -  if (strcmp (file, N_("")))
> +  if (strcmp (file, special_fname_builtin ()))
>  {
>line = s.line;
>if (context->show_column)
> @@ -2593,7 +2593,7 @@ test_diagnostic_get_location_text ()
>const char *old_progname = progname;
>progname = "PROGNAME";
>assert_location_text ("PROGNAME:", NULL, 0, 0, true);
> -  assert_location_text (":", "", 42, 10, true);
> +  assert_location_text (":", special_fname_builtin(), 42, 10,
> true);
>assert_location_text ("foo.c:42:10:", "foo.c", 42, 10, true);
>assert_location_text ("foo.c:42:9:", "foo.c", 42, 10, true, 0);
>assert_location_text ("foo.c:42:1010:", "foo.c", 42, 10, true, 1001);
> 
> 
> But I am not 100% sure it is correct 

Sorry, the first hunk fails, as special_fname_builtin () is already there.
The second part applies, but then I get:

/work/gnu/git/build-trunk/./gcc/xgcc -B/work/gnu/git/build-trunk/./gcc/  -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc-trunk/gcc/testsuite/selftests
../../gcc-trunk/gcc/diagnostic.cc:2584: assert_location_text: FAIL:
ASSERT_STREQ (expected_loc_text, actual_loc_text)
 val1=":"
 val2=":"

PROGNAME: interner Compiler-Fehler: in fail_formatted, bei selftest.cc:63
0x1f1ccee selftest::fail_formatted(selftest::location const&, char const*, ...)
../../gcc-trunk/gcc/selftest.cc:63
0x1f1cd91 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../gcc-trunk/gcc/selftest.cc:92
0x1f22806 assert_location_text
../../gcc-trunk/gcc/diagnostic.cc:2584
0x1f24b81 test_diagnostic_get_location_text
../../gcc-trunk/gcc/diagnostic.cc:2596
0x1f24b81 selftest::c_diagnostic_cc_tests()
../../gcc-trunk/gcc/diagnostic.cc:2681
0x99ea97 selftest::c_family_tests()
../../gcc-trunk/gcc/c-family/c-common.cc:9146
0x1e46873 selftest::run_tests()
../../gcc-trunk/gcc/selftest-run-tests.cc:119
0xf29e69 toplev::run_self_tests()
../../gcc-trunk/gcc/toplev.cc:2184
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode (siehe -freport-bug).
Bitte fügen Sie jedem Fehlerbericht die vollständige Aufrufkette bei.
Weitere Hinweise finden Sie unter »«.
make[2]: *** [../../gcc-trunk/gcc/c/Make-lang.in:128: s-selftest-c] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
make[2]: Verzeichnis „/work/gnu/git/build-trunk/gcc“ wird verlassen
make[1]: *** [Makefile:4573: all-gcc] Fehler 2
make[1]: Verzeichnis „/work/gnu/git/build-trunk“ wird verlassen
make: *** [Makefile:1024: all] Fehler 2

So the localization is only partly dealt with.

[Bug middle-end/107723] lround/ceil/floor with -fno-fp-int-builtin-inexact

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

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

--- Comment #2 from Andrew Pinski  ---
Hmm, only lround is documented and the other two are not, I filed PR 107724 for
the missing documentation.

[Bug middle-end/107724] New: __builtin_{l,ll}floor* and __builtin_{l,ll}ceil* are not documented

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

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

Bug ID: 107724
   Summary: __builtin_{l,ll}floor* and __builtin_{l,ll}ceil* are
not documented
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I found this while looking quickly into PR 107723, these two sets of built-ins
are not documented. While __builtin_{l,ll}round* set is documented.
The floor and ceil sets are even an extension on top and not part of any
standard as far as I can tell even.  They are mostly used to optimize to one
instruction for many targets.

[Bug middle-end/107723] lround/ceil/floor with -fno-fp-int-builtin-inexact

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|RISC-V lround/ceil/floor|lround/ceil/floor with
   |with|-fno-fp-int-builtin-inexact
   |-fno-fp-int-builtin-inexact |
  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
This is not a target issue though.
As x86_64 produces:
ceilh:
sub rsp, 8
callceil
add rsp, 8
cvttsd2si   rax, xmm0
ret

cvttsd2si will raise inexact also.

[Bug analyzer/107711] internal compiler error: Segmentation fault

[urs at akk dot org via Gcc-bugs]

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

--- Comment #6 from urs at akk dot org ---
Created attachment 53913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53913=edit
head of fanalyzer-dump with patch from 53911

[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-16

--- Comment #1 from Andrew Pinski  ---
static void
test_diagnostic_get_location_text ()
{
  const char *old_progname = progname;
  progname = "PROGNAME";
  assert_location_text ("PROGNAME:", NULL, 0, 0, true);
  assert_location_text (":", "", 42, 10, true);


Hmmm. This is where 42 and 10 are coming from.
Oh the problem is the use directly "" here rather than
special_fname_builtin .

This might fix/improve that:
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 22f7b0b6d6e..5764ce672ec 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -470,7 +470,7 @@ diagnostic_get_location_text (diagnostic_context *context,
   const char *file = s.file ? s.file : progname;
   int line = 0;
   int col = -1;
-  if (strcmp (file, N_("")))
+  if (strcmp (file, special_fname_builtin ()))
 {
   line = s.line;
   if (context->show_column)
@@ -2593,7 +2593,7 @@ test_diagnostic_get_location_text ()
   const char *old_progname = progname;
   progname = "PROGNAME";
   assert_location_text ("PROGNAME:", NULL, 0, 0, true);
-  assert_location_text (":", "", 42, 10, true);
+  assert_location_text (":", special_fname_builtin(), 42, 10, true);
   assert_location_text ("foo.c:42:10:", "foo.c", 42, 10, true);
   assert_location_text ("foo.c:42:9:", "foo.c", 42, 10, true, 0);
   assert_location_text ("foo.c:42:1010:", "foo.c", 42, 10, true, 1001);


But I am not 100% sure it is correct 

[Bug analyzer/107711] internal compiler error: Segmentation fault

[urs at akk dot org via Gcc-bugs]

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

--- Comment #5 from urs at akk dot org ---
On Wed, Nov 16, 2022 at 03:54:54PM +, dmalcolm at gcc dot gnu.org wrote:
> If you're familiar with gdb, would you be able to reproduce the crasher under
> gdb, by adding:
>   -wrapper gdb,--args
> to the crashing gcc invocation, and getting a backtrace at the point of the
> crash.

Program received signal SIGSEGV, Segmentation fault.
0x00cf0871 in LINEMAPS_USED(line_maps const*, bool) ()
(gdb) bt
#0  0x00cf0871 in LINEMAPS_USED(line_maps const*, bool) ()
#1  0x02e50aa3 in LINEMAPS_MACRO_USED(line_maps const*) ()
#2  0x02e50adc in LINEMAPS_MACRO_LOWEST_LOCATION(line_maps const*) ()
#3  0x02e7cd2e in linemap_location_from_macro_expansion_p(line_maps
const*, unsigned int) ()
#4  0x02e7c49d in linemap_lookup(line_maps const*, unsigned int) ()
#5  0x02e7f752 in _cpp_warn_if_unused_macro ()
#6  0x02e8a46d in ht_forall(ht*, int (*)(cpp_reader*, ht_identifier*,
void const*), void const*) ()
#7  0x02e6d9e6 in cpp_forall_identifiers(cpp_reader*, int
(*)(cpp_reader*, cpp_hashnode*, void*), void*) ()
#8  0x02e6f1b2 in cpp_finish(cpp_reader*, _IO_FILE*) ()
#9  0x00d26427 in c_common_finish() ()
#10 0x0151a5f5 in finalize(bool) ()
#11 0x0151a966 in do_compile(bool) ()
#12 0x0151ad0e in toplev::main(int, char**) ()
#13 0x02dded3e in main ()

> Otherwise, would you be able to try rebuilding gcc with attachment 53911, and
> then use -fdump-analyzer, which with that patch ought to dump which name it's
> failing on (the dump is written to SOURCEFILE.analyzer.txt).

See attachment

[Bug bootstrap/107722] Bootstrap failure for some locales starting with r13-4070

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/107723] New: RISC-V lround/ceil/floor with -fno-fp-int-builtin-inexact

[kevinl at rivosinc dot com via Gcc-bugs]

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

Bug ID: 107723
   Summary: RISC-V lround/ceil/floor with
-fno-fp-int-builtin-inexact
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevinl at rivosinc dot com
  Target Milestone: ---

This was observed when solving
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605481.html. For
example, 

int ceil(double i)
{
  return __builtin_lceil(i);
}

-march=rv64gc -mabi=lp64d -fno-fp-int-builtin-inexact generates

ceil1:
addisp,sp,-16
sd  ra,8(sp)
callceil
ld  ra,8(sp)
fcvt.l.d a0,fa0,rtz
addisp,sp,16
sext.w  a0,a0
jr  ra

fcvt can possibly set the inexact exception flag, so this seems to be a
violation.

[Bug bootstrap/107722] New: Boostrap failure for some locales starting with r13-4070

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

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

Bug ID: 107722
   Summary: Boostrap failure for some locales starting with
r13-4070
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

I get the following failure on OpenSuse 15.3 with g++-11 and with r13-4070
(system is x86_64-pc-linux-gnu):

make[2]: Verzeichnis „/work/gnu/git/build-trunk/gcc“ wird betreten
/work/gnu/git/build-trunk/./gcc/xgcc -B/work/gnu/git/build-trunk/./gcc/  -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc-trunk/gcc/testsuite/selftests
../../gcc-trunk/gcc/diagnostic.cc:2584: assert_location_text: FAIL:
ASSERT_STREQ (expected_loc_text, actual_loc_text)
 val1=":"
 val2=":42:10:"

PROGNAME: interner Compiler-Fehler: in fail_formatted, bei selftest.cc:63
0x1f1747e selftest::fail_formatted(selftest::location const&, char const*, ...)
../../gcc-trunk/gcc/selftest.cc:63
0x1f17521 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../gcc-trunk/gcc/selftest.cc:92
0x1f1cf96 assert_location_text
../../gcc-trunk/gcc/diagnostic.cc:2584
0x1f1f30e test_diagnostic_get_location_text
../../gcc-trunk/gcc/diagnostic.cc:2596
0x1f1f30e selftest::c_diagnostic_cc_tests()
../../gcc-trunk/gcc/diagnostic.cc:2681
0x99cbe7 selftest::c_family_tests()
../../gcc-trunk/gcc/c-family/c-common.cc:9144
0x1e40963 selftest::run_tests()
../../gcc-trunk/gcc/selftest-run-tests.cc:119
0xf27f69 toplev::run_self_tests()
../../gcc-trunk/gcc/toplev.cc:2184
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode (siehe -freport-bug).
Bitte fügen Sie jedem Fehlerbericht die vollständige Aufrufkette bei.
Weitere Hinweise finden Sie unter »«.
make[2]: *** [../../gcc-trunk/gcc/c/Make-lang.in:128: s-selftest-c] Fehler 1
make[2]: Verzeichnis „/work/gnu/git/build-trunk/gcc“ wird verlassen
make[1]: *** [Makefile:4573: all-gcc] Fehler 2
make[1]: Verzeichnis „/work/gnu/git/build-trunk“ wird verlassen
make: *** [Makefile:1024: all] Fehler 2

However, if I change the locale using LC_ALL=C, the compile succeeds.

Am I missing something?

[Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses

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

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

Bug ID: 107721
   Summary: Lost typespec with constant expressions using array
constructors and parentheses
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

While working on pr107680, I noticed the following issue:

program p
  print *, "*** Expect integer:"
  print *, [integer ::  [1.0] ] **  2
  print *, [integer :: ([1.0])] **  2
  print *, "*** Expect real:"
  print *, [real::  [2] ]   **  2
  print *, [real:: ([2])]   **  2
  print *, "*** Expect complex:"
  print *, [complex ::  [3] ]   **  2
  print *, [complex :: ([3])]   **  2
end

There should be no effect by the parentheses here, but with 11-branch onwards
I get:

 *** Expect integer:
   1
   1.
 *** Expect real:
   4.
   4
 *** Expect complex:
 (9.,0.)
   9


Intel correctly prints:

 *** Expect integer:
   1
   1
 *** Expect real:
   4.00
   4.00
 *** Expect complex:
 (9.00,0.000E+00)
 (9.00,0.000E+00)


Note that 10-branch and older ICE on this code...

[Bug libstdc++/107720] [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-11-16
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

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

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

--- Comment #25 from Jeffrey A. Law  ---
To outline what we were thinking.  Yes, it's possible that 4->3 combinations
aren't supported.  I'd have to sit down with the combine sources to be sure.

So the alternate approach we came up with was to mimick ZBS's ability to load
up single bit constants with a define_insn_and_split, obviously splitting it
into a constant load + shift unconditionally if it's still around post-combine.

That's going to lead into a bigger question about constant loads.  Right now we
tend to break them down during expansion.  The advantage of that is the
components become CSE candidates.  The downside is it will tend to inhibit
instruction combination as we've seen in this case.  I don't have a good answer
on the best approach.

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

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

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

--- Comment #24 from Jeffrey A. Law  ---
Just a note.  Raphael and I are going to poke at this from a different
direction.

[Bug libstdc++/107720] New: [13 regression] New C++ library test cases (and many others) in r13-3936-g1d9454aba615ea fail

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

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

Bug ID: 107720
   Summary: [13 regression] New C++ library test cases (and many
others) in r13-3936-g1d9454aba615ea fail
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:1d9454aba615eadd0d85c93713dd848227345f67, r13-3936-g1d9454aba615ea

This was on a make check of a simple (non-bootstrap) built compiler.  I only
see this on one system.

Ubuntu 22.04.1 LTS
gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1) 


FAIL: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_pedantic_errors.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/operator_names.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess
errors)
FAIL: std/format/arguments/args.cc (test for excess errors)
FAIL: std/format/error.cc (test for excess errors)
FAIL: std/format/formatter.cc (test for excess errors)
FAIL: std/format/functions/format.cc (test for excess errors)
FAIL: std/format/functions/format_to_n.cc (test for excess errors)
FAIL: std/format/functions/size.cc (test for excess errors)
FAIL: std/format/functions/vformat_to.cc (test for excess errors)
FAIL: std/format/parse_ctx.cc (test for excess errors)
FAIL: std/format/string.cc (test for excess errors)
FAIL: std/format/string_neg.cc (test for excess errors)


FAIL: 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2566:
error: '_Args_next_value_' was not declared in this scope; did you mean
'_Arg_next_value_'?
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2903:
error: expected ';' before 'else'
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2906:
error: expected ';' before 'else'
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2999:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:3019:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2999:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:3019:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1421:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&,
std::chars_format&, std::size_t&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1423:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&,
std::chars_format&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1425:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1421:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&,
std::chars_format&, std::size_t&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1423:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&,
std::chars_format&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:1425:
error: call of overloaded 'to_chars(char*&, char*&, __ieee128&)' is ambiguous
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2999:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:3019:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:2999:
error: duplicate case value
/home/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/format:3019:
error: duplicate case value


commit 1d9454aba615eadd0d85c93713dd848227345f67 (HEAD, refs/bisect/bad)
Author: Jonathan Wakely 
Date:   Tue Oct 18 21:20:06 2022 +0100

libstdc++: Implement C++20  [PR104166]

[Bug middle-end/107719] 14% regression on TSVC s3113 on znve4 compared to GCC 7.5

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
As you say, the inner loop is the same, and it iterates 32000 times. Most
likely it crosses an instruction fetch boundary differently, try
-falign-loops=32.

[Bug middle-end/107719] New: 14% regression on TSVC s3113 on znve4 compared to GCC 7.5

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

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

Bug ID: 107719
   Summary: 14% regression on TSVC s3113 on znve4 compared to GCC
7.5
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

jh@alberti:~/tsvc/bin> cat tt5.c
#include 

typedef double real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
real_t qq;
int
main(void)
{
//reductions
//maximum of absolute value


real_t max;
for (int nl = 0; nl < iterations*4; nl++) {
max = fabs(a[0]);
for (int i = 0; i < LEN_1D; i++) {
if ((fabs(a[i])) > max) {
max = fabs(a[i]);
}
}
qq += max;
}

return max;
}
jh@alberti:~/tsvc/bin> /home/jh/trunk-install/bin/gcc -Ofast -march=native
tt5.c  ; perf stat ./a.out

 Performance counter stats for './a.out':

913.92 msec task-clock:u  #0.999 CPUs utilized  
 0  context-switches:u#0.000 /sec   
 0  cpu-migrations:u  #0.000 /sec   
   108  page-faults:u #  118.172 /sec   
 3,342,731,634  cycles:u  #3.658 GHz   
  (83.37%)
15,353  stalled-cycles-frontend:u #0.00% frontend cycles
idle (83.37%)
12,484  stalled-cycles-backend:u  #0.00% backend cycles
idle  (83.38%)
 7,989,930,772  instructions:u#2.39  insn per cycle 
  #0.00  stalled cycles per
insn  (83.37%)
 1,597,552,117  branches:u#1.748 G/sec 
  (83.37%)
   401,094  branch-misses:u   #0.03% of all branches   
  (83.13%)

   0.91493 seconds time elapsed

   0.91463 seconds user
   0.0 seconds sys


jh@alberti:~/tsvc/bin> gcc -Ofast -march=native tt5.c  ; perf stat ./a.out

 Performance counter stats for './a.out':

880.97 msec task-clock:u  #0.999 CPUs utilized  
 0  context-switches:u#0.000 /sec   
 0  cpu-migrations:u  #0.000 /sec   
   110  page-faults:u #  124.862 /sec   
 3,218,698,288  cycles:u  #3.654 GHz   
  (83.21%)
11,566  stalled-cycles-frontend:u #0.00% frontend cycles
idle (83.21%)
12,185  stalled-cycles-backend:u  #0.00% backend cycles
idle  (83.21%)
 7,989,544,164  instructions:u#2.48  insn per cycle 
  #0.00  stalled cycles per
insn  (83.48%)
 1,597,229,244  branches:u#1.813 G/sec 
  (83.66%)
   401,157  branch-misses:u   #0.03% of all branches   
  (83.23%)

   0.881919601 seconds time elapsed

   0.881627000 seconds user
   0.0 seconds sys


It is off-noise. GCC 7.5 does:
main:
.LFB0:
.cfi_startproc
vmovsd  a(%rip), %xmm4
vmovsd  qq(%rip), %xmm3
movl$40, %ecx
movl$a+256000, %edx
vmovapd .LC1(%rip), %zmm2
vandps  .LC0(%rip), %xmm4, %xmm4
vbroadcastsd%xmm4, %zmm4
.p2align 4,,15
.L3:
movl$a, %eax
vmovapd %zmm4, %zmm0
.p2align 4,,15
.L2:
vandpd  (%rax), %zmm2, %zmm1
addq$64, %rax
vmaxpd  %zmm1, %zmm0, %zmm0
cmpq%rax, %rdx
jne .L2
vshufi32x4  $78, %zmm0, %zmm0, %zmm1
decl%ecx
vmaxpd  %zmm0, %zmm1, %zmm0
vshufi32x4  $77, %zmm0, %zmm0, %zmm1
vmaxpd  %zmm0, %zmm1, %zmm1
vpshufd $254, %zmm1, %zmm0
vmaxpd  %zmm1, %zmm0, %zmm0
vaddsd  %xmm0, %xmm3, %xmm3
jne .L3
vmovsd  %xmm3, qq(%rip)
vcvttsd2si  %xmm0, %eax
vzeroupper
ret
.cfi_endproc

while trunk
main:
.LFB0:
.cfi_startproc
vmovsd  a(%rip), %xmm4
vmovsd  qq(%rip), %xmm3
movl$40, %ecx
movl$a+256000, %edx
vandpd  .LC0(%rip), %xmm4, %xmm4
vbroadcastsd.LC2(%rip), %zmm2
vbroadcastsd%xmm4, %zmm4
.p2align 4
.p2align 3
.L3:
vmovapd %zmm4, %zmm0
movl$a, %eax
.p2align 4
.p2align 3
.L2:
vandpd  (%rax), %zmm2, %zmm1
addq$64, %rax
vmaxpd  %zmm1, %zmm0, %zmm0
cmpq%rax, %rdx
   

[Bug tree-optimization/107715] TSVC s161 and s277 for double runs at zen4 30 times slower when vectorization is enabled

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|TSVC s161 for double runs   |TSVC s161 and s277 for
   |at zen4 30 times slower |double runs at zen4 30
   |when vectorization is   |times slower when
   |enabled |vectorization is enabled

--- Comment #4 from Jan Hubicka  ---
This looks to be same issue but also an regression wrt GCC 7.5.0

typedef double real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
real_t qq;
int
main(void)
{


for (int nl = 0; nl < iterations; nl++) {
for (int i = 0; i < LEN_1D-1; i++) {
if (a[i] >= (real_t)0.) {
goto L20;
}
if (b[i] >= (real_t)0.) {
goto L30;
}
a[i] += c[i] * d[i];
L30:
b[i+1] = c[i] + d[i] * e[i];
L20:
;
}
}

return 1;
}
jh@alberti:~/tsvc/bin> gcc -Ofast -march=native tt4.c  ; time ./a.out

real0m0.879s
user0m0.879s
sys 0m0.000s
jh@alberti:~/tsvc/bin> /home/jh/trunk-install/bin/gcc -Ofast -march=native
tt4.c  ; time ./a.out

real0m1.742s
user0m1.741s
sys 0m0.000s
jh@alberti:~/tsvc/bin> clang -Ofast -march=native tt4.c  ; time ./a.out

real0m0.879s
user0m0.879s
sys 0m0.000s

[Bug tree-optimization/99411] s311, s312, s31111, s31111, s3110, vsumr benchmark of TSVC is vectorized by clang better than by gcc

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

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

--- Comment #7 from Jan Hubicka  ---
With znver4 current trunk and clang15 I still see this problem (clang code is
about 60% faster) for s311, s312 and s3111.
Curious s3 and s3110 no longer shows a regression.

[Bug target/87832] AMD pipeline models are very costly size-wise

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

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

--- Comment #10 from Alexander Monakov  ---
(In reply to Jan Hubicka from comment #9)
> Actually for older cores I think the manufacturers do not care much.  I
> still have a working Bulldozer machine and I can do some testing.
> I think in Buldozer case I was basing the latency throughput on data in
> Agner Fog's manuals.

Ahhh, how could I forget that his manuals have data for those cores too. Thanks
for the reminder! This solves the conundrum nicely:

AMD Jaguar ('btver2' in GCC): int/fp division is not pipelined, separate int/fp
dividers;

AMD Bulldozer, Steamroller ('bdver1', 'bdver3'): int division is not pipelined
(one divider), fp division is slightly pipelined (two independent dividers);

Zhaoxin Lujiazui appears to use the same divider as VIA Nano 3000, which is not
pipelined.

So it's already enough to produce a decent patch.

> How do you test it?

For AMD Zen patches I was using measurements by Andreas Abel (
https://uops.info/table_overview.html ) and running a few experiments myself by
coding loops in NASM and timing them with 'perf stat' on a Zen 2 CPU.

[Bug middle-end/107718] New: clang optimizes TSVC s317 a lot better

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

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

Bug ID: 107718
   Summary: clang optimizes TSVC s317 a lot better
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is a stupid benchmark but still...

jh@alberti:~/tsvc/bin> more tt2.c

typedef double real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
real_t qq;
int
main(void)
{

real_t q;
for (int nl = 0; nl < 5*iterations; nl++) {
q = (real_t)1.;
for (int i = 0; i < LEN_1D/2; i++) {
q *= (real_t).99;
}
qq+=q;
}

return q;
}
jh@alberti:~/tsvc/bin> time ./a.out

real0m0.805s
user0m0.805s
sys 0m0.000s
jh@alberti:~/tsvc/bin> clang -Ofast -march=native tt2.c  
jh@alberti:~/tsvc/bin> time ./a.out

real0m0.010s
user0m0.007s
sys 0m0.003s

Clang does:
.LBB0_2:#   Parent Loop BB0_1 Depth=1
# =>  This Inner Loop Header: Depth=2
vmulpd  %zmm2, %zmm3, %zmm3
vmulpd  %zmm2, %zmm4, %zmm4
vmulpd  %zmm2, %zmm5, %zmm5
vmulpd  %zmm2, %zmm6, %zmm6
addl$-3200, %ecx# imm = 0xF380
jne .LBB0_2
# %bb.3:#   in Loop: Header=BB0_1 Depth=1
vmulpd  %zmm3, %zmm4, %zmm3


So it runs multiplications and because of unrolling combines the exponent?

[Bug tree-optimization/99408] s3251 benchmark of TSVC vectorized by clang runs about 7 times faster compared to gcc

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

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

--- Comment #2 from Jan Hubicka  ---
This also reproduces with zen4 and double.

jh@alberti:~/tsvc/bin> cat tt.c
typedef double real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
void
main(void)
{
for (int nl = 0; nl < iterations; nl++) {
for (int i = 0; i < LEN_1D-1; i++){
a[i+1] = b[i]+c[i];
b[i]   = c[i]*e[i];
d[i]   = a[i]*e[i];
}
}
}
jh@alberti:~/tsvc/bin> ~/trunk-install/bin/gcc -Ofast -march=native tt.c
jh@alberti:~/tsvc/bin> time ./a.out

real0m3.590s
user0m3.585s
sys 0m0.004s
jh@alberti:~/tsvc/bin> clang -Ofast -march=native tt.c
tt.c:6:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void
^
tt.c:6:1: note: change return type to 'int'
void
^~~~
int
1 warning generated.
jh@alberti:~/tsvc/bin> time ./a.out

real0m1.538s
user0m1.538s
sys 0m0.000s

gcc generates:

   │ 60:   vmovapd0x67e080(%rax),%zmm7  
  0.15 │   vmovapd0x601080(%rax),%zmm2  
  1.07 │   add$0x40,%rax
   │   vaddpd 0x6bc840(%rax),%zmm7,%zmm0
  0.00 │   vmovupd%zmm0,0x6fb048(%rax)  
 11.10 │   vmulpd 0x601040(%rax),%zmm7,%zmm0
  9.46 │   vmovapd%zmm0,0x6bc840(%rax)  
  0.01 │   vmulpd 0x6fb040(%rax),%zmm2,%zmm0
 78.20 │   vmovapd%zmm0,0x63f840(%rax)  
   │   cmp$0x3e7c0,%rax 
   │ ↑ jne60

clang generates:
   │   nop  
   │ a0:   vmovupd   (%r9,%rdx,1),%zmm15
  0.46 │   vmovupd   (%r9,%rdi,1),%zmm19
  0.22 │   vmovupd   0x40(%r9,%rdx,1),%zmm16
  0.56 │   vmovupd   0x40(%r9,%rdi,1),%zmm22
  0.92 │   vmovupd   0x80(%r9,%rdx,1),%zmm17
  1.85 │   vmovupd   0x80(%r9,%rdi,1),%zmm21
  1.51 │   vaddpd(%r9,%rcx,1),%zmm15,%zmm18 
  0.84 │   vmulpd%zmm15,%zmm19,%zmm15   
  0.47 │   vmovupd   %zmm15,(%r9,%rcx,1)
  3.37 │   vaddpd0x40(%r9,%rcx,1),%zmm16,%zmm15 
  0.56 │   vmulpd%zmm16,%zmm22,%zmm16   
  0.69 │   vmovupd   %zmm16,0x40(%r9,%rcx,1)
  3.82 │   vmovupd   %zmm18,0x8(%r9,%rsi,1) 
  3.27 │   vmovapd   %zmm15,%zmm20  
   │   vmovupd   %zmm15,0x48(%r9,%rsi,1)
  3.60 │   vpermt2pd %zmm18,%zmm13,%zmm20   
  0.47 │   vpermt2pd %zmm14,%zmm13,%zmm18   
  0.36 │   vmulpd%zmm19,%zmm18,%zmm18   
  1.07 │   vmulpd%zmm22,%zmm20,%zmm14   
  1.33 │   vmovupd   %zmm18,(%r9,%r8,1) 
  6.31 │   vmovupd   %zmm14,0x40(%r9,%r8,1) 
  8.02 │   vaddpd0x80(%r9,%rcx,1),%zmm17,%zmm14 
  0.53 │   vmovapd   %zmm14,%zmm16  
  0.05 │   vmovupd   %zmm14,0x88(%r9,%rsi,1)
  3.08 │   vpermt2pd %zmm15,%zmm13,%zmm16   
  0.41 │   vmulpd%zmm17,%zmm21,%zmm15   
  0.20 │   vmovupd   %zmm15,0x80(%r9,%rcx,1)
  1.60 │   vmulpd%zmm21,%zmm16,%zmm15   
  1.16 │   vmovupd   %zmm15,0x80(%r9,%r8,1) 
  3.13 │   add   $0xc0,%r9  
   │   cmp   $0x3e7c0,%r9   
  0.03 │ ↑ jne   a0   

So a forward-dependency here?

[Bug c++/107310] [12/13 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional since r12-5638-ga3e75c1491cd2d50

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is similar to C:
void bar (int *x);
__attribute__((noreturn)) void baz (void);

int
foo (void)
{
  int a __attribute__((cleanup (bar)));
  if (1)
baz ();
}
on which we were at -O0 warning already in 4.7, haven't tried older compilers.
In C we optimizing the if (0) and if (1) conditions at genericization time,
only in C++ we were and now we no longer do.

[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars

[kevin.bracey at alifsemi dot com via Gcc-bugs]

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

--- Comment #2 from Kevin Bracey  ---
I've just spotted another apparent generic selection problem in my reproducer
for  bug 107714 - should I create a new issue for it?

[Bug middle-end/107709] IVOPTs is introducing a non-zero assumption

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
we might be able to provide a lightweight ranger based query to determine if an
ssa_name is  non-null in a block.. in fact..  we may not need anything special.

/* Create a new ranger instance and associate it with a function.
   Each call must be paired with a call to disable_ranger to release
   resources.  If USE_IMM_USES is true, pre-calculate sideffects like
   non-null uses as required using the immediate use chains.  */
extern gimple_ranger *enable_ranger (struct function *m,
 bool use_imm_uses = true);

simply using the on-demand default which sets use_imm_uses to true is probably
enough,  When a pointer is queried, if it hasn't been done yet, all immediate
uses are scanned and if there is an inferred range, those blocks are tagged
with an on-exit range on non-zero.

simply querying get_range_query->range_of_expr (r, name, stmt)  will then walk
the dom tree and tell you through r if name is non-zero or not.

If we end up needing something more efficient for this purpose, we could
harvest that code and produce a module which much more efficiently processes
inferred ranges simply looking for whether a specific property is true or not