[Bug target/104440] New: nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

Bug ID: 104440
   Summary: nvptx: FAIL: gcc.c-torture/execute/pr53465.c
execution test
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With nvptx target, driver version 510.47.03 and board GT 1030 I run into:
...
FAIL: gcc.c-torture/execute/pr53465.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr53465.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr53465.c   -O3 -g  execution test
...

Passes with nvptx-none-run -O0:
...
$ ( export NVPTX_NONE_RUN="$(pwd -P)/install/bin/nvptx-none-run -O0" ;
./test.sh )
=== gcc Summary ===

# of expected passes12
$
...

I can minimize it at -O1 to:
...
void __attribute__((noinline, noclone))
foo (int y)
{
  int i;
  int c;
  for (i = 0; i < y; i++)
{
  int d = i + 1;
  if (i && d <= c)
__builtin_abort ();
  c = d;
}
}

int
main ()
{
  foo (2);
  return 0;
}
...

I can make the test pass by initializing c with any value (or by doing the
equivalent at ptx level).

Note that the read of c in the loop body only happens in the second iteration,
by which time it's initialized, so the example is valid.

Gcc however translates this at gimple level to:
...
_1 = i != 0;
_2 = d <= c;
_3 = _1 & _2;
...
which does imply a read of c while it's undefined.

We can prevent this by using --param=logical-op-non-short-circuit=0, and that
makes the minimized example pass.  But not the original example.

If we translate the example into cuda, we see that the loop's first iteration
is peeled off, even at -O0.  This has the effect that there are two "d <= c"
tests.  The first one has an undefined input, but is dead code.  The second one
has its inputs defined on both loop entry and backedge.

We could try to report this to nvidia, but I'm not sure they want to fix this.
They've pushed back on examples involving reads from uninitialized regs before,
and looking at what cuda does, it seems they try to ensure this invariant.

Unfortunately, pass_initialize_regs does not insert the required init.

So, it looks like we'll have to fix this in the compiler.

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

 Target||nvptx
   Keywords||testsuite-fail

--- Comment #1 from Tom de Vries  ---
Tentative patch that fixes example:
...
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index 5b26c0f4c7dd..4dc154434853 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -1565,6 +1565,23 @@ nvptx_declare_function_name (FILE *file, const char
*name, cons
t_tree decl)
  fprintf (file, "\t.reg%s ", nvptx_ptx_type_from_mode (mode, true));
  output_reg (file, i, split, -2);
  fprintf (file, ";\n");
+ switch (mode)
+   {
+   case HImode:
+ fprintf (file, "\tmov.u16 %%r%d, 0;\n", i);
+ break;
+   case SImode:
+ fprintf (file, "\tmov.u32 %%r%d, 0;\n", i);
+ break;
+   case DImode:
+ fprintf (file, "\tmov.u64 %%r%d, 0;\n", i);
+ break;
+   case BImode:
+ fprintf (file, "\tsetp.ne.u32 %%r%d,0,0;\n", i);
+ break;
+   default:
+ gcc_unreachable ();
+   }
}
 }

...

[Bug middle-end/103641] [11 regression] Severe compile time regression in SLP vectorize step

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

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

--- Comment #32 from Tamar Christina  ---
> 
> I suppose the slowness is still entirely within synth_mult?

I'm not sure... I can't seem to get the same granularity level that Andrew
got... How did you get that report Andrew?

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

--- Comment #2 from Andrew Pinski  ---
I thought there was another bug that reported a similar issue.

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

--- Comment #3 from Andrew Pinski  ---
>Unfortunately, pass_initialize_regs does not insert the required init.

There is some ideas of getting rid of pass_initialize_regs for GCC 13 too.

[Bug middle-end/103641] [11 regression] Severe compile time regression in SLP vectorize step

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

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

