[Bug target/103327] Do not search MINGW in the search dir

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

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

--- Comment #1 from Richard Biener  ---
Please post patches to gcc-patc...@gcc.gnu.org

[Bug c++/103326] constexpr crashing when uses with vector extensions

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2021-11-19
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

#1  0x00e6c39a in tsubst_copy (t=, 
args=, complain=3, 
in_decl=)
at /home/rguenther/src/gcc3/gcc/cp/pt.c:17303
17303   gcc_unreachable ();

I think I have a simple patch.

[Bug tree-optimization/103325] 1 << -1 is never reduced to a constant during gimple

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-19
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think we used to constant fold this as 1<<1.  GCC 7 does

> gcc-7 -S t.c -fdump-tree-original
t.c: In function 'main':
t.c:2:12: warning: right shift count is negative [-Wshift-count-negative]
   return 1 >> (-1);
^~
> cat t.c.003t.original 

;; Function main (null)
;; enabled by -tree-original


{
  return 2;
}
return 0;

but IIRC that behavior was removed from {int_const,wide}_int_binop at some
point, maybe also to enable sanitization.

gimple-ssa-isolate-paths.c would be one place to turn such code into
unreachable or traps (see other PRs to make the behavior configurable).

[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite

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

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

--- Comment #2 from Richard Biener  ---
I'm usually running pieces that affect the area I am patching like vect.exp for
vectorizer stuff.  Generally a smoke test would be dg-torture.exp (runs C and
C++ pieces) and execute.exp (C, ObjC, Go and Fortran).

Thus,

make check RUNTESTFLAGS="execute.exp"
make check RUNTESTFLAGS="dg-torture.exp"

for crosses compile.exp might be more light weight than execute.exp.  In
reality
bootstrap itself should be smoke test enough ...

[Bug tree-optimization/103322] [12 Regression] galgel from spec2000 is now broken on x86_64 with -Ofast -march=native -flto (on core)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|galgel from spec2000 is now |[12 Regression] galgel from
   |broken on x86_64 with   |spec2000 is now broken on
   |-Ofast -march=native -flto  |x86_64 with -Ofast
   |(on core)   |-march=native -flto (on
   ||core)
   Target Milestone|--- |12.0
 Target||x86_64-*-*
   Keywords||wrong-code

[Bug target/103320] 12 Regression] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|regression  |target
 Target||powerpc64le
Summary|Spec 2017 benchmark roms_r  |12 Regression] Spec 2017
   |fails on PowerPC for -Ofast |benchmark roms_r fails on
   ||PowerPC for -Ofast
   Target Milestone|--- |12.0

[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|---

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-19
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

--- Comment #6 from Andrew Pinski  ---
Can you test this after r12-5393 ?

[Bug tree-optimization/103317] [12 regression] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed. thanks for the reduced testcase even.

[Bug tree-optimization/103317] [12 regression] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

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

https://gcc.gnu.org/g:09d462146b3107c665265b11ad925c61a91c6efb

commit r12-5393-g09d462146b3107c665265b11ad925c61a91c6efb
Author: Andrew Pinski 
Date:   Thu Nov 18 23:38:30 2021 +

Fix PR 103317, ICE after PHI-OPT, minmax_replacement producing invalid SSA

The problem is r12-5300-gf98f373dd822b35c allows phiopt to recognize more
basic blocks
but missed one location where the basic block does not need to be empty but
still
needs to have a single predecessor. This patch fixes that over sight.

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

PR tree-optimization/103317

gcc/ChangeLog:

* tree-ssa-phiopt.c (minmax_replacement): For the non empty
middle bb case, check to make sure it has a single predecessor.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr103317-1.c: New test.

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 18 Nov 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
> 
> Aldy Hernandez  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #9 from Aldy Hernandez  ---
> I can reproduce this with -i ref with -O3 -ffast-math but not with -O3
> -fno-unsafe-math-optimizations.
> 
> Richi the configury bits you shared once upon a time had
> -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> this test for -ffast-math that we had -fno-unsafe-math-optimizations?

Indeed - interesting.  I don't remember anything and I have originally
copied this config from our testers which means iff then maybe
Martin knows ... ;)

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Vsevolod Livinskiy from comment #4)
> The same error can be triggered for X86.
> Here is the link to the Compiler Explorer: https://godbolt.org/z/8zMhfhs5o
> 
> This reproducer was found with YARPGen.

This one is specifically the same as PR 103317 where I submitted a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584926.html

I don't know if the original testcase is the same though.

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Vsevolod Livinskiy  changed:

   What|Removed |Added

 CC||vsevolod.livinskij at frtk dot 
ru

--- Comment #4 from Vsevolod Livinskiy  ---
The same error can be triggered for X86.
Here is the link to the Compiler Explorer: https://godbolt.org/z/8zMhfhs5o

This reproducer was found with YARPGen.

Reproducer:
long a;
short b;
extern unsigned long d[];
const unsigned long long (const unsigned long long ,
const unsigned long long ) {
  if (f < g)
return g;
  return f;
}
const unsigned long long (const unsigned long long ,
const unsigned long long ) {
  return f < g ? f : g;
}
void j() {
  for (int i = 0;; i = 8)
d[i] = h(e(a, c[i] && b), 7);
}

