[Bug fortran/99350] [10/11/12/13/14 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1869

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

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

Paul Thomas  changed:

   What|Removed |Added

 Blocks|87477   |
 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
program p
   character((0.)/0), target :: c = 'abc'
   print *, c
end

Is a sufficient reproducer and so this is not an associate bug.

I am removing it from the blocks PR87477 list but will keep at it. For whatever
reason, the parentheses block the identification of the divide by zero.

Removing the decl.cc chunk in the patch identified in comment #1 (thanks again
Martin!) fixes this problem but changes the error messages in the testcases.

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements

[admin--- via Gcc-bugs]

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

--- Comment #2 from Thorsten Otto  ---
But even if i rewrite it like that, i still get the warning.

I avoided doing anything machine specific in the first example, but if i
actually do, and use something like:

PROCEDURE test;
BEGIN
  ASM("movl %1,%%eax; addl $1,%%eax; movl %%eax,%0" : "=r"(x) : "0"(x) :
"eax");
END test;

i still get the warning.

BTW, is there a reason why the string in the asm statement can't be
concatenated?

eg. especially if the statement becomes longer, you would usually want to write
it something like

  ASM("movl %1,%%eax;" +
  "addl $1,%%eax;" +
  "movl %%eax,%0"
 : "=r"(x) : "0"(x) : "eax");

[Bug target/97784] Expressions evaluated as long chain instead of as tree or the like

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-07

[Bug rtl-optimization/68274] __builtin_unreachable pessimizes code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed in GCC 13 by vrp2 removing the __builtin_unreachable at that point and
allowing a later phiopt to do the job.

