[Bug target/101714] [POWER] vec_min / vec_max handles NaN incorrectly when evaluated at compile time

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-07
 Ever confirmed|0   |1
 CC||bergner at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
On current trunk (GCC12), this issue is gone, it has been fixed by r12-4987 as
we don't expand the bif for folding in middle-end without fast-math.

Maybe we should backport it since this PR is filed for 10.2.1.

[Bug c++/104503] [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’

[egor.pugin at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Egor Pugin  ---
But what is using  in 2.cpp?
Module m does not export anything.

[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

https://gcc.gnu.org/g:176df4ccb58689aae29511b99d60a448558ede94

commit r12-8039-g176df4ccb58689aae29511b99d60a448558ede94
Author: Andreas Krebbel 
Date:   Thu Apr 7 07:29:13 2022 +0200

IBM zSystems/testsuite: PR105147: Skip pr105140.c

pr105140.c fails on IBM zSystems with "vector argument passed to
unprototyped function".  s390_invalid_arg_for_unprototyped_fn in
s390.cc is triggered by that.

gcc/testsuite/ChangeLog:

PR target/105147
* gcc.dg/pr105140.c: Skip for s390*-*-*.

[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

--- Comment #6 from Surya Kumari Jangala  ---
I will be debugging the issue to figure the root cause.

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

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

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Okay, so I went to https://docs.njoy21.io/install.html
and started to follow the instructions to get the source.
After consuming 1.6 GB of diskspace where there are
no *.f90 files in those 1.6 GB, I am inclined to 
close this PR unless you come up with a small
testcase.

[Bug c++/101051] [10/11/12 Regression] ICE in splice_late_return_type with trailing return type on a conversion operator, caused by r10-6571

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

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

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

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

commit r12-8037-gf44a5c700f409b96ba923864158349700628133d
Author: Jason Merrill 
Date:   Wed Apr 6 21:57:33 2022 -0400

c++: conversion with trailing return type [PR101051]

We've had a diagnostic for this, but since r10-6571 added an assert to
splice_late_return_type, we need to diagnose before we call it.

PR c++/101051

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Reject conversion with trailing return
sooner.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/trailing15.C: New test.

[Bug c++/101717] [9/10/11/12 Regression] ICE capturing static member within stateless generic lambda

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

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

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

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

commit r12-8036-g8e4339f5023286d25c7dfa40b4c88e63b780cfd7
Author: Jason Merrill 
Date:   Wed Apr 6 22:20:49 2022 -0400

c++: nested generic lambda in DMI [PR101717]

We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a
non-generic
lambda.

PR c++/101717

gcc/cp/ChangeLog:

* lambda.cc (lambda_expr_this_capture): Check all enclosing
lambdas for completeness.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-this4.C: New test.

[Bug c++/105191] New: '' "is not a constant expression" regression in GCC 12

[strager.nds at gmail dot com via Gcc-bugs]

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

Bug ID: 105191
   Summary: '' "is not a constant expression"
regression in GCC 12
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: strager.nds at gmail dot com
  Target Milestone: ---

Created attachment 52763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52763=edit
C++ source file which demonstrates the issue

Compared to GCC 10 and GCC 11.2, GCC 12 reports an error when compiling my
program. A reduced test case is attached (test.cpp). I think the error is a
false positive; I think my code is valid C++.

g++
(Compiler-Explorer-Build-gcc-d8ac63e4c638a814c2cb7a9f4cebb6606caa4985-binutils-2.36.1)
12.0.1 20220404 (experimental):
g++ (GCC) 12.0.1 20220401 (Red Hat 12.0.1-0):
$ /usr/bin/c++ -std=gnu++11 test.cpp -c
test.cpp:17:5: error: non-constant array initialization
   17 |   D{},
  | ^
test.cpp:18:1: error: call to non-‘constexpr’ function ‘C::C()’
   18 | };
  | ^
test.cpp:7:8: note: ‘C::C()’ is not usable as a ‘constexpr’ function because:
7 | struct C {
  |^
test.cpp:9:5: note: defaulted default constructor does not initialize ‘B C::b’
9 |   B b;
  | ^
$ /usr/bin/c++  -std=gnu++20 test.cpp -c
test.cpp:18:1: error: ‘D [1]{D{C [1]{C{A{((const char*)"")}’ is not a
constant expression
   18 | };
  | ^

g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0:
g++ (Compiler-Explorer-Build-gcc--binutils-2.36.1) 11.2.0:
$ g++-10 -std=gnu++11 test.cpp -c
(no error)
$ g++-10 -std=gnu++20 test.cpp -c
(no error)

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

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

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

--- Comment #7 from Steve Kargl  ---
On Thu, Apr 07, 2022 at 01:09:01AM +, kermitnuc at gmail dot com wrote:
> --- Comment #6 from Kermit Bunde  ---
> I ran the stack size up to ~64Mb.
> 
> I can compile MCNP which is much bigger.
> Again, 10.3 compiled it with a stack size of 8 Mb.
> 

Okay, so we may have eliminated the stack size,
which is a very common cause of segfaults.

You appear to be using Darwin.  I don't use
Darwin.  Restore the lines that you think
are causing a problem and start eliminate
all other code until you get a small 
manageable piece of code.

Until someone has time to do the debug, you
could use 10.3 as work around.

[Bug c++/101717] [9/10/11/12 Regression] ICE capturing static member within stateless generic lambda

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
This looks like the same issue as PR99795, to which I attached a partial patch.
 Feel free to use whatever of that looks useful to you.

[Bug c++/101051] [10/11/12 Regression] ICE in splice_late_return_type with trailing return type on a conversion operator, caused by r10-6571

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 104503 Summary: [12 regression][modules] bits/shared_ptr_base.h: error: 
must ‘#include ’ before using ‘typeid’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104503

   What|Removed |Added

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

[Bug c++/104503] [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Egor Pugin from comment #0)
> cat << EOF > 1.cpp
> export module m;
> import ;
> EOF

> cat << EOF > 2.cpp
> import m;
> int main(){}
> EOF

This doesn't work because  is never imported into 2.cpp.  It's
imported into 1.cpp, but not exported from module m.  If you change the line in
1.cpp to

export import ;

then it works.

[Bug c++/100370] [11/12 Regression] Incorrect -Wplacement-new with union

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

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Jason Merrill  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592856.html

[Bug c++/105187] [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/105187] [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

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

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

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

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

commit r12-8034-gd9421784980276b42ecdce85b6dde28e965c88c6
Author: Jason Merrill 
Date:   Wed Apr 6 20:04:21 2022 -0400

c++: vector compound literal [PR105187]

My cleanup in r12-296 cleared TREE_HAS_CONSTRUCTOR on digested class
initializers, but we leave it set for vectors, since we can't wrap them in
TARGET_EXPR.

PR c++/105187

gcc/cp/ChangeLog:

* typeck2.cc (store_init_value): Allow TREE_HAS_CONSTRUCTOR for
vectors.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/20050113-1.c: Moved to...
* c-c++-common/torture/20050113-1.c: ...here.

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

[kermitnuc at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Kermit Bunde  ---
I ran the stack size up to ~64Mb.

I can compile MCNP which is much bigger.
Again, 10.3 compiled it with a stack size of 8 Mb.

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

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

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

--- Comment #5 from Steve Kargl  ---
On Wed, Apr 06, 2022 at 09:54:00PM +, kermitnuc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105182
> 
> --- Comment #4 from Kermit Bunde  ---
> This subroutine compiles when GCC 10.3 is used.  What was changed for 11.1 
> that
> might impact this?

I have no idea.  A few hundered bug fixes and several new features
were added in 11.1.  

> 
> Is there a compiler option that I can use to provide more information to you?
> 

What is your stack size?  I suspect that gfortran is putting
more things on the stack such as temporary arrays and you've
exhausted it.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

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

--- Comment #19 from Andrew Pinski  ---
It is a small optimization to remove the file is the timestamp is valid while
compiling.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

[jason at zx2c4 dot com via Gcc-bugs]

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

--- Comment #18 from Jason A. Donenfeld  ---
If it truly doesn't matter whether local_tick is a valid value or an overflowed
one (to 0 or to -1 in this case), then just remove `&& (!local_tick ||
local_tick == (unsigned)-1)`. If you object to removing that line, then surely
you intend for local_tick to play some role in this. In that case, the fact
that one condition can overflow to become another condition sounds like the
logic is occasionally suboptimal.

In other words, it strikes me that your choices are:

1) remove a conditional clause that has no meaning;
2) fix the overflow in the value of a variable checked by that conditional
clause;
3) neglect to change anything, and have that conditional clause sometimes have
meaning and sometimes not.

Maybe having buggy code -- going with choice (3) -- doesn't matter overly much,
because other things in your system still make okay overall decisions. But that
doesn't change the fact that the condition is buggy when it overflows.

Anyway, I defer to comment 14, and note that we're now on comment 18, over a
bug with a trivial fix and an available patch. I think that's an indication
that whatever is happening here is truly out of my hands, so I'll duck out now.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #17 from Andrew Pinski  ---
The stamp value is used to synchronize
   note and data files and to synchronize merging within a data
   file. It need not be an absolute time stamp, merely a ticker that
   increments fast enough and cycles slow enough to distinguish
   different compile/run/compile cycles.

So unlinking the da file is ok as it will be merged (remove data) correctly
anyways.

I think you are reading the comment in coverage.cc incorrectly.

/* Only remove the da file, if we're emitting coverage code and
   cannot uniquely stamp it.  If we can stamp it, libgcov will DTRT.  */

Basically the unlink is there just in case we can't uniquely stamp the da file
and do another compile that was already there. That is it will be emptied out
when the program is run with a different timestamp; removing the file while
compiling is just in case so you don't get mix matched results.

Again there is no need to fix this.

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to Patrick Palka from comment #4)
> N.B. coerce_template_parms sometimes does encode the implicit conversion for
> a dependent NTTP argument, but only for sake of specialization matching (in
> light of 'auto' template parms IIUC), the IMPLICIT_CONV_EXPR built is a
> no-op otherwise.

This IMPLICIT_CONV_EXPRs I'm referring to are built by 
maybe_convert_nontype_argument.

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

--- Comment #4 from Patrick Palka  ---
N.B. coerce_template_parms sometimes does encode the implicit conversion for a
dependent NTTP argument, but only for sake of specialization matching (in light
of 'auto' template parms IIUC), the IMPLICIT_CONV_EXPR built is a no-op
otherwise.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
 Ever confirmed|1   |0
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-April/5
   ||92897.html
  Component|driver  |plugins
 Status|WAITING |UNCONFIRMED

--- Comment #16 from Andrew Pinski  ---
WAITING is not the right thing.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

[jason at zx2c4 dot com via Gcc-bugs]

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

Jason A. Donenfeld  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|WAITING

--- Comment #15 from Jason A. Donenfeld  ---
I submitted a patch for this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592897.html

I'm also reopening this bug.

Feel free to take that patch and do whatever you want with it. I get the idea
you don't generally like outside contributions and I've probably submitted that
patch with all the wrong conventions, so I won't mind if you take that and
mangle it in a totally different direction without further feedback. Mostly I
just want to point out how easy this is to fix (at least I think?).

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67898
 CC||jason at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
I wonder if this is ultimately a manifestation of PR67898.  After substituting
into an NTTP, if the type of the NTTP or the type of its argument is still
dependent then we can't yet check the implicit conversion from the argument
type to the parameter type.  And we don't encode this implicit conversion
within the substituted argument (as e.g. an IMPLICIT_CONV_EXPR) because we'll
check the conversion again when we call coerce_template_parms the next time
around anyway.

However, as PR67898 illustrates, this causes problems if a subsequent template
parameter refers to this NTTP, e.g:

  template struct A;
  template using B = A;

Here A should resolve to A but it instead resolves to A because we don't encode the implicit conversion (from int to U) within the
substituted argument for V, and hence substitution into the default argument
yields decltype(W), which is just int, rather than yielding decltype(U(W)).

Seems we can run into the same issue during normalization as illustrated in
this current PR.  The normal form for E in commment #2 is just (X != 0) (with
mapping X -> X) but we really should be encoding the implicit conversions into
the mapping (yielding something like X -> unsigned(int(X))).

So I wonder if the best way to tackle this PR is to tackle PR67898 more
generally?

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

--- Comment #2 from Patrick Palka  ---
Here's a testcase which illustrates that the fix must happen during
normalization, not during satisfaction, since after normalization we don't know
which concepts we looked through to yield the given atom:

template
concept C = (X != 0);

template
concept D = C;

template
concept E = D;

static_assert(E<-1>); // should fail due to implicit conversion from '-1' to
unsigned

[Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug report.  I'm testing a fix.

[Bug analyzer/105190] New: False positive from -Wanalyzer-malloc-leak with symbolic writes to structs

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

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

Bug ID: 105190
   Summary: False positive from -Wanalyzer-malloc-leak with
symbolic writes to structs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Discovered whilst working on the fix for PR analyzer/102308:

#include "analyzer-decls.h"

struct st
{
  void *ptr[10];
  int arr[10];
};

struct st
test_conc_sym_ptr_sym_conc_arr (int i, struct st *p)
{
  struct st s;
  s.ptr[i] = __builtin_malloc (1024);
  __analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
  p->arr[5] = 42;
  __analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
  __analyzer_describe (0, p->arr[5]);  /* { dg-warning "42" } */
  return s;
} /* { dg-bogus "leak" "" { xfail *-*-* } } */
// TODO: ^^XFAIL

struct st
test_conc_sym_ptr_sym_sym_arr (int i, struct st *p, int j)
{
  struct st s;
  s.ptr[i] = __builtin_malloc (1024);
  __analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
  p->arr[j] = 42;
  __analyzer_describe (0, s.ptr[i]); /* { dg-warning "HEAP_ALLOCATED_REGION" }
*/
  __analyzer_describe (0, p->arr[j]);  /* { dg-warning "42" } */
  return s;
} /* { dg-bogus "leak" "" { xfail *-*-* } } */
// TODO: ^^XFAIL

[Bug c++/103871] [11/12 Regression] co_await causes build error

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

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Jason Merrill from comment #8)
> Any update?

I have a fix (for a number of the coroutine issues, including this one) - it
needs tidying for posting .. will try to do that over the weekend.

[Bug c++/105187] [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

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

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

Sebastian Pop  changed:

   What|Removed |Added

  Attachment #52755|0   |1
is obsolete||

--- Comment #5 from Sebastian Pop  ---
Created attachment 52762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52762=edit
patch

The attached patch fixes the issue for __sync builtins by adding the missing
barrier to -march=armv8-a+nolse path in the outline-atomics functions.

The patch also changes the behavior of __atomic builtins for -moutline-atomics
-march=armv8-a+nolse to be the same as for -march=armv8-a+lse.

[Bug c++/103871] [11/12 Regression] co_await causes build error

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

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

--- Comment #8 from Jason Merrill  ---
Any update?

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

[kermitnuc at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Kermit Bunde  ---
This subroutine compiles when GCC 10.3 is used.  What was changed for 11.1 that
might impact this?

Is there a compiler option that I can use to provide more information to you?

[Bug tree-optimization/105189] [9/10/11/12 Regression] Wrong code with -O1

[davidfromonline at gmail dot com via Gcc-bugs]

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

David Stone  changed:

   What|Removed |Added

 CC||davidfromonline at gmail dot 
com

--- Comment #2 from David Stone  ---
Simplified reproducer: https://godbolt.org/z/vbvKzPchP

```
int a() { return -1; }

int f() {
return (unsigned)a() >= 0 && 1;
}
```

Interestingly, the bug does not occur for C code:
https://godbolt.org/z/7efs1aEEz

[Bug target/105010] [12 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

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

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

--- Comment #14 from Peter Bergner  ---
(In reply to Piotr Kubaj from comment #13)
> Is it possible there's an underlying bug in GCC and it only works on Linux
> because the default for Linux for 32-bits is POWER7?

Well the default for -m32 should not be POWER7 (unless you configured with
--with-cpu=power7 or --with-cpu-32=power7)!  Segher and I talked offline on how
to fix this and it's not a one-line fix. :-(  I believe he is working on it
though.

[Bug jit/65884] libgccjit fails to link on ia64-linux-gnu

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

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

--- Comment #2 from Sergei Trofimovich  ---
> /usr/bin/ia64-linux-gnu-ld: libgccjit.so.0.0.1: short data segment overflowed 
> (0x400a68 >= 0x40)

It's the ia64 way to say that .sdata overflowed 4MB of 'static' constants and
variables (which is not that much by modern standards). I think libgccjit.so is
only a victim of it's big size.

I wonder if it will builds successfully if you configure gcc with -mno-sdata
added:
$ ./configure CFLAGS="-O2 -g -mno-sdata" CXXFLAGS="-O2 -g -mno-sdata"

It should be a safe option that generates slightly less efficient code when
accesses gp-relative data.

(I'll need some time to set the cross-compiler up locally to test myself)

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

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

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

--- Comment #3 from Steve Kargl  ---
On Wed, Apr 06, 2022 at 08:50:42PM +, kermitnuc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105182
> 
> --- Comment #2 from Kermit Bunde  ---
> (In reply to kargl from comment #1)
> > Thanks for the report, but we're going to need some help.  Code in NJOY21
> > seems to be C++.  I found an errorr.f90 file under NJOY2016. This is an
> > 11000 line code, which pulls in a number of modules.  Can you try to 
> > reduce this to something manageable?
> 
> If one comments out these lines in subroutine resprx:
>  !--Unresolved
>  if (lru.eq.2) then
> call rpxunr(a,amur,mxlru2,iest,ieed,nwscr)
>  !--Resolved with sammy method
>  else if (nmtres.gt.0) then
> call rpxsamm(nwscr,a,ier)
>  !--Resolved with errorj method
>  else
> if (lcomp.eq.0) then
>call rpxlc0(nwscr,a)
> else if (lcomp.eq.1.or.lcomp.eq.2) then
>call rpxlc12(nwscr,a,iest,ieed)
> endif
>  endif
> 
> Then error.f90 will compile.
> Is there a limit to how many subroutine calls are allowed?
> 

No.  There is an OS imposed limit on stack memory. Perhaps,
you're hitting a stack limit.

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #19 from Peter Bergner  ---
(In reply to Eric Botcazou from comment #17)
> The test fails on VxWorks, where there is no 128-bit long double:
> 
> cc1: warning: The '-mfloat128' option may not be fully supported
> 
> so it looks like a DejaGNU selector is missing.

Eric, we don't have access to test VxWorks.  Can you try changing the
dg-require using ppc_float128_sw to ppc_float128_hw and see if that fixes it
for you?

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

[kermitnuc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kermit Bunde  ---
(In reply to kargl from comment #1)
> Thanks for the report, but we're going to need some help.  Code in NJOY21
> seems to be C++.  I found an errorr.f90 file under NJOY2016. This is an
> 11000 line code, which pulls in a number of modules.  Can you try to 
> reduce this to something manageable?

If one comments out these lines in subroutine resprx:
 !--Unresolved
 if (lru.eq.2) then
call rpxunr(a,amur,mxlru2,iest,ieed,nwscr)
 !--Resolved with sammy method
 else if (nmtres.gt.0) then
call rpxsamm(nwscr,a,ier)
 !--Resolved with errorj method
 else
if (lcomp.eq.0) then
   call rpxlc0(nwscr,a)
else if (lcomp.eq.1.or.lcomp.eq.2) then
   call rpxlc12(nwscr,a,iest,ieed)
endif
 endif

Then error.f90 will compile.
Is there a limit to how many subroutine calls are allowed?

[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-April/057743.html

[Bug jit/102824] building pdf/dvi documentation for libgccjit fails

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

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

--- Comment #4 from David Malcolm  ---
As noted in https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592889.html
the above patch seems to fix "make jit.pdf", but doesn't fix "make jit.dvi"; it
seems to be looking for .eps files for the images.

I last used TeX roughly 3 decades ago, so help fixing this would be welcome :)

[Bug jit/102824] building pdf/dvi documentation for libgccjit fails

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

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

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

https://gcc.gnu.org/g:790e9814454662b6cd51d2fce1aa022ef73fedb8

commit r12-8031-g790e9814454662b6cd51d2fce1aa022ef73fedb8
Author: David Malcolm 
Date:   Wed Apr 6 16:20:10 2022 -0400

jit: fix location of .png files for "make jit.pdf" [PR102824]

"make jit.pdf" seems to be looking in
  gcc/jit/docs/_build/texinfo/libgccjit-figures
for the .png files, but they were in the source tree in:
  gcc/jit/docs/_build/texinfo

Fix "make jit.pdf" via:
  git mv \
gcc/jit/docs/_build/texinfo/*.png \
gcc/jit/docs/_build/texinfo/libgccjit-figures

gcc/jit/ChangeLog:
PR jit/102824
* docs/_build/texinfo/factorial.png: Move to...
* docs/_build/texinfo/libgccjit-figures/factorial.png: ...here.
* docs/_build/texinfo/factorial1.png: Move to...
* docs/_build/texinfo/libgccjit-figures/factorial1.png: ...here.
* docs/_build/texinfo/sum-of-squares.png: Move to...
* docs/_build/texinfo/libgccjit-figures/sum-of-squares.png:
...here.
* docs/_build/texinfo/sum-of-squares1.png: Move to...
* docs/_build/texinfo/libgccjit-figures/sum-of-squares1.png:
...here.

Signed-off-by: David Malcolm 

[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Testing the following patch:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 21c8797c938..45a04dab703 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -8108,12 +8108,12 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code,
bool *array_alloc_wo_spec)
goto failure;

  case  DIMEN_RANGE:
-   if (ar->start[i] == 0 || ar->end[i] == 0)
+   // F2018:R937:
+   // allocate-coshape-spec is [ lower-bound-expr : ] upper-bound-expr
+   if (ar->start[i] == 0 || ar->end[i] == 0 || ar->stride[i] != NULL)
  {
-   /* If ar->stride[i] is NULL, we issued a previous error.  */
-   if (ar->stride[i] == NULL)
- gfc_error ("Bad array specification in ALLOCATE statement "
-"at %L", >where);
+   gfc_error ("Bad array specification in ALLOCATE statement "
+  "at %L", >where);
goto failure;
  }
else if (gfc_dep_compare_expr (ar->start[i], ar->end[i]) == 1)

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

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

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

--- Comment #4 from Patrick Palka  ---
Related rejects-valid C++11 testcase:

template struct A;
template using B = A;

using type = A;
using type = B;// incorrectly resolves to A
 // instead of A

[Bug tree-optimization/105189] [9/10/11/12 Regression] Wrong code with -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-04-06
 Ever confirmed|0   |1
   Target Milestone|--- |9.5
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with my r9-1971-g315aa691f486bfe71bae0a5fc8828db26daebb56

int a = -1;

int
foo (int b)
{
  return b;
}

int
main ()
{
  int c = foo (a) >= 0U && 4;
  if (c != 1)
__builtin_abort ();
}

[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

The checking for bad array shape specifications needs improvement.

[Bug tree-optimization/105189] New: [9/10/11/12 Regression] Wrong code with -O1

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 105189
   Summary: [9/10/11/12 Regression] Wrong code with -O1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://gcc.godbolt.org/z/zGn1a49KT

Reproducer:
#include 

int var_16 = -1;

int a(int b) { return b; }

int main() {
int c = (unsigned int)a(var_16) >= 0 && 4;
printf("%d\n", c);
if (c != 1)
__builtin_abort();
}

Error:
>$ g++ -O1 driver.cpp && ./a.out 
0
>$ g++ -O0 driver.cpp && ./a.out 
1

gcc version 12.0.1 20220406 (git://gcc.gnu.org/git/gcc.git:master
9fd377a747375a82912bd81c67b275301489785c)

[Bug tree-optimization/105185] [12 Regression] ICE in visit_reference_op_call, at tree-ssa-sccvn.cc:5144

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |12.0

[Bug c++/105187] [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

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

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

--- Comment #2 from Marek Polacek  ---
We're tripping on this assert

+  /* A COMPOUND_LITERAL_P CONSTRUCTOR is the syntactic form; by the time we
get
+ here it should have been digested into an actual value for the type.  */
+  gcc_checking_assert (TREE_CODE (value) != CONSTRUCTOR
+  || processing_template_decl
+  || !TREE_HAS_CONSTRUCTOR (value));

(gdb) p value
$1 = 
(gdb) pge
{1.0e+0 / 0.0 - 1.0e+0 / 0.0, 1.0e+0 / 0.0 - 1.0e+0 / 0.0}

[Bug c++/105187] [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-06
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r12-296-g3f0de4dd51fd9a.

[Bug jit/65884] libgccjit fails to link on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
The problem is still present in gcc-12:

/usr/bin/time -v /home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/xg++
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/src/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -DIN_GCC -fPIC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o libgccjit.so.0.0.1 -shared
\
 attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o
jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o
jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a
libcommon.a \
 ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a  libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -lz -lzstd  \
  \
  -Wl,--version-script,../../src/gcc/jit/libgccjit.map 
-Wl,-soname,libgccjit.so.0
/usr/bin/ia64-linux-gnu-ld: libgccjit.so.0.0.1: short data segment overflowed
(0x400a68 >= 0x40)
collect2: error: ld returned 1 exit status
Command exited with non-zero status 1
Command being timed:
"/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/xg++
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/src/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -fPIC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -o libgccjit.so.0.0.1 -shared attribs.o
jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o jit/jit-recording.o
jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o jit/jit-builtins.o
jit/jit-spec.o gcc.o libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl -lz -lzstd
-Wl,--version-script,../../src/gcc/jit/libgccjit.map
-Wl,-soname,libgccjit.so.0"
User time (seconds): 24.17
System time (seconds): 0.71
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:24.89
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 662704
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 50658
Voluntary context switches: 13
Involuntary context switches: 59
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 16384
Exit status: 1

[Bug c++/105186] ICE in canonicalize_attr_name, at attribs.h:146

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-06
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Somewhat better test:

__attribute__((__int128)) int i;

[Bug c++/105188] New: ICE in rtl_verify_bb_pointers, at cfgrtl.cc:2829

[gscfq--- via Gcc-bugs]

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

Bug ID: 105188
   Summary: ICE in rtl_verify_bb_pointers, at cfgrtl.cc:2829
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5, at -O1+ :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
typedef struct { char c[0x4000]; } s;
void f (s);
int g (s *x)
{
  f (*x);
}


$ g++-12-20220403 -c z1.cc -O2
z1.cc: In function 'int g(s*)':
z1.cc:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
6 | }
  | ^
z1.cc:5:5: sorry, unimplemented: passing too large argument on stack
5 |   f (*x);
  |   ~~^~~~
during RTL pass: expand
z1.cc:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0x10d3b0f crash_signal
../../gcc/toplev.cc:322
0xb90233 rtl_verify_bb_pointers
../../gcc/cfgrtl.cc:2829
0xb90233 rtl_verify_flow_info_1
../../gcc/cfgrtl.cc:2881
0xb90de2 rtl_verify_flow_info
../../gcc/cfgrtl.cc:3126
0xb7028a verify_flow_info()
../../gcc/cfghooks.cc:282
0x1e1e243 checking_verify_flow_info
../../gcc/cfghooks.h:214
0x1e1e243 try_optimize_cfg
../../gcc/cfgcleanup.cc:2980
0x1e1e2e3 cleanup_cfg(int)
../../gcc/cfgcleanup.cc:3143
0xb6d1c6 execute
../../gcc/cfgexpand.cc:6971

[Bug c++/105187] New: [12 Regression] ICE in store_init_value, at cp/typeck2.cc:925

[gscfq--- via Gcc-bugs]

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

Bug ID: 105187
   Summary: [12 Regression] ICE in store_init_value, at
cp/typeck2.cc:925
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With file gcc.c-torture/compile/20050113-1.c :
(gcc configured with --enable-checking=yes)


$ gcc-12-20220403 -c 20050113-1.c
$
$ g++-12-20220403 -c 20050113-1.c
20050113-1.c: In function 'int main()':
20050113-1.c:6:64: internal compiler error: in store_init_value, at
cp/typeck2.cc:925
6 |   V2SF a = (V2SF) {1.0f/0.0f - 1.0f/0.0f, 1.0f/0.0f - 1.0f/0.0f};
  |^
0xa61ded store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.cc:923
0x7df0b1 check_initializer
../../gcc/cp/decl.cc:7403
0x80e256 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.cc:8374
0x93c965 cp_parser_init_declarator
../../gcc/cp/parser.cc:22821
0x911ce2 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15280
0x913879 cp_parser_declaration_statement
../../gcc/cp/parser.cc:14361
0x913f9b cp_parser_statement
../../gcc/cp/parser.cc:12446
0x914ff4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12850
0x9150d7 cp_parser_compound_statement
../../gcc/cp/parser.cc:12802
0x93b6c0 cp_parser_function_body
../../gcc/cp/parser.cc:25060
0x93b6c0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25111
0x93bd3a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31241
0x93cff4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31157
0x93cff4 cp_parser_init_declarator
../../gcc/cp/parser.cc:22582
0x911ce2 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15280
0x9445ae cp_parser_declaration
../../gcc/cp/parser.cc:14966
0x94512d cp_parser_translation_unit
../../gcc/cp/parser.cc:5010
0x94512d c_parse_file()
../../gcc/cp/parser.cc:48057
0xad39a2 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1240

[Bug c++/105186] New: ICE in canonicalize_attr_name, at attribs.h:146

[gscfq--- via Gcc-bugs]

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

Bug ID: 105186
   Summary: ICE in canonicalize_attr_name, at attribs.h:146
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.cc
__attribute__((__int128))


$ g++-12-20220403 -c z1.cc
z1.cc:1:16: internal compiler error: Segmentation fault
1 | __attribute__((__int128))
  |^~~~
0x10d3b0f crash_signal
../../gcc/toplev.cc:322
0x9035f5 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3456
0x9035f5 canonicalize_attr_name
../../gcc/attribs.h:146
0x9035f5 cp_parser_gnu_attribute_list
../../gcc/cp/parser.cc:28737
0x903831 cp_parser_gnu_attributes_opt
../../gcc/cp/parser.cc:28662
0x94439c cp_parser_declaration
../../gcc/cp/parser.cc:14844
0x94512d cp_parser_translation_unit
../../gcc/cp/parser.cc:5010
0x94512d c_parse_file()
../../gcc/cp/parser.cc:48057
0xad39a2 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1240

[Bug c/105185] New: [12 Regression] ICE in visit_reference_op_call, at tree-ssa-sccvn.cc:5144

[gscfq--- via Gcc-bugs]

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

Bug ID: 105185
   Summary: [12 Regression] ICE in visit_reference_op_call, at
tree-ssa-sccvn.cc:5144
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20220306 and 20220327, at -O1+ :
(derived from pr104825.c)


$ cat z1.c
int foo (fmt)
char* fmt;
{
  return (__builtin_strchr (fmt, '*') != 0
  || __builtin_strchr (fmt, 'n') != 0);
}
void bar ()
{
  if (foo ())
__builtin_abort ();
}


$ gcc-12-20220403 -c z1.c
$
$ gcc-12-20220403 -c z1.c -O2
during GIMPLE pass: fre
z1.c: In function 'bar':
z1.c:11:1: internal compiler error: Segmentation fault
   11 | }
  | ^
0xe0a17f crash_signal
../../gcc/toplev.cc:322
0x103c188 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3570
0x103c188 visit_reference_op_call
../../gcc/tree-ssa-sccvn.cc:5144
0x1046b93 visit_stmt
../../gcc/tree-ssa-sccvn.cc:5847
0x1047bfb process_bb
../../gcc/tree-ssa-sccvn.cc:7482
0x1049c8e do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
../../gcc/tree-ssa-sccvn.cc:7967
0x104a75b execute
../../gcc/tree-ssa-sccvn.cc:8233

[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---


Error detected with a constant instead :


$ cat z2.f90
program p
   real, allocatable :: x[:,:]
   integer, parameter :: n = 2
   allocate (x[::n, *])
end


$ cat z3.f90
program p
   real, allocatable :: x[:,:]
   allocate (x[::2, *])
end


$ gfortran-12-20220403 -c z2.f90 -fcoarray=single
z2.f90:4:15:

4 |allocate (x[::n, *])
  |   1
Error: Bad array dimension at (1)

[Bug fortran/105184] New: ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

[gscfq--- via Gcc-bugs]

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

Bug ID: 105184
   Summary: ICE in gfc_array_init_size, at
fortran/trans-array.cc:5841
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   real, allocatable :: x[:,:]
   integer :: n = 2
   allocate (x[::n, *])
end


$ gfortran-12-20220403 -c z1.f90 -fcoarray=single
z1.f90:4:23:

4 |allocate (x[::n, *])
  |   1
internal compiler error: in gfc_array_init_size, at fortran/trans-array.cc:5841
0x7b4647 gfc_array_init_size
../../gcc/fortran/trans-array.cc:5841
0x7b4647 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool)
../../gcc/fortran/trans-array.cc:6119
0x829de6 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.cc:6741
0x7ab8c7 trans_code
../../gcc/fortran/trans.cc:2088
0x7d4b7e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x75734e translate_all_program_units
../../gcc/fortran/parse.cc:6669
0x75734e gfc_parse_file()
../../gcc/fortran/parse.cc:6956
0x7a47df gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug other/105183] New: New test case gcc.dg/ipa/remref-7.c fails with -m32

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

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

Bug ID: 105183
   Summary: New test case gcc.dg/ipa/remref-7.c fails with -m32
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e, r12-7936-gf6d65e803623c7

It works fine for 64 bits.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
ipa.exp=gcc.dg/ipa/remref-7.c"
FAIL: gcc.dg/ipa/remref-7.c scan-ipa-dump inline "Removed a reference"
# of expected passes2
# of unexpected failures1

f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e is the first bad commit
commit f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e
Author: Martin Jambor 
Date:   Thu Mar 31 16:50:24 2022 +0200

ipa: Create LOAD references when necessary during inlining (PR 103171)

[Bug libstdc++/56106] complex pow improvements

[Alexander.Voigt at desy dot de via Gcc-bugs]

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

Alexander Voigt  changed:

   What|Removed |Added

 CC||Alexander.Voigt at desy dot de

--- Comment #1 from Alexander Voigt  ---
I would like to support the suggestion 2 to add overloads for
pow(complex,scalar) when scalar is an integer type. 

The reason is that if scalar is an integer type (but not int), the function
pow(complex,scalar) produces (unnecessarily) imprecise results. Here is an
example where scalar is of type int64_t:


#include 
#include 
#include 
#include 

int main() {
const std::complex z(0.0, -0.9272952180016123);
const int64_t n = -11; // precise result if n is of type int
std::cout << std::setprecision(17) << std::pow(-z, n) << '\n';
// Output: (-5.6202077021041968e-15,2.2940441836319949)
// Expected output: (-0,2.2940441836319949)
}


The output of this code snipped when compiling with gcc version 10.2.1 20210110
(Debian 10.2.1-6) as

   g++ bug.cpp
   ./a.out

gives the imprecise real part -5.6202077021041968e-15 (expected real part:
0.0).
When n is changed to type int, the real part is exactly 0.0, as expected.
Adding overloads for (non-int) integral types would thus improve the precision
of the output.

[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6

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

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

--- Comment #9 from avieira at gcc dot gnu.org ---
Found the issue, it's due to the way we encode TARGET_CPU_DEFAULT in aarch64,
it is only able to support 64 cores and we have 65 now.

Testing a work around for now and we have plans to fix this properly in GCC 13.

[Bug fortran/105182] compiling NJOY21 causes a ICE segmentation fault: 11

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Thanks for the report, but we're going to need some help.  Code in NJOY21
seems to be C++.  I found an errorr.f90 file under NJOY2016. This is an
11000 line code, which pulls in a number of modules.  Can you try to 
reduce this to something manageable?

[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/104985] [12 Regression] ICE: SIGSEGV in undo_to_marker / adjust_reg_mode with -Os -frounding-math since r12-4767-g81342e95827f77

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

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

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

https://gcc.gnu.org/g:61bee6aed26eb30b798c75b9a595c9d51e080442

commit r12-8030-g61bee6aed26eb30b798c75b9a595c9d51e080442
Author: Jakub Jelinek 
Date:   Wed Apr 6 18:42:52 2022 +0200

combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array
[PR104985]

The testcase in the PR fails under valgrind on mips64 (but only Martin
can reproduce, I couldn't).
But the problem reported there is that SUBST_MODE remembers addresses
into the regno_reg_rtx array, then some splitter needs a new pseudo
and calls gen_reg_rtx, which reallocates the regno_reg_rtx array
and finally undo operation is done and dereferences the old regno_reg_rtx
entry.
The rtx values stored in regno_reg_rtx array seems to be created
by gen_reg_rtx only and since then aren't modified, all we do for it
is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does).

So, I think it is useless to use where.r for UNDO_MODE and store
_reg_rtx[regno] in struct undo, we can store just
regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of
pointer to pointer to REG) or could also store just the regno.

The following patch does the latter, and because SUBST_MODE no longer
needs to be a macro, changes all SUBST_MODE uses to subst_mode.

2022-04-06  Jakub Jelinek  

PR rtl-optimization/104985
* combine.cc (struct undo): Add where.regno member.
(do_SUBST_MODE): Rename to ...
(subst_mode): ... this.  Change first argument from rtx * into int,
operate on regno_reg_rtx[regno] and save regno into where.regno.
(SUBST_MODE): Remove.
(try_combine): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever.  For UNDO_MODE,
use
regno_reg_rtx[undo->where.regno] instead of *undo->where.r.
(undo_to_marker): For UNDO_MODE, use
regno_reg_rtx[undo->where.regno]
instead of *undo->where.r.
(simplify_set): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever.

[Bug target/103938] [9/10/11/12 Regression] ICE with __builtin_prefetch and vectors

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alex Coplan from comment #4)
> Confirmed on trunk. I can only reproduce the ICE with trunk, not with
> earlier released versions.

Are you sure you configured the previous released versions with
--enabled-checking=yes ? That is the only way to get the ICE on released
versions.
I accidentally released a toolchain to our build folks internally inside
Marvell with checking enabled and that is how I found this issue. This code is
reduced from VPP.

[Bug c++/105164] new warning in clang, missing in gcc: -Wbitwise-instead-of-logical

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Same for trunk.git/gcc/rtl-ssa/internals.inl. The result is going into a bool,
so I see no need for |, only ||.

[Bug c++/105164] new warning in clang, missing in gcc: -Wbitwise-instead-of-logical

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
I had a quick look at the two warnings for gcc/gimple-ssa-sprintf.cc
and they look like they could move from | to || happily.

[Bug target/103938] [9/10/11/12 Regression] ICE with __builtin_prefetch and vectors

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

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

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-06
 CC||acoplan at gcc dot gnu.org

--- Comment #4 from Alex Coplan  ---
Confirmed on trunk. I can only reproduce the ICE with trunk, not with earlier
released versions.

[Bug target/105181] Store and load with updating the pointer is not used as often as it should be on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|[optimization] gcc generate |Store and load with
   |worse code than clang base  |updating the pointer is not
   |on advanced simd|used as often as it should
   ||be on aarch64

--- Comment #1 from Andrew Pinski  ---
This is just an induction variable selection issue. Gcc decides using one is
better than using 3 where the store and loads do the update too.
This is most likely a cost model issue as ivopts does have some support for
these kinds of instructions.

[Bug fortran/105182] New: compiling NJOY21 causes a ICE segmentation fault: 11

[kermitnuc at gmail dot com via Gcc-bugs]

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

Bug ID: 105182
   Summary: compiling NJOY21 causes a ICE segmentation fault: 11
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kermitnuc at gmail dot com
  Target Milestone: ---

GCC 10.3 compiles NJOY21 without issue.  GCC 11.1 and 11.2 do not.  

GCC configure script:
/configure  --prefix=/usr/local/gcc-1030 --enable-languages=c,c++,fortran,lto
CC=/usr/bin/gcc CXX=/usr/bin/g++ LD=/usr/bin/ld  --with-gmp=/usr/local
--with-mpfr=/usr/local  --with-mpc=/usr/local --with-isl=/usr/local
--with-libiconv-prefix=/usr/local --with-libiconv=/usr/local --with-system-zlib
--with-native-system-header-dir=/usr/include --build=x86_64-apple-darwin21.4.0 
CXXFLAGS="-I/usr/local/include " CCFLAGS="-I/usr/local/include " 
LDFLAGS="-L/usr/local/lib " CPPFLAGS="-I/usr/local/include " --enable-libatomic
--enable-libgomp --enable-libitm --enable-libquadmath
--enable-libquadmath-support -enable-shared --enable-shared-libgcc
--enable-static --enable-version-specific-runtime-libs
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk 

Similar for 11.1 and 11.2.
Using XCODE 13 on MacOS 12.3.1

NJOY21 is available at:  https://www.njoy21.io
The error when compiling the ERRORR.F90 subroutine.

NJOY configure script:
cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_VERBOSE_MAKEFILE:BOOL=TRUE -D
CMAKE_CXX_COMPILER=/usr/local/gcc-1120/bin/x86_64-apple-darwin21.4.0-c++ -D
CMAKE_Fortran_COMPILER=/usr/local/gcc-1120/bin/x86_64-apple-darwin21.4.0-gfortran
-D CMAKE_Fortran_FLAGS_RELEASE='-fno-stack-limit -frecursive -fcheck=all
-pedantic -Wdo-subscript  -std=legacy -v -fdump-tree-original -Wdo-subscript '
../


Compiler output:


[ 27%] Building Fortran object
_deps/njoy-build/CMakeFiles/njoy.dir/src/samm.f90.o
/Users/kermitnuc/NJOY21/bin/_deps/njoy-src/src/samm.f90:4518:38:

 4515 |do n=1,100
  | 2 
..
 4518 |  a(n)=-(delta*(xn-1)*(xn-2)*a(n-1)+&
  |  1
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)
[-Wdo-subscript]
/Users/kermitnuc/NJOY21/bin/_deps/njoy-src/src/samm.f90:4519:37:

 4515 |do n=1,100
  | 2
..
 4519 |(rhoi-2*eta)*(delta**2)*a(n-2)+(delta**3)*a(n-3))/&
  | 1
Warning: Array reference at (1) out of bounds (-1 < 1) in loop beginning at (2)
[-Wdo-subscript]
/Users/kermitnuc/NJOY21/bin/_deps/njoy-src/src/samm.f90:4519:55:

 4515 |do n=1,100
  | 2  
..
 4519 |(rhoi-2*eta)*(delta**2)*a(n-2)+(delta**3)*a(n-3))/&
  |   1
Warning: Array reference at (1) out of bounds (-2 < 1) in loop beginning at (2)
[-Wdo-subscript]
[ 28%] Building Fortran object
_deps/njoy-build/CMakeFiles/njoy.dir/src/errorr.f90.o
f951: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_deps/njoy-build/CMakeFiles/njoy.dir/build.make:239:
_deps/njoy-build/CMakeFiles/njoy.dir/src/errorr.f90.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2603:
_deps/njoy-build/CMakeFiles/njoy.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

[Bug c++/104668] [12 Regression] ICE in lookup_attribute_spec, at attribs.cc:425

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

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

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

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

commit r12-8029-g9fd377a747375a82912bd81c67b275301489785c
Author: Jakub Jelinek 
Date:   Wed Apr 6 17:53:41 2022 +0200

c++: Fix up ICE when cplus_decl_attributes is called with error_mark_node
attributes [PR104668]

cplus_decl_attributes can be called with attributes equal to
error_mark_node, there are some spots in the function that test
it or decl_attributes it calls starts with:
  if (TREE_TYPE (*node) == error_mark_node || attributes ==
error_mark_node)
return NULL_TREE;
But the recent PR104245 change broke this when processing_template_decl
is true.

The patch returns early for attributes error_mark_node from
cplus_decl_attributes.

2022-04-06  Jakub Jelinek  

PR c++/104668
* decl2.cc (splice_template_attributes): Return NULL if *p is
error_mark_node.
(cplus_decl_attributes): Return early if attributes is
error_mark_node.  Don't check that later.

* g++.dg/cpp0x/pr104668.C: New test.

[Bug c++/105143] c++20: ICE when trying to emit a [[nodiscard]] warning and non-type template arugument

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12 so far, backport to the 11 branch (for 11.3) to follow.

[Bug c++/105143] c++20: ICE when trying to emit a [[nodiscard]] warning and non-type template arugument

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

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

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

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

commit r12-8028-ge58484a019c57b1085bbbcc1654f1944feddfe73
Author: Patrick Palka 
Date:   Wed Apr 6 11:46:25 2022 -0400

c++: make -Wctad-maybe-unsupported respect complain [PR105143]

We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during overload resolution in the second testcase.

PR c++/105143

gcc/cp/ChangeLog:

* pt.cc (do_class_deduction): Check complain before attempting
to issue a -Wctad-maybe-unsupported warning.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nodiscard1.C: New test.
* g++.dg/warn/Wctad-maybe-unsupported4.C: New test.

[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os

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

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

--- Comment #9 from Jakub Jelinek  ---
Some of the ICEs are gone, but pr104327.c is still rejected.

[Bug target/105069] [12 regression] sh-elf internal compiler errors and test failures with -Os

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

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

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

https://gcc.gnu.org/g:6283d5ad4779d3e5b7b2a93e76de03264a7c7cc6

commit r12-8027-g6283d5ad4779d3e5b7b2a93e76de03264a7c7cc6
Author: Jakub Jelinek 
Date:   Wed Apr 6 17:36:54 2022 +0200

sh: Fix up __attribute__((optimize ("Os"))) handling on SH [PR105069]

As mentioned in the PR, various tests on sh-elf ICE like:
make check-gcc RUNTESTFLAGS="compile.exp='pr104327.c pr58332.c pr81360.c
pr84425.c'"
FAIL: gcc.c-torture/compile/pr104327.c   -O0  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O1  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O2  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O3 -g  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O1  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O2  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O3 -g  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -Os  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O1  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O2  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O3 -g  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -Os  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O1  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O2  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O3 -g  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -Os  (internal compiler error:
'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -Os  (test for excess errors)
With the following patch, none of those tests ICE anymore, though
pr104327.c still FAILs with:
Excess errors:
/usr/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr104327.c:6:1: error:
inlining failed in call to 'always_inline' 'bar': target specific option
mismatch
I think that would be fixable by overriding TARGET_CAN_INLINE_P
hook and allowing at least for always_inline changes in sh_div_str.

2022-04-06  Jakub Jelinek  

PR target/105069
* config/sh/sh.opt (mdiv=): Add Save.

[Bug driver/105096] --target-help not an alias for --help=target

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master, not planning to do a backport.

[Bug driver/105096] --target-help not an alias for --help=target

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

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

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

https://gcc.gnu.org/g:717b2d4191e80dc8aae3847675de73ed3f611fb7

commit r12-8026-g717b2d4191e80dc8aae3847675de73ed3f611fb7
Author: Martin Liska 
Date:   Thu Mar 31 08:45:58 2022 +0200

--target-help: align with --help=target

PR driver/105096

gcc/ChangeLog:

* common.opt: Document properly based on what it does.
* gcc.cc (display_help): Unify with what we have in common.opt.
* opts.cc (common_handle_option): Do not print undocumented
options.

[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed for rs6000.  As I mentioned on the ML, s390 may still have this same
issue.
If so, please reopen, update the target field, etc.

[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

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

commit r12-8025-gc65d15d40738f3691ff1a39907a4b93e9fe5c5ae
Author: Segher Boessenkool 
Date:   Wed Apr 6 15:22:24 2022 +

rs6000/testsuite: Skip pr105140.c

This test fails with error "AltiVec argument passed to unprototyped
function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
from 2005) actually tests for any vector type argument.  It also does
not fail on Darwin, not reflected here though.

2022-04-06  Segher Boessenkool  

gcc/testsuite/
PR target/105147
* gcc.dg/pr105140.c: Skip for powerpc*-*-*.

[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions

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

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

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

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

commit r12-8024-gcc76c502a761ddaee215bcbd8fe4720e46d3b9dd
Author: Jason Merrill 
Date:   Wed Apr 6 10:59:40 2022 -0400

c++: -Wunused-value and array init [PR104702]

Here, because of problems with the new warning-control code and expressions
that change location, the suppress_warning on the INDIRECT_REF didn't work.
Those problems still need to be worked out, but it's simple to avoid
needing
to use suppress_warning in the first place by using a reference instead.

PR c++/104702

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Use a reference for the result.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wunused-19.C: New test.

[Bug c/105181] New: [optimization] gcc generate worse code than clang base on neon

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 105181
   Summary: [optimization] gcc generate worse code than clang base
on neon
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

test case:
void loop(int N, double *a, double *b) {
  // #pragma clang loop vectorize_width(4, scalable)
  for (int i = 0; i < N; i++) {
a[i] = b[i] + 1.0;
  }
}

gcc's kernel loop body:
.L4:
ldr q0, [x2, x3]
faddv0.2d, v0.2d, v1.2d
str q0, [x1, x3]
add x3, x3, 16
cmp x3, x0
bne .L4

llvm's kernel loop body:
.LBB0_9:// =>This Inner Loop Header: Depth=1
ldr q1, [x12], #16
subsx10, x10, #2
faddv1.2d, v1.2d, v0.2d
str q1, [x11], #16
b.ne.LBB0_9

see detail in https://godbolt.org/z/54nssME4f

[Bug ada/79724] GNAT tools do not respect --program-suffix and --program-prefix

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #10 from Nicolas Boulenguez  ---
Hello.

I suggest that Homebrew adopt a solution tested for years by Debian:
* install the executables as TARGET-gcc-VERSION
* add symbolic links if necessary (gcc, gcc-VERSION, TARGET-gcc)
* apply the patch provided here over 3 years ago
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
  This URL always links to latest rebase:
 
https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/ada-gcc-name.diff

Until the assumptions are made explicit, the upstream code trying to guess the
name of the gcc executable will probably keep changing, as it has for at least
ten years. I have counted at least 6 similar bugs, and that’s only on Debian. 

This leads to duplicate efforts. For example, the diagnostic of this specific
index error is included in the patch above.

[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

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

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

--- Comment #4 from Sebastian Pop  ---
The attached patch degrades performance on cpus with LSE: the barrier is not
needed when outline-atomics execute an LSE instruction.

I was thinking to add the barrier to the armv8.0 generic path (no LSE) in the
outline-atomics functions.

[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/105150] [9/10/11/12 Regression] ICE with -Ofast: verify_gimple failed

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

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

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

https://gcc.gnu.org/g:5df29fe79df659617793f955a1ea6c23a0617fe2

commit r12-8022-g5df29fe79df659617793f955a1ea6c23a0617fe2
Author: Jakub Jelinek 
Date:   Wed Apr 6 16:47:47 2022 +0200

gimple.cc: Follow-up to adjust gimple_call_builtin_p and
gimple_call_combined_fn [PR105150]

On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> But it seems like the magic incantation to detect ârealâ built-in
> function calls is getting longer and longer.  Can we not abstract this
> in a single place rather than have to repeat the same long sequence in
> multiple places?

I've already committed it, so it can be only dealt with an incremental
patch.
Here is a patch that adjusts instead
gimple_builtin_call_types_compatible_p,
after the assert:
  if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
if (tree decl = builtin_decl_explicit (DECL_FUNCTION_CODE (fndecl)))
  fndecl = decl;
but we then lose the theoretical possibility of comparing against the
actual user declaration.  Though I guess in the
gimple-fold.cc
gimple-low.cc
gimple-match-head.cc
calls to that function we also want this rather than what they do
currently.

2022-04-06  Jakub Jelinek  

PR tree-optimization/105150
* gimple.cc (gimple_builtin_call_types_compatible_p): Use
builtin_decl_explicit here...
(gimple_call_builtin_p, gimple_call_combined_fn): ... rather than
here.

[Bug c++/105143] c++20: ICE when trying to emit a [[nodiscard]] warning and non-type template arugument

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-06

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug c++/104578] [12 Regression][CWG1315] accepts invalid partial template specialization, non-type template argument depends on a template parameter

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[12 Regression] accepts |[12 Regression][CWG1315]
   |invalid partial  template   |accepts invalid partial
   |specialization, non-type|template specialization,
   |template argument depends   |non-type template argument
   |on a template parameter |depends on a template
   ||parameter
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jason Merrill  ---
This was changed by r12-1093, which implements https://wg21.link/cwg1315 . 
This testcase seems like exactly the sort of thing that DR1315 intended to
allow.

[Bug c/105180] New: K style definition does not evaluate array size

[gcc at emil dot codes via Gcc-bugs]

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

Bug ID: 105180
   Summary: K style definition does not evaluate array size
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at emil dot codes
  Target Milestone: ---

GCC doesn't evaluates the size of an array when declared as a parameter in K
style declaration.


Example program:

#include 

int crime(s, c)
char *s;
char c[static printf("%s\n", s)];
{
return 0;
}

int accomplice(s) char *s;
{
return crime(s, s);
}

int main(void)
{
return accomplice("Hello");
}

This should print "Hello\n". When using an ANSI definition, it does, but in
K, nothing is printed, `printf` isn't evaluated at all.

According to godbolt's compiler explorer, it is a regression which appeared
after GCC 4.6.4 and before or in GCC 4.7.1
It works correctly in clang but not in modern GCC.

[Bug c++/100608] [10/11/12 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type

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

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

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

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

commit r12-8021-gfd0024e48e94008915a6b18112efbbd8abc81ed8
Author: Jason Merrill 
Date:   Tue Apr 5 16:02:04 2022 -0400

c++: -Wshadow=compatible-local type vs var [PR100608]

The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types.  If only one is, they aren't compatible.

PR c++/100608

gcc/cp/ChangeLog:

* name-lookup.cc (check_local_shadow): Use -Wshadow=local
if exactly one of 'old' and 'decl' is a type.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wshadow-compatible-local-3.C: New test.

[Bug debug/105179] New: -fcprop-registers shrinks a DWARF location range making a variable optimized out at -Og

[dc.delia at protonmail dot com via Gcc-bugs]

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

Bug ID: 105179
   Summary: -fcprop-registers shrinks a DWARF location range
making a variable optimized out at -Og
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dc.delia at protonmail dot com
  Target Milestone: ---

In this code, the value of variable l_36 from function e is available when
debugging on line 23, which uses it as (dead) call argument for a function in
the same module, but is optimized out at the very next line 24, which uses it
as call argument for a function from an external module.

This seems to affect only -Og, as at -O1/O2/O3 the value is available.

Apparently, with -fcprop-registers the range in the DWARF location definition
of l_36 does not include the call to the external function, while it does if
disabled and the compiled code is unchanged. At -Og the location of the
variable is defined using DW_OP_reg, while other levels see a DW_OP_addr.

We found this issue on x64 using gdb 11.2 with gcc commit 500d3f0a302; as for
gcc releases, the issue is found in gcc-10 (we tested 10.3) and 11 (11.1),
while the variable value was available in, e.g., 6.4, 7.5, 8.4, and 9.3.

$ cat a.c  
short a;
int c;

short b()
{
 return a;
}
short d(unsigned short f)
{
 return 0;
}
void e(char f)
{
   short g;
   char l_36;
   int l_51, l_57 = 0 ;
   for (; c <= 0; c++)
   {
   int l_30 = 0, l_80 = 2;
   char l_81 = f;
   g = b();
   l_36 = g;
   l_51 = d(l_36);
   test(l_36, l_51, l_57, l_30, l_80, l_81);
   }
}
int main ()
{
   e(8);
}
$ cat lib.c  
#include 

void test(int l_36, int l_51, int l_57, int l_30, int l_80, int l_81) {
   printf("%d %d %d %d %d %d %d", l_36, l_51, l_57, l_30, l_80, l_81);
}

GDB trace:
$ gcc -Og -g a.c lib.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 24
Breakpoint 1 at 0x400529: file a.c, line 24.
(gdb) r
Starting program: /tmp/opt 

Breakpoint 1, e (f=f@entry=8 '\b') at a.c:24
24  test(l_36, l_51, l_57, l_30, l_80, l_81);
(gdb) info loc
l_30 = 0
l_80 = 2
l_81 = 8 '\b'
g = 0
l_36 = 
l_51 = 0
l_57 = 0

Code at -Og:
00400504 :
 400504:   55  push   %rbp
 400505:   53  push   %rbx
 400506:   48 83 ec 08 sub$0x8,%rsp
 40050a:   89 fd   mov%edi,%ebp
 40050c:   eb 43   jmp400551 
 40050e:   b8 00 00 00 00  mov$0x0,%eax
 400513:   e8 de ff ff ff  callq  4004f6 
 400518:   89 c3   mov%eax,%ebx
 40051a:   66 0f be f8 movsbw %al,%di
 40051e:   0f b7 ffmovzwl %di,%edi
 400521:   e8 d8 ff ff ff  callq  4004fe 
 400526:   0f bf f0movswl %ax,%esi
 400529:   0f be fbmovsbl %bl,%edi
 40052c:   44 0f be cd movsbl %bpl,%r9d
 400530:   41 b8 02 00 00 00   mov$0x2,%r8d
 400536:   b9 00 00 00 00  mov$0x0,%ecx
 40053b:   ba 00 00 00 00  mov$0x0,%edx
 400540:   b8 00 00 00 00  mov$0x0,%eax
 400545:   e8 2f 00 00 00  callq  400579 
 40054a:   83 05 e3 0a 20 00 01addl   $0x1,0x200ae3(%rip)#
601034 
 400551:   83 3d dc 0a 20 00 00cmpl   $0x0,0x200adc(%rip)#
601034 
 400558:   7e b4   jle40050e 
 40055a:   48 83 c4 08 add$0x8,%rsp
 40055e:   5b  pop%rbx
 40055f:   5d  pop%rbp
 400560:   c3  retq 

DWARF at -Og:
0x00e7: DW_TAG_variable
  DW_AT_name("l_36")
  DW_AT_decl_line   (15)
  DW_AT_decl_column (0x0a)
  DW_AT_type(0x01c4 "char")
  DW_AT_location(0x0036: 
 [0x0040051a, 0x00400525): DW_OP_reg0 RAX)
  DW_AT_GNU_locviews(0x0034)

In the DWARF location info from -Og, the range does not include the call to the
test function at address 400545.

Through some testing we found out that the transformation behind the issue is
likely -fcprop-registers. With -fno-cprop-registers, variable l_36 appears with
its value when stepping at line 24 and the DWARF location info seems correctly
defined for the whole lifetime of the variable.

DWARF at -Og with -fno-cprop-registers:
0x00e7: DW_TAG_variable
  DW_AT_name("l_36")
  DW_AT_decl_line   (15)
  DW_AT_decl_column (0x0a)
  DW_AT_type(0x01d9 "char")
  DW_AT_location(0x0036: 
 [0x0040051a, 0x00400551): DW_OP_reg3 RBX)

[Bug libstdc++/105178] [11 Regression] g++ incorrectly reports invalid use of incomplete type

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2022-04-06
 Ever confirmed|0   |1
Summary|g++ incorrectly reports |[11 Regression] g++
   |invalid use of incomplete   |incorrectly reports invalid
   |type|use of incomplete type
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104242

--- Comment #2 from Patrick Palka  ---
Confirmed, trunk and 11.2.0 accept the testcase. 

This is likely caused by r11-9303-g853b9d54365372 and the same bug as PR104242
except reported against 11 instead of trunk.  I can confirm that backporting
r12-7708-g7a42b1fa1a090e to the 11 branch fixes the testcase there.

[Bug libstdc++/105178] g++ incorrectly reports invalid use of incomplete type

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Richard Biener  ---
Sounds more like a library issue to me

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #22 from rguenther at suse dot de  ---
On Wed, 6 Apr 2022, amacleod at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
> 
> --- Comment #20 from Andrew Macleod  ---
> That is correct.
> 
>   tree op1_type = TREE_TYPE (gimple_assign_rhs1 (s));
>   tree op2_type = TREE_TYPE (gimple_assign_rhs2 (s));
>   tree l = build_int_cst (op2_type, 0);
>   // C is [0, N), but fortran is [0, N], so default to [0, N].
>   tree u = build_int_cst (op2_type, element_precision (op1_type));
>   int_range_max shift (l, u);
>   add_range (gimple_assign_rhs2 (s), shift);
> 
> I build a range for the RHS shift-by operand (op2_type) from 0 to the 
> precision
> of the left operand (op1_type)...THats all we were using op1 for. I was
> just under the misimpression that op1 would have a TYPE_PRECISION, not
> realizing vectors could be there and they don't set that field.
> 
> I believe that to be correct?

Yes.  For vector types TYPE_PRECISION is overloaded and specifies
log2 of the number of vector elements instead.

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

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

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

--- Comment #21 from Jakub Jelinek  ---
Yes, though I think we should fix the Fortran FE so that it only relies on [0,
N) .  If the shift count is constant, it can deal with it at compile time, if
it is variable, can emit a COND_EXPR for the shift_count == N case.

[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #20 from Andrew Macleod  ---
That is correct.

  tree op1_type = TREE_TYPE (gimple_assign_rhs1 (s));
  tree op2_type = TREE_TYPE (gimple_assign_rhs2 (s));
  tree l = build_int_cst (op2_type, 0);
  // C is [0, N), but fortran is [0, N], so default to [0, N].
  tree u = build_int_cst (op2_type, element_precision (op1_type));
  int_range_max shift (l, u);
  add_range (gimple_assign_rhs2 (s), shift);

I build a range for the RHS shift-by operand (op2_type) from 0 to the precision
of the left operand (op1_type)...THats all we were using op1 for. I was
just under the misimpression that op1 would have a TYPE_PRECISION, not
realizing vectors could be there and they don't set that field.

I believe that to be correct?

[Bug c++/105178] New: g++ incorrectly reports invalid use of incomplete type

[oss.abde.sassi at gmail dot com via Gcc-bugs]

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

Bug ID: 105178
   Summary: g++ incorrectly reports invalid use of incomplete type
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oss.abde.sassi at gmail dot com
  Target Milestone: ---

Created attachment 52761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52761=edit
self-contained small example to reproduce the error

g++ 11.20.1 incorrectly reports an invalid use of incomplete type when
compiling the attached code in main.cpp.

Note that changing the `TransitionTo` class constructor to any of the following
forms will make the compiler compile the code with no error:


// These will not produce an error:

TransitionTo() : data_{} {
}

TransitionTo(int number = 0, std::any data = {}) : data_{std::move(data)} {
}

TransitionTo(int number, std::any data = {}) : data_{std::move(data)} {
}

Command used:
-

gcc -v -save-temps -std=c++17 -o test-incomplete-type main.cpp >
cmdline-output.txt 2>&1

Output from command
---

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20220127/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220127 (Red Hat 11.2.1-9) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-o' 'test-incomplete-type'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'test-incomplete-type-'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -std=c++17 -fpch-preprocess -o
test-incomplete-type-main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/backward
 /usr/lib/gcc/x86_64-redhat-linux/11/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-o' 'test-incomplete-type'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'test-incomplete-type-'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus -fpreprocessed
test-incomplete-type-main.ii -quiet -dumpdir test-incomplete-type- -dumpbase
main.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -std=c++17 -version -o
test-incomplete-type-main.s
GNU C++17 (GCC) version 11.2.1 20220127 (Red Hat 11.2.1-9)
(x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20220127 (Red Hat 11.2.1-9), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 11.2.1 20220127 (Red Hat 11.2.1-9)
(x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20220127 (Red Hat 11.2.1-9), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e80ddce1451d1b9471a6adee59f3d39d
In file included from /usr/include/c++/11/bits/move.h:57,
 from /usr/include/c++/11/bits/stl_pair.h:59,
 from /usr/include/c++/11/utility:70,
 from /usr/include/c++/11/tuple:38,
 from main.cpp:3:
/usr/include/c++/11/type_traits: In instantiation of ‘struct
std::__and_ >,
std::is_copy_constructible > >’:
/usr/include/c++/11/type_traits:2215:11:   required by substitution of
‘template using _Require = std::__enable_if_t >::value> [with _Cond =
{std::__not_ >,
std::is_copy_constructible >}]’
/usr/include/c++/11/any:187:8:   required by substitution of 

[Bug c++/105174] [Concepts] Example from temp.func.order-p6 selects wrong overload

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Confirmed.  P2113 was implemented in GCC 11 by commit r11-1571-g57b4daf8dc4ed7,
which says:

commit 57b4daf8dc4ed7b669cc70638866ddb00f5b7746
Date:   Thu Jun 11 23:58:54 2020 -0400

c++: Refinements to "more constrained".

P2113 from the last C++ meeting clarified that we only compare constraints
on functions or function templates that have equivalent template parameters
and function parameters.

I'm not currently implementing the complicated handling of reversed
comparison operators here; thinking about it now, it seems like a lot of
complexity to support a very weird usage.  If I write two similar
comparison
operators to be distinguished by their constraints, why would I write one
reversed?  If they're two unrelated operators, they're very unlikely to be
similar enough for the complexity to help.  I've started a discussion on
the
committee reflector about changing these rules.