Error:
>$ g++ -O2 -c func.cpp
func.cpp: In function 'void j()':
func.cpp:15:6: error: definition in block 5 does not dominate use in block 3
   15 | void j() {
  |  ^
for SSA_NAME: _23 in statement:
_6 = PHI <_4(5), _23(3), _23(4)>
PHI argument
_23
for PHI node
_6 = PHI <_4(5), _23(3), _23(4)>
during GIMPLE pass: phiopt
func.cpp:15:6: internal compiler error: verify_ssa failed
0x141284f verify_ssa(bool, bool)
/testing/gcc/gcc_src_master/gcc/tree-ssa.c:1211
0x10e86d5 execute_function_todo
/testing/gcc/gcc_src_master/gcc/passes.c:2049
0x10e901b execute_todo
/testing/gcc/gcc_src_master/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

gcc version 12.0.0 2028 (d6ec661e3931773e2f571ed4f6dd8b0402d8687d) (GCC)

[Bug testsuite/103282] New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292 fails

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Worked for me as of r12-5390-gd3152981f71eef1

I should say this was on x86_64.
And passing as of r12-5363 on aarch64-linux-gnu.

Is it failing for 32bit or 64bit or both

[Bug testsuite/103282] New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292 fails

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

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

--- Comment #4 from Andrew Pinski  ---
Worked for me as of r12-5390-gd3152981f71eef1

[Bug tree-optimization/103257] [9/10/11/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|9.5 |12.0

--- Comment #10 from Andrew Pinski  ---
Fixed on the trunk, not going to backport for GCC 9 or 10 since it is a small
missed optimization, not found until now.

[Bug tree-optimization/103257] [9/10/11/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

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

https://gcc.gnu.org/g:527e54a431473cc497204226a21f2831d2375e66

commit r12-5392-g527e54a431473cc497204226a21f2831d2375e66
Author: Andrew Pinski 
Date:   Tue Nov 16 04:46:21 2021 +

Fix tree-optimization/103257: Missed jump threading due too early
conversion of bool*A into bool?A:0

So like many optimizations on the gimple level, sometimes it makes sense to
do the
optimization early or later. In this case, creating a cond expression early
causes
other optimizations to be missed.  So just disable it until
canonicalize_math_p ()
is false.

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

PR tree-optimization/103257

gcc/ChangeLog:

* match.pd
((m1 >/=/<= m2) * d -> (m1 >/=/<= m2) ? d : 0):
Disable until !canonicalize_math_p ().

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/vrp116.c: Check optimized instead of vrp1.
* gcc.dg/tree-ssa/pr103257-1.c: New test.

[Bug middle-end/103314] [12 regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault since r12-5358

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584935.html

--- Comment #7 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584935.html

[Bug target/103252] questionable codegen with kmovd

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Hongtao.liu  ---

> 
> So for short live range reg, we may lose opportunity to allocate best
> regclass, maybe add peephole2 to handle those cases instead of tune RA.
No, r132 is also used as addr, but currently lra only add cost of movement from
 mask to gpr, but we could possibly run out of gpr which means there will be an
extra spill, and this is not counted by record_address_regs.

modified   gcc/ira-costs.c
@@ -1226,7 +1226,7 @@ record_address_regs (machine_mode mode, addr_space_t as,
rtx x,
struct costs *pp;
int *pp_costs;
enum reg_class i;
-   int k, regno, add_cost;
+   int k, regno, add_cost, potential_spill_cost;
cost_classes_t cost_classes_ptr;
enum reg_class *cost_classes;
move_table *move_in_cost;
@@ -1239,6 +1239,7 @@ record_address_regs (machine_mode mode, addr_space_t as,
rtx x,
  ALLOCNO_BAD_SPILL_P (ira_curr_regno_allocno_map[regno]) = true;
pp = COSTS (costs, COST_INDEX (regno));
add_cost = (ira_memory_move_cost[Pmode][rclass][1] * scale) / 2;
+   potential_spill_cost = add_cost / 5;
if (INT_MAX - add_cost < pp->mem_cost)
  pp->mem_cost = INT_MAX;
else
@@ -1252,6 +1253,10 @@ record_address_regs (machine_mode mode, addr_space_t as,
rtx x,
  {
i = cost_classes[k];
add_cost = (move_in_cost[i][rclass] * scale) / 2;
+   /* If we run out of rclass regs, there could be an extra spill,
+  Let's say 20% possibility.  */
+   if (!ira_class_subset_p[i][rclass])
+ add_cost += potential_spill_cost;
if (INT_MAX - add_cost < pp_costs[k])
  pp_costs[k] = INT_MAX;

[Bug target/103327] New: Do not search MINGW in the search dir

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103327
   Summary: Do not search MINGW in the search dir
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

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

This is also a patch used in TDM-GCC since GCC searches wrong dir in /mingw
which is useless

[Bug bootstrap/103306] [12 Regression] parallel build hangs since r12-5234-g04c5a9 when /usr/include includes broken symbolic links

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #16 from Zdenek Sojka  ---
(In reply to Xi Ruoyao from comment #15)
> patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584815.html

Thank you for the patch; it fixes non-bootstrap build for me. I didn't check
full bootstrap yet.

Is there a chance to check why is there the strange behavior now, with the
abort() in fixincludes?
- parallel build hangs (eg. no "Error" or "Waiting for unfinished jobs" message
from make)
- non-parallel build succeeds (even though fixincludes aborted)

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

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

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

Bug 96121 Summary: Uninitialized variable copying in member initialized list 
not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121

   What|Removed |Added

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

[Bug c++/96121] Uninitialized variable copying in member initialized list not diagnosed

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
At last, implemented.

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

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

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

Bug 19808 Summary: miss a warning about uninitialized member usage in member 
initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

   What|Removed |Added

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

[Bug c++/96121] Uninitialized variable copying in member initialized list not diagnosed

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

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

Bug 19808 Summary: miss a warning about uninitialized member usage in member 
initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

   What|Removed |Added

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

[Bug c++/34307] when data member name is same as parameter name, possible to omit parameter name in constructor without warning

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

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

Bug 19808 Summary: miss a warning about uninitialized member usage in member 
initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

   What|Removed |Added

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

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

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

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

Bug 19808 Summary: miss a warning about uninitialized member usage in member 
initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

   What|Removed |Added

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

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #51 from Marek Polacek  ---
At last, implemented.

[Bug c++/96121] Uninitialized variable copying in member initialized list not diagnosed

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

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

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

https://gcc.gnu.org/g:0790c8aacdfb4fd096aa580dae0fe49172c43ab2

commit r12-5391-g0790c8aacdfb4fd096aa580dae0fe49172c43ab2
Author: Marek Polacek 
Date:   Tue Nov 10 20:07:24 2020 -0500

c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

2021 update: Last year I posted a version of this patch:

but it didn't make it in.  The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings.  Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.

I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what.  On the other hand,
I think we really should do something about this.  So I've simplified
the original patch as much as it seemed reasonable.  For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?).  I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't.  I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more.  It turned out that this abridged version still warns about 90%
cases where users would expect a warning.

More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.
(This is bug 21678.)

This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like

  struct A {
int a;
int b;
A() : b(1), a(b) { }
  };

where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.

I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on.  Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:

  struct B {
int 
int *p;
int a;
B() : r(a), p(), a(1) { } // ok
  };

Likewise, don't warn in unevaluated contexts such as sizeof.  Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.

PR c++/19808
PR c++/96121

gcc/cp/ChangeLog:

* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r.  New parameter
to track uninitialized fields.  If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(find_uninit_fields): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized.  When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r.  Also when
initializing base clases.  Pass uninitialized down to
perform_member_init.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
   

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

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

https://gcc.gnu.org/g:0790c8aacdfb4fd096aa580dae0fe49172c43ab2

commit r12-5391-g0790c8aacdfb4fd096aa580dae0fe49172c43ab2
Author: Marek Polacek 
Date:   Tue Nov 10 20:07:24 2020 -0500

c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

2021 update: Last year I posted a version of this patch:

but it didn't make it in.  The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings.  Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.

I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what.  On the other hand,
I think we really should do something about this.  So I've simplified
the original patch as much as it seemed reasonable.  For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?).  I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't.  I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more.  It turned out that this abridged version still warns about 90%
cases where users would expect a warning.

More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.
(This is bug 21678.)

This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like

  struct A {
int a;
int b;
A() : b(1), a(b) { }
  };

where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.

I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on.  Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:

  struct B {
int 
int *p;
int a;
B() : r(a), p(), a(1) { } // ok
  };

Likewise, don't warn in unevaluated contexts such as sizeof.  Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.

PR c++/19808
PR c++/96121

gcc/cp/ChangeLog:

* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r.  New parameter
to track uninitialized fields.  If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(find_uninit_fields): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized.  When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r.  Also when
initializing base clases.  Pass uninitialized down to
perform_member_init.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
  

[Bug c++/21678] Using inline disables warnings about missing return statements

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

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

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

https://gcc.gnu.org/g:0790c8aacdfb4fd096aa580dae0fe49172c43ab2

commit r12-5391-g0790c8aacdfb4fd096aa580dae0fe49172c43ab2
Author: Marek Polacek 
Date:   Tue Nov 10 20:07:24 2020 -0500

c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

2021 update: Last year I posted a version of this patch:

but it didn't make it in.  The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings.  Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.

I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what.  On the other hand,
I think we really should do something about this.  So I've simplified
the original patch as much as it seemed reasonable.  For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?).  I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't.  I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more.  It turned out that this abridged version still warns about 90%
cases where users would expect a warning.

More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.
(This is bug 21678.)

This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like

  struct A {
int a;
int b;
A() : b(1), a(b) { }
  };

where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.

I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on.  Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:

  struct B {
int 
int *p;
int a;
B() : r(a), p(), a(1) { } // ok
  };

Likewise, don't warn in unevaluated contexts such as sizeof.  Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.

PR c++/19808
PR c++/96121

gcc/cp/ChangeLog:

* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r.  New parameter
to track uninitialized fields.  If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(find_uninit_fields): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized.  When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r.  Also when
initializing base clases.  Pass uninitialized down to
perform_member_init.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
   

[Bug c++/103326] New: constexpr crashing when uses with vector extensions

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103326
   Summary: constexpr crashing when uses with vector extensions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

using x86_64_v16qi [[gnu::__vector_size__ (16)]] = char;

template
void foo()
{
constexpr x86_64_v16qi zero{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0};
}

void foo2()
{
foo();
}

D:\hg\fast_io\.tmp>g++ -S simd_constexpr_crashing.cc -Ofast -std=c++20
-march=native -I../include
simd_constexpr_crashing.cc: In instantiation of 'void foo() [with T = int]':
simd_constexpr_crashing.cc:11:10:   required from here
simd_constexpr_crashing.cc:6:32: internal compiler error: in tsubst_copy, at
cp/pt.c:17303
6 | constexpr x86_64_v16qi zero{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0};
  |^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/103252] questionable codegen with kmovd

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Hongtao.liu  ---
(In reply to Jason A. Donenfeld from comment #9)
> >  When the mask registers are available for use, RA considers them and when 
> > spilling to those is cheaper than to memory, it spills to them and not 
> > memory.
> 
> Yes, this is the thing I don't get. When you compare the codegen for avx512
> vs non-avx512, the non-avx512 doesn't spill at all there. So this isn't
> "spill to memory" vs "spill to mask register". This is "don't spill" vs
> "spill to mask register". And the latter seems clearly worse.

for non-avx512, Due to the small number of registers available, and the short
live range of r132, r132 is first
Pushing a18(r132,l0) (cost 70)  (allocate as mem first)
 and then finally found there're available register
Popping a18(r132,l0) -- assign reg 2. - (allocate as register when
there're available register)

for avx512, due to enough number of registers available, r132 is finally
assigned as alternative class. for while picture avx512 has less mem allocated.

avx2:
Disposition:
   26:r82  l1 31:r82  l0 3   36:r89  l1 22:r89  l0 2
   13:r97  l0 5   37:r101 l1 13:r101 l0 4   27:r103 l1   mem
4:r103 l0   mem   38:r105 l1 05:r105 l0 0   28:r108 l1 6
6:r108 l0 60:r112 l0 0   29:r113 l1 57:r113 l0 5
   30:r114 l1   mem8:r114 l0   mem   31:r115 l1   mem9:r115 l0   mem
   22:r118 l0 0   21:r119 l0 0   40:r128 l1 0   39:r129 l1 0
   17:r130 l0 1   16:r131 l0 2   18:r132 l0 2   15:r136 l0 1
   12:r139 l0 0   32:r142 l1   mem   10:r142 l0   mem   33:r143 l1 4
   20:r143 l0   mem   34:r144 l1   mem   11:r144 l0   mem   35:r145 l1   mem
   19:r145 l0   mem   25:r146 l0 0   24:r147 l0 1   23:r148 l0 2
   41:r149 l1 0   14:r150 l0 0

avx512:
Disposition:
   26:r82  l1 31:r82  l0 3   36:r89  l1 12:r89  l0 2
   13:r97  l0 4   37:r101 l1 23:r101 l0 1   27:r103 l1   mem
4:r103 l0   mem   38:r105 l1 05:r105 l0 0   28:r108 l1 6
6:r108 l0 60:r112 l0 0   29:r113 l1 47:r113 l0 4
   30:r114 l1   mem8:r114 l0   mem   31:r115 l1   mem9:r115 l0   mem
   22:r118 l0 0   21:r119 l0 0   40:r128 l1 0   39:r129 l1 0
   17:r130 l0 2   16:r131 l068   18:r132 l068   15:r136 l0 2
   12:r139 l0 0   32:r142 l1   mem   10:r142 l0   mem   33:r143 l1   mem
   20:r143 l0   mem   34:r144 l1 5   11:r144 l0 5   35:r145 l1   mem
   19:r145 l0   mem   25:r146 l0 0   24:r147 l0 1   23:r148 l0 2
   41:r149 l1 0   14:r150 l0 0



So for short live range reg, we may lose opportunity to allocate best regclass,
maybe add peephole2 to handle those cases instead of tune RA.

[Bug target/103100] [11/12 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584927.html
   Keywords||patch

--- Comment #9 from Andrew Pinski  ---
New patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584927.html

[Bug tree-optimization/103317] [12 regression] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584926.html

--- Comment #11 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584926.html

[Bug middle-end/103314] [12 regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault since r12-5358

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Fixes the problem and we should not run into the back and forth issue.

Oh and it only happens with this undefined (at runtime) code :).

[Bug tree-optimization/103325] 1 << -1 is never reduced to a constant during gimple

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

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

--- Comment #1 from Andrew Pinski  ---
I should note I noticed this while working on PR 103314.

[Bug tree-optimization/103325] New: 1 << -1 is never reduced to a constant during gimple

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

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

Bug ID: 103325
   Summary: 1 << -1 is never reduced to a constant during gimple
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
int main() {
  return 1 >> (-1);
}

GCC is the only compiler I have tried (MSVC, ICC and clang/LLVM) which does not
remove the shift.
Yes this is undefined behavior but really I think it is best to reduce to
something rather than keeping around the shift. Even converting it to
__builtin_unreachable will be ok in my book.

[Bug target/102543] -march=cascadelake performs odd alignment peeling

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-5390-gd3152981f71eef16e50246a94819c39ff1489c70
Author: liuhongt 
Date:   Sat Oct 9 09:42:10 2021 +0800

Reduce cost of aligned sse register store.

Make them be equal to cost of unaligned ones to avoid odd alignment
peeling.

Impact for SPEC2017 on CLX:
fprate:
  503.bwaves_rBuildSame
  507.cactuBSSN_r -0.22
  508.namd_r  -0.02
  510.parest_r-0.28
  511.povray_r-0.20
  519.lbm_r   BuildSame
  521.wrf_r   -0.58
  526.blender_r   -0.30
  527.cam4_r   1.07
  538.imagick_r0.01
  544.nab_r   -0.09
  549.fotonik3d_r BuildSame
  554.roms_r  BuildSame
intrate:
  500.perlbench_r -0.25
  502.gcc_r   -0.15
  505.mcf_r   BuildSame
  520.omnetpp_r1.03
  523.xalancbmk_r -0.13
  525.x264_r  -0.05
  531.deepsjeng_r -0.27
  541.leela_r -0.24
  548.exchange2_r -0.06
  557.xz_r-0.10
  999.specrand_ir  2.69

gcc/ChangeLog:

PR target/102543
* config/i386/x86-tune-costs.h (skylake_cost): Reduce cost of
storing 256/512-bit SSE register to be equal to cost of
unaligned store to avoid odd alignment peeling.
(icelake_cost): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr102543.c: New test.

[Bug middle-end/103314] [12 regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault since r12-5358

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

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

--- Comment #5 from Andrew Pinski  ---
Simplified testcase:
int main() {
  unsigned c = 0, d = c ? 1 ^ c ^ 1 >> (-1) : 0;
  return c;
}

The problem is we get:
#3  0x00b5aa2d in fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) () at
/home/apinski/src/upstream-gcc/gcc/gcc/fold-const.c:10822
10822 tem = generic_simplify (loc, code, type, op0, op1);
$1 = void
(gdb) p debug_generic_expr(op0)
(unsigned int) (1 >> -1)
$2 = void
(gdb) p debug_generic_expr(op1)
1
$3 = void
(gdb) op code
Undefined command: "op".  Try "help".
(gdb) p code
$4 = BIT_XOR_EXPR

Which we produce:
(unsigned int) ((1 >> -1) ^ 1)

But the code in fold_binary_loc comes a long and decides we should
reassociative this and it just goes back and forth or deciding which is
correct.

So doing this instead:
   TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
   || (GIMPLE && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION
(type))

Fixes the problem and we should not run into the back and forth issue.

[Bug tree-optimization/103317] [12 regression] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #10 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #9)
> Created attachment 51834 [details]
> patch which I am testing
> 
> This is the patch which I am testing which should get us back to where we
> were.

I can confirm this fixes the ICE on the reduced test case as well as the
original large test case.  Thanks for looking into this Andrew!

[Bug c++/103198] ICE for requires requires clause with varadic templates

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

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

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

https://gcc.gnu.org/g:09c24fe42ff2cef3f3291f5a7540a5835c08430c

commit r12-5389-g09c24fe42ff2cef3f3291f5a7540a5835c08430c
Author: Patrick Palka 
Date:   Thu Nov 18 19:32:22 2021 -0500

c++: implicit dummy object in requires clause [PR103198]

In the testcase below satisfaction misbehaves for f and g ultimately
because find_template_parameters fails to notice that the constraint
'val.x' depends on the template parms of the class template.  In
contrast, satisfaction works just fine for h.

The problem seems to come down to a difference in how any_template_parm_r
handles 'this' vs a dummy object: it walks the TREE_TYPE of the former
but not the latter, and this causes us to miss the tparm dependencies in
f/g's constraints since in their case the implicit object parm through
which we access 'val' is a dummy object.  (For h, since we know it's a
non-static member function when parsing its trailing constraints, the
implicit object parm is 'this', not a dummy object.)

This patch fixes this inconsistency by making any_template_parm_r walk
into the TREE_TYPE of a dummy object, like it already does for 'this'.

PR c++/103198

gcc/cp/ChangeLog:

* pt.c (any_template_parm_r): Walk the TREE_TYPE of a dummy
object.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-this1.C: New test.

[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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


This what have been running since 2010 (and was there for a few years before
that):
cd check-check-dir; $(RUNTEST) TMPDIR=`pwd` --all --tools gcc
$(DGFLAGS) \
  --srcdir=$(SRC)/gcc/testsuite execute.exp=2112-1.c

This was for an out of tree already built toolchain testing even. If this
fails, I don't run the full testsuite. (this is not what I run for my upstream
testing though, only for my internal toolchain testing).

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> I don't have SPEC CPU 2006 setup, can you attach the preprocessed source?

Also can you test if https://gcc.gnu.org/bugzilla/attachment.cgi?id=51834 fixes
the problem?

[Bug tree-optimization/103317] [12 regression] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 51834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51834=edit
patch which I am testing

This is the patch which I am testing which should get us back to where we were.

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

--- Comment #2 from Andrew Pinski  ---
I don't have SPEC CPU 2006 setup, can you attach the preprocessed source?

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

Bug 103049 Summary: [C++23] P0849R8 - auto(x): decay-copy in the language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103049

   What|Removed |Added

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

[Bug c++/103049] [C++23] P0849R8 - auto(x): decay-copy in the language

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Implemented in GCC 12.

[Bug c++/103049] [C++23] P0849R8 - auto(x): decay-copy in the language

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

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

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

https://gcc.gnu.org/g:93810fd673654db9ff16170624a6d36449eab241

commit r12-5386-g93810fd673654db9ff16170624a6d36449eab241
Author: Marek Polacek 
Date:   Wed Nov 3 11:04:22 2021 -0400

c++: Implement C++23 P0849R8 - auto(x) [PR103049]

This patch implements P0849R8 which allows auto in a functional cast,
the result of which is a prvalue.

[expr.type.conv]/1 says that the type is determined by placeholder type
deduction.  We only accept 'auto', not 'decltype(auto)' -- that the
type shall be auto comes from [dcl.type.auto.deduct].  Therefore the
rules are like for [temp.deduct.call], deducing template arguments from
a function call, so the result type will never be a reference, and we
decay arrays/functions.

PR c++/103049

gcc/cp/ChangeLog:

* semantics.c (finish_compound_literal): Accept C++23 auto{x}.
* typeck2.c (build_functional_cast_1): Accept C++23 auto(x).

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/auto25.C: Adjust dg-error.
* g++.dg/cpp0x/auto9.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-2.C: Likewise.
* g++.dg/cpp2a/concepts-pr84979-3.C: Likewise.
* g++.dg/cpp23/auto-fncast1.C: New test.
* g++.dg/cpp23/auto-fncast2.C: New test.
* g++.dg/cpp23/auto-fncast3.C: New test.
* g++.dg/cpp23/auto-fncast4.C: New test.
* g++.dg/cpp23/auto-fncast5.C: New test.
* g++.dg/cpp23/auto-fncast6.C: New test.

[Bug tree-optimization/103311] [12 Regression] ICE in complex_mul_pattern::build(vec_info*) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
MLA ended up getting not detected, for some reason the testcases where getting
skipped.

[Bug testsuite/103324] New: RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite

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

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

Bug ID: 103324
   Summary: RFE: Add a `make quickcheck` or `make smoketest`
Makefile target to allow only running a portion of the
testsuite
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: mikestump at comcast dot net, ro at CeBiTec dot 
Uni-Bielefeld.DE
  Target Milestone: ---

The GCC testsuite is very big, and running it can take a long time. It would be
nice if there were alternate `check` or `test` targets that could be used to
run just a random sampling of the testsuite, or just a subset of the testsuite
that is known to run quickly, for cases when I am feeling impatient and only
need to verify that basic functionality works, without checking for every
possible regression. I have seen other people mentioning that patches "seem to
work ok after smoketesting" so it would be nice if their method of smoketesting
were actually available for the rest of us to use.

[Bug fortran/87851] [9/10/11/12 Regression] Wrong return type for len_trim

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #14 from anlauf at gcc dot gnu.org ---
Potential fix:

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 2090adf01e7..238b1b72385 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11499,6 +11499,7 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym
*function,
   switch (function->id)
{
  case GFC_ISYM_INDEX:
+ case GFC_ISYM_LEN_TRIM:
if (strcmp ("kind", gfc_dummy_arg_get_name (*dummy_arg)) == 0)
  return false;
  /* Fallthrough.  */

This depends on Mikael's fix for PR97896 and is likely the cleanest solution.

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Some further interesting examples:

struct A {
  template struct B;
  template struct B { }; // #1
  template struct B { }; // #2
};

Presumably we should continue to diagnose that #2 is a redefinition of #1.


And for class-scope explicit specializations (which GCC doesn't yet support):

struct A {
  template void f();  // #1
  template void f();// #2
  template<> void f();  // #3, specialization of #2
};

The above testcase was valid before P1787, is it still so?

[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||tkoenig at gcc dot gnu.org
   Last reconfirmed||2021-11-18
 Status|UNCONFIRMED |NEW

--- Comment #15 from Thomas Koenig  ---
There should at least be a warning for code like

double 
sin(double x) {
  return x/2 + x;
}

double
foo(double x) {
  return 1 - sin(-x);
}

[Bug c/103323] Front end simplifies sin although no header included

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Andrew Pinski from comment #1)
> sin is a reserved symbol in c, you need to use -fno-builtins if you don't
> want the optimization.

Ah, correct.

I also see that PR 51437 has the request for a warning.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |12.0

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #8 from Andrew Pinski  ---
I will go look into this after a nap.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #7 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #5)
> Hmm, I fixed one like this yesterday. Are you sure it is not fixed?

Yes, I built with a trunk from this morning and just verified it still ICEs
with a new checkout (6f4ac4f81f89caac7e74127ed2e6db6bbb3d7426).

[Bug analyzer/94365] false positive leak when using container_of-like constructs

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-18
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Malcolm  ---
Thanks for filing this.

The code changed a lot in GCC 11, and again in GCC 12.

Testing again with trunk (for GCC 12); the false leak of ‘a’ report still
occurs, but the -Wanalyzer-free-of-non-heap report is fixed.

[Bug c/103323] Front end simplifies sin although no header included

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
sin is a reserved symbol in c, you need to use -fno-builtins if you don't want
the optimization.

[Bug c/103323] New: Front end simplifies sin although no header included

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

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

Bug ID: 103323
   Summary: Front end simplifies sin although no header included
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

$ cat a.c
double 
sin(double x) {
  return x/2 + x;
}

double
foo(double x) {
  return 1 - sin(-x);
}
$ gcc -S -fdump-tree-original a.c 
$ cat a.c.005t.original 

;; Function sin (null)
;; enabled by -tree-original


{
  return x / 2.0e+0 + x;
}


;; Function foo (null)
;; enabled by -tree-original


{
  return sin (x) + 1.0e+0;
}

$ gcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,c++,fortran --enable-maintainer-mode
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib
gcc-Version 12.0.0 2026 (experimental) [master revision
e87559d202d:f4e6da6e8ac:36ec54aac7da134441c83248e14825381b8d6f17] (GCC) 

The sin(x) in the tree dump should be sin(-x).

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

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

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

--- Comment #4 from Marek Polacek  ---
Does that mean that code like this (from type_traits) needs to be fixed?

  class __make_unsigned_selector_base
  {
  protected:
template struct _List { }; 

template 
  struct _List<_Tp, _Up...> : _List<_Up...>
  { static constexpr size_t __size = sizeof(_Tp); };

template
  struct __select;

template
  struct __select<_Sz, _List<_Uint, _UInts...>, true>
  { using __type = _Uint; };

template
  struct __select<_Sz, _List<_Uint, _UInts...>, false>
  : __select<_Sz, _List<_UInts...>>
  { }; 
  };

when parsing the default template argument I can't know if it can be parsed
right away or if I need to delay parsing (unless it's a simple literal, which
in this case it isn't).

[Bug testsuite/103282] New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292 fails

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
g:6f4ac4f81f89caac7e74127ed2e6db6bbb3d7426, r12-5385
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
tree-ssa.exp=gcc.dg/tree-ssa/modref-dse-5.c"
FAIL: gcc.dg/tree-ssa/modref-dse-5.c scan-tree-dump dse2 "Deleted dead store:
wrap"

I am still seeing this on current trunk on big endian systems (power 7 and
power 8).

[Bug fortran/101329] ICE: Invalid expression in gfc_element_size

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed for gcc-12.  Closing.

Thanks for the report!

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Aldy Hernandez  ---
I can reproduce this with -i ref with -O3 -ffast-math but not with -O3
-fno-unsafe-math-optimizations.

Richi the configury bits you shared once upon a time had
-fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
this test for -ffast-math that we had -fno-unsafe-math-optimizations?

I just wanna know before I go down the rabbit hole ;-).

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jan Hubicka
:

https://gcc.gnu.org/g:9d3f1435a348bece9e11787df982bd465db74ed8

commit r11-9248-g9d3f1435a348bece9e11787df982bd465db74ed8
Author: Jan Hubicka 
Date:   Wed Nov 17 22:04:26 2021 +0100

Fix modref summary streaming

Fixes bug in streaming in modref access tree that now cause a failure
of gamess benchmark.  The bug is quite old (present in GCC11 release) but
it
needs quite interesting series of events to manifest. In particular
 1) At lto time ISRA turns some parameters passed by reference to scalar
 2) At lto time modref computes summaries for old parameters and then
updates
them but does so quite stupidly believing that the load from parameters
are now unkonwn loads (rather than optimized out).
This renders summary not very useful since it thinks every memory
aliasing
int is now accssed (as opposed as parameter dereference)
 3) At stream in we notice too early that summary is useless, set
every_access
flag and drop the list.  However while reading rest of the summary we
overwrite the flag back to 0 which makes us to lose part of summary.
 4) right selection of partitions needs to be done to avoid late modref
from
recalculating and thus fixing the summary.

This patch fixes the stream in bug, however we also should fix updating of
summaries.

gcc/ChangeLog:

2021-11-17  Jan Hubicka  

PR ipa/103246
* ipa-modref.c (read_modref_records): Fix streaminig in of
every_access
flag.

(cherry picked from commit 425369bf3068a9f840d1c2f04a4d4c38e924d4dc)

[Bug fortran/101329] ICE: Invalid expression in gfc_element_size

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

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

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

https://gcc.gnu.org/g:3535be6c6f440909798d1c78e862a657f7adaf63

commit r12-5384-g3535be6c6f440909798d1c78e862a657f7adaf63
Author: Harald Anlauf 
Date:   Wed Nov 17 22:21:24 2021 +0100

Fortran: NULL() is not interoperable

gcc/fortran/ChangeLog:

PR fortran/101329
* check.c (is_c_interoperable): Reject NULL() as it is not
interoperable.

gcc/testsuite/ChangeLog:

PR fortran/101329
* gfortran.dg/pr101329.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug target/102952] New code-gen options for retpolines and straight line speculation

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #29 from H.J. Lu  ---
Fixed for GCC 12.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #6 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-cvs/2021-November/356905.html

[Bug tree-optimization/103321] [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-cvs/2021-November/356905.html

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested patch for the first issue.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #5 from Andrew Pinski  ---
Hmm, I fixed one like this yesterday. Are you sure it is not fixed?

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Peter Bergner  ---
My bisect flagged the following commit as causing the ICE:

commit f98f373dd822b35c52356b753d528924e9f89678
Commit: Richard Biener 
CommitDate: Tue Nov 16 11:31:05 2021 +0100

tree-optimization/102880 - make PHI-OPT recognize more CFGs

This allows extra edges into the middle BB for the PHI-OPT
transforms using replace_phi_edge_with_variable that do not
end up moving stmts from that middle BB.  This avoids regressing
gcc.dg/tree-ssa/ssa-hoist-4.c with the actual fix for PR102880
where CFG cleanup has the choice to remove two forwarders and
picks "the wrong" leading to

[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

--- Comment #8 from Segher Boessenkool  ---
So it seems to think that all registers in the preferred class,
GEN_OR_VSX_REGS,
are the same cost?  They very much are not :-(

[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think when instantiating templates we shouldn't be adding attributes from
current_optimize_pragma, optimization_current_node or current_target_pragma.
It shouldn't really matter where we instantiate the code from, but where it is
declared.
E.g. given
#pragma GCC push_options
#pragma GCC target "avx"
template 
inline void foo ()
{
}
#pragma GCC pop_options
#pragma GCC push_options
#pragma GCC target "avx2"
void
bar ()
{
  foo<0> ();
}
#pragma GCC pop_options
both GCC 10 and 11 emit:
__attribute__((target ("avx2")))
void bar ()
{
  foo<0> ();
}


__attribute__((target ("avx")))
void foo<0> ()
{
  GIMPLE_NOP
}
but GCC 12 emits:
__attribute__((target ("avx2")))
void bar ()
{
  foo<0> ();
}


__attribute__((target ("avx2"), target ("avx")))
void foo<0> ()
{
  GIMPLE_NOP
}

Another thing is if optimize/target attributes can be ever dependent.  If they
can, I think we have another problem because clearly
ix86_valid_target_attribute_p starts from TREE_TARGET_OPTION
(target_option_default_node) rather than from DECL_FUNCTION_SPECIFIC_TARGET
(fndecl).  I think it should start from the latter if fndecl and
DECL_FUNCTION_SPECIFIC_TARGET is non-NULL (similarly for other targets),
otherwise I really don't understand how
#include 

__attribute__((target ("avx"))) __attribute__((target ("crc32"))) void
foo ()
{
  __m256 a = {}, b = {};
  __m256 c = _mm256_and_ps (a, b);
  unsigned int d = 1;
  d = __crc32b (d, 0x55);
}
can work properly (it doesn't).

For the former issue, perhaps apply_late_template_attributes could temporarily
override current_optimize_pragma, optimization_current_node and
current_target_pragma around the cplus_decl_attributes call in there.
Also scope_chain->omp_declare_target_attribute.

Note, I think older GCCs suffered from this bug too, but before
r12-299-ga0fdff3cf33f7284 we didn't call cplus_decl_attributes at least when
there wasn't any dependent attribute.  But I guess it should be easy to add
some unrelated dependent attribute to trigger it before.

[Bug tree-optimization/103322] New: galgel from spec2000 is now broken on x86_64 with -Ofast -march=native -flto (on core)

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

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

Bug ID: 103322
   Summary: galgel from spec2000 is now broken on x86_64 with
-Ofast -march=native -flto (on core)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is seen at:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64/recent.html
Seems last successful run was Nov 12, 2021 21:00 UTC: RAW, SVN update log
fist failing is Nov 13, 2021 21:00 UTC
spec.cpu2000.results.178_galgel.peak.000.benchmark: 178.galgel
spec.cpu2000.results.178_galgel.peak.000.copies: 1
spec.cpu2000.results.178_galgel.peak.000.errors000: Child returned with invalid
return code
spec.cpu2000.results.178_galgel.peak.000.errors001: Output miscompare
s

According to log revisions g:264f061997c..af47f22fd57

[Bug tree-optimization/103266] [12 regression] llvm-13 miscompilation: __builtin_assume_aligned causes over-aggressive dce

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r12-5379-gc331a75d49b6043399f5ccce72a02ccf3b0ddc56
Author: Jan Hubicka 
Date:   Thu Nov 18 18:41:43 2021 +0100

Fix modref wrt __builtin_assume_aligned

__builtin_assume_aligned has bit contraictionary fnspec description "1cX "
which means that parameter 1 is returned but also unused.  PTA code takes
precedence to parameter being returned, while modref takes the info that
parameter is unused.  This patch tweaks modref to follow PTA semantics (as
suggested by Richard in the PR log)

gcc/ChangeLog:

2021-11-18  Jan Hubicka  

PR ipa/103266
* ipa-modref.c (modref_eaf_analysis::merge_call_lhs_flags): Unused
parameter may still be returned.
(modref_eaf_analysis::analyze_ssa_name): Call merge_call_lhs_flags
even for unused function args.

gcc/testsuite/ChangeLog:

2021-11-18  Jan Hubicka  

PR ipa/103266
* g++.dg/torture/pr103266.C: New test.

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

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

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

--- Comment #3 from Jason Merrill  ---
(In reply to Marek Polacek from comment #2)
> class C {
>   template  struct _List;
> 
>   template  struct S; // #1
> 
>   template 
>   struct S<_Sz, _List<_Uint, _UInts...>>; // #2
> 
>   static constexpr bool value = false;
> };
> 
> #2 wants to lookup_template_class S, but S can contain a DEFERRED_PARSE, so
> that's not going to work.  Perhaps we have to delay finish_template_type
> until the end of class somehow...

As I was saying in our meeting, I think in this testcase #2 is ill-formed
because it depends on a default argument that hasn't been parsed yet.

[Bug tree-optimization/103321] New: [12 regression] ICE at tree-ssa.c:1211 after r12-5300

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

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

Bug ID: 103321
   Summary: [12 regression] ICE at tree-ssa.c:1211 after r12-5300
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f98f373dd822b35c52356b753d528924e9f89678, r12-5300 

I am seeing an ICE when building the spec2017 test case 445.gobmk

/home/seurer/gcc/git/install/gcc-test/bin/gcc -c -o engine/value_moves.o
-DSPEC_CPU -DNDEBUG -DHAVE_CONFIG_H -I. -I.. -I../include -I./include  -m64 -O3
-mcpu=power8 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model
-mpopcntd -mrecip=rsqrt engine/value_moves.c
engine/value_moves.c: In function 'value_move_reasons':
engine/value_moves.c:3030:1: error: definition in block 38 does not dominate
use in block 37
 3030 | }
  | ^
for SSA_NAME: iftmp.54_199 in statement:
iftmp.54_143 = PHI 
PHI argument
iftmp.54_199
for PHI node
iftmp.54_143 = PHI 
during GIMPLE pass: phiopt
engine/value_moves.c:3030:1: internal compiler error: verify_ssa failed
0x10f15523 verify_ssa(bool, bool)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa.c:1211
0x10a6a65f execute_function_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2049
0x10a6b8eb do_per_function
/home/seurer/gcc/git/gcc-test/gcc/passes.c:1687
0x10a6bb0b execute_todo
/home/seurer/gcc/git/gcc-test/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake: *** [engine/value_moves.o] Error 1
Error with make 'specmake -j 1 build': check file
'/home/seurer/gcc/cpu2006/benchspec/CPU2006/445.gobmk/build/build_base_ppc64./make.err'
  Command returned exit code 2
  Error with make!
*** Error building 445.gobmk


commit f98f373dd822b35c52356b753d528924e9f89678
Author: Richard Biener 
Date:   Mon Nov 15 15:19:36 2021 +0100

tree-optimization/102880 - make PHI-OPT recognize more CFGs

[Bug tree-optimization/103311] [12 Regression] ICE in complex_mul_pattern::build(vec_info*) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
Fixed on trunk.

[Bug tree-optimization/103311] [12 Regression] ICE in complex_mul_pattern::build(vec_info*) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r12-5378-g4f0a2f5a3ddb1024b885c066a18caae4d733bb6c
Author: Tamar Christina 
Date:   Thu Nov 18 17:10:36 2021 +

middle-end: check that both sides of complex expression is a mul.

Both sides of the VEC_PERM_EXPR need to be a MULT but the check
was accidentally checking if both sides are a mul.

The FMS case would be handled by the validate_multiplication but
this makes the requirement more explicit and we exit earlier.

gcc/ChangeLog:

PR tree-optimization/103311
* tree-vect-slp-patterns.c (complex_mul_pattern::matches,
complex_fms_pattern::matches): Check for multiplications.

gcc/testsuite/ChangeLog:

PR tree-optimization/103311
* gcc.target/aarch64/pr103311.c: New test.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #3 from Peter Bergner  ---
A not too old trunk build didn't ICE, so this looks new.  I'll bisect it to
find the bad commit.

[Bug tree-optimization/103266] [12 regression] llvm-13 miscompilation: __builtin_assume_aligned causes over-aggressive dce

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

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

--- Comment #7 from Jan Hubicka  ---
I am testing
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index c94f0589d44..e5d2b11025a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -2033,10 +2033,7 @@ modref_eaf_analysis::merge_call_lhs_flags (gcall *call,
int arg,
   bool indirect)
 {
   int index = SSA_NAME_VERSION (name);
-
-  /* If value is not returned at all, do nothing.  */
-  if (!direct && !indirect)
-return;
+  bool returned_directly = false;

   /* If there is no return value, no flags are affected.  */
   if (!gimple_call_lhs (call))
@@ -2047,10 +2044,23 @@ modref_eaf_analysis::merge_call_lhs_flags (gcall *call,
int arg,
   if (arg >= 0)
 {
   int flags = gimple_call_return_flags (call);
-  if ((flags & ERF_RETURNS_ARG)
- && (flags & ERF_RETURN_ARG_MASK) != arg)
-   return;
+  if (flags & ERF_RETURNS_ARG)
+   {
+ if ((flags & ERF_RETURN_ARG_MASK) == arg)
+   returned_directly = true;
+ else
+  return;
+   }
+}
+  /* Make ERF_RETURNS_ARG overwrite EAF_UNUSED.  */
+  if (returned_directly)
+{
+  direct = true;
+  indirect = false;
 }
+  /* If value is not returned at all, do nothing.  */
+  else if (!direct && !indirect)
+return;

   /* If return value is SSA name determine its flags.  */
   if (TREE_CODE (gimple_call_lhs (call)) == SSA_NAME)
@@ -2273,11 +2283,13 @@ modref_eaf_analysis::analyze_ssa_name (tree name)
if (gimple_call_arg (call, i) == name)
  {
int call_flags = gimple_call_arg_flags (call, i);
-   if (!ignore_retval && !(call_flags & EAF_UNUSED))
+   if (!ignore_retval)
  merge_call_lhs_flags
  (call, i, name,
-  !(call_flags & EAF_NOT_RETURNED_DIRECTLY),
-  !(call_flags & EAF_NOT_RETURNED_INDIRECTLY));
+  !(call_flags & (EAF_NOT_RETURNED_DIRECTLY
+  | EAF_UNUSED)),
+  !(call_flags & (EAF_NOT_RETURNED_INDIRECTLY
+  | EAF_UNUSED)));
if (!(ecf_flags & (ECF_CONST | ECF_NOVOPS)))
  {
call_flags = callee_to_caller_flags

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-18
   Keywords||ice-on-valid-code

--- Comment #2 from Peter Bergner  ---
Confirmed.  Here's a creduced test case. This fails even with -O1 -mcpu=power8:

bergner@pike:~/gcc/BUGS/PR103317$ cat bug.i
int a, b;
char c;
void
d (void)
{
  char e = c;
  if (b)
if (c < 16 - 11)
  e = 16 - 11;
  if (e > 8)
e = 8;
  a = e;
}

bergner@pike:~/gcc/BUGS/PR103317$ gcc -S -O1 -mcpu=power8 bug.i 
bug.i: In function ‘d’:
bug.i:13:1: error: definition in block 3 does not dominate use in block 2
   13 | }
  | ^
for SSA_NAME: _2 in statement:
e_5 = PHI <_2(2), _4(3)>
PHI argument
_2
for PHI node
e_5 = PHI <_2(2), _4(3)>
during GIMPLE pass: phiopt
bug.i:13:1: internal compiler error: verify_ssa failed
0x11989b73 verify_ssa(bool, bool)

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

--- Comment #8 from Tamar Christina  ---
(In reply to Aldy Hernandez from comment #7)
> Could someone post the relevant configury bits used for the ppc64le case.
> 
> I used:
> 
> runcpu --config=myconfig -a validate --iterations=1  --ignore-errors
> --rebuild --noreportable -i test --tune=base 500.perlbench
> 

The test dataset has extra checks that check differences between signed and
unsigned zero which -ffast-math turns on and `-fno-unsafe-math-optimizations`
doesn't turn off.  You'll want to do a ref run instead,

so either `-i ref` or just drop the `-i` entirely, since you've already
specified `--noreportable` it won't do the `train and ref` automatically.  The
test dataset is also likely too small to show the issue.

[Bug c++/103319] [coroutines] ICE in is_this_parameter, at cp/semantics.c:10672

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

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

--- Comment #1 from Iain Sandoe  ---
ah, incidentally, that patch is likely also a fix for 96517.

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

--- Comment #7 from Aldy Hernandez  ---
Could someone post the relevant configury bits used for the ppc64le case.

For example, I have:

   OPTIMIZE= -O3 -m64 -mcpu=power9 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd -mrecip=rsqrt

My inherited config file also has the following for the 500.perlbench test:

   EXTRA_OPTIMIZE  = -fno-strict-aliasing -fno-unsafe-math-optimizations^M

I noticed as per comment #2, that seurer's doesn't add
-fno-unsafe-math-optimizations.

Also, what runcpu flags are used?

I used:

runcpu --config=myconfig -a validate --iterations=1  --ignore-errors --rebuild
--noreportable -i test --tune=base 500.perlbench

...which fails in an altogether different manner:


Contents of test.err

op/sprintf2.t   not ok 1457 - negative zero
op/sprintf2.t|  # Failed test 1457 - negative zero at op/sprintf2.t line 701
op/sprintf2.t|  #  got "0x0p+0"
op/sprintf2.t|  # expected "-0x0p+0"
op/sprintf2.t   not ok 1458 - negative zero
op/sprintf2.t|  # Failed test 1458 - negative zero at op/sprintf2.t line 702
op/sprintf2.t|  #  got "+0x0p+0"
op/sprintf2.t|  # expected "-0x0p+0"
op/sprintf2.t   not ok 1459 - negative zero
op/sprintf2.t|  # Failed test 1459 - negative zero at op/sprintf2.t line 703
op/sprintf2.t|  #  got "0x0.0p+0"
op/sprintf2.t|  # expected "-0x0.0p+0"
Failed 1 test out of 317, 99.68% okay.

Is the above what y'all are getting, or is the "Minimum abstol: nan" message
totally different?

[Bug tree-optimization/103254] [12 Regression] Compile time hog in compare_values_warnv since r12-4790-g4b3a325f07acebf4

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
This is a long sequence, made from the following pattern:

  _156 = _155 & _147;
  _157 = (int) _156;
  j_158 = _157 & j_149;
  _164 = (short int) j_158;
  _165 = _164 & _156;

Since GORI doesn't yet cache anything, each name evaluation is a "new" request.
 to resolve _165 it calculates  _164 and _156.
Note that _164 is also ultimately defined by _156 (in combination with _j_149).
so that means we evaluate _156 twice to get _165.

This rapidly triggers the same exponential growth we encountered with PR
100081, so we will need to limit this sort of thing in general until GORI
starts caching outgoing values.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P2  |P1

[Bug regression/103318] Spec 2017 benchmark perlbench_r fails on PowerPC for -Ofast and -O3, passes with -O2

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

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P2  |P1

[Bug regression/103320] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast

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

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P2  |P1

[Bug regression/103320] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast

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

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

Michael Meissner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Severity|normal  |major
   Priority|P3  |P2

[Bug regression/103320] New: Spec 2017 benchmark roms_r fails on PowerPC for -Ofast

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

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

Bug ID: 103320
   Summary: Spec 2017 benchmark roms_r fails on PowerPC for -Ofast
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The Spec 2017 benchmark roms_r compiles fine but produces the wrong output when
compiled with -Ofast options on both power9 and power10.  In going back with
the previous runs that I've done on power10, it worked with sources checked out
on October 17th, but failed with sources checked out on November 4th and
November 17th.

I used the options:
-g -mlittle -save-temps=obj -ffast-math -Ofast -mcpu=power10 -mrecip \
-funroll-loops -m64 -finline-arg-packing -static-libgfortran \
-fstack-arrays -std=legacy -frandom-seed=spec2017

[Bug c++/103319] New: [coroutines] ICE in is_this_parameter, at cp/semantics.c:10672

[avi--- via Gcc-bugs]

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

Bug ID: 103319
   Summary: [coroutines] ICE in is_this_parameter, at
cp/semantics.c:10672
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

Possibly related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102489

A very large test case gives me this:

distcc[3605276] ERROR: compile /home/avi/scylla/db/commitlog/commitlog.cc on
localhost failed
/home/avi/scylla/db/commitlog/commitlog.cc: In function ‘void
db::commitlog::segment::cycle(bool,
bool)operator()(db::commitlog::segment::cycle(bool,
bool)_ZZN2db9commitlog7segment5cycleEbbENKUlvE_clEv.frame*)’:
/home/avi/scylla/db/commitlog/commitlog.cc:901:9: internal compiler error: in
is_this_parameter, at cp/semantics.c:10672
  901 | }, [&]() -> future<> {


It is accepted by clang.

gcc 12 accepts the code, and gcc 11 with this patch backported:

commit daa9c6b015a33fa98af0ee7cd6919120248ab5f9 (tag: is_this_parameter)
Author: Jason Merrill 
Date:   Sat Nov 13 17:16:46 2021 -0500

c++: is_this_parameter and coroutines proxies

Compiling coroutines/pr95736.C with the implicit constexpr patch broke
because is_this_parameter didn't recognize the coroutines proxy for 'this'.

gcc/cp/ChangeLog:

* semantics.c (is_this_parameter): Check DECL_HAS_VALUE_EXPR_P
instead of is_capture_proxy.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 60e0982cc48..15404426bce 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -11380,11 +11380,12 @@ float_const_decimal64_p (void)
 bool
 is_this_parameter (tree t)
 {
   if (!DECL_P (t) || DECL_NAME (t) != this_identifier)
 return false;
-  gcc_assert (TREE_CODE (t) == PARM_DECL || is_capture_proxy (t)
+  gcc_assert (TREE_CODE (t) == PARM_DECL
+ || (TREE_CODE (t) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (t))
  || (cp_binding_oracle && TREE_CODE (t) == VAR_DECL));
   return true;
 }

 /* Insert the deduced return type for an auto function.  */



Also works. Requesting this backport for gcc 11 (I don't know if this is a
regression or not since I'm attempting to migrate from clang).

I don't have a reduced test case. I can try to reduce it, but perhaps knowledge
of the fix will make coming up with a small test case simple.

[Bug target/102952] New code-gen options for retpolines and straight line speculation

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

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

--- Comment #28 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:2196a681d7810ad8b227bf983f38ba716620545e

commit r12-5377-g2196a681d7810ad8b227bf983f38ba716620545e
Author: H.J. Lu 
Date:   Wed Oct 27 06:27:15 2021 -0700

x86: Add -mindirect-branch-cs-prefix

Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to
indirect thunk with branch target in r8-r15 registers so that the call
and jmp instruction length is 6 bytes to allow them to be replaced with
"lfence; call *%r8-r15" or "lfence; jmp *%r8-r15" at run-time.

gcc/

PR target/102952
* config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): Emit
CS prefix for -mindirect-branch-cs-prefix.
(ix86_output_indirect_branch_via_reg): Likewise.
* config/i386/i386.opt: Add -mindirect-branch-cs-prefix.
* doc/invoke.texi: Document -mindirect-branch-cs-prefix.

gcc/testsuite/

PR target/102952
* gcc.target/i386/indirect-thunk-cs-prefix-1.c: New test.
* gcc.target/i386/indirect-thunk-cs-prefix-2.c: Likewise.

[Bug tree-optimization/103317] Spec 2017 benchmark blender_r fails with -Ofast on PowerPc (power9, power10)

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

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

--- Comment #1 from Peter Bergner  ---
I'll try and creduce the test case.

[Bug debug/103241] Odd 0 length entries in location lists

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

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

--- Comment #13 from Jakub Jelinek  ---
 '-dA'
  Annotate the assembler output with miscellaneous debugging
  information.
It prints comments into the assembly, making the debug info in there readable
for humans.

[Bug regression/103318] Spec 2017 benchmark perlbench_r fails on PowerPC for -Ofast and -O3, passes with -O2

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

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P2
   Severity|normal  |major
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

[Bug c++/89074] valid pointer equality constexpr comparison rejected

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

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

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

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

commit r12-5376-gca243ada71656651a8753e88164a1f0f019be1c3
Author: Jonathan Wakely 
Date:   Thu Nov 18 12:39:20 2021 +

libstdc++: Fix std::char_traits::move for constexpr

The constexpr branch in __gnu_cxx::char_traits::move compares the string
arguments to see if they overlap, but relational comparisons between
unrelated pointers are not core constant expressions.

I want to replace the comparisons with a loop using pointer equality to
determine whether the end of the source string is in the destination
string. However, that doesn't work with GCC, due to PR c++/89074 so
allocate a temporary buffer instead and copy out into that first, so
that overlapping source and destination don't matter. The allocation
isn't supported by the current Intel icc so use the loop as a fallback.

libstdc++-v3/ChangeLog:

* include/bits/char_traits.h (__gnu_cxx::char_traits::move):
Do not compare unrelated pointers during constant evaluation.
*
testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc:
Improve tests for char_traits::move.

[Bug regression/103318] New: Spec 2017 benchmark perlbench_r fails on PowerPC for -Ofast and -O3, passes with -O2

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

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

Bug ID: 103318
   Summary: Spec 2017 benchmark perlbench_r fails on PowerPC for
-Ofast and -O3, passes with -O2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The Spec 2017 benchmark perlbench_r compiles fine but produces the wrong output
when compiled with -O3 or -Ofast options on both power9 and power10.  Using -O2
produces the right results on power10.  In going back with the previous runs
that I've done on power10, it worked with sources checked out on October 17th,
but failed with sources checked out on November 4th and November 17th.

For power10, the options that I use are:
-g -mlittle -save-temps=obj -ffast-math -Ofast -mcpu=power10 -mrecip \
-funroll-loops -m64  -fgnu89-inline -Wno-multichar -DSPEC_LP64 \
-frandom-seed=spec2017 -D_XOPEN_SOURCE=500 -DSPEC_LINUX_PPC_LE \
-fno-strict-aliasing -std=gnu11 -Wno-builtin-macro-redefined -w