[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381

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

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

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

https://gcc.gnu.org/g:3f085e45755643f13d4fa45a12a6ade45be98f95

commit r14-1601-g3f085e45755643f13d4fa45a12a6ade45be98f95
Author: Andrew Pinski 
Date:   Sun Jun 4 19:42:08 2023 -0700

Handle const_int in expand_single_bit_test

After expanding directly to rtl instead of
creating a tree, we could end up with
a const_int which is not ready to be handled
by extract_bit_field.
So need to the constant folding here instead.

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

PR middle-end/110117

gcc/ChangeLog:

* expr.cc (expand_single_bit_test): Handle
const_int from expand_expr.

gcc/testsuite/ChangeLog:

* gcc.dg/pr110117-1.c: New test.
* gcc.dg/pr110117-2.c: New test.

[Bug middle-end/110117] [14 Regression] ICE on valid code at -O1 with "-ftree-vrp -fno-tree-ccp -fno-tree-forwprop": in as_a, at machmode.h:381

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

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

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

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

commit r14-1600-ge60593f3881c72a96a3fa4844d73e8a2cd14f670
Author: Andrew Pinski 
Date:   Sun Jun 4 19:21:05 2023 -0700

Improve do_store_flag for single bit when there is no non-zero bits

In r14-1534-g908e5ab5c11c, I forgot you could turn off CCP or
turn off the bit tracking part of CCP so we would lose out
what TER was able to do before hand. This moves around the
TER code so that it is used instead of just the nonzerobits.
It also makes it easier to remove the TER part of the code
later on too.

OK? Bootstrapped and tested on x86_64-linux-gnu.

Note it reintroduces PR 110117 (which was accidently fixed after
r14-1534-g908e5ab5c11c). The next patch in series will fix that.

gcc/ChangeLog:

* expr.cc (do_store_flag): Rearrange the
TER code so that it overrides the nonzero bits
info if we had `a & POW2`.

[Bug tree-optimization/14753] [tree-ssa] some missed forward propagation opportunities

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

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

Bug 110134 Summary: [10/11/12/13/14 Regression] (-unsigned1) != CST is not 
optimized to unsigned1 != CST at the gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110134

   What|Removed |Added

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

[Bug tree-optimization/110134] [10/11/12/13/14 Regression] (-unsigned1) != CST is not optimized to unsigned1 != CST at the gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed on the trunk for GCC 14, the performance regression due to this bug I
doubt is noticable since it had not been noticed since GCC 6 even (well PR
14753 noticed it but it was similar to this one, it was not noticed in real
code yet).

[Bug tree-optimization/110134] [10/11/12/13/14 Regression] (-unsigned1) != CST is not optimized to unsigned1 != CST at the gimple level

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

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

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

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

commit r14-1599-gcc155ff9c38848a8e6a7125dd0b66ac0aef47880
Author: Andrew Pinski 
Date:   Mon Jun 5 19:12:43 2023 -0700

For the `-A CMP -B -> B CMP A` pattern allow EQ/NE for all integer types

I noticed while looking at some code generation issue, that forwprop
was not handling `-a == 0` for unsigned types and I was confused why
it was not.
r6-1814-g66e1cacf608045 removed these from fold because they
were supposed to be already handled by the match.pd patterns
but it was missed that the match.pd patterns checked
TYPE_OVERFLOW_UNDEFINED while fold didn't do that for NE/EQ.
This patch removes the restriction on NE/EQ on TYPE_OVERFLOW_UNDEFINED.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/110134
* match.pd (-A CMP -B -> B CMP A): Allow EQ/NE for all integer
types.
(-A CMP CST -> B CMP (-CST)): Likewise.

gcc/testsuite/ChangeLog:

PR tree-optimization/110134
* gcc.dg/tree-ssa/negneq-1.c: New test.
* gcc.dg/tree-ssa/negneq-2.c: New test.
* gcc.dg/tree-ssa/negneq-3.c: New test.
* gcc.dg/tree-ssa/negneq-4.c: New test.

[Bug tree-optimization/110151] New: warning: 'strncpy' output truncated copying 10 bytes from a string of length 26 [-Wstringop-truncation]

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

Bug ID: 110151
   Summary: warning: 'strncpy' output truncated copying 10 bytes
from a string of length 26 [-Wstringop-truncation]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yinyuefengyi at gmail dot com
  Target Milestone: ---

For the below two cases(https://godbolt.org/z/5rbMTeqW9), are they false
positive warnings seem unnecessary since:

for foo1:
 memset has cleared the memory;

for foo2:
 though 'dest[11] = '\0';' is not the 'immediately' next_stmt after strncpy but
it does setting the last element to nul? 

#include 
#include 

int foo1 () {
char src[40];
char dest[12];

memset(dest, '\0', sizeof(dest));
strcpy(src, "This is tutorialspoint.com");
strncpy(dest, src, 10);

printf("%s", dest);
return(0);
}

char a;
int foo2 () {
char src[40];
char dest[12];

strcpy(src, "This is tutorialspoint.com");
strncpy(dest, src, 10);
a = dest[0];
dest[11] = '\0';

printf("%s", dest);
return(0);
}

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

Bug 89263 Summary: Simplify bool expression to OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263

   What|Removed |Added

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

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

Bug 89263 Summary: Simplify bool expression to OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263

   What|Removed |Added

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

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

Bug 89263 Summary: Simplify bool expression to OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263

   What|Removed |Added

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

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed finally (after 18 years) of messing around with PHI-OPT :).

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 94898 Summary: Failure to optimize compare plus sub of same operands into 
compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94898

   What|Removed |Added

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

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

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

https://gcc.gnu.org/g:64d90d06d2db43538c8a45adbb3d74842f7868ae

commit r14-1597-g64d90d06d2db43538c8a45adbb3d74842f7868ae
Author: Andrew Pinski 
Date:   Wed May 24 07:08:45 2023 +

Add match patterns for `a ? onezero : onezero` where one of the two
operands are constant

This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.

This was reported a few times and I thought I would finally
add the match pattern for this.

This hits a few times in GCC itself too.

Notes on the testcases:
* phi-opt-2.c: This now is optimized to `a & b` in phiopt rather than
ifcombine
* phi-opt-25b.c: The test part that was failing was parity which now gets
`x & y` treatment.
* ssa-thread-21.c: there is no longer a threading opportunity, so need to
disable phiopt.
  Note PR 109957 is filed for the now missing optimization in that testcase
too.

gcc/ChangeLog:

PR tree-optimization/89263
PR tree-optimization/99069
PR tree-optimization/20083
PR tree-optimization/94898
* match.pd: Add patterns to optimize `a ? onezero : onezero` with
one of the operands are constant.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-2.c: Adjust the testcase.
* gcc.dg/tree-ssa/phi-opt-25b.c: Adjust the testcase.
* gcc.dg/tree-ssa/ssa-thread-21.c: Disable phiopt.
* gcc.dg/tree-ssa/phi-opt-27.c: New test.
* gcc.dg/tree-ssa/phi-opt-28.c: New test.
* gcc.dg/tree-ssa/phi-opt-29.c: New test.
* gcc.dg/tree-ssa/phi-opt-30.c: New test.
* gcc.dg/tree-ssa/phi-opt-31.c: New test.
* gcc.dg/tree-ssa/phi-opt-32.c: New test.

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

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

https://gcc.gnu.org/g:64d90d06d2db43538c8a45adbb3d74842f7868ae

commit r14-1597-g64d90d06d2db43538c8a45adbb3d74842f7868ae
Author: Andrew Pinski 
Date:   Wed May 24 07:08:45 2023 +

Add match patterns for `a ? onezero : onezero` where one of the two
operands are constant

This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.

This was reported a few times and I thought I would finally
add the match pattern for this.

This hits a few times in GCC itself too.

Notes on the testcases:
* phi-opt-2.c: This now is optimized to `a & b` in phiopt rather than
ifcombine
* phi-opt-25b.c: The test part that was failing was parity which now gets
`x & y` treatment.
* ssa-thread-21.c: there is no longer a threading opportunity, so need to
disable phiopt.
  Note PR 109957 is filed for the now missing optimization in that testcase
too.

gcc/ChangeLog:

PR tree-optimization/89263
PR tree-optimization/99069
PR tree-optimization/20083
PR tree-optimization/94898
* match.pd: Add patterns to optimize `a ? onezero : onezero` with
one of the operands are constant.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-2.c: Adjust the testcase.
* gcc.dg/tree-ssa/phi-opt-25b.c: Adjust the testcase.
* gcc.dg/tree-ssa/ssa-thread-21.c: Disable phiopt.
* gcc.dg/tree-ssa/phi-opt-27.c: New test.
* gcc.dg/tree-ssa/phi-opt-28.c: New test.
* gcc.dg/tree-ssa/phi-opt-29.c: New test.
* gcc.dg/tree-ssa/phi-opt-30.c: New test.
* gcc.dg/tree-ssa/phi-opt-31.c: New test.
* gcc.dg/tree-ssa/phi-opt-32.c: New test.

[Bug tree-optimization/109957] Missing loop PHI optimization

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

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

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

https://gcc.gnu.org/g:64d90d06d2db43538c8a45adbb3d74842f7868ae

commit r14-1597-g64d90d06d2db43538c8a45adbb3d74842f7868ae
Author: Andrew Pinski 
Date:   Wed May 24 07:08:45 2023 +

Add match patterns for `a ? onezero : onezero` where one of the two
operands are constant

This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.

This was reported a few times and I thought I would finally
add the match pattern for this.

This hits a few times in GCC itself too.

Notes on the testcases:
* phi-opt-2.c: This now is optimized to `a & b` in phiopt rather than
ifcombine
* phi-opt-25b.c: The test part that was failing was parity which now gets
`x & y` treatment.
* ssa-thread-21.c: there is no longer a threading opportunity, so need to
disable phiopt.
  Note PR 109957 is filed for the now missing optimization in that testcase
too.

gcc/ChangeLog:

PR tree-optimization/89263
PR tree-optimization/99069
PR tree-optimization/20083
PR tree-optimization/94898
* match.pd: Add patterns to optimize `a ? onezero : onezero` with
one of the operands are constant.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-2.c: Adjust the testcase.
* gcc.dg/tree-ssa/phi-opt-25b.c: Adjust the testcase.
* gcc.dg/tree-ssa/ssa-thread-21.c: Disable phiopt.
* gcc.dg/tree-ssa/phi-opt-27.c: New test.
* gcc.dg/tree-ssa/phi-opt-28.c: New test.
* gcc.dg/tree-ssa/phi-opt-29.c: New test.
* gcc.dg/tree-ssa/phi-opt-30.c: New test.
* gcc.dg/tree-ssa/phi-opt-31.c: New test.
* gcc.dg/tree-ssa/phi-opt-32.c: New test.

[Bug tree-optimization/99069] Failure to optimize bool selection pattern

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

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

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

https://gcc.gnu.org/g:64d90d06d2db43538c8a45adbb3d74842f7868ae

commit r14-1597-g64d90d06d2db43538c8a45adbb3d74842f7868ae
Author: Andrew Pinski 
Date:   Wed May 24 07:08:45 2023 +

Add match patterns for `a ? onezero : onezero` where one of the two
operands are constant

This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.

This was reported a few times and I thought I would finally
add the match pattern for this.

This hits a few times in GCC itself too.

Notes on the testcases:
* phi-opt-2.c: This now is optimized to `a & b` in phiopt rather than
ifcombine
* phi-opt-25b.c: The test part that was failing was parity which now gets
`x & y` treatment.
* ssa-thread-21.c: there is no longer a threading opportunity, so need to
disable phiopt.
  Note PR 109957 is filed for the now missing optimization in that testcase
too.

gcc/ChangeLog:

PR tree-optimization/89263
PR tree-optimization/99069
PR tree-optimization/20083
PR tree-optimization/94898
* match.pd: Add patterns to optimize `a ? onezero : onezero` with
one of the operands are constant.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-2.c: Adjust the testcase.
* gcc.dg/tree-ssa/phi-opt-25b.c: Adjust the testcase.
* gcc.dg/tree-ssa/ssa-thread-21.c: Disable phiopt.
* gcc.dg/tree-ssa/phi-opt-27.c: New test.
* gcc.dg/tree-ssa/phi-opt-28.c: New test.
* gcc.dg/tree-ssa/phi-opt-29.c: New test.
* gcc.dg/tree-ssa/phi-opt-30.c: New test.
* gcc.dg/tree-ssa/phi-opt-31.c: New test.
* gcc.dg/tree-ssa/phi-opt-32.c: New test.

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

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

https://gcc.gnu.org/g:64d90d06d2db43538c8a45adbb3d74842f7868ae

commit r14-1597-g64d90d06d2db43538c8a45adbb3d74842f7868ae
Author: Andrew Pinski 
Date:   Wed May 24 07:08:45 2023 +

Add match patterns for `a ? onezero : onezero` where one of the two
operands are constant

This adds a match pattern that are for boolean values
that optimizes `a ? onezero : 0` to `a & onezero` and
`a ? 1 : onezero` to `a | onezero`.

This was reported a few times and I thought I would finally
add the match pattern for this.

This hits a few times in GCC itself too.

Notes on the testcases:
* phi-opt-2.c: This now is optimized to `a & b` in phiopt rather than
ifcombine
* phi-opt-25b.c: The test part that was failing was parity which now gets
`x & y` treatment.
* ssa-thread-21.c: there is no longer a threading opportunity, so need to
disable phiopt.
  Note PR 109957 is filed for the now missing optimization in that testcase
too.

gcc/ChangeLog:

PR tree-optimization/89263
PR tree-optimization/99069
PR tree-optimization/20083
PR tree-optimization/94898
* match.pd: Add patterns to optimize `a ? onezero : onezero` with
one of the operands are constant.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/phi-opt-2.c: Adjust the testcase.
* gcc.dg/tree-ssa/phi-opt-25b.c: Adjust the testcase.
* gcc.dg/tree-ssa/ssa-thread-21.c: Disable phiopt.
* gcc.dg/tree-ssa/phi-opt-27.c: New test.
* gcc.dg/tree-ssa/phi-opt-28.c: New test.
* gcc.dg/tree-ssa/phi-opt-29.c: New test.
* gcc.dg/tree-ssa/phi-opt-30.c: New test.
* gcc.dg/tree-ssa/phi-opt-31.c: New test.
* gcc.dg/tree-ssa/phi-opt-32.c: New test.

[Bug c++/98105] constexpr and unnamed namespace yields relocation R_X86_64_PC32 against undefined symbol ... can not be used when making a shared object; recompile with -fPIC

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

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

--- Comment #3 from Andrew Pinski  ---
Reduced:
```
void f(const int&);

namespace {
  struct myFactory
  {
static constexpr int s_sList = 1;
  };
}
//constexpr int myFactory::s_sList;
void sdi_register_model()
{
  f(myFactory::s_sList);
}
```

If we uncomment the definition, it works.

I think this is correct behavior, just we should produce a better error message
of not have the definition and only the declaration here.

[Bug debug/86257] Program compiled with fPIC crashes while stepping over thread-local variable GDB

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #14 from cuilili  ---
This regression has been fixed with the commit below and we can close this
ticket.

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

[Bug target/58208] deque 32-bit "-O3" bug

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #15)
> This was a glibc issue.
> 
> Fixed by glibc commit 5e49c52efdb37eb0aa315156f39056f25ff9ddaa (
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=5e49c52efdb37eb0aa315156f39056f25ff9ddaa )

Which was included in glibc-2.13 (and above).

[Bug target/58208] deque 32-bit "-O3" bug

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Pinski  ---
This was a glibc issue.

Fixed by glibc commit 5e49c52efdb37eb0aa315156f39056f25ff9ddaa (
https://sourceware.org/git/?p=glibc.git;a=commit;h=5e49c52efdb37eb0aa315156f39056f25ff9ddaa
)

[Bug target/58208] deque 32-bit "-O3" bug

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

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

--- Comment #14 from Andrew Pinski  ---
movdqa  %xmm1, 16(%esp)
movdqa  %xmm0, 32(%esp)

Maybe stack alignment for deconstructors.

[Bug tree-optimization/110038] [14 Regression] ICE: in rewrite_expr_tree_parallel, at tree-ssa-reassoc.cc:5522 with --param=tree-reassoc-width=2147483647

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #5 from cuilili  ---
(In reply to Martin Jambor from comment #4)
> So is this now fixed?

Yes, the attachment case has been fixed.

[Bug target/84377] gcc-7.3.0 miscompiles truncf128@@GLIBC_2.26 in libm.so

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Dup of bug 81763 in the end.

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

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dilfridge at gentoo dot org

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

[Bug target/84377] gcc-7.3.0 miscompiles truncf128@@GLIBC_2.26 in libm.so

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

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

--- Comment #5 from Andrew Pinski  ---
The gimple level is the same:
```
  _5 = 281474976710655 >> j0_20;
  _6 = ~_5;
  _7 = (long long unsigned int) _6;
  _8 = _7 & _35;
  qw_u.parts64.msw = _8;
  qw_u.parts64.lsw = 0;
```

The place where it changes first between GCC 7.3 and 7.4 is IRA.

[Bug c++/51571] No named return value optimization while adding a dummy scope

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #10 from Jason Merrill  ---
Fixed for GCC 14.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

--- Comment #9 from Jason Merrill  ---
Fixed for GCC 14 so far.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1593-g7e0b65b239c3a0d68ce94896b236b03de666ffd6
Author: Jason Merrill 
Date:   Sun Jun 4 12:09:11 2023 -0400

c++: enable NRVO from inner block [PR51571]

Our implementation of the named return value optimization has been limited
to variables declared in the outermost block of the function, to avoid
needing to handle the case where the variable needs to be destroyed due to
going out of scope.  PR92407 pointed out a case we were missing, where the
variable goes out of scope due to a goto and we were failing to destroy it.

It occurred to me that this problem is the flip side of PR33799, where we
need to be sure to destroy the return value if a cleanup throws on return;
here we want to avoid destroying the return value when exiting the
variable's scope on return.  We can use the same flag to indicate to both
cleanups that we're returning.

This implements the guaranteed copy elision specified by P2025 (which is
not
yet part of the draft standard).

PR c++/51571
PR c++/92407

gcc/cp/ChangeLog:

* decl.cc (finish_function): Simplify NRV handling.
* except.cc (maybe_set_retval_sentinel): Also set if NRV.
(maybe_splice_retval_cleanup): Don't add the cleanup region
if we don't need it.
* semantics.cc (nrv_data): Add simple field.
(finalize_nrv): Set it.
(finalize_nrv_r): Check it and retval sentinel.
* cp-tree.h (finalize_nrv): Adjust declaration.
* typeck.cc (check_return_expr): Remove named_labels check.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv23.C: New test.

[Bug c++/51571] No named return value optimization while adding a dummy scope

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

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

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1593-g7e0b65b239c3a0d68ce94896b236b03de666ffd6
Author: Jason Merrill 
Date:   Sun Jun 4 12:09:11 2023 -0400

c++: enable NRVO from inner block [PR51571]

Our implementation of the named return value optimization has been limited
to variables declared in the outermost block of the function, to avoid
needing to handle the case where the variable needs to be destroyed due to
going out of scope.  PR92407 pointed out a case we were missing, where the
variable goes out of scope due to a goto and we were failing to destroy it.

It occurred to me that this problem is the flip side of PR33799, where we
need to be sure to destroy the return value if a cleanup throws on return;
here we want to avoid destroying the return value when exiting the
variable's scope on return.  We can use the same flag to indicate to both
cleanups that we're returning.

This implements the guaranteed copy elision specified by P2025 (which is
not
yet part of the draft standard).

PR c++/51571
PR c++/92407

gcc/cp/ChangeLog:

* decl.cc (finish_function): Simplify NRV handling.
* except.cc (maybe_set_retval_sentinel): Also set if NRV.
(maybe_splice_retval_cleanup): Don't add the cleanup region
if we don't need it.
* semantics.cc (nrv_data): Add simple field.
(finalize_nrv): Set it.
(finalize_nrv_r): Check it and retval sentinel.
* cp-tree.h (finalize_nrv): Adjust declaration.
* typeck.cc (check_return_expr): Remove named_labels check.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv23.C: New test.

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1592-gb192e2007e1c98b548f4aa878523b485968d24a4
Author: Jason Merrill 
Date:   Sun Jun 4 12:00:55 2023 -0400

c++: NRV and goto [PR92407]

Here our named return value optimization was breaking the required
destructor when the goto takes 'a' out of scope.  The simplest fix is to
disable the optimization in the presence of user labels.

We could do better by disabling the optimization only if there is a
backward
goto across the variable declaration, but we don't currently track that.

PR c++/92407

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): Prevent NRV in the presence of
named labels.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv22.C: New test.

[Bug c++/58487] Missed return value optimization

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

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

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

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

commit r14-1594-g2ae5384d457b9c67586de012816dfc71a6943164
Author: Jason Merrill 
Date:   Tue Jun 6 12:46:26 2023 -0400

c++: Add -Wnrvo

While looking at PRs about cases where we don't perform the named return
value optimization, it occurred to me that it might be useful to have a
warning for that.

This does not fix PR58487, but might be interesting to people watching it.

PR c++/58487

gcc/c-family/ChangeLog:

* c.opt: Add -Wnrvo.

gcc/ChangeLog:

* doc/invoke.texi: Document it.

gcc/cp/ChangeLog:

* typeck.cc (want_nrvo_p): New.
(check_return_expr): Handle -Wnrvo.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv25.C: New test.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

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

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

--- Comment #22 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:08cea4e56a094ff9cc7c65fdc9ce8c4d7aff64be

commit r14-1591-g08cea4e56a094ff9cc7c65fdc9ce8c4d7aff64be
Author: Jason Merrill 
Date:   Tue Jun 6 15:31:23 2023 -0400

c++: fix throwing cleanup with label

While looking at PR92407 I noticed that the expectations of
maybe_splice_retval_cleanup weren't being met; an sk_cleanup level was
confusing its attempt to recognize the outer block of the function.  And
even if I fixed the detection, it failed to actually wrap the body of the
function because the STATEMENT_LIST it got only had the label, not anything
after it.  So I moved the call after poplevel does pop_stmt_list on all the
sk_cleanup levels.

PR c++/33799

gcc/cp/ChangeLog:

* except.cc (maybe_splice_retval_cleanup): Change
recognition of function body and try scopes.
* semantics.cc (do_poplevel): Call it after poplevel.
(at_try_scope): New.
* cp-tree.h (maybe_splice_retval_cleanup): Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/eh/return1.C: Add label cases.

[Bug c++/58050] No return value optimization when calling static function through unnamed temporary

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4fe84e2a4c0b600d2bc01f171b3b9dd1f4357208

commit r14-1589-g4fe84e2a4c0b600d2bc01f171b3b9dd1f4357208
Author: Jason Merrill 
Date:   Tue Jun 6 12:01:23 2023 -0400

c++: add NRV testcase [PR58050]

This was fixed in GCC 10.

PR c++/58050

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv24.C: New test.

[Bug target/84377] gcc-7.3.0 miscompiles truncf128@@GLIBC_2.26 in libm.so

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

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

--- Comment #4 from Andrew Pinski  ---
GCC 7.3.0:
```
.loc 1 42 0 discriminator 2
movl$65535, %edi
movl$-1, %esi
movl$0, 48(%esp)
shrdl   %edi, %esi
testb   $32, %cl
sarx%ecx, %edi, %edi
movl$0, 52(%esp)
cmovne  %edi, %esi
andn%eax, %esi, %esi
andn%edx, %esi, %edi
movl%esi, 56(%esp)
movl%edi, 60(%esp)
vmovdqa 48(%esp), %xmm3
vmovaps %xmm3, (%esp)
```

GCC 7.4.0:
```
.loc 1 42 0 discriminator 2
movl$65535, %edi
movl$-1, %esi
movl$0, 48(%esp)
shrdl   %edi, %esi
sarx%ecx, %edi, %edi
movl%edi, %ebx
movl$0, 52(%esp)
sarl$31, %ebx
testb   $32, %cl
cmovne  %edi, %esi
cmovne  %ebx, %edi
andn%eax, %esi, %esi
andn%edx, %edi, %edi
movl%esi, 56(%esp)
movl%edi, 60(%esp)
vmovdqa 48(%esp), %xmm3
vmovaps %xmm3, (%esp)
```

[Bug target/84377] gcc-7.3.0 miscompiles truncf128@@GLIBC_2.26 in libm.so

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||7.4.0, 7.5.0, 8.1.0
  Known to fail||7.3.0

--- Comment #3 from Andrew Pinski  ---
So I can reproduce it with GCC 7.3.0 with:
```
-xc -march=skylake -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a
-mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma
-mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1
-mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr
-mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf
-mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw
-mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps
-mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -m32
-O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -fno-strict-aliasing
-frounding-math -fstack-protector-all -mpreferred-stack-boundary=4  -fPIC
```
But it passes with GCC 7.4.0.

[Bug tree-optimization/14753] [tree-ssa] some missed forward propagation opportunities

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||85234, 110134

--- Comment #13 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #12)
> Summary of the ones still need to be done:
> comment #0:
> * foo
PR 85234 (I think)

> comment #3:
> * rshift_gt
PR 85234 (I think)
> * rshift_eq
PR 85234 (I think)
> * mask_gt
I don't think this has a bug #

> * neg_eq_cst
> * neg_eq_var
PR 110134 (just submitted a patch for that)

> 
> comment #4:
> * minus_cst
I don't think this has a bug #


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85234
[Bug 85234] missed optimisation opportunity for (x >> CST)!=0 is not optimized
to   (((unsigned)x) >=  (1

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

--- Comment #5 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620829.html

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

--- Comment #7 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620829.html

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||0829.html

--- Comment #10 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620829.html

[Bug modula2/110019] Reported line numbers ar off-by-1 when preprocessing source files

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug modula2/110019] Reported line numbers ar off-by-1 when preprocessing source files

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:29c82c6ca929e0f5eccfe038dea71177d814c6b7

commit r14-1588-g29c82c6ca929e0f5eccfe038dea71177d814c6b7
Author: Gaius Mulley 
Date:   Wed Jun 7 01:21:19 2023 +0100

PR modula2/110019 Reported line numbers off by 1 when cpp invoked.

Fix off by one in m2.flex when the line number is set via cpp.

gcc/m2/ChangeLog:

PR modula2/110019
* gm2-compiler/SymbolKey.mod (SearchAndDo): Reformatted.
(ForeachNodeDo): Reformatted.
* gm2-compiler/SymbolTable.mod (AddListify): Join list
with "," or "and" if more than one word is in the list.
* m2.flex: Remove -1 from atoi(yytext) line number.

gcc/testsuite/ChangeLog:

PR modula2/110019
* gm2/cpp/fail/cpp-fail.exp: New test.
* gm2/cpp/fail/foocpp.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/110019] Reported line numbers ar off-by-1 when preprocessing source files

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #2 from Gaius Mulley  ---
Created attachment 55276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55276=edit
Proposed fix

Here is a proposed patch:

[Bug target/54089] [SH] Refactor shift patterns

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

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

--- Comment #67 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #66)
> (In reply to Alexander Klepikov from comment #65)
> > > I'm thinking of something else.
> > 
> > During kernel compile I got few internal errors in different passes. That
> > is, additional loop optimization pass patch is no good at all.
> 
> I am sorry, I am, as always, panicking ahead of time. I think I found what's
> wrong and do additional tests.

Don't worry.  I know what you're going through.  Been there myself ;)
Take your time.

[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Backported as r13-7423-gff58310f274e49 for 13.2

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

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

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

--- Comment #3 from Jonathan Wakely  ---
It looks like I forgot to actually format using 'P' though, I only parsed it
from the format string.

This would fix that, and disable the P2519 changes for -std=c++20 and
-std=c++23:

--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2081,19 +2081,29 @@ namespace __format
if (__finished())
  return __first;

+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// P2519R3 Formatting pointers
__first = __spec._M_parse_zero_fill(__first, __last);
if (__finished())
  return __first;
+#endif

__first = __spec._M_parse_width(__first, __last, __pc);

-   if (__first != __last && (*__first == 'p' || *__first == 'P'))
+   if (__first != __last)
  {
-   if (*__first == 'P')
+   if (*__first == 'p')
+ ++__first;
+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
+   else if (*__first == 'P'))
+   {
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // P2519R3 Formatting pointers
  __spec._M_type = __format::_Pres_P;
-   ++__first;
+ ++__first;
+   }
+#endif
  }

if (__finished())
@@ -2113,6 +2123,18 @@ namespace __format
  const int __n = __ptr - __buf;
  __buf[0] = '0';
  __buf[1] = 'x';
+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
+ if (_M_spec._M_type == _Pres_)
+   {
+ __buf[1] = 'X';
+ for (auto __p = __buf + 2; __p != __res.ptr; ++__p)
+#if __has_builtin(__builtin_toupper)
+   *__p = __builtin_toupper(*__p);
+#else
+   *__p = std::toupper(*__p);
+#endif
+   }
+#endif

  basic_string_view<_CharT> __str;
  if constexpr (is_same_v<_CharT, char>)

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

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

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

--- Comment #2 from Jonathan Wakely  ---
GCC's formatter specialization has:

// _GLIBCXX_RESOLVE_LIB_DEFECTS
// P2519R3 Formatting pointers
__first = __spec._M_parse_zero_fill(__first, __last);
if (__finished())
  return __first;

__first = __spec._M_parse_width(__first, __last, __pc);

if (__first != __last && (*__first == 'p' || *__first == 'P'))
  {
if (*__first == 'P')
  __spec._M_type = __format::_Pres_P;
++__first;
  }

Arguably, P2591 is not fixing a defect and so parsing '0' and 'P' could be
guarded behind a check for #if __cplusplus > 202302L but I think it's more
useful to treat this as a fix for C++20 and C++23, not just a C++26 change.

[Bug ipa/92606] [10/11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

--- Comment #18 from Andrew Pinski  ---
Here is a x86_64 testcase:
```
typedef __UINT16_TYPE__ T;

#define NI __attribute__((noinline,noclone,no_icf))

static const __seg_fs T xyz_prog[] = { 123, 123, 123 };
static __seg_gs T xyz[] = { 123, 123, 123 };
volatile int x = 0;

NI void prf (T f)
{
if (f != 123)
__builtin_abort();
}

NI void func_progmem()
{
prf(xyz_prog[x]);
}

NI void func_ram()
{
prf(xyz[x]);
}

int main()
{
func_progmem();
func_ram();
}
```

We get:
movzwl  %fs:xyz_prog(%rax,%rax), %edi
...
movzwl  %gs:xyz(%rax,%rax), %edi
...
.section.rodata
.align 2
.type   xyz_prog, @object
.size   xyz_prog, 6
xyz_prog:
.value  123
.value  123
.value  123
.setxyz,xyz_prog

Maybe for x86_64, it is less of an issue because the fs/gs address space
overlap with the main address space.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

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

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

--- Comment #1 from Jonathan Wakely  ---
0p is proposed by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2510r3.pdf

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

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

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

--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Reducing the std module down to the following always produces a crash in
dmd_aaGetRvalue when running debian/ubuntu pre-compiled gdc-13 under gdb.

---
struct Tid
{
MessageBox mbox;
}

struct ThreadInfo
{
bool[Tid] links;
}

class MessageBox
{
}
---

Reproducing with own built gdc is proving to be elusive.

[Bug c++/110150] std::optional inside template leads to long compilation time

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Steven Xia  ---
(In reply to Andrew Pinski from comment #2)
> basically you are getting optional ...

Understood, thanks for the quick reply

[Bug c++/110150] std::optional inside template leads to long compilation time

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

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

--- Comment #2 from Andrew Pinski  ---
basically you are getting optional ...

[Bug modula2/110019] Reported line numbers ar off-by-1 when preprocessing source files

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Confirmed - thanks for the bug report.

[Bug c++/110150] std::optional inside template leads to long compilation time

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog

--- Comment #1 from Andrew Pinski  ---
I am not shocked because even this takes some time (not as much as the original
one):
```
template 
struct optional
{
T a;
optional();
template
optional(const optional&);
};

template
void f(T x)
{
f(optional(x));
}
int main()
{
   // using std::optional;
optional x;
f(x);
return 0;
}
```

There is an enable if on the optional constructor in the std::optional case
which makes the time increase even more.

I doubt there is much to be optimized here except maybe lowering the template
depth limit (from the current 900, that is -ftemplate-depth=900 is the
default).

[Bug ipa/92606] [10/11/12/13/14 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

--- Comment #17 from Andrew Pinski  ---
(In reply to Georg-Johann Lay from comment #3)
> Created attachment 47485 [details]
> 123f.c: C test case with address space __flash.
> 
> ...and the code is also wrong with address spaces like __flash (and the same
> options like in comment #1):
> 
> $ avr-gcc -mmcu=atmega128 123f.c -flto -Os -save-temps -o 123f.elf

Note you don't need -flto if you change xyz be static.

[Bug c++/110150] New: std::optional inside template leads to long compilation time

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

Bug ID: 110150
   Summary: std::optional inside template leads to long
compilation time
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following program is very slow to compile (>40 seconds). Tested on
GCC-trunk.

To quickly reproduce: https://gcc.godbolt.org/z/rsT3n38sY
```
#include 
template
void f(T x)
{
f(std::optional(x));
}
int main()
{
using std::optional;
optional x;
f(x);
return 0;
}
```

[Bug libgcc/84292] __sync_add_and_fetch returns the old value instead of the new value

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed in GCC 9 as all earlier branches are no longer supported.

[Bug bootstrap/110085] make clean inside the gcc directory when configured with m2 language and for sh-elf messes up

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed; not going to backport to GCC 10, 11, or 12 as only GCC 13 has m2.

[Bug bootstrap/110085] make clean inside the gcc directory when configured with m2 language and for sh-elf messes up

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:044ee48215fd7eca1f1680758cd27574ff274417

commit r13-7421-g044ee48215fd7eca1f1680758cd27574ff274417
Author: Andrew Pinski 
Date:   Mon Jun 5 04:32:00 2023 +

Fix PR 110085: `make clean` in GCC directory on sh target causes a failure

On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS)
named m2,
this conflicts with the langauge m2. So when you do a `make clean`, it will
remove
the m2 directory and then a build will fail. Now since
r0-78222-gfa9585134f6f58,
the multilib directories are no longer created in the gcc directory as
libgcc
was moved to the toplevel. So we can remove the part of clean that removes
those
directories.

Tested on x86_64-linux-gnu and a cross to sh-elf that `make clean` followed
by
`make` works again.

Committed as approved.

gcc/ChangeLog:

PR bootstrap/110085
* Makefile.in (clean): Remove the removing of
MULTILIB_DIR/MULTILIB_OPTIONS directories.

(cherry picked from commit afd87299cefd021daf0158d5b6276c37013996b9)

[Bug tree-optimization/110134] [10/11/12/13/14 Regression] (-unsigned1) != CST is not optimized to unsigned1 != CST at the gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-June/62
   ||0818.html
   Keywords||patch

--- Comment #4 from Andrew Pinski  ---
Patch submitted with a few testcases to make sure it will not regress again:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620818.html

[Bug libstdc++/110149] New: std::format for pointer arguments allows a '0' option

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 110149
   Summary: std::format for pointer arguments allows a '0' option
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55275=edit
test case bug.cc

In C++ 20, a sign, a '#' option, and a '0' option are disallowed for
std::format strings with a pointer argument. The text has the same language for
all three:

In https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf
§ 22.14.2.2 Standard format specifiers [format.string.std]
Paragraph 5: "The sign option is only valid for arithmetic types other than
charT and bool or when an integer presentation type is specified."
Paragraph 7: "The # option  This option is valid for arithmetic types other
than charT and bool or when an integer presentation type is specified, and not
otherwise."
Paragraph 8: "The 0 option is valid for arithmetic types other than charT and
bool or when an integer presentation type is specified."

Paragraph 21 specifies the available integer presentation types; 'p' is not one
of them, it is listed in paragraph 25 instead.

Therefore in the attached program bug.cc, an error should be signalled in line
28 and in line 29.

How to reproduce:
1)
$ g++ -Wall -std=gnu++20 bug.cc

2) Enable line 18 or line 19 or line 23 or line 24.
$ g++ -Wall -std=gnu++20 bug.cc


Note also that the '0' option cannot be part of a width specification, because
the width cannot start with '0'.

[Bug middle-end/110148] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Only g:e5405f065bace0685cb3b8878d1dfc7a6e7ef409 sticks out but there is no FMA
possible in s242 as far as I can tell 

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

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

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

--- Comment #4 from ibuclaw at gcc dot gnu.org ---
Test case should deterministically crash when kernel.randomize_va_space=0.

[Bug tree-optimization/71414] 2x slower than clang summing small float array, GCC should consider larger vectorization factor for "unrolling" reductions

[drraph at gmail dot com via Gcc-bugs]

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

Raphael C  changed:

   What|Removed |Added

 CC||drraph at gmail dot com

--- Comment #12 from Raphael C  ---
This problem has been recently discussed at:

https://stackoverflow.com/questions/76407241/why-is-cython-so-much-slower-than-numba-for-this-simple-loop

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #3 from ibuclaw at gcc dot gnu.org ---
It would be handy if there was a test that didn't import all of Phobos.

[Bug middle-end/110148] New: TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8

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

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

Bug ID: 110148
   Summary: TSVC s242 regression between
g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and
g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8
   Product: gcc
   Version: 13.1.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: ---

Seen here:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=171.854.0 (benzen)
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=463.854.0 (helene)
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=283.854.0 (lntzen3)

So it seems to affect both intel (Helene) and zens
TSVC/s1244 is also regressing same day but only on zens

[Bug tree-optimization/110062] missed vectorization in graphicsmagick

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Jan Hubicka  ---
#include 
struct pixel {float red, green, blue, opacity;};
struct ipixel {unsigned char red, green, blue, opacity;};
test(float *k, struct ipixel *r, int width, int columns, struct ipixel *q)
{
struct pixel pixel;
for (int v=0; v < width; v++)
  {
for (int u=0; u < width; u++)
 {
pixel.red+=k[u]*r[u].red;
pixel.green+=k[u]*r[u].green;
pixel.blue+=k[u]*r[u].blue;
  }   
k+=width;
r+=(size_t) columns+width;
  }
q->red=pixel.red;
q->green=pixel.green;
q->blue=pixel.blue;
q->opacity=255;
}

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

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

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

--- Comment #37 from Jakub Jelinek  ---
What happened with this patch?

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from seurer at gcc dot gnu.org ---
I do not see the problem currently occurring in gcc 13.

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet

[aemseemann at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Martin Seemann  ---
That's great news, looking forward to the next point release.
Thank you very much for taking this to the committee and getting the process in
motion so quickly!

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

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

--- Comment #66 from Alexander Klepikov  
---
(In reply to Alexander Klepikov from comment #65)
> > I'm thinking of something else.
> 
> During kernel compile I got few internal errors in different passes. That
> is, additional loop optimization pass patch is no good at all.

I am sorry, I am, as always, panicking ahead of time. I think I found what's
wrong and do additional tests.

[Bug c++/110122] [13/14 Regression] using an aggregate with a member variable with a user defined copy constructor in a class NTTP causes capture and use of the `this` pointer in a generic lambda to p

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to waffl3x from comment #3)
> Very cool, thanks, since your test case seems to cause problems in GCC 11
> and GCC 12 does that mean the bug goes deeper than I thought?
> 
> (In reply to Patrick Palka from comment #2)
> > It seems only the first testcase exhibits a 13 regression, we never accepted
> > the second testcase.
> 
> Is that what you meant here btw, that since your second test case triggers
> the bug in 11 and 12 that it belongs as a different regression test?

Yes, it seems the original testcase is exhibiting two bugs (one of which a GCC
13 regression), whereas the second testcase exhibits one (non-regression) bug.

In your original testcase Bar's copy constructor shouldn't be needed since the
template parameter V isn't being copied anywhere, but we're somehow end up with
an illegitimate use of the constructor (bug #1) and then we're also failing to
synthesize it (bug #2).

In the second testcase Bar's copy constructor is legitimately needed since
we're arguably making a copy of V when writing the specialization
Doppelganger, but we fail to synthesize the constructor (bug #2).

> 
> Sadly, the workaround doesn't work when `Bar` is a class template.
> https://godbolt.org/z/41xWrar5e
> So it doesn't work in my specific case :(

Ah, does it work for you to give Bar an explicitly defaulted copy and default
ctor?

[Bug demangler/110147] UBSAN error in rust-demangle.c: NULL pointer passed to memcpy

[lukas.dresel at cs dot ucsb.edu via Gcc-bugs]

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

--- Comment #1 from lukas.dresel at cs dot ucsb.edu ---
The invocation was `rust_demangle(mangled=0x18140ad "_RYC0.vdj\\lc[kniso,bz",
options=0x103)`.

The original bug report to binutils can be found here with more details:
https://sourceware.org/bugzilla/show_bug.cgi?id=30507

[Bug demangler/110147] New: UBSAN error in rust-demangle.c: NULL pointer passed to memcpy

[lukas.dresel at cs dot ucsb.edu via Gcc-bugs]

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

Bug ID: 110147
   Summary: UBSAN error in rust-demangle.c: NULL pointer passed to
memcpy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukas.dresel at cs dot ucsb.edu
  Target Milestone: ---

This was discovered using our hybrid fuzzer originally on `binutils` `nm-new`.

It appears to be caused by passing the string "_RYC0.vdj\\lc[kniso,bz" to
`rust_demangle`.

In the second invocation of `str_buf_append`, the `memcpy` src pointer is set
to NULL.

I have added the attached `nm-new` binary with debug symbols which exhibits the
error, and the reproducing testcase. The above string was extracted from gdb.

[Bug middle-end/110141] Wrong code at -O2 on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
Another -fstack-reuse= issue.

[Bug middle-end/31542] Incorrect optization with nan values

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Just closing as fixed.

[Bug target/102974] GCC optimization is very poor for add carry and multiplication combos

[slash.tmp at free dot fr via Gcc-bugs]

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

--- Comment #16 from Mason  ---
For the record, the example I provided was intended to show that, with some
help, GCC can generate good code for bigint multiplication. In this situation,
"help" means a short asm template.

[Bug c++/100765] attribute incorrectly applied during type alias deduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gcc-bugzilla@richardebeling
   ||.de

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

[Bug c++/110140] Vector extensions cause false conflict in template argument deduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 100765.

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

[Bug c++/110140] Vector extensions cause false conflict in template argument deduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
I have seen this exact case before. PR 107123 is about deduction of the vector
size.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

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

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

--- Comment #3 from Jakub Jelinek  ---
I've tried
struct S {
  double value;
  constexpr S(double value) : value (value) {}
};

inline constexpr S s[] = { 1e126 };

int
main ()
{
  __builtin_printf ("%.32La %.32La\n", (long double) s[0].value, (long
double)(double)s[0].value);
  __builtin_printf ("%.32La %.32La\n", 1e126L, (long double)(double)1e126L);
  __builtin_printf ("%.32La\n", (long double) 1e126);
}
and that prints
0xb.d176620a5020p+415
0xb.d176620a5020p+415
0xb.d176620a501fc000p+415
0xb.d176620a5020p+415
0xb.d176620a501fc000p+415
with -m32 -fexcess-precision=standard, which matches my expectations.

[Bug target/110146] New: ICE in riscv_vector::function_builder::add_unique_function()

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

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

Bug ID: 110146
   Summary: ICE in
riscv_vector::function_builder::add_unique_function()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palmer at gcc dot gnu.org
  Target Milestone: ---

A few of us were talking about this in the patchwork sync today, I think Juzhe
might have a fix already.  I'm getting a few thousand ICEs running the test
suite, they started yesterday for me.

Executing on host:
/scratch/merges/rgt-gcc-trunk/toolchain/build-gcc-linux-stage2/gcc/xgcc
-B/scratch/merges/rgt-gcc-trunk/toolchain/build-gcc-linux-stage2/gcc/
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/base/binop_vx_constraint-30.c
 -march=rv32imac -mabi=ilp32 -mcmodel=medlow   -fdiagnostics-plain-output  
-march=rv32gcv -mabi=ilp32d -O3 -S   -o binop_vx_constraint-30.s(timeout =
600)
spawn -ignore SIGHUP
/scratch/merges/rgt-gcc-trunk/toolchain/build-gcc-linux-stage2/gcc/xgcc
-B/scratch/merges/rgt-gcc-trunk/toolchain/build-gcc-linux-stage2/gcc/
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/base/binop_vx_constraint-30.c
-march=rv32imac -mabi=ilp32 -mcmodel=medlow -fdiagnostics-plain-output
-march=rv32gcv -mabi=ilp32d -O3 -S -o binop_vx_constraint-30.s
In file included from
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/base/riscv_vector.h:8,
 from
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/base/binop_vx_constraint-30.c:4:
/scratch/merges/rgt-gcc-trunk/toolchain/build-gcc-linux-stage2/gcc/include/riscv_vector.h:94:9:
internal compiler error: Segmentation fault
0x1107ac3 crash_signal
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/toplev.cc:314
0x7fcf6952508f ???
   
/build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x14022bb tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/tree.h:3689
0x14022bb type_hash_canon_hash(tree_node*)
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/tree.cc:6028
0x1418475 build_function_type(tree_node*, tree_node*, bool)
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/tree.cc:7454
0x1586775
riscv_vector::function_builder::add_unique_function(riscv_vector::function_instance
const&, riscv_vector::function_shape const*, tree_node*, vec&)
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins.cc:3414
0x158715b build_one
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins-shapes.cc:52
0x15871f7 build_all
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins-shapes.cc:69
0x15871f7 riscv_vector::build_base::build(riscv_vector::function_builder&,
riscv_vector::function_group_info const&) const
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins-shapes.cc:84
0x1580cf6
riscv_vector::function_builder::register_function_group(riscv_vector::function_group_info
const&)
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins.cc:3259
0x1580cf6 riscv_vector::handle_pragma_vector()
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-vector-builtins.cc:4072
0x156757e riscv_pragma_intrinsic
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/config/riscv/riscv-c.cc:191
0xa9747a c_parser_pragma
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/c/c-parser.cc:13330
0xac4a55 c_parser_external_declaration
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/c/c-parser.cc:1906
0xac521d c_parser_translation_unit
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/c/c-parser.cc:1779
0xac521d c_parse_file()
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/c/c-parser.cc:24657
0xb33d69 c_common_parse_file()
   
/scratch/merges/rgt-gcc-trunk/riscv-gnu-toolchain/gcc/gcc/c-family/c-opts.cc:1248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #1)
> Weird, the 1e126 constant shouldn't be with excess precision because it is
> stored into a double field (using ctor).

Yeah, I've fixed nearly all the other tests that fail with
-fexcess-precision=standard but this one confused me. I don't know what's
happening.

> So perhaps the to_chars implementation actually relying somewhere on excess
> precision not happening?

Given that all the implementation is inside libstdc++.so I don't see how it can
be affected by the options used to include the  header in the
testcase.

[Bug libstdc++/110145] 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Weird, the 1e126 constant shouldn't be with excess precision because it is
stored into a double field (using ctor).
So perhaps the to_chars implementation actually relying somewhere on excess
precision not happening?

[Bug libgomp/109837] [OpenMP] despite 'requires unified_address' there is segfault when 'is_device_ptr' is not used

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

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

--- Comment #3 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #2)
> (For GCN, enabling unified_address makes sense.)

Now done via commit r14-1584-gf1af7d65ff64fe7102d1490ef46ea491a533e641

> TODO: It does not harm to have some Fortran ('type(c_ptr)') and C/C++
> testcase in libgomp/testsuite/ but nothing else needs to be done.

Still to be done.

[Bug libstdc++/110145] New: 20_util/to_chars/double.cc fails for -m32 -fexcess-precision=standard

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

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

Bug ID: 110145
   Summary: 20_util/to_chars/double.cc fails for -m32
-fexcess-precision=standard
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/double.cc:56968:
test01():: [with auto:1 = double_to_chars_testcase
[1679]]: Assertion 'result.ec == errc{}' failed.
FAIL: 20_util/to_chars/double.cc execution test

Fails for this testcase:

{1e126, chars_format::fixed,
"248677616189928820425446708698348384614392259722252941999757930266031634937628176537515300"
"58413655532282839040"},

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Thanks, Jakub. That works nicely.

Fixed for GCC 14.

[Bug c++/51571] No named return value optimization while adding a dummy scope

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55271|0   |1
is obsolete||

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

Full patch I'm going to test.
Unfortunately, I haven't been successful at getting the subc stuff working when
not using __builtin_sub_overflow builtins nor _subborrow_u* instrinsics, only
addc seems to work in that case, seems reassoc rewrites stuff that we no longer
are able to even pattern match __builtin_sub_overflow in that case.

So, maybe even adding the ugly clang builtins as a canned way how to express it
canonically would be useful, the pattern matching can't handle infinite number
of different ways how to write the same thing.

[Bug target/110144] New: cris-unknown-elf cross build fails with ICE if RTL checking is enabled

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

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

Bug ID: 110144
   Summary: cris-unknown-elf cross build fails with ICE if RTL
checking is enabled
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitar at gcc dot gnu.org
  Target Milestone: ---

I'm trying to cross build the current trunk:

  $ configure --target=cris-unknown-elf --with-newlib --without-headers
--enable-languages=c --disable-nls --disable-libssp --enable-checking=yes,rtl

But the configure stage for libgcc fails with:

configure:3814:
/home/dinux/projects/pru/local-workspace/cris-gcc-build/./gcc/xgcc
-B/home/dinux/projects/pru/local-workspace/cris-gcc-build/./gcc/
-B/usr/local/cris-unknown-elf/bin/ -B/usr/local/cris-unknown-elf/lib/ -isystem
/usr/local/cris-unknown-elf/include -isystem
/usr/local/cris-unknown-elf/sys-include-c -g -O2  conftest.c >&5
during RTL pass: mach2
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx note) in PATTERN, at rtl.h:1511
   16 | }
  | ^
0x6c9a81 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
../../gcc/gcc/rtl.cc:907
0x767bb8 PATTERN(rtx_def*)
../../gcc/gcc/rtl.h:1511
0x768158 PATTERN(rtx_def*)
../../gcc/gcc/rtl.h:1479
0x768158 cris_postdbr_cmpelim
../../gcc/gcc/config/cris/cris.cc:378
0x768158 execute
../../gcc/gcc/config/cris/cris.cc:331


Note that without "--enable-checking=yes,rtl" the cross toolchain compilation
is successful.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

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

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

Bug 96004 Summary: Copy elision with conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96004

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE