[Bug web/92880] New: Documentation for Built-in Vector-Extensions should mention C99 Fixed-width ints as base types

[arthur200126 at gmail dot com]

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

Bug ID: 92880
   Summary: Documentation for Built-in Vector-Extensions should
mention C99 Fixed-width ints as base types
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur200126 at gmail dot com
  Target Milestone: ---

The current version of gcc doc section 6.52 "Using Vector Instructions through
Built-in Functions" does not seem to mention the possibility of using C99
fixed-width stdint types like uint32_t.

Since a quick test seems to show that these types do in fact work, it would be
a good idea to mention it in the documentation. This should, in theory, allow
programmers to write truly platform-independent vectorized code.

A test case with some knobs to play with:

  #include 

  #define namevxsi(u, l) vec_i##u##x##l##_t
  #define mkvxsi(u, l) \
typedef uint##u##_t namevxsi(u, l) __attribute__ ((vector_size (l * u /
8)))

  mkvxsi(8, 16);  /* vec_i8x16_t */
  #define vectype namevxsi(8, 16)

  vectype op(vectype a, vectype b)
  {
a = 2 * b + 1;
return a;
  }

(Hell, it even works with __uint128_t.)

[Bug web/92880] Documentation for Built-in Vector-Extensions should mention C99 Fixed-width ints as base types

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Because the fixed types in C99 are just typedef of normal types.  So it really
does not need to describe that.

[Bug libgomp/92881] New: [OpenACC] In async context, need to use 'gomp_remove_var_async' instead of 'gomp_remove_var'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92881
   Summary: [OpenACC] In async context, need to use
'gomp_remove_var_async' instead of 'gomp_remove_var'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

As discussed in
.

Searching through my email archive, I just re-discovered that it was actually
me who wrote some of that code,
.  ;-)

[Bug rtl-optimization/92882] New: [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124

[marxin at gcc dot gnu.org]

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

Bug ID: 92882
   Summary: [10 Regression] ICE in
regstat_bb_compute_calls_crossed, at regstat.c:327
since r279124
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

After we added a new assert in the revision, I see the following ICE:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/secnds.f -fno-inline -O2
-c
during RTL pass: sched1
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/secnds.f:34:0:

   34 |   end
  | 
internal compiler error: in regstat_bb_compute_calls_crossed, at regstat.c:327
0x5875ee regstat_bb_compute_calls_crossed
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regstat.c:327
0x5875ee regstat_compute_calls_crossed()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regstat.c:380
0x113f4dc sched_init()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/haifa-sched.c:7337
0x1140b2d haifa_sched_init()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/haifa-sched.c:7354
0xacb20a schedule_insns()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/sched-rgn.c:3514
0xacb813 schedule_insns()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/sched-rgn.c:3508
0xacb813 rest_of_handle_sched
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/sched-rgn.c:3726
0xacb813 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/sched-rgn.c:3834
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgomp/92881] [OpenACC] In async context, need to use 'gomp_remove_var_async' instead of 'gomp_remove_var'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-10
   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||matmal01 at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
I would close this as fixed.

[Bug rtl-optimization/92866] [10 Regression] libgo build failure on arm-linux-gnueabihf (ICE, segfault)

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Matthias Klose  ---
and it works again with r279131 ...

[Bug tree-optimization/92862] Suspicious codes in tree-ssa-loop-niter.c and predict.c

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Dec 10 08:36:56 2019
New Revision: 279156

URL: https://gcc.gnu.org/viewcvs?rev=279156&root=gcc&view=rev
Log:
Fix typos in 2 functions.

2019-12-10  Martin Liska  

PR tree-optimization/92862
* predict.c (predict_paths_leading_to_edge): Fix typo from e to e2.
* tree-ssa-loop-niter.c (loop_only_exit_p): Return false
instead of true;

Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/92862] Suspicious codes in tree-ssa-loop-niter.c and predict.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
Summary|incorrect warning of|[10 Regression] incorrect
   |__builtin_memset offset is  |warning of __builtin_memset
   |out of the bounds on|offset is out of the bounds
   |zero-size allocation and|on zero-size allocation and
   |initialization  |initialization
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r278983.

[Bug middle-end/92876] ICE in expand_UNIQUE, at internal-fn.c:2599

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||cesar at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r231081. It was rejected before the revision.

[Bug fortran/92874] ICE in gfc_dep_compare_expr, at fortran/dependency.c:36

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-10
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I've got a patch for that.

[Bug fortran/92873] ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's very old issue.

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to jules from comment #6)
> Please don't start making changes to the reference-counting code that is
> being replaced by my overhaul patch.

We first need to establish a stable baseline, with test cases, and then (or, as
part of that) merge the several independent pieces of the big "OpenACC
reference count overhaul".

> The existing code was rewritten for a
> reason -- that being, I hit various problems with it (albeit long since
> forgotten) that interfered with the manual deep-copy implementation.

So you'll have to dig out your notes, and/or we'll have to figure out any
rationale again, now.  Patches that change such fundamental things in libgomp
we cannot just commit on the basis that once they made sense to somebody.  They
have to come with rationale, and test cases.

> We have
> refcount self-checking code for the overhauled code.

... which surely can be adapted.

And, per my understanding, this is only checking libgomp internal consistency,
but not the semantics exposed to users via OpenACC directives/API calls etc.,
which in part you're changing of your patch (without test cases).  This, again,
I've spent the best part of the past weeks understanding, writing test cases
for, filing GCC PRs, resolving them one by one, independently, incrementally,
comprehensibly.

> We can address corner-case bug fixes as follow-ons once the main overhaul
> patch is committed.

Further bug fixes, yes, but we have to make some reasonable effort to not
introduce new bugs with the big "OpenACC reference count overhaul" changes.

It doesn't help if these changes go in, then the OpenACC 2.6 manual deep copy
changes, but as part of that the dynamic reference counting behavior
unexpectedly changes/breaks, for example.