--- Comment #33 from Andrew Pinski  ---
(In reply to Tamar Christina from comment #32)
> I'm not sure... I can't seem to get the same granularity level that Andrew
> got... How did you get that report Andrew?

I was using perf record/perf report to get that report.

[Bug middle-end/103641] [11 regression] Severe compile time regression in SLP vectorize step

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

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

--- Comment #34 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #33)
> (In reply to Tamar Christina from comment #32)
> > I'm not sure... I can't seem to get the same granularity level that Andrew
> > got... How did you get that report Andrew?
> 
> I was using perf record/perf report to get that report.

Ah! doh.. thanks I'll take a look

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

--- Comment #4 from Tom de Vries  ---
(In reply to Andrew Pinski from comment #2)
> I thought there was another bug that reported a similar issue.

You mean related to nvptx, or in general?

FWIW, I do remember looking at this issue before in the nvptx context, but I
couldn't find a related PR.

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > I thought there was another bug that reported a similar issue.
> 
> You mean related to nvptx, or in general?

It was in general. PR 2 is related but not the same issue.


PR 61810 is the one pointing out the problems with init-regs and talking about
removing it.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

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

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

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

https://gcc.gnu.org/g:0af7ef050aed9f678d70d79931ede38374fde863

commit r12-7091-g0af7ef050aed9f678d70d79931ede38374fde863
Author: Jakub Jelinek 
Date:   Tue Feb 8 09:30:17 2022 +0100

libgomp: Fix segfault with posthumous orphan tasks [PR104385]

The following patch fixes crashes with posthumous orphan tasks.
When a parent task finishes, gomp_clear_parent clears the parent
pointers of its children tasks present in the parent->children_queue.
But children that are still waiting for dependencies aren't in that
queue yet, they will be added there only when the sibling they are
waiting for exits.  Unfortunately we were adding those tasks into
the queues with the original task->parent which then causes crashes
because that task is gone and freed.  The following patch fixes that
by clearing the parent field when we schedule such task for running
by adding it into the queues and we know that the sibling task which
is about to finish has NULL parent.

2022-02-08  Jakub Jelinek  

PR libgomp/104385
* task.c (gomp_task_run_post_handle_dependers): If parent is NULL,
clear task->parent.
* testsuite/libgomp.c/pr104385.c: New test.

[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes

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

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

Stafford Horne  changed:

   What|Removed |Added

 CC||shorne at gcc dot gnu.org

--- Comment #8 from Stafford Horne  ---
I am seeing a similar ICE when building glibc.

/home/shorne/work/gnu-toolchain/gcc/libstdc++-v3/src/c++98/localename.cc: In
constructor 'std::locale::_Impl::_Impl(const char*, std::size_t)':
/home/shorne/work/gnu-toolchain/gcc/libstdc++-v3/src/c++98/localename.cc:315:3:
internal compiler error: in df_refs_verify, at df-scan.cc:4003
  315 |   }
  |   ^
0x6ad94e df_refs_verify
/home/shorne/work/gnu-toolchain/gcc/gcc/df-scan.cc:4003
0xc2d286 df_insn_refs_verify
/home/shorne/work/gnu-toolchain/gcc/gcc/df-scan.cc:4086
0xc2eefb df_bb_verify
/home/shorne/work/gnu-toolchain/gcc/gcc/df-scan.cc:4119
0xc2f28f df_scan_verify()
/home/shorne/work/gnu-toolchain/gcc/gcc/df-scan.cc:4240
0xc1bc14 df_verify()
/home/shorne/work/gnu-toolchain/gcc/gcc/df-core.cc:1818
0xc1bc14 df_analyze_1
/home/shorne/work/gnu-toolchain/gcc/gcc/df-core.cc:1214
0x177e1e1 execute_rtl_cprop
/home/shorne/work/gnu-toolchain/gcc/gcc/cprop.cc:1925
0x177e1e1 execute
/home/shorne/work/gnu-toolchain/gcc/gcc/cprop.cc:1964
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

I confirm the patch also fixes things for me.

[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes

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

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

--- Comment #9 from Stafford Horne  ---
Note, I said glibc but of course error I listed was when compiling gcc during
glibc toolchain building.

[Bug driver/104416] 'lto-wrapper' invoking 'mkoffload's with duplicated command-line options

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

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

--- Comment #1 from Richard Biener  ---
Quite probably -Wl,... are in both compiler and linker opts.

[Bug tree-optimization/104420] [12 Regression] Inconsistent checks for X * 0.0 optimization

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-08
   Priority|P3  |P1
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> That's a consequence of -fsanitize=undefined turning on
> -fno-delete-null-pointer-checks (it has to, otherwise -fsanitize=null
> wouldn't work properly).
> And -fno-delete-null-pointer-checks says that variables or functions can be
> placed at NULL address.

Note that's "historical" mostly, the correct way to check whether objects can
be at NULL address is the corresponding address-space hook.  Of course that
leaves us with no way for the user to override what the target thinks (unless
the target provides its own way to do that).

IMHO we can simply take away this option from the user, it was a mistake to
document it that way when it had this effect due to lack of a better way.

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:04b54cc486cc6fcc40380445e500eaf46d7901dc

commit r12-7092-g04b54cc486cc6fcc40380445e500eaf46d7901dc
Author: Tom de Vries 
Date:   Thu Feb 3 14:00:02 2022 +0100

[nvptx] Fix .local atomic regressions

In PR target/104364, two problems were reported:
- in muniform-simt mode, an atom.cas insn is no longer executed in the
  "master lane" only.
- in msoft-stack mode, an __atomic_compare_exchange_n on stack memory is
  translated assuming it accesses local memory, while that's not the case.

Fix these by:
- ensuring that all insns with atomic attribute are also predicable, such
  that the validate_change in nvptx_reorg_uniform_simt will succeed, and
  asserting that it does, and
- guarding the local atomics implementation with a new function
  nvptx_mem_local_p that correctly handles msoft-stack.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-02-04  Tom de Vries  

PR target/104364
* config/nvptx/nvptx-protos.h (nvptx_mem_local_p): Declare.
* config/nvptx/nvptx.cc (nvptx_reorg_uniform_simt): Assert that
change is validated.
(nvptx_mem_local_p): New function.
* config/nvptx/nvptx.md: Use nvptx_mem_local_p.
(define_c_enum "unspecv"): Add UNSPECV_CAS_LOCAL.
(define_insn "atomic_compare_and_swap_1_local"): New
non-atomic, non-predicable define_insn, factored out of ...
(define_insn "atomic_compare_and_swap_1"): ... here.
Make predicable again.
(define_expand "atomic_compare_and_swap"): Use
atomic_compare_and_swap_1_local.

gcc/testsuite/ChangeLog:

2022-02-04  Tom de Vries  

PR target/104364
* gcc.target/nvptx/softstack-2.c: New test.
* gcc.target/nvptx/uniform-simt-1.c: New test.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||mkretz at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Matthias?

[Bug fortran/104428] [12 Regression] ICE in gfc_trans_omp_declare_variant, at fortran/trans-openmp.cc:7648

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |12.0

[Bug fortran/104429] [9/10/11/12 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.5

[Bug fortran/104430] [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.5

[Bug testsuite/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|target  |testsuite
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Tom de Vries  ---
Fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f05cc4fd6f0f52b8629ed6f7c068b5b2de7fa627

[Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics"

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #8 from Tom de Vries  ---
Fixed by "[nvptx] Fix .local atomic regressions".

[Bug middle-end/104436] spurious -Wdangling-pointer assigning local address to a class passed by value

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

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

--- Comment #2 from Richard Biener  ---
DECL_BY_REFERENCE on the PARM_DECL tells you that indeed (not on the fndecl).

[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #1 from Richard Biener  ---
I'm not sure if passes like combine or fwprop would work well after RA but I'm
quite sure that moving prologue/epilogue generation and shrink-wrapping before
RA will not ;)

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
Not having inline atomics already breaks so many things.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

--- Comment #4 from Matthias Kretz (Vir)  ---
I can certainly take a look, but so far my GCC internals experience ends with
the C++ front-end. This ICEs in the pass where front-end trees are transformed
into GIMPLE, right? So it would be a pass that is not shared with the FORTRAN
front-end, which surely doesn't have this problem? But in principle, the two
front-ends would have to produce equivalent GIMPLE for
  C++: __builtin_assoc_barrier(x + y) - y
  FORTRAN: (x + y) - y
right?

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from Richard Biener  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Tom de Vries from comment #4)
> > (In reply to Andrew Pinski from comment #2)
> > > I thought there was another bug that reported a similar issue.
> > 
> > You mean related to nvptx, or in general?
> 
> It was in general. PR 2 is related but not the same issue.
> 
> 
> PR 61810 is the one pointing out the problems with init-regs and talking
> about removing it.

I think there's a bug that ifcombine produces the situation and that
valgrind complains about uninitialized uses.

Note that indeed the init-regs pass should go away.

It's somewhat unfeasible to compute a must-initialized regs so the issue
is really hard to avoid.  But nobody tried yet (it would also come at a cost
of course).  It would definitely inhibit all early short-circuiting on
GENERIC (a good thing, but with a lot of fallout I think).

That said, --param logical-op-non-short-circuit=0 is only a workaround until
you hit ifcombine doing similar transforms.

LOGICAL_OP_NON_SHORT_CIRCUIT is a target macro btw, so you could arrange it
to be zero for nvptx (but that's of course too late since the hosts
LOGICAL_OP_NON_SHORT_CIRCUIT value will be used).

[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Tom de Vries from comment #4)
> > > (In reply to Andrew Pinski from comment #2)
> > > > I thought there was another bug that reported a similar issue.
> > > 
> > > You mean related to nvptx, or in general?
> > 
> > It was in general. PR 2 is related but not the same issue.
> > 
> > 
> > PR 61810 is the one pointing out the problems with init-regs and talking
> > about removing it.
> 
> I think there's a bug that ifcombine produces the situation and that
> valgrind complains about uninitialized uses.
> 
> Note that indeed the init-regs pass should go away.
> 
> It's somewhat unfeasible to compute a must-initialized regs so the issue
> is really hard to avoid.  But nobody tried yet (it would also come at a cost
> of course).  It would definitely inhibit all early short-circuiting on
> GENERIC (a good thing, but with a lot of fallout I think).
> 
> That said, --param logical-op-non-short-circuit=0 is only a workaround until
> you hit ifcombine doing similar transforms.
> 
> LOGICAL_OP_NON_SHORT_CIRCUIT is a target macro btw, so you could arrange it
> to be zero for nvptx (but that's of course too late since the hosts
> LOGICAL_OP_NON_SHORT_CIRCUIT value will be used).

But it would at least prevent ifcombine from doing the transform (ifcombine
only runs on the offload side).

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Matthias Kretz (Vir) from comment #4)
> I can certainly take a look, but so far my GCC internals experience ends
> with the C++ front-end. This ICEs in the pass where front-end trees are
> transformed into GIMPLE, right? So it would be a pass that is not shared
> with the FORTRAN front-end, which surely doesn't have this problem? But in
> principle, the two front-ends would have to produce equivalent GIMPLE for
>   C++: __builtin_assoc_barrier(x + y) - y
>   FORTRAN: (x + y) - y
> right?

The issue is somewhere in the C frontend which uses EXCESS_PRECISION_EXPR
which it fails to properly lower (in C frontend or c-family code) when
the __builtin_assoc_barrier is processed.  I don't know the details there,
Joseph might.  There might be similar issues with C_MAYBE_CONST_EXPR.

[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue

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

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
fwprop should at least stand a chance of working that late.
Was wondering whether reinitialising the loop info would be
a problem, but we already do that later (when computing
alignments).

[Bug c++/104437] Constructor of templated class with full instantiation name rejected in -std=c++2a

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-08
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords|rejects-valid   |accepts-invalid, diagnostic

--- Comment #2 from Jonathan Wakely  ---
Definitely b, this is not valid in C++20.

The inline keyword shouldn't change anything, that should be invalid too.

[Bug c++/104437] Constructor of templated class with full instantiation name rejected in -std=c++2a

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
It's https://wg21.link/cwg2237 and was implemented in r11-532:

  c++: C++20 DR 2237, disallow simple-template-id in cdtor.

  This patch implements DR 2237 which says that a simple-template-id is
  no longer valid as the declarator-id of a constructor or destructor;
  see [diff.cpp17.class]#2.  It is not explicitly stated but out-of-line
  destructors with a simple-template-id are also meant to be ill-formed
  now.  (Out-of-line constructors like that are invalid since DR1435 I
  think.)  This change only applies to C++20; it is not a DR against C++17.

  I'm not crazy about the diagnostic in constructors but ISTM that
  cp_parser_constructor_declarator_p shouldn't print errors.

We already have PR 97202 about to poor diagnostic.

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

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jengelh at inai dot de

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

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

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

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

--- Comment #8 from Jonathan Wakely  ---
PR 104437 pointed out that the invalid constructor is accepted if it has a
redundant inline specifier:

template struct S : Base {
inline S() {}
};

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
(In reply to palmer from comment #3)
> I'm not sure what the right way to go about fixing this is.
> 
> Assuming the inline atomics
>  work out we'll end
> up with libstdc++ using atomics when compiled with newer GCCs and using
> locks when compiled with older GCCs.  Those two implementations aren't
> compatible with each other, as the direct atomics won't respect the lock. 
> That certainly means these two implementations can't coexist, but I'm not
> actually sure if this is an ABI break because I don't know what the ABI
> surface is supposed to be here.

It's definitely an ABI break. You can't pass a std::shared_ptr (or anything
using it, like std::future) between translation units that disagree about the
atomics policy.


> As far as I can tell simple uses cases are safe here, as __exchange_and_add
> isn't inlined outside of the shared library (though I'm not seeing anything
> guaranteeing that, so I may be wrong here).

But user code can use std::shared_ptr and other reference-counted types, and
inline those functions. This isn't just about libstdc++.so itself.


> Doing something like trying to
> mmap a shared_ptr and access from both flavors of the library (maybe one's
> statically linked, for example) would also break, and I could imagine that
> existing in real code.

You don't need to do anything fancy like that to hit the problem. Just two
translation units, one compiled with the old gcc and one compiled with the new.

> It looks like LLVM already has inline atomics, so presumably the same issues
> would arise when mixing libstdc++ libraries compiled with LLVM and GCC.

Yup.

[Bug target/104422] nvptx: for-3.exe fail with driver 390.x

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

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

--- Comment #2 from Tom de Vries  ---
Hmm, I reran on a(In reply to Tom de Vries from comment #0)
> #pragma distribute simd

omp missing ... I need to reproduce this.

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to palmer from comment #3)
> > It looks like LLVM already has inline atomics, so presumably the same issues
> > would arise when mixing libstdc++ libraries compiled with LLVM and GCC.
> 
> Yup.

But not just "when mixing libstdc++ libraries". When mixing pretty much any C++
code that uses libstdc++ headers.

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to palmer from comment #3)
> > > It looks like LLVM already has inline atomics, so presumably the same 
> > > issues
> > > would arise when mixing libstdc++ libraries compiled with LLVM and GCC.
> > 
> > Yup.
> 
> But not just "when mixing libstdc++ libraries". When mixing pretty much any
> C++ code that uses libstdc++ headers.

Oh actually, sorry, that's wrong. The atomic policy for libstdc++ is set at
configure time, based on the GCC building it. We define a macro, and that is
fixed for the lifetime of that libstdc++ installation. So it doesn't matter if
you compile those same headers with Clang, which _could_ use atomic built-ins,
the atomic policy is still decided by the macro which doesn't change after
installation.

So it's only a problem when mixing user code compiled with old and new
libstdc++ headers.

And I've been confusing the _GLIBCXX_ATOMIC_BUILTINS macro with the
_GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro.

If _GLIBCXX_ATOMIC_BUILTINS changes from undefined to 1, I think that's OK. Old
code will still call the non-inline functions in libstdc++.so, but those will
now be consistent with the inline ones that new code is calling.

The problem for std::shared_ptr and similar ref-counts is if
_GLIBCXX_HAVE_ATOMIC_LOCK_POLICY changes from undefined to 1. What is the state
of that macro on RISC-V today?

[Bug libstdc++/87846] std::filesystem::create_directories with a path with a trailing slash does not create any directory

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

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

--- Comment #5 from Jonathan Wakely  ---
N.B. the experimental::filesystem::create_directories function still has this
problem on Windows, but the TS support on Windows is minimal anyway. I'm not
going to fix it at this time.

[Bug c++/104426] -fsanitize=undefined causes constexpr failures

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

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

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

Untested fix.
This stops the implied setting of -fno-delete-null-pointer-checks for
sanitizers and instead introduces an inline function that decides if null
pointer checks should be done or not.  In initializers and C++ manifestly
constant expressions only the -f{,no-}delete-null-pointer-checks from command
line or implied from some DSP targets will be honored (and separate question is
if automatic vars can be assumed to be non-NULL even on those targets), while
outside of those we keep what we've been doing before, i.e. UBSan disables
those optimizations so that -fsanitize=null etc. can continue working
correctly.

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

[schwab--- via Gcc-bugs]

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

--- Comment #8 from Andreas Schwab  ---
It's #undef in 11.

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #4 from Thomas Schwinge  ---
Created attachment 52370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52370&action=edit
'_muldc3-good.o'

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #5 from Thomas Schwinge  ---
Created attachment 52371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52371&action=edit
'_muldc3-bad.o'

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #6 from Thomas Schwinge  ---
Created attachment 52372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52372&action=edit
'_muldc3-WIP.o'

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #7 from Thomas Schwinge  ---
All your three patches combined still doesn't help resolve the problem.
And, what I realized: they don't even change the Nvidia/CUDA Driver reported
"used [...] registers".
Does that mean that the Driver "doesn't care" that we feed into it simple PTX
code, using less PTX registers -- it seems able to do these optimizations all
by itself?  :-O
(At least regarding number of registers used -- I didn't verify the SASS code
generated.)
(Emitting cleaner, "de-cluttered" code in GCC/nvptx is still very much
valuable, of course: if only for our own visual consumption!  ... at least as
long as it doesn't make 'nvptx.md' etc. much more complex...)

For "good" vs. "bad"/"not-so-good" (before vs. after "nvptx: Transition nvptx
backend to STORE_FLAG_VALUE = 1"), the only code generation difference is in
the '__muldc3' function ('nvptx-none/libgcc/_muldc3.o'), and that one is the
only '.extern' dependency aside from the '__reduction_lock' global variable
('nvptx-none/libgcc/reduction.o').
(In the following, working around  "'lto-wrapper'
invoking 'mkoffload's with duplicated command-line options".)

This means, I can conveniently manually create a minimal nvptx 'libgcc.a':

$ cp build-gcc-offload-nvptx-none/nvptx-none/libgcc/_muldc3.o ./
$ rm -f libgcc.a && ar q libgcc.a _muldc3.o
build-gcc-offload-nvptx-none/nvptx-none/libgcc/reduction.o

..., and compile 'libgomp.oacc-c-c++-common/reduction-cplx-dbl.c' with
'-foffload=nvptx-none=-Wl,-L.'.  (Via 'GOMP_DEBUG=1' verified that identical
PTX code is loaded to GPU.)

Then, hand-modify '_muldc3.o', re-create 'libgcc.a', re-compile, re-execute.

Verified that before "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1"
'__muldc3' (attached '_muldc3-good.o') works fine, and after "nvptx: Transition
nvptx backend to STORE_FLAG_VALUE = 1" '__muldc3' (attached '_muldc3-bad.o')
does show the problem originally reported here.

I then gradually morphed the former into the latter (beginning with eliding
simple changes like renumbered registers etc.), until only one last change was
necessary to turn "good" into "bad" (attached '_muldc3-WIP.o'); showing the
"still-good" state:

[...]
@@ -1716,8 +1718,16 @@
 cvt.rn.f64.s32 %r84,%r27;
 copysign.f64 %r61,%r61,%r84;
 .loc 2 1981 32
+// Current/after "nvptx: Transition nvptx backend to STORE_FLAG_VALUE =
1":
+/*
 selp.u32 %r86,1,0,%r138;
 mov.u32 %r85,%r86;
+*/
+// Before "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1":
+set.u32.leu.f64 %r86,%r57,0d7fef;
+neg.s32 %r87,%r86;
+mov.u32 %r85,%r87;
+//
 cvt.u16.u8 %r140,%r85;
 mov.u16 %r89,%r140;
 xor.b16 %r88,%r89,1;
@@ -1770,8 +1780,16 @@
[...]

That is, things go "bad" if we here use the '%r138' that was computed (and
used) earlier in the code, and things are "good" if we re-compute locally. 
Same for '%r139' in the second code block.

(Interestingly, it is tolerated if one of the long-lived registers are used,
but things go "bad" only if *both* are used.  But that's probably just a
distraction?  And again, I have not inspected the actual SASS code, but just
looked at the JIT-time "used [...] registers".)

Do we thus conclude that what happens is that the "nvptx: Transition nvptx
backend to STORE_FLAG_VALUE = 1" changes here enable an "optimization" in GCC
such that values that have previously been compute may be re-used later in the
code, without re-computing them.  But on the flip side, of course, this means
that the values have to kept live in (SASS) registers.  (That's just my theory;
I haven't verified the actual SASS.)

In other words: at least in this case here, it seems preferrable to re-compute
instead of keeping registers occupied.  (But I'm of course not claiming that to
be a simple yes/no decision...)

It seem we're now in territory of tuning CPU vs. GPU code generation?

Certainly, GCC has not seen much care for the latter (GPU code generation).
I mean: verify GCC pass pipeline generally, and parameterization of individual
passes for GPU code generation.
Impossible to get "right", of course, but maybe some heuristics for CPU vs. GPU
may be discovered and implemented?
I'm sure there must be some literature on that topic?

All that complicated by the fact the with the (several different versions of
the) Nvidia/CUDA Driver's PTX -> SASS translation/optimization we have another
moving part...

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

This works for me.

[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

--- Comment #1 from Tom de Vries  ---
One of the dimensions that I test is env var GOMP_NVPTX_JIT, with values:
- -O0, and
- default (using unset GOMP_NVPTX_JIT), which supposedly is -O4.

Looking at f.i. test-case for-3.c, compilation takes 3 minutes and execution a
few seconds.  It would make sense to reuse the executable.

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #8 from Thomas Schwinge  ---
Well.  Here's another problem.

Re-testing things using a "bad" '__muldc3' from a build with your three patches
applied, I notice that my '_muldc3-WIP.o' "old"/replacement code uses a
'set.u32.leu.f64', 'neg.s32', 'mov.u32' sequence.  That works.
However, if I replace that with a localized (its own '.reg .pred %r138_;')
'setp.leu.f64', 'selp.u32' sequence (as per your code generation changes), then
it doesn't in fact work!  Huh.

Will later continue looking into this.

[Bug target/104422] nvptx: for-3.exe fail with driver 390.x

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> While testing libgomp using legacy driver 390.x on a maxwell card, Quadro
> K620 I ran into a for-3.exe execution failure.

Reproduced with 390.147 driver on pascal card, GT 1030, gcc build from master
commit 73f4a989b7f ("[nvptx] Fix 'main (int argc)' compilation").

Reproduces both with and without GOMP_NVPTX_JIT=-O0.

[Bug libstdc++/87846] std::filesystem::create_directories with a path with a trailing slash does not create any directory

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

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

--- Comment #6 from Jonathan Wakely  ---
Actually no, it's fine, the relevant test fails because exists("foo/") fails,
due to PR 1, and *that* isn't fixed for the experimental TS.

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

--- Comment #9 from Jonathan Wakely  ---
Thanks. Changing that will cause an ABI break in the headers (and so affect
user code, not just the libstdc++.so library).

Clang and GCC will still be compatible, because the macros are still set once
by configure when building libstdc++.

One solution would be to override the checks in libstdc++-v3/acinclude.m4 so
that _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY is also #undef for RISC-V, even after the
atomic built-ins are supported. That would preserve the ABI, but would mean
ref-counting in libstdc++ is sub-optimal.

Or let the default change, and vendors who want to preserve the old ABI can
configure with --with-libstdcxx-lock-policy=mutex to override the default.

[Bug target/104283] nvptx-none needs more user friendly architecture handling

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r12-7098-gdecde11183bdccc46587d6614b75f3d56a2f2e4a
Author: Tom de Vries 
Date:   Fri Feb 4 08:53:52 2022 +0100

[nvptx] Choose -mptx default based on -misa

While testing with driver version 390.147 I ran into the problem that it
doesn't support ptx isa version 6.3 (the new default), only 6.1.

Furthermore, using the -mptx option is a bit user-unfriendly.

Say we want to compile for sm_80.  We can use -misa=sm_80 to specify that,
but
then run into errors because the default ptx version is 6.3, which doesn't
support sm_80 yet.

Address both these issues by:
- picking a default -mptx based on the active -misa, and
- ensuring that the default -mptx is at least 6.0 (instead
  of 6.3).

Also add an error in case of incompatible options like
"-misa=sm_80 -mptx=6.3":
...
cc1: error: PTX version (-mptx) needs to be at least 7.0 to support \
  selected -misa (sm_80)
...

Tested on x86_64-linux with nvptx accelerator.

gcc/ChangeLog:

2022-02-08  Tom de Vries  

PR target/104283
* config/nvptx/nvptx-opts.h (enum ptx_version): Add PTX_VERSION_3_0
and PTX_VERSION_4_2.
* config/nvptx/nvptx.cc (first_ptx_version_supporting_sm)
(default_ptx_version_option, ptx_version_to_string)
(sm_version_to_string, handle_ptx_version_option): New function.
(nvptx_option_override): Call handle_ptx_version_option.
(nvptx_file_start): Use ptx_version_to_string and
sm_version_to_string.
* config/nvptx/nvptx.md (define_insn "nvptx_shuffle")
(define_insn "nvptx_vote_ballot"): Use TARGET_PTX_6_0.
* config/nvptx/nvptx.opt (mptx): Remove 'Init'.

[Bug target/104283] nvptx-none needs more user friendly architecture handling

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #2 from Tom de Vries  ---
Fixed by commit "[nvptx] Choose -mptx default based on -misa".

[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 52374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52374&action=edit
gcc12-pr102140.patch

Untested fix.

[Bug target/101929] r12-2549 regress x264_r by 4% on CLX.

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
The rev. was reverted, see PR98138 for vectorization of this kernel.

[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link

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

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

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

https://gcc.gnu.org/g:5750952bec1e632d1f804f4a1bed2f74c0f3b189

commit r12-7099-g5750952bec1e632d1f804f4a1bed2f74c0f3b189
Author: Jonathan Wakely 
Date:   Mon Feb 7 23:36:47 2022 +

libstdc++: Fix filesystem::remove_all for Windows [PR104161]

The recursive_directory_iterator::__erase member was failing for
Windows, because the entry._M_type value is always file_type::none
(because _Dir_base::advance doesn't populate it for Windows) and
top.unlink uses fs::remove which sets an error using the
system_category. That meant that ec.value() was a Windows error code and
not an errno value, so the comparisons to EPERM and EISDIR failed.
Instead of depending on a specific Windows error code for attempting to
remove a directory, just use directory_entry::refresh() to query the
type first. This doesn't avoid the TOCTTOU races with directory
symlinks, but we can't avoid them on Windows without openat and
unlinkat, and creating symlinks requires admin privs on Windows anyway.

This also fixes the fs::remove_all(const path&) overload, which was
supposed to use the same logic as the other overload, but I forgot to
change it before my previous commit.

libstdc++-v3/ChangeLog:

PR libstdc++/104161
* src/c++17/fs_dir.cc (fs::recursive_directory_iterator::__erase):
[i_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Refresh entry._M_type member,
instead of checking for errno values indicating a directory.
* src/c++17/fs_ops.cc (fs::remove_all(const path&)): Use similar
logic to non-throwing overload.
(fs::remove_all(const path&, error_code&)): Add comments.
* src/filesystem/ops-common.h: Likewise.

[Bug c++/103706] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503

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

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

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

https://gcc.gnu.org/g:34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964

commit r12-7101-g34ba3d9a2bf72742b1c150a2dd17d10e3e3f0964
Author: Patrick Palka 
Date:   Tue Feb 8 08:46:13 2022 -0500

c++: constrained auto in lambda using outer tparms [PR103706]

Here we're crashing during satisfaction of the lambda's placeholder type
constraints because the constraints depend on the template arguments
from the enclosing scope, which aren't part of the lambda's DECL_TI_ARGS.

This patch fixes this by making do_auto_deduction consider the
"regenerating" template arguments of a lambda for satisfaction,
mirroring what's done in satisfy_declaration_constraints.

PR c++/103706

gcc/cp/ChangeLog:

* constraint.cc (satisfy_declaration_constraints): Use
lambda_regenerating_args instead.
* cp-tree.h (lambda_regenerating_args): Declare.
* pt.cc (lambda_regenerating_args): Define, split out from
satisfy_declaration_constraints.
(do_auto_deduction): Use lambda_regenerating_args to obtain the
full set of outer template arguments for satisfaction when
inside a lambda.

gcc/testsuite/ChangeLog:

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

[Bug c++/103706] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503

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

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

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

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

commit r12-7102-gdb5f1c17031ad8a898d77121f1e0e0141306e22a
Author: Patrick Palka 
Date:   Tue Feb 8 08:46:32 2022 -0500

c++: lambda in pack expansion using pack in constraint [PR103706]

Here when expanding the pack expansion pattern containing a constrained
lambda, the template argument for each Ts is an ARGUMENT_PACK_SELECT,
which we store inside the lambda's LAMBDA_EXPR_REGEN_INFO.  Then during
satisfaction of the lambda's constraint C the satisfaction cache
uses this argument as part of the key to the corresponding sat_entry, but
iterative_hash_template_arg and template_args_equal deliberately don't
handle ARGUMENT_PACK_SELECT.

Since it's wrong to preserve ARGUMENT_PACK_SELECT inside a hash table
due to its instability (as documented in iterative_hash_template_arg),
this patch helps make sure the satisfaction cache doesn't see such trees
by resolving ARGUMENT_PACK_SELECT arguments before adding them to
LAMBDA_EXPR_REGEN_INFO.

PR c++/103706

gcc/cp/ChangeLog:

* pt.cc (preserve_args): New function.
(tsubst_lambda_expr): Use it when setting LAMBDA_EXPR_REGEN_INFO.

gcc/testsuite/ChangeLog:

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

[Bug c++/103706] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE: |[11 Regression] ICE: tree
   |tree check: accessed elt 1  |check: accessed elt 1 of
   |of 'tree_vec' with 0 elts   |'tree_vec' with 0 elts in
   |in hash, at |hash, at
   |cp/constraint.cc:2503   |cp/constraint.cc:2503

--- Comment #8 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug c++/103706] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2503

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/104441] New: [12 Regression] vzeroupper is placed at the wrong place

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

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

Bug ID: 104441
   Summary: [12 Regression] vzeroupper is placed at the wrong
place
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, lili.cui at intel dot com
  Target Milestone: ---
Target: x86-64

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

When compiled with -march=skylake -Wno-attributes, GCC 12 generated:

.L3:
vmovd   (%rdi), %xmm0
vmovd   (%rdi,%r13), %xmm1
vpinsrd $1, (%rdi,%r12), %xmm1, %xmm1
vpinsrd $1, (%rdi,%rsi), %xmm0, %xmm0
vmovd   (%rax,%rbx), %xmm2
vinserti128 $0x1, %xmm1, %ymm0, %ymm0
vmovd   (%rax), %xmm1
vpinsrd $1, (%rax,%rcx), %xmm1, %xmm1
vpinsrd $1, (%rax,%r11), %xmm2, %xmm2
addl$4, %edx
vinserti128 $0x1, %xmm2, %ymm1, %ymm1
vpsadbw %ymm1, %ymm0, %ymm0
vpaddd  %ymm0, %ymm3, %ymm0
vmovdqa %ymm0, %ymm3
addq%r10, %rdi
addq%r9, %rax
cmpl%r8d, %edx
jb  .L3
vzeroupper   <<< Clear upper 128bits.
popq%rbx
popq%r12
vextracti128$0x1, %ymm3, %xmm3  << The upper 128bits of YMM3 are
used.
vpaddd  %xmm3, %xmm0, %xmm0
popq%r13
vmovd   %xmm0, %eax
popq%rbp

This is triggered by

commit 9775e465c1fbfc32656de77c618c61acf5bd905d
Author: H.J. Lu 
Date:   Tue Jul 27 07:46:04 2021 -0700

x86: Don't set AVX_U128_DIRTY when zeroing YMM/ZMM register

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

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

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

--- Comment #11 from Jakub Jelinek  ---
Patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589875.html
and deferred for gcc 13.

[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
   Last reconfirmed||2022-02-08

[Bug c++/104410] [11/12 Regression] Internal error using default-initialized constexpr bool in requires clause

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

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

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

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

commit r12-7103-g7ff201d85fad11ba6365a5612124b75b385a97bd
Author: Patrick Palka 
Date:   Tue Feb 8 09:11:29 2022 -0500

c++: satisfaction value of type const bool [PR104410]

Here constant evaluation of the atomic constraint use_func_v
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool.  So let's just relax the
assert to accept cv-qualified bool.

PR c++/104410

gcc/cp/ChangeLog:

* constraint.cc (satisfaction_value): Relax assert to accept
cv-qualified bool.

gcc/testsuite/ChangeLog:

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

[Bug c++/80951] Deducing noexcept only works when also deducing something else

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

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

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

https://gcc.gnu.org/g:676e987b850a7352ece750a8f3a1ac5dae6b3627

commit r12-7104-g676e987b850a7352ece750a8f3a1ac5dae6b3627
Author: Patrick Palka 
Date:   Tue Feb 8 09:11:31 2022 -0500

c++: deducing only from noexcept-spec [PR80951]

The "fail-fast" predicate uses_deducible_template_parms used by
unify_one_argument is neglecting to look inside the noexcept-spec of a
function type.  This causes deduction to spuriously fail whenever the
noexcept-spec is the only part of the type which contains a deducible
template parameter.

PR c++/80951

gcc/cp/ChangeLog:

* pt.cc (uses_deducible_template_parms): Consider the
noexcept-spec of a function type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/noexcept-type25.C: New test.

[Bug c++/80951] Deducing noexcept only works when also deducing something else

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/104410] [11 Regression] Internal error using default-initialized constexpr bool in requires clause

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12 Regression] Internal |[11 Regression] Internal
   |error using |error using
   |default-initialized |default-initialized
   |constexpr bool in requires  |constexpr bool in requires
   |clause  |clause

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug libgomp/66005] libgomp make check time is excessive

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
First, ACK, and "sorry".


(As has been discussed in the past) we cannot just enable the standard
GCC/DejaGnu parallel testing for the libgomp testsuite, because a lot of the
test cases internally use parallelism, so we'd heavily oversubscribe system
resources.

However, there is one thing that I think we may do, and I'm expecting that to
help a lot: parallelize *all* compilation, while just allowing for *one*
execution test job slot.  That will require some GCC DejaGnu test harness
hackery which I've not yet gotten to look into.  That is, enable the usual
GCC/DejaGnu parallel testing, but also have some kind of mutex for the
execution test invocation.  This has to play nicely with DejaGnu timeout
handling, etc.

[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||openacc, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-08
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66005

--- Comment #2 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #0)
> I noticed that a lot of time is spent running libgomp tests that do not use 
> the accelerator, and which are not needed for my purposes.

We can assume that effectively all OpenACC test cases use any available GPUs.

For OpenMP test cases indeed there is no clear answer.

> It would be nice if libgomp provided a mode to run only tests that use the 
> accelerator, to drive down the test-board.sh execution time.

We may add a knob to skip the OpenACC '-foffload=disable' testing.

For OpenMP test cases, we'd either have to manually mark them up (error prone
and generally ugly), or scan the source file(s) (error prone and generally
ugly), or use some kind of marker that gets set during compilation if any
offloading code has been generated.

Regarding the latter, you also reported:

(In reply to Tom de Vries from comment #1)
> Looking at f.i. test-case for-3.c, compilation takes 3 minutes

We should be able to at least mitigate that problem via my PR66005 idea.

> and execution a few seconds.  It would make sense to reuse the executable.

I suppose you mean re-use across what currently are independent libgomp
testsuite invocations:

(In reply to Tom de Vries from comment #1)
> One of the dimensions that I test is env var GOMP_NVPTX_JIT, with values:
> - -O0, and
> - default (using unset GOMP_NVPTX_JIT), which supposedly is -O4.

For OpenACC, we'd hook that into the existing looping over any available GPUs
(plus host fallback).

For OpenMP, there currently is no such looping.

If paralellizing compilation via PR66005 is not sufficient then indeed we have
to think about switching OpenACC testing to a mode where only once we do
compile (without any '-foffload=[...]), and then loop over 'ACC_DEVICE_TYPE'
etc.

[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place

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

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

--- Comment #1 from H.J. Lu  ---
ix86_check_avx_upper_register doesn't check

(vec_select:V2DI (reg/v:V4DI 23 xmm3 [orig:91 ymm ] [91])
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
]))

[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue

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

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

--- Comment #3 from Segher Boessenkool  ---
Also combine could work that late in principle: it can deal with hard
registers, after all.  But it would be a terrible idea.  A single combine
pass is expensive enough, we don't want to run it N times.  Also, if you
run combine more than once, you get odd effects, mostly because the results
of splitters are combined back again.

After *logue insertion all the simpler (more local!) optimisations are still
run (DSE, DCE, if conversion, const prop, peep).

It is unclear why the CFG wasn't straightened out here.  Is the bb commented
as "asm" actually asm?  Then GCC will not see it is very cheap/small, yeah.

[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #2)
> For OpenMP test cases, we'd either have to manually mark them up (error
> prone and generally ugly), or scan the source file(s) (error prone and
> generally ugly), or use some kind of marker that gets set during compilation
> if any offloading code has been generated.

I was thinking along the lines of already existing markers in the exec:
...
$ nm for-3.exe | grep offload
 U GOMP_offload_register_ver
 U GOMP_offload_unregister_ver
00a59718 D __offload_funcs_end
00a58a58 d .offload_func_table
00a58a58 D __offload_func_table
00a5ca38 D __offload_vars_end
00a59718 d .offload_var_table
00a59718 D __offload_var_table
...

Say, if the exec doesn't have a __offload_func_table, it can be skipped.

This would allow to do one test run, where you run all the tests, and generate
the offloading tests list, and then several more runs (using the same sources,
so the list is still up to date) where you just do the accelerator tests.

[Bug c++/104425] SFINAE hard error on failed resolution of << for defined class in namespace

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

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

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

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

commit r12-7109-gbe862bf1f612c884597ace4cbfdec972a0bf0eef
Author: Patrick Palka 
Date:   Tue Feb 8 09:47:34 2022 -0500

c++: Add testcase for already fixed PR [PR104425]

Fixed by r12-1829.

PR c++/104425

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization10.C: New test.

[Bug c++/104425] SFINAE hard error on failed resolution of << for defined class in namespace

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
   Keywords|needs-bisection |
   Target Milestone|--- |12.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96204
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed by r12-1829.

[Bug c++/104411] Cannot capture by reference using braced initializer

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Patrick Palka  ---
dup

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

[Bug c++/95069] Capture by reference cannot use list-initalization

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||oliver.rosten at googlemail 
dot co
   ||m

--- Comment #3 from Patrick Palka  ---
*** Bug 104411 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Andrew Macleod
:

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

commit r11-9543-ged35d4205e8c139d27d3d47c528aaa9f82f0ac1b
Author: Andrew MacLeod 
Date:   Mon Jan 31 11:37:16 2022 -0500

Range on entry should only check dominators for non-null.

Range-on-entry checks should no check the state of non-null within the
current
block.   If dominators are present, use the dominator.

PR tree-optimization/104288
gcc/
* gimple-range-cache.cc (ssa_range_in_bb): Only use non-null from
the
dominator entry ranges.
* gimple-range.cc (gimple_ranger::range_of_expr): Ditto.
gcc/testsuite/
* gcc.dg/pr104288.c: New.

[Bug target/104345] [12 Regression] "nvptx: Transition nvptx backend to STORE_FLAG_VALUE = 1" patch made some code generation worse

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

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

--- Comment #9 from Thomas Schwinge  ---
OK!  Putting your "nvptx: Add support for 64-bit mul.hi (and other)
instructions" on top, that considerably changes (simplifies!) the generated
'__muldc3' PTX code; the regression disappears.  :-)

(I have, so far, only manually tested
'libgomp.oacc-c-c++-common/reduction-cplx-dbl.c'.  I'll report later in the
unlikely case that any other/new issues should appear.)


(And, will later test your "nvptx: Tweak constraints on copysign instructions"
on top, too.)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #8 from Hannes Hauswedell  ---
Hi, I wanted to ask politely whether you have discussed this issue and came to
a conclusion?

It if it is still being discussed, can you at least "confirm" this issue and
put it on some list for the next patch-level releases? Otherwise, it will be
forgotten. And the longer we wait with a decision, the less likely it will be
that it can be backported.

Thank you!

[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place

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

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

--- Comment #2 from H.J. Lu  ---
Created attachment 52376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52376&action=edit
A patch

I am testing this.

[Bug target/104422] nvptx: for-3.exe fail with driver 390.x

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

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

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Reproduces both with and without GOMP_NVPTX_JIT=-O0.

Pff, that was an artefact of having bumped the default ptx isa to 6.3.

So, let's try again ...

Reproduced with 390.147 driver on pascal card, GT 1030, gcc build from master
commit "[nvptx] Unbreak build, add PTX_ISA_SM70".  Doens't reproduce with
GOMP_NVPTX_JIT=-O0.

Minimal test-case:
...
#define N 1500

#pragma omp declare target
int a[N];

__attribute__((noinline, noclone)) void
f3_ds_normal ()
{
  volatile int s3 = 1;
#pragma omp distribute simd 
  for (int i = 0; i < N; i += s3)
a[i] += 7;
}
#pragma omp end declare target

int
main ()
{
  for (int i = 0; i < N; i++)
a[i] = i - 29;

#pragma omp target update to(a)

#pragma omp target teams
  f3_ds_normal ();

#pragma omp target update from(a)

  for (int i = 0; i < N; i++)
if (a[i] != i - 22)
  __builtin_abort ();

  return 0;
}
...

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Hannes Hauswedell from comment #8)
> Hi, I wanted to ask politely whether you have discussed this issue and came
> to a conclusion?

No, because the current priority is gcc 12.

[Bug libstdc++/104442] New: atomic::wait incorrectly loops in case of spurious notification when __waiter is shared

[poulhies at adacore dot com via Gcc-bugs]

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

Bug ID: 104442
   Summary: atomic::wait incorrectly loops in case of spurious
notification when __waiter is shared
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: poulhies at adacore dot com
  Target Milestone: ---

Created attachment 52377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52377&action=edit
patch fixing the issue

We are observing a deadlock in 100334.cc on vxworks.

This is caused by :

template
  void
  _M_do_wait_v(_Tp __old, _ValFn __vfn)
  {
__platform_wait_t __val;
if (__base_type::_M_do_spin_v(__old, __vfn, __val))
   return;

do
  {
__base_type::_M_w._M_do_wait(__base_type::_M_addr, __val);
  }
while (__detail::__atomic_compare(__old, __vfn()));
  }

When several thread are sharing the waiter (as in 100334.cc), the notify_one()
will wake all threads blocked in the _M_do_wait() above. The thread whose data
changed exits the loop correctly, but the others are looping back in
_M_do_wait() with the same arguments. As the waiter's value has changed since
the previous iteration but not __val, the method directly returns (as if it had
detected a notification) and the loop continues.

On GNU/Linux, the test is PASS because the main thread is still scheduled and
will do a .store(1) on all atoms, unblocking all the busy-waiting thread (but
the thread doing a busywait can still be observed with gdb).

On vxworks, the main thread is never scheduled again (I think there's no
preemption at the same prio level) and the busy-wait starves the system.

The attached patch is a possible fix. It moves the spin() call inside the loop,
updating the __val at every iteration. A better fix is probably possible but
may require some refactoring (a bit more than I'm comfortable with).

I've checked the patch for regression on gcc-master for x86_64. It also fixes
the test on gcc-11 for aarch64-vxworks7.

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |10.4
   Last reconfirmed||2022-02-08

--- Comment #10 from Jonathan Wakely  ---
I think we should backport it except for the removal of the default
constructors for {back_,front_,}insert_iterator, ostream_iterator and
basic_istream_view. If we keep those default constructible on the release
branches I think the chance of breaking any code is minimal.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jonathan.wright at arm dot com,
   ||wirkus at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Note, -fpack-struct is an ABI changing option, so it should be used with extra
care.
Anyway, I guess the backends (both aarch64 and arm) need to decide what exactly
they want.
Either for these internal lang_hooks.types.simulate_record_decl created types
temporarily rest to default the -fpack-struct stuff, or allow them to have
smaller alignment, or increase the alignment afterwards.
Because those
  tree t = lang_hooks.types.simulate_record_decl (input_location,
  tuple_type_name,
  make_array_slice (&field,
1));
  gcc_assert (TYPE_MODE_RAW (t) == TYPE_MODE (t)
  && TYPE_ALIGN (t) == alignment);
and
  ls64_arm_data_t = lang_hooks.types.simulate_record_decl (input_location,
 tuple_type_name,
 make_array_slice (&field, 1));

  gcc_assert (TYPE_MODE (ls64_arm_data_t) == V8DImode);
  gcc_assert (TYPE_MODE_RAW (ls64_arm_data_t) == TYPE_MODE (ls64_arm_data_t));
  gcc_assert (TYPE_ALIGN (ls64_arm_data_t) == 64);
assertions otherwise of course fail.
Now, seems the arm backend actually doesn't assert this.
Note, when those types were defined in arm_neon.h, -fpack-struct usedd to be
applied to those.

The changes were done in r12-4907-g8197ab94b47c814632d758dd36a121ad4114ff70
and r12-5955-gfdcddba8f29ea3878851b8b4cd37d0fd3476d3bf

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[svante.signell at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Svante Signell  ---
With the proposed patches everything builds fine. The only issue to resolve is
how to make sure libatomic and libbacktrace builds in build/i686-gnu before
libgo/gotools.

Any ideas? I'm not sure if this is a Debian or upstream problem.

After a failed build I did:
make -C build configure-target-libatomic
make -C build/i686-gnu/libatomic/

make -C build configure-target-libbacktrace
make -C build/i686-gnu/libbacktrace/

debian/rules build
fakeroot debian/rules binary
All debs built fine.

Additionally make -C build/i686-gnu/libgo check reports in
build/i686-gnu/libgo/libgo.sum

=== libgo Summary ===

# of expected passes181
# of unexpected failures9

Thanks!

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
Makefile.def already has the required dependencies:

dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
dependencies = { module=all-target-libgo; on=all-target-libffi; };
dependencies = { module=all-target-libgo; on=all-target-libatomic; };

[Bug c++/104410] [11 Regression] Internal error using default-initialized constexpr bool in requires clause

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:411db3b4cf8655ecb5b7d666318546c73f2d156b

commit r11-9544-g411db3b4cf8655ecb5b7d666318546c73f2d156b
Author: Patrick Palka 
Date:   Tue Feb 8 09:11:29 2022 -0500

c++: satisfaction value of type const bool [PR104410]

Here constant evaluation of the atomic constraint use_func_v
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool.  So let's just relax the
assert to accept cv-qualified bool.

PR c++/104410

gcc/cp/ChangeLog:

* constraint.cc (satisfaction_value): Relax assert to accept
cv-qualified bool.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 7ff201d85fad11ba6365a5612124b75b385a97bd)

[Bug libstdc++/104443] New: common_iterator::operator-> is not correctly implemented

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 104443
   Summary: common_iterator::operator-> is not correctly
implemented
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

When the adapted iterator type I is a pointer type or has operator->,
std::common_iterator::operator-> is required to return the iterator by
reference ([common.iter.access]/(5.1), and std::get for std::variant always
returns reference).

However, currently libstdc++'s implementation returns the iterator by value in
these cases, because "return _M_it;" is used and the return type is specified
by decltype(auto). "return (_M_it);" should be used instead.

Currently only libc++ correctly implements both common_iterator::operator-> and iterator_traits>::pointer. See
https://gcc.godbolt.org/z/1Tn5cGrhh.

[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-08

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[ian at airs dot com via Gcc-bugs]

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

--- Comment #5 from Ian Lance Taylor  ---
> The only issue to resolve is how to make sure libatomic and libbacktrace 
> builds in build/i686-gnu before libgo/gotools.

That question doesn't sound right.  The gotools are built for the target.  They
shouldn't depend on build/i686-gnu, which is built for the host.  The gotools
should depend on the target libatomic and the target libbacktrace, and they do.

What problem are you trying to solve?

[Bug c++/104410] [11 Regression] Internal error using default-initialized constexpr bool in requires clause

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 11.3/12.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

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

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

--- Comment #6 from Jakub Jelinek  ---
In this particular case it is:
(note 38 19 20 (var_location p (unspec:DI [
(const_int 0 [0])
] UNSPEC_TLS)) NOTE_INSN_VAR_LOCATION)
where p's value should be equal to that __builtin_thread_pointer () aka the
base of the TLS region.

I wonder if it could be represented as DW_OP_lit0 DW_OP_form_tls_address,
one would need to test that in debugger.
And if it works, figure out some target independent way or perhaps a target
hook that would propagate this case from the target dependent UNSPEC_TLS to
dwarf2out.cc that it could emit such location.

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

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

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

--- Comment #10 from palmer at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > (In reply to Jonathan Wakely from comment #5)
> > > (In reply to palmer from comment #3)
> > > > It looks like LLVM already has inline atomics, so presumably the same 
> > > > issues
> > > > would arise when mixing libstdc++ libraries compiled with LLVM and GCC.
> > > 
> > > Yup.
> > 
> > But not just "when mixing libstdc++ libraries". When mixing pretty much any
> > C++ code that uses libstdc++ headers.
> 
> Oh actually, sorry, that's wrong. The atomic policy for libstdc++ is set at
> configure time, based on the GCC building it. We define a macro, and that is
> fixed for the lifetime of that libstdc++ installation. So it doesn't matter
> if you compile those same headers with Clang, which _could_ use atomic
> built-ins, the atomic policy is still decided by the macro which doesn't
> change after installation.
> 
> So it's only a problem when mixing user code compiled with old and new
> libstdc++ headers.
> 
> And I've been confusing the _GLIBCXX_ATOMIC_BUILTINS macro with the
> _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro.

I hadn't even noticed the _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro, thanks!

> If _GLIBCXX_ATOMIC_BUILTINS changes from undefined to 1, I think that's OK.
> Old code will still call the non-inline functions in libstdc++.so, but those
> will now be consistent with the inline ones that new code is calling.

My specific worry was users mixing in routines from two different versions of
libstdc++: for example, maybe there's some statically linked executable that
puts a shared pointer into a mmap'd region, which it then expects to work when 

After signing off last night I realized that none of that would work anyway,
though, as even with the same library on both ends users would end up with a
different mutex and thus races.  So I think that one isn't worth worrying
about.

[snip, I'm mixing two replies here]

> Thanks. Changing that will cause an ABI break in the headers (and so affect
> user code, not just the libstdc++.so library).
> 
> Clang and GCC will still be compatible, because the macros are still set
> once by configure when building libstdc++.

>From my reading of this, GCC and clang will build libstdc++ binaries with
incompatible ABIs: clang has inline atomics, so the 2-byte CAS check will
succeed and we'll end up with libstdcxx_atomic_lock_policy=atomic .  I don't
actually have a clang build around to test that with, though, and I'm not sure
if folks are shipping clang-built libstdc++ anywhere (and if so, are expecting
it to be compatible with a GCC-built libstdc++).

> One solution would be to override the checks in libstdc++-v3/acinclude.m4 so
> that _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY is also #undef for RISC-V, even after
> the atomic built-ins are supported. That would preserve the ABI, but would
> mean ref-counting in libstdc++ is sub-optimal.
> 
> Or let the default change, and vendors who want to preserve the old ABI can
> configure with --with-libstdcxx-lock-policy=mutex to override the default.

I guess I'm not really sure here: normally I'd say we're stuck with the default
being ABI compatible, but I don't know the rules in libstdc++.  I'm assuming
that forcing the default to be mutex could still allow users who want atomic to
configure with --with-libstdcxx-lock-policy=atomic, so at least there's a path
forward.  IIUC users will get link errors when moving between the two flavors
(the explicit template instantiations will have different integer values), so
at least there's a way for distros to make sure they've re-built everything if
they want to change.

I could also imagine a much more complicated third option: essentially
upgrading the mutex to an RW-like lock and allowing the atomic-based routines
to proceed concurrently.  I poked around the locking code a bit have no idea if
this would even be possible, it's all complicated enough that it seems like at
best a bad idea.

I guess this is really a distro sort of question, but I'd lean towards forcing
the default to mutex on RISC-V, thus keeping ABI compatibility.  Then at least
the distros can pick if they want to have a flag day around this.

[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
It could be e.g. done by having the targetm.const_not_ok_for_debug_p target
hook not return true for the UNSPEC_TLS case and have some new target hook that
would handle emitting debug info for an UNSPEC.

Or a way to just quiet the note (I'll repeat it is -fchecking only) would be to
use as the operand of UNSPEC_TLS not const0_rtx as it does, but some magic
SYMBOL_REF with SYMBOL_REF_TLS_MODEL non-zero on it.  Say like:
--- gcc/config/aarch64/aarch64.md.jj2022-01-11 23:11:21.682300103 +0100
+++ gcc/config/aarch64/aarch64.md   2022-02-08 19:51:00.581676457 +0100
@@ -6833,7 +6833,8 @@ (define_insn "ldr_got_tiny_sidi"

 (define_insn "aarch64_load_tp_hard"
   [(set (match_operand:DI 0 "register_operand" "=r")
-   (unspec:DI [(const_int 0)] UNSPEC_TLS))]
+   (unspec:DI [(match_operand 1 "aarch64_tls_le_symref" "S")]
+  UNSPEC_TLS))]
   ""
   "mrs\\t%0, tpidr_el0"
   [(set_attr "type" "mrs")]
--- gcc/config/aarch64/aarch64.cc.jj2022-02-04 14:36:54.262615676 +0100
+++ gcc/config/aarch64/aarch64.cc   2022-02-08 19:46:58.206051731 +0100
@@ -18474,7 +18474,9 @@ aarch64_load_tp (rtx target)
 target = gen_reg_rtx (Pmode);

   /* Can return in any reg.  */
-  emit_insn (gen_aarch64_load_tp_hard (target));
+  rtx sym = gen_rtx_SYMBOL_REF (Pmode, "");
+  SYMBOL_REF_FLAGS (sym) = TLS_MODEL_LOCAL_EXEC << SYMBOL_FLAG_TLS_SHIFT;
+  emit_insn (gen_aarch64_load_tp_hard (target, sym));
   return target;
 }

[Bug c++/104418] [C++17+] Error inheriting base class constructors by using-declaration

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Fedor Chelnokov  ---
Thanks. I submitted Clang bug:
https://github.com/llvm/llvm-project/issues/53653

[Bug middle-end/104285] openmp offload linker issue

[xw111luoye at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ye Luo  ---
Here is a minimal reproducer.
https://github.com/ye-luo/openmp-target/tree/master/tests/linking/two_identical_templates

$ g++ -fopenmp -foffload=nvptx-none -O3 -c test_a.cpp 
$ g++ -fopenmp -foffload=nvptx-none -c test_a.cpp 
$ g++ -fopenmp -foffload=nvptx-none -c test_b.cpp 
$ g++ -fopenmp -foffload=nvptx-none  main.cpp test_a.o test_b.o 
lto1: fatal error: test_a.o: section _Z8test_mapIfEvv$_omp_fn$0.2375 is missing
compilation terminated.
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1
exit status
compilation terminated.
lto-wrapper: fatal error:
/soft/gcc/gcc-12-dev-2022-02-08/libexec/gcc/x86_64-pc-linux-gnu/12.0.1//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

$ g++ -fopenmp -foffload=disable -c test_a.cpp
$ g++ -fopenmp -foffload=disable -c test_b.cpp
g++ -fopenmp -foffload=disable main.cpp test_a.o test_b.o

Using be862bf1f612c884597ace4cbfdec972a0bf0eef from master

[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

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

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

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

https://gcc.gnu.org/g:0c3e491a4e5ae74bfbed6d167d403d262b5a4adc

commit r12-7111-g0c3e491a4e5ae74bfbed6d167d403d262b5a4adc
Author: Jakub Jelinek 
Date:   Tue Feb 8 20:14:30 2022 +0100

rs6000: Fix up vspltis_shifted [PR102140]

The following testcase ICEs, because
(const_vector:V4SI [
(const_int 0 [0]) repeated x3
(const_int -2147483648 [0x8000])
])
is recognized as valid easy_vector_constant in between split1 pass and
end of RA.
The problem is that such constants need to be split, and the only
splitter for that is:
(define_split
  [(set (match_operand:VM 0 "altivec_register_operand")
(match_operand:VM 1 "easy_vector_constant_vsldoi"))]
  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode) && can_create_pseudo_p ()"
There is only a single splitting pass before RA, so after that finishes,
if something gets matched in between that and end of RA (after that
can_create_pseudo_p () would be no longer true), it will never be
successfully split and we ICE at final.cc time or earlier.

The i386 backend (and a few others) already use
(cfun->curr_properties & PROP_rtl_split_insns)
as a test for split1 pass finished, so that some insns that should be split
during split1 and shouldn't be matched afterwards are properly guarded.

So, the following patch does that for vspltis_shifted too.

2022-02-08  Jakub Jelinek  

PR target/102140
* config/rs6000/rs6000.cc (vspltis_shifted): Return false also if
split1 pass has finished already.

* gcc.dg/pr102140.c: New test.

[Bug c++/104403] [12 Regression] ICE while optimizing lambda that returns address of a static variable hidden in a switch

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

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

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

https://gcc.gnu.org/g:1755141a9ea0dddabb52776cddc4c9325eed27c6

commit r12-7112-g1755141a9ea0dddabb52776cddc4c9325eed27c6
Author: Jakub Jelinek 
Date:   Tue Feb 8 20:15:42 2022 +0100

c++: Remove superflous assert [PR104403]

I've added the assert because start_decl diagnoses such vars for C++20 and
earlier:
  if (current_function_decl && VAR_P (decl)
  && DECL_DECLARED_CONSTEXPR_P (current_function_decl)
  && cxx_dialect < cxx23)
but as can be seen, we cam trigger the assert in older standards e.g.
during
non-manifestly constant evaluation.  Rather than refining the assert that
DECL_EXPRs for such vars don't appear for C++20 and older if they are
inside
of functions declared constexpr this patch just removes the assert, the
code rejects encountering those vars in constant expressions anyway.

2022-02-08  Jakub Jelinek  

PR c++/104403
* constexpr.cc (cxx_eval_constant_expression): Don't assert
DECL_EXPRs
of TREE_STATIC vars may only appear in -std=c++23.

* g++.dg/cpp0x/lambda/lambda-104403.C: New test.

[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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