[Bug fortran/92872] [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||burnus at gcc dot gnu.org,
   ||kcy at codesourcery dot com,
   ||marxin at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r276444.

[Bug c++/92869] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[igor.chorazewicz at intel dot com]

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

--- Comment #2 from Igor Chorazewicz  ---
Hm, from what I thought C++11 (not sure about C++14 but probably also) allows
ctors to be explicitly defaulted for aggregates. See C++11 [dcl.init.aggr]. 

Consider the following code:

#include 
#include 
#include 

template 
struct A {
A() = default;
A(const A &) = default;
A(A &&) = default;

T arr[N];   
};

int main()
{
A a {{1,2,3}};
}

This code compiles with g++ 9.2 for -std=c++11, -std=c++14, std=c++17 (but not
for -std=c++2a) and fails to compile for g++ 10 for all standards

[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Thomas Schwinge  ---
(In reply to jules from comment #2)
> Again, please don't change this code under the feet of the refcount overhaul
> patch!

But why?  This here is one independent chance.  The big "OpenACC reference
count overhaul" will then either lose some of its changes, or replace this here
by something else ('GOMP_MAP_VARS_OPENACC_ENTER_DATA'), but it's an incremental
step (forward).


> Using the (currently OpenMP-specific) GOMP_MAP_VARS_ENTER_DATA is
> going to end up mighty confusing from OpenACC-specific code.

Why do you think so?  It has exactly! the semantics that we need here, for this
PR.

[Bug tree-optimization/92883] New: [10 Regression] ICE in compare_values_warnv

[krebbel at gcc dot gnu.org]

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

Bug ID: 92883
   Summary: [10 Regression] ICE in compare_values_warnv
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47456&action=edit
Reduced testcase

Compiling the attached testcase for IBM Z with

gcc -O2 -march=z13 t.c -c

during IPA pass: cp
crash0.c: At top level:
crash0.c:718:1: internal compiler error: in compare_values_warnv, at
tree-vrp.c:540
0x1b5cd43 compare_values_warnv(tree_node*, tree_node*, bool*)
/home/andreas/gcc/gcc/tree-vrp.c:539
0x1b5ce15 compare_values(tree_node*, tree_node*)
/home/andreas/gcc/gcc/tree-vrp.c:700
0x1ba9beb value_range::check()
/home/andreas/gcc/gcc/value-range.cc:283
0x1baa673 value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:236
0x1bad70b value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:84
0x1bad70b value_range::intersect_helper(value_range const*, value_range const*)
/home/andreas/gcc/gcc/value-range.cc:943
0x1bae4c7 value_range::intersect(value_range const*)
/home/andreas/gcc/gcc/value-range.cc:1323
0x208db01 propagate_vr_across_jump_function
/home/andreas/gcc/gcc/ipa-cp.c:2020
0x208db01 propagate_constants_across_call
/home/andreas/gcc/gcc/ipa-cp.c:2393
0x20917d3 propagate_constants_topo
/home/andreas/gcc/gcc/ipa-cp.c:3313
0x20917d3 ipcp_propagate_stage
/home/andreas/gcc/gcc/ipa-cp.c:3409
0x20958f5 ipcp_driver
/home/andreas/gcc/gcc/ipa-cp.c:5261
0x20958f5 execute
/home/andreas/gcc/gcc/ipa-cp.c:5354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



The testcase compiles fine before r278185

[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|s390x-linux-gnu |s390x-linux-gnu,
   ||sparc-sun-solaris2.11
 CC||ro at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
I'm seeing the same ICE on 32-bit SPARC (only; 64-bit is fine):

+FAIL: gfortran.fortran-torture/execute/math.f90,  -O3 -g  (internal compiler
error)

during RTL pass: sched1
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.fortran-torture/execute/math.f90:19:0:
internal compiler error: in regstat_bb_compute_calls_crossed, at regstat.c:327
0xbc723b regstat_bb_compute_calls_crossed
/vol/gcc/src/hg/trunk/local/gcc/regstat.c:327
0xbc723b regstat_compute_calls_crossed()
/vol/gcc/src/hg/trunk/local/gcc/regstat.c:380
0x142882f sched_init()
/vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:7337
0x142a5ab haifa_sched_init()
/vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:7354
0xc0e59f schedule_insns()
/vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3514
0xc0ef63 schedule_insns()
/vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3508
0xc0ef63 rest_of_handle_sched
/vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3726
0xc0ef63 execute
/vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3834

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #47456|0   |1
is obsolete||

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47457&action=edit
Actually reduced testcase

gcc -O2 t.c -c

during IPA pass: cp
t.c:17:1: internal compiler error: in compare_values_warnv, at tree-vrp.c:540
0x1b5cd43 compare_values_warnv(tree_node*, tree_node*, bool*)
/home/andreas/gcc/gcc/tree-vrp.c:539
0x1b5ce15 compare_values(tree_node*, tree_node*)
/home/andreas/gcc/gcc/tree-vrp.c:700
0x1ba9beb value_range::check()
/home/andreas/gcc/gcc/value-range.cc:283
0x1baa673 value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:236
0x1bad70b value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:84
0x1bad70b value_range::intersect_helper(value_range const*, value_range const*)
/home/andreas/gcc/gcc/value-range.cc:943
0x1bae4c7 value_range::intersect(value_range const*)
/home/andreas/gcc/gcc/value-range.cc:1323
0x208db01 propagate_vr_across_jump_function
/home/andreas/gcc/gcc/ipa-cp.c:2020
0x208db01 propagate_constants_across_call
/home/andreas/gcc/gcc/ipa-cp.c:2393
0x20917d3 propagate_constants_topo
/home/andreas/gcc/gcc/ipa-cp.c:3313
0x20917d3 ipcp_propagate_stage
/home/andreas/gcc/gcc/ipa-cp.c:3409
0x20958f5 ipcp_driver
/home/andreas/gcc/gcc/ipa-cp.c:5261
0x20958f5 execute
/home/andreas/gcc/gcc/ipa-cp.c:5354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/92872] [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r276444.

Untested patch:

--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -884,3 +884,3 @@ get_CFI_desc (gfc_symbol *sym, gfc_expr *expr,

-  if (tmp && DECL_LANG_SPECIFIC (tmp))
+  if (tmp && DECL_LANG_SPECIFIC (tmp) && GFC_DECL_SAVED_DESCRIPTOR (tmp))
 tmp = GFC_DECL_SAVED_DESCRIPTOR (tmp);

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[will at kernel dot org]

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

Will Deacon  changed:

   What|Removed |Added

 CC||will at kernel dot org

--- Comment #1 from Will Deacon  ---
I just ran into this with GCC 9.2 and reproduced on trunk. The combination of
-fpatchable-function-entry with -mbranch-protection={standard,bti} is likely to
be used for building the Linux kernel when in-kernel BTI is used in conjunction
with dynamic function tracing. I think this will be a common configuration, so
although forcing the options to be mutually exclusive is definitely better than
broken codegen, ultimately we're going to need a way to combine them.

I suspect that placing the PACIASP before the NOPs is going to be problematic
unless it's done for all functions (including leaf functions), otherwise
hooking the NOPs at runtime is difficult because you can't tell whether or not
x30 is signed. You may end up needing to use BTI for the target instead.

The Clang folks are starting to look at -fpatchable-function-entry for AArch64
and will need to follow whatever you end up doing here.

[Bug fortran/92872] [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Author: burnus
Date: Tue Dec 10 10:32:12 2019
New Revision: 279160

URL: https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev
Log:
Fortran] PR 92872 – Fix get_CFI_desc

PR fortran/92872
* trans-array.c (get_CFI_desc): Fix cond whether saved desc exists.

PR fortran/92872
* gfortran.dg/bind_c_optional-1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_optional-1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92884] New: [SVE] Add support for chained extract-last reductions

[rsandifo at gcc dot gnu.org]

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

Bug ID: 92884
   Summary: [SVE] Add support for chained extract-last reductions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Extract-last (i.e. CLASTB) reductions can't yet handle chained
conditions, such as those seen in gcc.dg/vect/vect-cond-reduc-5.c.
We just fall back to the normal COND_REDUCTION handling instead.

If we have:

res_0 = PHI ;
res_1 = COND_EXPR ;
res_2 = COND_EXPR ;
...
res_n = COND_EXPR ;

one alternative would be (pseudo-code):

res_0 = PHI ;
vec.res_1 = vec.val_1;
vec.res_2 = VEC_COND_EXPR ;
...
vec.res_n = VEC_COND_EXPR ;
vec.cond_any = IOR_EXPR ;
res_n = .EXTRACT_LAST (res_0, vec.cond_any, vec.res_n);

Perhaps it would make sense to move the IFN_EXTRACT_LAST generation
from vectorizable_condition to vect_create_epilog_for_reduction.
All vectorizable_condition would need to do differently from
COND_REDUCTION is to handle the special case of:

vec.res_1 = vec.val_1;

instead of using a VEC_COND_EXPR between vec.val_1 and vec.res_0.
(res_0 isn't vectorised for EXTRACT_LAST_REDUCTION.)

[Bug other/92870] new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |sudi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/92872] [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #3)
> trunk/gcc/testsuite/gfortran.dg/bind_c_optional-1.f90

FIXED. Thanks for the report! You seems to have/create a nice test collection
which is very, very helpful to avoid issues in the release!

Note that due to PR 92189, your example only works at run time if the lower
bound starts at 0 – at least it seems to work by chance, if I allocated it with
lbound = 0 in the caller. (That's what I do in the added test case.)


(In reply to Martin Liška from comment #1)
> Confirmed, started with r276444.

Thanks for doing all those bug triages!

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target|s390x-ibm-linux |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||jakub at gcc dot gnu.org
   Host|s390x-ibm-linux |
 Ever confirmed|0   |1
  Build|s390x-ibm-linux |

--- Comment #2 from Jakub Jelinek  ---
Cleaned up testcase, ICEs at -O2 also on x86_64-linux:
int a, b, c, d;
unsigned e;
void baz (void *, int);
void grault (int, unsigned long);
int foo (unsigned g) { return a / g; }
void bar (void *g) { if (b) baz (g, 5); }
static void quux (int, unsigned long);
static void qux (unsigned long g) { if (g) { d = foo (-1); quux (e, (d & 2) +
g); } }
static void quux (int g, unsigned long m) { (void) g; grault (c, m); bar ("");
}
void corge () { qux (e); }

[Bug other/92870] new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114

[sudi at gcc dot gnu.org]

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

--- Comment #1 from sudi at gcc dot gnu.org ---
Ah I think I need a better effective target check. This test would only pass
for target that have a vector/scalar shift/rotate optab.

[Bug web/92880] Documentation for Built-in Vector-Extensions should mention C99 Fixed-width ints as base types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #2 from Jonathan Wakely  ---
(In reply to Mingye Wang from comment #0)
> Since a quick test seems to show that these types do in fact work,

Of course it does. As Andrew said, they're just typedefs.

> it would
> be a good idea to mention it in the documentation. This should, in theory,
> allow programmers to write truly platform-independent vectorized code.

Not really, because uint32_t is not guaranteed to be available on all
platforms.

uint_least32_t is more portable, but not guaranteed to have exactly 32 bits.

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #3 from Jakub Jelinek  ---
The fix for the ICE is easy:
--- gcc/ipa-cp.c.jj 2019-12-06 00:40:40.0 +0100
+++ gcc/ipa-cp.c2019-12-10 11:57:10.354999085 +0100
@@ -2400,7 +2400,7 @@ propagate_vr_across_jump_function (cgrap
 NOP_EXPR,
 param_type,
 jfunc->m_vr->type ()))
-   vr.intersect (*jfunc->m_vr);
+   vr.intersect (jvr);
}
  return dest_lat->meet_with (&vr);
}
but what isn't quite obvious why the code ever tries to intersect the range [0,
0xUL] which I'd bet comes from corge passing unsigned int to an
unsigned long argument, and ~[0B, 0B] with char[1] * type which must come from
quux calling bar with "" argument which is certainly non-NULL.  I mean, what do
those two ranges have in common?

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Note, qux is passing through the argument to quux (after it has been determined
that d after early inlining has [0, 1] range and thus d & 2 is always 0):
  # RANGE [0, 4294967295] NONZERO 4294967295
  _2 = (long unsigned int) e.3_1;
  qux (_2);
...
qux (long unsigned int g)
{
  long unsigned int g_5(D) = g;
  long unsigned int _1;
...
   [local count: 1073741824]:
  if (g_5(D) != 0)
goto ; [33.00%]
...
  # RANGE [1, 18446744073709551615]
  _1 = g_5(D);
  e.5_2 = e;
  e.6_3 = (int) e.5_2;
  quux (e.6_3, _1);

so I'd expect an intersection between the [0, 4294967295] range and
[1, 18446744073709551615], yielding [1, 4294967295], but instead it intersects
[0, 4294967295] with the pointer-ish unrelated ~[0B, 0B] where the effect is
actually the same.  I think the #c3 patch is fairly obviously correct, but
there is still the question if there isn't something else broken too.

[Bug fortran/92885] New: ICE (segfault) with allocatable coarrays

[davidgkinniburgh at yahoo dot co.uk]

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

Bug ID: 92885
   Summary: ICE (segfault) with allocatable coarrays
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidgkinniburgh at yahoo dot co.uk
  Target Milestone: ---

Please can someone check this out? Compiles with ifort 19.0.5.281. Thanks.  

   program caf_alloc_gfortran_ice
   ! coarray program
   ! gfortran -c -Wall -fcoarray=single -O0 caf_alloc_gfortran_ice.f90
   ! Thread model: win32
   ! gcc version 9.2.0 (GCC) on Windows

   IMPLICIT none

   type string
  character(:), allocatable :: s
   end type string

   type result
  type(string), allocatable :: sp(:)
   end type result

   ! coarray
   type(result), allocatable :: results(:)[:]

   ! now allocate
   allocate(results(2)[*])

   end program caf_alloc_gfortran_ice


gives

   21 |allocate(results(2)[*])
  |
internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Jakub Jelinek  ---
What I see is that the jfunc->m_vr originally pointed to the expected
long unsigned int [1, +INF]
value range.
But the hash table used to store the value ranges actually doesn't care about
type compatibility of different value ranges.
So I think we need additionally:
--- gcc/ipa-prop.c.jj   2019-12-06 01:26:39.0 +0100
+++ gcc/ipa-prop.c  2019-12-10 12:38:57.564926519 +0100
@@ -121,7 +121,7 @@ struct ipa_vr_ggc_hash_traits : public g
   static bool
   equal (const value_range *a, const value_range *b)
 {
-  return a->equal_p (*b);
+  return a->equal_p (*b) && types_compatible_p (a->type (), b->type ());
 }
   static void
   mark_empty (value_range *&p)
because value_range equal_p really assumes that it is called with compatible
typed value ranges.

[Bug c++/86373] Destructor shall not be instantiated in C++17 mode for prvalue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 Ever confirmed|0   |1

[Bug libstdc++/92886] New: Inappropriate comment for std::ios_base::trunc

[kakkoko at pushf dot jp]

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

Bug ID: 92886
   Summary: Inappropriate comment for std::ios_base::trunc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kakkoko at pushf dot jp
  Target Milestone: ---

The comment attached to std::ios_base::trunc looks wrong.

libstdc++-v3/include/bits/ios_base.h:

/// Open for input.  Default for @c ofstream.
static const openmode trunc =   _S_trunc;

"Open for input"?  Hmm... It looks copy-pasted from the comment on
std::ios_base::in...

/// Open for input.  Default for @c ifstream and fstream.
static const openmode in =  _S_in;

Proposal:

-/// Open for input.  Default for @c ofstream.
+/// Truncate to zero length after opening.  Default for @c ofstream.
 static const openmode trunc =  _S_trunc;

[Bug c++/89311] Brace initialization needlessly invokes destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is fixed on trunk and gcc-9-branch, by the patches for PR 85552, so I'm
closing it as a dup of that.

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

[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||raphael.kubo.da.costa@intel
   ||.com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 89311 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Andreas Schwab from comment #4)
> Workaround: use release checking.

Stupid question: How do I do that? Is there a switch that can be passed to the
configure script?

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> (In reply to Andreas Schwab from comment #4)
> > Workaround: use release checking.
> 
> Stupid question: How do I do that? Is there a switch that can be passed to
> the configure script?

-fno-checking, or -fchecking=0. I will take a look at the bug today.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Martin Liška from comment #6)
> (In reply to John Paul Adrian Glaubitz from comment #5)
> > (In reply to Andreas Schwab from comment #4)
> > > Workaround: use release checking.
> > 
> > Stupid question: How do I do that? Is there a switch that can be passed to
> > the configure script?
> 
> -fno-checking, or -fchecking=0. I will take a look at the bug today.

Okay. Thanks. Let me know if you need access to an Itanium box. To my shame, I
haven't managed to set up a GCC porterbox for ia64 yet which has been on my
TODO list for quite a while.

Hopefully early next year.

[Bug target/92822] [10 Regression] testsuite failures on aarch64 after r278938

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #2 from nsz at gcc dot gnu.org ---
e.g.

#include 

float32x2_t
foo (float32x2_t v0, float32x4_t v1)
{
  return vmulx_laneq_f32 (v0, v1, 0);
}

used to get translated to

foo:
fmulx   v0.2s, v0.2s, v1.s[0]
ret

now it is

foo:
adrpx0, .LC0
ldr q2, [x0, #:lo12:.LC0]
tbl v1.16b, {v1.16b}, v2.16b
fmulx   v0.2s, v0.2s, v1.2s
ret
.size   foo, .-foo
.section.rodata.cst16,"aM",@progbits,16
.align  4
.LC0:
.byte   0
.byte   1
.byte   2
.byte   3
.byte   0
.byte   1
.byte   2
.byte   3
.byte   0
.byte   1
.byte   2
.byte   3
.byte   4
.byte   5
.byte   6
.byte   7

[Bug libgomp/92835] [OpenACC] Run time error with enter./exit data

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-10
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
(In reply to Ron from comment #0)
> I am trying to compile and run my OpenACC code with GNU 9.1.0 branch.
> 
> I am getting the following error:

Thanks for the report.

> libgomp:  GOACC_enter_exit_data UNHANDLED kind 0x01
> 
> What does this mean?  My code works fine with PGI.

Huh, that's strange.  That's the data mapping kind used for the OpenACC
'copyin' clause, which certainly I see handled in 'GOACC_enter_exit_data'.  Can
you tell what your source code line is?  You can run your code in GDB, with
'break gomp_fatal', and when this hits, then 'backtrace'.

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/92822] [10 Regression] testsuite failures on aarch64 after r278938

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
it seems at least the following neon intrinsics are affected:

float32x2_t vmulx_laneq_f32 (float32x2_t, float32x4_t, const int);
float32x2_t vmul_laneq_f32 (float32x2_t, float32x4_t, const int);
float32x2_t vfma_laneq_f32 (float32x2_t, float32x2_t, float32x4_t, const int);
float32x2_t vfms_laneq_f32 (float32x2_t, float32x2_t, float32x4_t, const int);
float64x1_t vmul_laneq_f64 (float64x1_t, float64x2_t, const int);

[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Dunno if it isn't just workaround, but it makes absolutely no sense to
DF_INSN_INFO_GET on insns for which we really don't need it, such as debug
insns, CODE_LABEL etc. for which we never use insn_info and we just continue;.
Patch like below fixes the ICE for me.
The question is if we just have some exception that for new labels etc. we
don't grow the tables, while for insns we always do.  If yes, the patch is a
real fix, if not, we can wait for further ICEs on the same assertion.

2019-12-10  Jakub Jelinek  

PR rtl-optimization/92882
* regstat.c (regstat_bb_compute_calls_crossed): Don't check
INSN_UID against DF_INSN_SIZE or use DF_INSN_INFO_GET unless
NONDEBUG_INSN_P.

* gfortran.dg/pr92882.f: New test.

--- gcc/regstat.c.jj2019-12-09 15:02:30.112287863 +0100
+++ gcc/regstat.c   2019-12-10 13:36:23.231327649 +0100
@@ -324,13 +324,13 @@ regstat_bb_compute_calls_crossed (unsign

   FOR_BB_INSNS_REVERSE (bb, insn)
 {
+  if (!NONDEBUG_INSN_P (insn))
+   continue;
+
   gcc_assert (INSN_UID (insn) < (int) DF_INSN_SIZE ());
   struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
   unsigned int regno;

-  if (!NONDEBUG_INSN_P (insn))
-   continue;
-
   /* Process the defs.  */
   if (CALL_P (insn))
{
--- gcc/testsuite/gfortran.dg/pr92882.f.jj  2019-12-10 13:38:17.737571868
+0100
+++ gcc/testsuite/gfortran.dg/pr92882.f 2019-12-10 13:38:07.453729553 +0100
@@ -0,0 +1,4 @@
+C PR rtl-optimization/92882
+C { dg-do compile }
+C { dg-options "-O2 -fno-inline" }
+  INCLUDE 'secnds.f'

[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|C++17 wrongly reports   |[10 Regression] C++17
   |aggregate type as   |wrongly reports aggregate
   |not-aggregate (when |type as not-aggregate (when
   |explicitly defaulted ctors  |explicitly defaulted ctors
   |are added)  |are added)

--- Comment #3 from Jakub Jelinek  ---
The #c2 testcase is rejected since r278298 aka P1816R0 implementation.

[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
And the
template 
struct A {
  A() = default;
  A(const A &) = default;
  A(A &&) = default;
  T arr[N];   
};

int main()
{
  if (!__is_aggregate (A))
__builtin_abort ();
}
testcase reduced from #c0 too.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[sch...@linux-m68k.org]

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

--- Comment #8 from Andreas Schwab  ---
--enable-checking=release

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[linkw at gcc dot gnu.org]

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

--- Comment #15 from Kewen Lin  ---
Author: linkw
Date: Tue Dec 10 12:54:21 2019
New Revision: 279166

URL: https://gcc.gnu.org/viewcvs?rev=279166&root=gcc&view=rev
Log:
[PATCH] Fix PR91790 by considering different first_stmt_info for realign

As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
is different from first_stmt_info, it's possible that the first_stmt DR isn't
initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
shouldn't use first_stmt_info for vect_setup_realignment, instead we can use
the one based on first_stmt_info_for_drptr DR with additional adjustment by
bumping the distance from first_stmt DR.

2019-12-10  Kewen Lin  

  Backport from mainline
  2019-11-27  Kewen Lin  

  PR tree-optimization/91790
  * gcc/tree-vect-stmts.c (vectorizable_load): Use the adjusted DR for
  vect_setup_realignment when first_stmt_info is different from
  first_stmt_info_for_drptr.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/tree-vect-stmts.c

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-10
 Ever confirmed|0   |1

--- Comment #9 from Martin Liška  ---
@John: Can you please attach a pre-processed source file (-E option). I should
be able to reproduce that then with a cross compiler.

[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[igor.chorazewicz at intel dot com]

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

--- Comment #5 from Igor Chorazewicz  ---
Ok, but P1816R0 talks about argument deduction - in my example I specify all
template arguments for A, so should this fail?

Moreover, for g++ 10 and g++ 9.2 even the following, non-template code fails
for -std=c++2a

struct A {
A() = default;
A(const A &) = default;
A(A &&) = default;

int arr[3];   
};

int main()
{
A a = {{1,2,3}};
}

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Martin Liška from comment #9)
> @John: Can you please attach a pre-processed source file (-E option). I
> should be able to reproduce that then with a cross compiler.

Is the output after "=== BEGIN GCC DUMP ===" in the logfile what you need?

> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=ia64&ver=1%3A20191130-1&stamp=1575698799&raw=0

Otherwise, I'll generate the pre-processed source as requested.

[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
#c5 is rejected with -std=c++2a starting with r263115 aka
http://wg21.link/p1008r1
So, I believe it is correct to reject this in C++20, but I think neither of
those papers have been a DR and so shouldn't affect C++17 or earlier
compilation modes.

[Bug fortran/92885] [8/9/10 Regression] ICE (segfault) with allocatable coarrays

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
  Known to work||6.5.0
   Target Milestone|--- |8.4
Summary|ICE (segfault) with |[8/9/10 Regression] ICE
   |allocatable coarrays|(segfault) with allocatable
   ||coarrays
 Ever confirmed|0   |1
  Known to fail||10.0, 7.4.0, 8.3.0, 9.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r243021.

[Bug c++/92869] [10 Regression] C++17 wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-10
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Created attachment 47458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47458&action=edit
gcc10-pr92869.patch

Thus, I think we want to do something like this.  Untested so far.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Martin Liška  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Martin Liška from comment #9)
> > @John: Can you please attach a pre-processed source file (-E option). I
> > should be able to reproduce that then with a cross compiler.
> 
> Is the output after "=== BEGIN GCC DUMP ===" in the logfile what you need?
> 
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=ia64&ver=1%3A20191130-1&stamp=1575698799&raw=0
> 
> Otherwise, I'll generate the pre-processed source as requested.

Yes, the file is what I needed. However, I can't reproduce that with a cross
compiler.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Created attachment 47459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47459&action=edit
test-case

[Bug fortran/92887] New: [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails

[burnus at gcc dot gnu.org]

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

Bug ID: 92887
   Summary: [F2008] Passing nullified/disassociated pointer or
unalloc allocatable to  OPTIONAL + VALUE dummy fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Cf. PR 44666, except that one this time has a VALUE in addition.

The following program segfaults at run time as 'aa' and 'pp' are dereferenced.

It should pass '0'* as absent argument plus false to the hidden _argument.

Cf. F2018, 15.5.2.12, Paragraph 1:
"A dummy argument […] is not present if the dummy argument […]
 * does not have the ALLOCATABLE or POINTER attribute, and corresponds to an
   actual argument that
   – has the ALLOCATABLE attribute and is not allocated, or
   – has the POINTER attribute and is disassociated;"

Cf. gfc_conv_procedure_call and search for:
  /* For scalar arguments with VALUE attribute which are passed by
 value, pass "0" and a hidden argument gives the optional
 status.  */

[* also CHARACTER or derived types are currently passed by value, but I think
   they should be copied + passed by reference, cf. PR91196 and possibly
   others. Likewise for arrays, but those are not yet supported with VALUE,
   cf. PR 92702]


implicit none (type, external)
integer, allocatable :: aa
integer, pointer :: pp
nullify(pp)
call sub(aa, pp)
contains
subroutine sub(x, y)
  integer, value, optional :: x, y
  if (present(x)) stop 1
  if (present(y)) stop 2
end subroutine sub
end

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[asolokha at gmx dot com]

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

Bug 91790 Summary: ICE: verify_ssa failed (error: definition in block 2 follows 
the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790

   What|Removed |Added

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

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #16 from Arseny Solokha  ---
Fixed on all affected branches by Kewen.

[Bug other/92870] new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114

[sudi at gcc dot gnu.org]

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

--- Comment #2 from sudi at gcc dot gnu.org ---
So I am sure how to get a list of targets that would support a particular
optab. I guess I can introduce a new effective target check with only the
targets that I know pass? Would that be ok?

[Bug rtl-optimization/92882] [10 Regression] ICE in regstat_bb_compute_calls_crossed, at regstat.c:327 since r279124

[matmal01 at gcc dot gnu.org]

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

--- Comment #3 from Matthew Malcomson  ---
(In reply to Jakub Jelinek from comment #2)
> The question is if we just have some exception that for new labels etc. we
> don't grow the tables, while for insns we always do.  If yes, the patch is a
> real fix, if not, we can wait for further ICEs on the same assertion.
> 

That's a good point.

At the time I proposed r279124 I decided that the comment inside
`df_recompute_luids` was enough of an indication that labels should be in the
tables, but another interpretation could be that we already know labels can be
outside of a table for some period of computation.



void
df_recompute_luids (basic_block bb)
{
  rtx_insn *insn;
  int luid = 0;

  df_grow_insn_info ();

  /* Scan the block an insn at a time from beginning to end.  */
  FOR_BB_INSNS (bb, insn)
{
  struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
  /* Inserting labels does not always trigger the incremental
 rescanning.  */
  if (!insn_info)
{
  gcc_assert (!INSN_P (insn));
  insn_info = df_insn_create_insn_record (insn);
}

  DF_INSN_INFO_LUID (insn_info) = luid;
  if (INSN_P (insn))
luid++;
}
}

[Bug c++/86037] __PRETTY_FUNCTION__ for constexpr lambda's is missing [with = type]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Bisection shows that the g++ 7 behavior mentioned above has been present before
r251433 where it started to be rejected (__PRETTY_FUNCTION__ was not declared),
then in r251567 started ICEing and finally with r258660 is accepted again, but
without the [with ...].
Unfortunately, due to the long time when it was ICEing, it is hard to narrow it
further.

[Bug c/87488] hyperlink filenames in diagnostics

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Indeed, RHEL5 (admittedly in extended lifecycle support only now) and RHEL6 use
old VTE though, dunno about the other long term support distros.  Dunno what
are the probabilities users will use new GCC on those (but, it is enough if
they use such old distros on the desktop and just ssh to some other host
running new gcc).

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[jules at gcc dot gnu.org]

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

--- Comment #8 from jules at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #7)
> We first need to establish a stable baseline, with test cases, and then (or,
> as part of that) merge the several independent pieces of the big "OpenACC
> reference count overhaul".

OK -- I think I misunderstood your strategy here, which is to avoid committing
that patch in one go. IMO (:-)) it's a clear improvement overall, particularly
with the consistency checking. Test coverage could probably be better -- but,
I'm sure many of the new tests introduced by the manual deep-copy patch would
not operate correctly without the refcounting fixes underneath (and the two
patches were all merged together to start with, of course).

> > The existing code was rewritten for a
> > reason -- that being, I hit various problems with it (albeit long since
> > forgotten) that interfered with the manual deep-copy implementation.
> 
> So you'll have to dig out your notes, and/or we'll have to figure out any
> rationale again, now.  Patches that change such fundamental things in
> libgomp we cannot just commit on the basis that once they made sense to
> somebody.  They have to come with rationale, and test cases.

That's holding the new code to a rather higher standard than some of the
existing code! But, that's OK, I suppose. I will see if there are any notes I
made at the time that might be helpful.

> > We have
> > refcount self-checking code for the overhauled code.
> 
> ... which surely can be adapted.

If you do that adaptation now, you might get a better idea of the state of the
current refcounting implementation! Not sure if that'll be helpful.

> And, per my understanding, this is only checking libgomp internal
> consistency, but not the semantics exposed to users via OpenACC
> directives/API calls etc., which in part you're changing of your patch
> (without test cases).  This, again, I've spent the best part of the past
> weeks understanding, writing test cases for, filing GCC PRs, resolving them
> one by one, independently, incrementally, comprehensibly.

No, not just internal consistency. At least with the deep copy bits, there was
user-visible breakage with the existing code (again, IIRC).

> > We can address corner-case bug fixes as follow-ons once the main overhaul
> > patch is committed.
> 
> Further bug fixes, yes, but we have to make some reasonable effort to not
> introduce new bugs with the big "OpenACC reference count overhaul" changes.

That's what the testsuite is for, I guess -- the burden of proof for getting
patches approved is lack of regressions in existing tests, generally. Yes there
could be more, but this is a real fundamental thing that most of the existing
OpenACC tests will touch in some way, so it's not *that* bad.

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[jules at gcc dot gnu.org]

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

--- Comment #9 from jules at gcc dot gnu.org ---
FWIW, I wrote this at the time wrt. the refcounting changes (some parts refer
to a previous iteration of the manual deep copy patches)...

Writing a couple of new attach/detach tests, I realised that reference
counting for OpenACC was pretty seriously broken. In an attempt to fix
that, I've:

 - written self-checking code to verify reference counts. This walks
   over the whole memory-mapping splay tree and re-counts references,
   making sure they match up with the running tallies kept by the
   mapping/unmapping routines.

 - removed the dubious "finalize" arguments from the unmap routines you
   pointed out. Call "detach" in more appropriate places.

 - rewritten gomp_acc_{insert,remove}_pointer, and change the way
   "enter data" mapping works in OpenACC to be more like the
   implementation for OpenMP (gomp_acc_remove_pointer is now modelled
   on target.c:gomp_exit_data).

 - ...which means we can get rid of the "acc_dev->openacc.data_environ"
   list. I think I added that to start with (ICBW!) but now I don't
   think we need it. That means we avoid a lot of scanning through
   linear linked lists to find the "right" target_mem_desc to unmap --
   which it turns out was buggy, and also probably conceptually wrong.
   (In GOACC_enter_exit_data, that meant each mapping clause got its own
   "target_mem_desc" when entering, which isn't how things normally work
   for gomp_map_vars. That meant that when "exit data"ing, again
   individual clauses could remove the corresponding target_mem_desc.
   What *didn't* work is if the mappings for a single target_mem_desc
   returned by GOACC_enter_exit_data refer to *other* target_mem_descs
   in their argument lists, rather than pointing back to the same one. A
   lot of the code that was checking "t->refcount" for "2" or "minrefs"
   in oacc-mem.c was simply broken.)

 - lookup_dev scans over the splay tree instead of looking through the
   data_environ list. It should have done that to start with -- it
   means it'll be able to find data mapped inside "pragma acc data"
   blocks, which it wouldn't have been able to previously.

It's a lot of changes, but (I hope!) with the RC_CHECKING feature we'll
be able to be a little more confident that we've got the memory map
refcounting right, at least.

[Bug c++/92560] ICE using decltype(x < y) when that operator uses operator<=>

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug libgomp/92888] New: [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a '#pragma acc declare'd variable

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92888
   Summary: [OpenACC] Failure to resolve back via 'acc_hostptr' an
'acc_deviceptr' retrieved for a '#pragma acc declare'd
variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
Depends on: 92877
  Target Milestone: ---

This currently fails:

double global_var;
#pragma acc declare create (global_var)

[...]
  void *global_var_p_d = acc_deviceptr (&global_var);
  assert (acc_hostptr (global_var_p_d) == &global_var);

Julian's got analysis and patch posted in
.


There isn't something similar to 'acc_hostptr' ("returns the host pointer
associated with a specific device address") in OpenMP, I suppose?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92877
[Bug 92877] [OpenACC] Failure to resolve back via 'acc_hostptr' an
'acc_deviceptr' retrieved for a structured mapping

[Bug libgomp/92888] [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a '#pragma acc declare'd variable

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 47460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47460&action=edit
'libgomp.oacc-c-c++-common/pr92888-1.c'

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I guess this example should be compiled:

A new-expression that creates an object of type T initializes that object as
follows:
...
-- Otherwise, the new-initializer is interpreted according to the
initialization rules of [dcl.init] for direct-initialization.

=> do dcl.init#17.6.2.2.

[Bug c++/92745] [8/9/10 Regression] Initializing array with vec4 results in compile error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

[tschwinge at gcc dot gnu.org]

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to jules from comment #6)
> This patch fixes the acc_map_data-device_already-3.c problem, which I guess
> has probably been broken forever.  [...]

..., hence not a priority to get that fixed now.  Thanks for the initial
analysis and WIP patch!  We now understand the issue, so I'll commit my test
case XFAILed.  I filed PR92888 for tracking this problem, so please move
discussion there.

[Bug c/92889] New: GCC-8 considers the _mm_gf2p8affine_epi64_epi8 intrinsic to be symmetric

[drucker.nir at gmail dot com]

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

Bug ID: 92889
   Summary: GCC-8 considers  the _mm_gf2p8affine_epi64_epi8
intrinsic to be symmetric
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drucker.nir at gmail dot com
  Target Milestone: ---

Created attachment 47461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47461&action=edit
Source file for reproducing the bug

GCC version: gcc-8 (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
Platform: Dell XPS 13 7390 2-in-1 with the 10th Intel(C) Core^TM Generation
(Micro architecture Codename ``Ice Lake''[ICL]) Intel(c) Core^TM i7-1065G7 CPU
1.30GHz.

The source file gfni_bug.c is a stand-alone file for reproducing the bug.
The file prints two vectors that are not supposed to be equal.

To compile use:
Correct compilation: gcc-8 -O3 -march=native gfni_bug.c -DGOOD_TEST=1
Bad compilation: gcc-8 -O3 -march=native gfni_bug.c

The problem is with the new _mm_gf2p8affine_epi64_epi8 (x86_64 GF-NI)
intrinsic.
When calling 
  OUT = _mm_gf2p8affine_epi64_epi8(A,B,0) 
gcc-8 translates it to assembler in two different ways:
1) vgf2p8affineqb $0x0, A, B, OUT //Good
2) vgf2p8affineqb $0x0, B, A, OUT //Bad

Where only one of these can be correct because the operation is not symmetric.

Thanks,
Nir Drucker

[Bug target/92723] [10 Regression] ICE in expand_shift_1, at expmed.c:2635

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Hand-reduced:
void
foo (unsigned long long *x, unsigned long long *y, int z)
{
  int i;
  for (i = 0; i < 1024; i++)
x[i] = (y[i] >> z) | (y[i] << (-z & (__SIZEOF_LONG_LONG__ * __CHAR_BIT__ -
1)));
}

[Bug target/92723] [10 Regression] ICE in expand_shift_1, at expmed.c:2635

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 47462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47462&action=edit
gcc10-pr92723.patch

Untested fix.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #28 from Maxim Kuvyrkov  ---
(In reply to Ilya Leoshkevich from comment #27)
> With
> 
> -DSPEC_CPU -DNDEBUG -DPERL_CORE   -O3 -save-temps=obj
> -fopt-info-vec-optimized   -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64
> -fgnu89-inline
> 
> on gcc113 I can see 2% slowdown:
> 
> r277511 (without this fix): 880.09s
> r277515 (with this fix):897.85s
> 
> The function that degraded the most is indeed S_regmatch:
> 
> $ perf diff perf-9760321.data perf-44b2b4c.data
> 32.24%   exe[.] S_regmatch  
> 
>  8.92%   exe[.] S_find_byclass.isra.0   
> 
>  6.80%   +0.28%  libc-2.19.so   [.] 0x0007dec0  
> 
>  5.20%   exe[.] S_regtry
> 
> 
> However, the "shape" of S_regmatch did not change, that is, when all
> offsets and register numbers are replaced with "x" in the objdump
> output, the old and the new versions are identical.  This hints at some
> microarchitectural effect - aliasing in the branch predictor maybe?
> 
> From my perspective, this happens too often, so I use the following test
> to rule this out: just add a nop at the beginning of the problematic
> function. This changes all the offsets and makes aliasing situation
> completely different.  And indeed, by adding a single nop to S_regmatch,
> I get wildly different results (for now this is just 1 repeat, I will
> run best-of-3 overnight):
> 
> r277511 (without this fix): 929.1s
> r277515 (with this fix):931.48s

Hi Ilya,

Thanks for the analysis.  Doesn't seem like we can do anything useful about
this regression.

[For completeness, I see same 5% slowdown with "-O3 -funroll-loops" as with
plain -O3 on Cortex-A57.]

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I've found an ICE:

struct A
{
  int a;
  int b;
  int c = 42;
};

void
fn ()
{
  auto y = new A(1, 2);
}

$ ./cc1plus -quiet i.C -std=c++2a
In function ‘void fn()’:
cc1plus: internal compiler error: in gimplify_init_constructor, at
gimplify.c:5195
0x1040e1b gimplify_init_constructor
/home/mpolacek/src/gcc/gcc/gimplify.c:5195
0x1041432 gimplify_modify_expr_rhs
/home/mpolacek/src/gcc/gcc/gimplify.c:5357
0x104257c gimplify_modify_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:5708
0x106868a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:13368
0x1046a72 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6810
0x1031946 gimplify_and_add(tree_node*, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:482
0x1069c9b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:13719
0x1046a72 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6810
0x1043c32 gimplify_compound_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:6012
0x10413ee gimplify_modify_expr_rhs
/home/mpolacek/src/gcc/gcc/gimplify.c:5345
0x104257c gimplify_modify_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:5708
0x106868a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:13368
0x1046a72 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6810
0x1045fa6 gimplify_cleanup_point_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:6552
0x106a117 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:13760
0x1046a72 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6810
0x1035e44 gimplify_statement_list
/home/mpolacek/src/gcc/gcc/gimplify.c:1857
0x106a4c4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:13812
0x1046a72 gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6810
0x10344f3 gimplify_bind_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:1420
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||alias
 Blocks||56456

--- Comment #3 from Martin Sebor  ---
The warning sees the IL below so it's doing the right thing.  GCC doesn't
"know" that operator new doesn't clobber this->m so it doesn't eliminate the
for loop.  Rewriting the loop like so avoids the warning and results in optimal
code equivalent to that emitted by Clang:

for(int j=0;j [local count: 1073741824]:
  MEM[(struct  &)&a] ={v} {CLOBBER};
  a.m = 0;
  _5 = operator new [] (0);
  a.p = _5;
  _2 = a.m; <<< unnecessary: _2 must be 0
  if (_2 <= 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 955630224]:
  _20 = (unsigned int) _2;
  _12 = _20 + 4294967295;
  _6 = (sizetype) _12;
  _21 = (sizetype) _2;
  _7 = _21 * 4;
  __builtin_memset (_5, 0, _7);

   [local count: 1073741833]:
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Nevermind, I had some local changes.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #29 from Ilya Leoshkevich  ---
Created attachment 47463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47463&action=edit
nop plugin

Hi Maxim,

Just to clear my conscience, could you please try the nop trick in your
setup?  I normally use the attached plugin for that.  Just build it and
add e.g.

-fplugin=$HOME/gcc-nop-plugin/libgcc_nop_plugin.so
-fplugin-arg-libgcc_nop_plugin-S_regmatch=4

to the compiler flags.

Best regards,
Ilya

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #13 from Arseny Solokha  ---
This one should block PR82407.

Citing Jakub from PR84345 comment 2:
> Isn't this dup of the many other qsort checking issues in the scheduler?
> The scheduler qsort comparator is not valid comparator in many ways.

[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME

[frederik at gcc dot gnu.org]

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

--- Comment #4 from Frederik Harwath  ---
Author: frederik
Date: Tue Dec 10 16:12:58 2019
New Revision: 279169

URL: https://gcc.gnu.org/viewcvs?rev=279169&root=gcc&view=rev
Log:
Add tests to verify OpenACC clause locations

Check that the column information for OpenACC clauses is communicated correctly
to the middle-end, in particular by the Fortran front-end (cf. PR 92793).

2019-12-10  Frederik Harwath  

gcc/testsuite/
* c-c++-common/goacc/clause-locations.c: New test.
* gfortran.dg/goacc/clause-locations.f90: New test.


Added:
trunk/gcc/testsuite/c-c++-common/goacc/clause-locations.c
trunk/gcc/testsuite/gfortran.dg/goacc/clause-locations.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/92890] New: Member name lookup

[nknikita at niisi dot ras.ru]

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

Bug ID: 92890
   Summary: Member name lookup
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nknikita at niisi dot ras.ru
  Target Milestone: ---

An example from ISO/IEC 14882:2017 (E) [class.member.lookup]/7:

struct A { int x; };// S(x,A) = {{A::x},{A}}   
struct B { float x; };  // S(x,B) = {{B::x},{B}}   
struct C: public A, public B {};// S(x,C) = {{invalid}, {A in C, B in
C}}   
struct D: public virtual C {};  // S(x,D) = S(x,C)  
struct E: public virtual C { char x; }; // S(x,E) = {{E::x},{E}}  
struct F: public D, public E {};// S(x,F) = S(x,E)  


int main () 
{   
F f;
f.x = 0; // OK, lookup finds E::x   
}

g++ is unable to compile it. I don't know if this error or not, but the example
can be compiled with clang++ (> 3.8.0) and vc++. The example is still present
in N4842.

[Bug tree-optimization/92879] [10 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
After some more thought I think I need to correct myself: I suppose even in a
ctor the this pointer might need to be treated as having escaped and be
accessible to a replacement operator new, but placement new is not replaceable
so it can't access such an escaped pointer.

[Bug c/92891] New: ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com]

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

Bug ID: 92891
   Summary: ice in decompose, at wide-int.h:984
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47464&action=edit
C source code

The attached C code, with recent gcc trunk and compiler flag -O2,
does this:

during GIMPLE pass: strlen
iplookup.c: In function ‘iplookup_router_entry’:
iplookup.c:148:1: internal compiler error: in decompose, at wide-int.h:984
0x5da4cc wi::int_traits >::decompose(long*,
u
nsigned int, generic_wide_int const&)
../../trunk/gcc/wide-int.h:984
0x949225 wi::int_traits >::decompose(long*,
u
nsigned int, generic_wide_int const&)
../../trunk/gcc/wide-int.h:1931
0x949225 wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int)
../../trunk/gcc/wide-int.h:1034
0x949225 generic_wide_int
>::generic_wide_int<
generic_wide_int >(generic_wide_int const&, 
unsigned int)

The problem first seems to occur sometime between revision 278950
and 279000.

Reducing the code now.

[Bug c/92889] GCC-8 considers the _mm_gf2p8affine_epi64_epi8 intrinsic to be symmetric

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 CC||jakub at gcc dot gnu.org,
   ||jbeulich at suse dot com
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I believe this has been fixed already for GCC10+ in r272783, so just that
change needs to be backported to GCC9 and GCC8.
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01833.html
CCing patch author.

[Bug c++/92890] Member name lookup

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug c++/77725] An example from the standard regarding member lookup fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nknikita at niisi dot ras.ru

--- Comment #2 from Jonathan Wakely  ---
*** Bug 92890 has been marked as a duplicate of this bug. ***

[Bug libstdc++/92886] Inappropriate comment for std::ios_base::trunc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-10
 Ever confirmed|0   |1

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2019-03-08 00:00:00 |2019-12-10

--- Comment #6 from Jonathan Wakely  ---
This is now blocking the implementation of std::ranges algorithms, because this
error is given for types that are only used in concept satisfaction (and never
actually odr-used):


#include 

template> Pred>
  constexpr void
  all_of(T*, Pred)
  { }

void
test01()
{
  struct X { };
  X x;
  all_of(&x, [](X&) { return false; });
}

Compiled with -std=gnu++2a and current trunk:

In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_types.h:71,
 from /home/jwakely/gcc/10/include/c++/10.0.0/iterator:61,
 from proj.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/iterator_concepts.h:669:40: error:
'std::indirect_result_t<_Proj&, _Iter> std::projected<_Iter,
_Proj>::operator*() const [with _Iter = test01()::X*; _Proj = std::identity;
std::indirect_result_t<_Proj&, _Iter> = test01()::X&]', declared using local
type 'test01()::X', is used but never defined [-fpermissive]
  669 |   indirect_result_t<_Proj&, _Iter> operator*() const; // not
defined
  |^~~~

[Bug c/92891] ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C code:

int a, b;
int *c() __attribute__((alloc_size(1)));
void d() {
  char *e = c(1);
  while (a) {
if (b <= 0)
  continue;
e[b] = 0;
  }
}

[Bug rtl-optimization/92892] New: [AARCH64] TBL-based permutations can be implemented more efficiently for 2-element vectors

[dpochepk at gmail dot com]

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

Bug ID: 92892
   Summary: [AARCH64] TBL-based permutations can be implemented
more efficiently for 2-element vectors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dpochepk at gmail dot com
  Target Milestone: ---

Current vector elements permutation implementation generates different
instructions depending on specific permutation form. For permutations like:
"target[0] = src1[0]; target[1] = src2[1];" the TBL instruction is used and
following instructions sequence is generated:

mov tmpReg1, src1;
mov tmpReg2, src2;
tbl target, {tmpReg1, tmpReg2}, ...
// the tmpReg1 and tmpReg2 registers which are numbered consecutively, as
required by tbl instruction

For 2-element vectors this sequence can be reduced to:

mov target[0], src1[0]
mov target[1], src2[1]


And it can be reduced to a single mov in case target = src, which is already
implemented in patch prototype I'm working on.

[Bug c++/92893] New: Unhelpful -Wstringop-overflow warning

[sbergman at redhat dot com]

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

Bug ID: 92893
   Summary: Unhelpful -Wstringop-overflow warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Recent GCC 10 trunk produces a -Wstringop-overflow warning that at least
gcc-c++-9.2.1-1.fc31.x86_64 does not produce.  Unfortunately the minimal
reproducer I came up with is still a bit lengthy:

> $ cat test.cc
> #include 
> 
> struct View {
>   View(char const * s): s_(s), n_(std::strlen(s)) {}
>   char const * s_;
>   std::size_t n_;
> };
> 
> template struct Add {
>   static char * add(char * buf, T const &);
> };
> 
> template struct Add {
>   static char * add(char * buf, char const s[N]) {
> std::memcpy(buf, s, N);
> return buf + N;
>   }
> };
> 
> template<> struct Add {
>   static char * add(char * buf, View const & v) {
> std::memcpy(buf, v.s_, v.n_);
> return buf + v.n_;
>   }
> };
> 
> template struct Cat {
>   Cat(T1 const & x, T2 const & y): x_(x), y_(y) {}
>   char * add(char * buf) const
>   { return Add::add(Add::add(buf, x_), y_); }
>   T1 const & x_;
>   T2 const & y_;
> };
> 
> template struct Add> {
>   static char * add(char * buf, Cat const & c) { return c.add(buf); }
> };
> 
> Cat catA(char const(&x)[1], View const & y) {
>   return {x, y};
> }
> 
> Cat, char const[4]> catB(
>   Cat const & x, char const (&y)[4])
> {
>   return {x, y};
> }
> 
> struct Buf { char buf[1]; };
> 
> Buf * get();
> 
> struct Str {
>   template Str(Cat c)
>   { c.add(get()->buf); }
> };
> 
> void f(char const * p) { Str(catB(catA("", View(p)), "xxx")); }

> $ g++ -O2 -c test.cc
> In member function ‘char* Cat::add(char*) const [with T1 = Cat char [1], View>; T2 = const char [4]]’,
> inlined from ‘Str::Str(Cat) [with T1 = Cat; 
> T2 = const char [4]]’ at test.cc:55:10,
> inlined from ‘void f(const char*)’ at test.cc:58:26:
> test.cc:15:16: warning: writing 4 bytes into a region of size 1 
> [-Wstringop-overflow=]
>15 | std::memcpy(buf, s, N);
>   | ~~~^~~

The warning only appears with this specific case where catB takes a char[4],
not for other char[N].

Buff::buf is meant to be a trailing flexible array member.  In the original
code, it needs to stay that way for compatibility reasons, but also if it is
replaced with the canonical GCC-extended flexible array member syntax,

> struct Buf { char buf[0]; };

the warning remains (this time as "writing 4 bytes into a region of size 0").

At least in the original code, I found no range of code that could be wrapped
in

> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wstringop-overflow"
[...]
> #pragma GCC diagnostic push

short of disabling the warning completely.  But maybe there is a way to
annotate the call to c.add(get()->buf) in the Str constructor, to break the
connection that Buf::buf is nominally of size 1 there?

[Bug libstdc++/92886] Inappropriate comment for std::ios_base::trunc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed on trunk, thanks.

[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence

[jules at gcc dot gnu.org]

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

--- Comment #4 from jules at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #3)
> (In reply to jules from comment #2)
> > Again, please don't change this code under the feet of the refcount overhaul
> > patch!
> 
> But why?  This here is one independent chance.  The big "OpenACC reference
> count overhaul" will then either lose some of its changes, or replace this
> here by something else ('GOMP_MAP_VARS_OPENACC_ENTER_DATA'), but it's an
> incremental step (forward).

It's hard for me to evaluate if the changes are correct, given that I don't
trust the current baseline, mostly.

> > Using the (currently OpenMP-specific) GOMP_MAP_VARS_ENTER_DATA is
> > going to end up mighty confusing from OpenACC-specific code.
> 
> Why do you think so?  It has exactly! the semantics that we need here, for
> this PR.

Is the desired behaviour change just the reference count initialized by
target.c:gomp_map_vars_internal? I suppose that's OK. The danger is if the
semantics needed for OpenMP ever shift away from what we need for OpenACC here.
But I guess this code might not be around for long anyway?

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[bp at alien8 dot de]

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

--- Comment #6 from Boris  ---
Ok, so there was a mix-up between patterns with and without multi-nodes
in your untested fix, which Micha found and fixed, see attached patch.
(otherwise it wouldn't even build a whole kernel).

With it, it fixed the pattern which I reported to properly overwrite
RAX:

  mov%gs:0x28,%rax
  mov%rax,0x10(%rsp)
  mov$0x6,%eax

Other places look good too:

  mov%gs:0x28,%rax
  mov%rax,0xf0(%rsp)
  mov0x120e664(%rip),%rax# 8220f020 


But browsing the code it generated, there are still suboptimal patterns
like:

  mov%gs:0x28,%rax
  mov%rax,0x8(%rsp)
  xor%eax,%eax
  mov0x98(%rdi),%rax

or

  mov%gs:0x28,%rax
  mov%rax,0x80(%rsp)
  xor%eax,%eax
  mov%rbx,%rax

I'm guessing this has to do with the patterns which probably should also
match mem and reg source operand. Or so, just guessing here.

Also, there's more complex stuff like:

  mov%gs:0x28,%rax
  mov%rax,-0x28(%rbp)
  xor%eax,%eax
  add%gs:0x7f00ffc4(%rip),%r13# 12360 
  mov0x80(%rdi),%rax
  test   %rax,%rax

and if that ADD can land under the following MOV, then, one could remove
the XOR too. But maybe that's too complicated to do or it'll become too
ugly...

Oh, and there actually are cases where the XOR *is* needed:

  mov%gs:0x28,%rax
  mov%rax,0x68(%rsp)
  xor%eax,%eax
  rep stos %rax,%es:(%rdi)

Fun.

Thanks!

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[bp at alien8 dot de]

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

--- Comment #7 from Boris  ---
Created attachment 47465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47465&action=edit
Micha's patterns fix

Fix for mix-up between patterns with and without multi-nodes.

[Bug c++/92894] New: "declared using local type 'test01()::X', is used but never defined" during concept satisfaction

[redi at gcc dot gnu.org]

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

Bug ID: 92894
   Summary: "declared using local type 'test01()::X', is used but
never defined" during concept satisfaction
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

The following should compile, because the undefined member function is never
odr-used, only its return type is needed.

#include 

template> Pred>
  constexpr void
  all_of(T*, Pred)
  { }

void
test01()
{
  struct X { };
  X x;
  all_of(&x, [](X&) { return false; });
}

Compiled with -std=gnu++2a and current trunk:

In file included from
/home/jwakely/gcc/10/include/c++/10.0.0/bits/stl_iterator_base_types.h:71,
 from /home/jwakely/gcc/10/include/c++/10.0.0/iterator:61,
 from proj.cc:1:
/home/jwakely/gcc/10/include/c++/10.0.0/bits/iterator_concepts.h:669:40: error:
'std::indirect_result_t<_Proj&, _Iter> std::projected<_Iter,
_Proj>::operator*() const [with _Iter = test01()::X*; _Proj = std::identity;
std::indirect_result_t<_Proj&, _Iter> = test01()::X&]', declared using local
type 'test01()::X', is used but never defined [-fpermissive]
  669 |   indirect_result_t<_Proj&, _Iter> operator*() const; // not
defined
  |^~~~


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Comment 6 seems to be a different issue, so I've reported that as PR 92894