[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Ed Catmur from comment #5)
> The original code is valid. A reduced valid case would be:
> ```
> template  struct S {};
> template  struct bucket {};
> template 
> int find_indices_impl(bucket const &);
> struct HashTable : bucket, 1>, bucket, 2> {};
> auto t = find_indices_impl>(HashTable{});
> ```

Oh yes and yes the above looks like the original code even.
It is definitely trying to match bucket, 2> base class with bucket,
i> though and it is ICEing there.

[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065

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

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

--- Comment #7 from Andrew Pinski  ---
Reduced further (which shows PR 110810 is the same here):
```
struct class1 {
  class1();
  ~class1();
};
using array = class1[1]; 
template 
void f()
{
  array{};
}
```

[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

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

[Bug c++/110810] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1068

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
It is a dup of bug 109899 in the end (will show why there in a second).

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

[Bug c++/110810] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1068

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

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

--- Comment #2 from Andrew Pinski  ---
You don't even need it to be a new or even ~X there:
```
struct Foo {
Foo() {}
~Foo() {}
};

struct X {
Foo data[4];
};

template
void f() {
X{};
}
```

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #5 from Ed Catmur  ---
The original code is valid. A reduced valid case would be:
```
template  struct S {};
template  struct bucket {};
template 
int find_indices_impl(bucket const &);
struct HashTable : bucket, 1>, bucket, 2> {};
auto t = find_indices_impl>(HashTable{});
```

[Bug c++/110810] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1068

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2023-07-26
 Ever confirmed|0   |1
   Target Milestone|--- |12.4
  Known to fail||12.1.0
 Status|UNCONFIRMED |NEW
  Known to work||11.4.0
Summary|ICE in check_noexcept_r, at |[12/13/14 Regression] ICE
   |cp/except.cc:1068   |in check_noexcept_r, at
   ||cp/except.cc:1068

--- Comment #1 from Andrew Pinski  ---
Confirmed.
You don't even need it to be a inplacement new:
```

struct Foo {
Foo() {}
~Foo() {}
};

struct X {
Foo data[4];
};

template
void f() {
auto& object = *new X{};
object.~X();
}
```

[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize

[vincent.riviere at freesbee dot fr via Gcc-bugs]

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

Vincent Riviere  changed:

   What|Removed |Added

 CC||vincent.riviere at freesbee 
dot fr

--- Comment #2 from Vincent Riviere  ---
I reproduce this bug with GCC 13.1.0 for m68k. It happens when compiling libgcc
with -mcpu=5475 -mshort -O2.

Affected files are:
unwind-dw2.c
unwind-dw2-fde.c
libgcov-driver.c

Workaround: compile with -O1.

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

[13958014620 at 139 dot com via Gcc-bugs]

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

--- Comment #5 from miles <13958014620 at 139 dot com> ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > I almost positive this was fixed by r14-159-g03cebd304955a6 which was
> > backported to GCC 13 branch r13-7277-ga713aa4f47ac1e (for 13.2.0) .
> 
> Yes, bisection confirms it. So this is a dup.
> 
> Aside: I'm not sure I'd call this a wrong-code bug. The testcase would be
> simpler if it used static_assert instead of assert, which would make it
> accepts-invalid / rejects-valid instead.
> 
> *** This bug has been marked as a duplicate of bug 108099 ***


> Aside: I'm not sure I'd call this a wrong-code bug.
Yep, the "unsigned" keyword qualifies an typedef-ed type is illegal according
to ISO_14882. It's acceptable that the compiler reports a failure, at least a
warning.

>The testcase would be simpler if it used static_assert instead of assert, 
>which would make itaccepts-invalid / rejects-valid instead.
Thanks a lot for your suggestion!

The experience of discovering this issue is very interesting.
I wrote a macro function to show the attributes of fundamental type for my son,
he's currently learning c++ language.

#define PRINT_TYPE_ATTRIBUTES(T)  \
cout << "typeid(" << O_YELLOW(#T) << ").name(): " <<
O_RED(typeid(T).name()) <

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

--- Comment #4 from Andrew Pinski  ---
Note if we do:
```
struct A{}; struct B{};
template  struct S {};
template  struct bucket {};
template 
int find_indices_impl(bucket const &);
using HashTable = bucket, 1>;
auto t = find_indices_impl>(HashTable{});
```
GCC correctly rejects the above but if we replace B{} with a floating point
value, we get the ICE (but not if we replace A{}). Maybe that will give an hint
of what is going wrong in the end.

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

--- Comment #3 from Andrew Pinski  ---
I reduced it to an invalid code (I don't know if the original was valid or
not):
```
template  struct S {};
template  struct bucket {};
template 
int find_indices_impl(bucket const &);
using HashTable = bucket, 1>;
auto t = find_indices_impl>(HashTable{});
```

If I remove the i template argument, GCC correctly rejects the above. If I
change 1.0 and 2.0 to the same value, GCC accepts the code correctly.


Note clang does not support double as a non-type template argument (yet).

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

--- Comment #9 from Kewen Lin  ---
(In reply to Iain Sandoe from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> > > 
> > > --- Comment #6 from Kewen Lin  ---
> > > (In reply to rguent...@suse.de from comment #5)
> > > > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > > > 
> > > > I think apart from the consideration what a single element vector
> > > > is compared to a scalar, a more to-the-point fix is
> > > > 
> > > >   if (VECTOR_TYPE_P (ltype)
> > > >   && memory_access_type != VMAT_ELEMENTWISE)
> > > 
> > > Thanks for the suggestion! I thought checking lnel can also cover
> > > VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems 
> > > impossible
> > > to have?
> > 
> > I think so, unless I'm convinced with a testcase ;)

I guess there is no such test case. ;)

> 
> (sorry for being a bit slow - we had a power outage that wasted most of the
> day)
> 
> Richi's suggested patch fixes build of a cross-build for powerpc-darwin and
> the test results look OK too.  A non-expert look at the code suggests that
> VMAT_ELEMENTWISE is already accounted for on the write side, so that we
> should not see a call to the costing code for the equivalent write-side.

Thanks Iain, I also bootstrapped and regtested the suggested fix on x86 and
powerpc64{,le}, just posted it for review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625484.html.

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

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

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

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

commit r14-2773-g9fdbd7d6fa5e0a76898dd66658934e3184111680
Author: Nathaniel Shead 
Date:   Sun Jul 23 01:15:14 2023 +1000

c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).

PR c++/96630
PR c++/98675
PR c++/70331

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_global_ctx::is_outside_lifetime): New
function.
(constexpr_global_ctx::get_value): Don't return expired values.
(constexpr_global_ctx::get_value_ptr): Likewise.
(constexpr_global_ctx::remove_value): Mark value outside
lifetime.
(outside_lifetime_error): New function.
(cxx_eval_call_expression): No longer track save_exprs.
(cxx_eval_loop_expr): Likewise.
(cxx_eval_constant_expression): Add checks for outside lifetime
values. Remove local variables at end of bind exprs, and
temporaries after cleanup points.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-lifetime1.C: New test.
* g++.dg/cpp1y/constexpr-lifetime2.C: New test.
* g++.dg/cpp1y/constexpr-lifetime3.C: New test.
* g++.dg/cpp1y/constexpr-lifetime4.C: New test.
* g++.dg/cpp1y/constexpr-lifetime5.C: New test.
* g++.dg/cpp1y/constexpr-lifetime6.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/96630] dangling reference accepted in constexpr evaluation

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

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

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

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

commit r14-2773-g9fdbd7d6fa5e0a76898dd66658934e3184111680
Author: Nathaniel Shead 
Date:   Sun Jul 23 01:15:14 2023 +1000

c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).

PR c++/96630
PR c++/98675
PR c++/70331

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_global_ctx::is_outside_lifetime): New
function.
(constexpr_global_ctx::get_value): Don't return expired values.
(constexpr_global_ctx::get_value_ptr): Likewise.
(constexpr_global_ctx::remove_value): Mark value outside
lifetime.
(outside_lifetime_error): New function.
(cxx_eval_call_expression): No longer track save_exprs.
(cxx_eval_loop_expr): Likewise.
(cxx_eval_constant_expression): Add checks for outside lifetime
values. Remove local variables at end of bind exprs, and
temporaries after cleanup points.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-lifetime1.C: New test.
* g++.dg/cpp1y/constexpr-lifetime2.C: New test.
* g++.dg/cpp1y/constexpr-lifetime3.C: New test.
* g++.dg/cpp1y/constexpr-lifetime4.C: New test.
* g++.dg/cpp1y/constexpr-lifetime5.C: New test.
* g++.dg/cpp1y/constexpr-lifetime6.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/70331] missing error dereferencing a dangling pointer (out of scope) in constexpr function

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

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

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

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

commit r14-2773-g9fdbd7d6fa5e0a76898dd66658934e3184111680
Author: Nathaniel Shead 
Date:   Sun Jul 23 01:15:14 2023 +1000

c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).

PR c++/96630
PR c++/98675
PR c++/70331

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_global_ctx::is_outside_lifetime): New
function.
(constexpr_global_ctx::get_value): Don't return expired values.
(constexpr_global_ctx::get_value_ptr): Likewise.
(constexpr_global_ctx::remove_value): Mark value outside
lifetime.
(outside_lifetime_error): New function.
(cxx_eval_call_expression): No longer track save_exprs.
(cxx_eval_loop_expr): Likewise.
(cxx_eval_constant_expression): Add checks for outside lifetime
values. Remove local variables at end of bind exprs, and
temporaries after cleanup points.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-lifetime1.C: New test.
* g++.dg/cpp1y/constexpr-lifetime2.C: New test.
* g++.dg/cpp1y/constexpr-lifetime3.C: New test.
* g++.dg/cpp1y/constexpr-lifetime4.C: New test.
* g++.dg/cpp1y/constexpr-lifetime5.C: New test.
* g++.dg/cpp1y/constexpr-lifetime6.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

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

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

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

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

commit r14-2772-gb8266af71c19a0bd7db4d08c8d2ee3c33214508c
Author: Nathaniel Shead 
Date:   Sun Jul 23 01:14:37 2023 +1000

c++: Prevent dangling pointers from becoming nullptr in constexpr
[PR110619]

Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values, and is also a visible
change to otherwise valid code (as in the linked PR).

The transformation is nonetheless important, however, both as a safety
guard against attackers being able to gain a handle to other data on the
stack, and to prevent duplicate warnings from later null-dereference
warning passes.

As such, this patch just delays the transformation until cp_genericize,
after constexpr function definitions have been generated.

PR c++/110619

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_genericize_r): Transform RETURN_EXPRs to
not return dangling pointers.
* cp-tree.h (RETURN_EXPR_LOCAL_ADDR_P): New flag.
(check_return_expr): Add a new parameter.
* semantics.cc (finish_return_stmt): Set flag on RETURN_EXPR
when referring to dangling pointer.
* typeck.cc (check_return_expr): Disable transformation of
dangling pointers, instead pass this information to caller.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-110619.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

--- Comment #2 from Andrew Pinski  ---
Reducing ...

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

--- Comment #7 from Tom de Vries  ---
(In reply to Alexander Monakov from comment #5)
> This trips Valgrind's data race detector (valgrind --tool=helgrind) too. So
> I don't think checking SANITIZE_THREAD is the correct approach.

Can you elaborate on what you consider a correct approach?

[Bug testsuite/110803] new test case gcc.c-torture/execute/pr109986.c in r14-2751-g2a3556376c69a1 fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug testsuite/110803] new test case gcc.c-torture/execute/pr109986.c in r14-2751-g2a3556376c69a1 fails

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

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

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

https://gcc.gnu.org/g:67357270772b9131f1780267485c9eba0331bd6f

commit r14-2767-g67357270772b9131f1780267485c9eba0331bd6f
Author: Andrew Pinski 
Date:   Tue Jul 25 21:50:33 2023 +

Fix 110803: use of plain char instead of signed char

So the problem here is that plain char can either be signed
or unsigned depending on the target (powerpc and aarch64 are
unsigned while most other targets are signed). So the testcase
gcc.c-torture/execute/pr109986.c was assuming plain char was signed
char which is wrong so it is better to just change the `char` to be
`signed char`.
Note gcc.c-torture/execute/pr109986.c includes gcc.dg/tree-ssa/pr109986.c
where the plain char was being used.

Committed as obvious after a quick test to make sure
gcc.c-torture/execute/pr109986.c
now passes and gcc.dg/tree-ssa/pr109986.c still passes.

gcc/testsuite/ChangeLog:

PR testsuite/110803
* gcc.dg/tree-ssa/pr109986.c: Change plain char to be
`signed char`.

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

--- Comment #6 from Tom de Vries  ---
(In reply to rguent...@suse.de from comment #4)
> I'm suggesting to not fix it ;) 

Can you explain why ?

It doesn't look difficult to fix to me, and I don't see any downsides.

> That said, is TSAN a useful vehicle?

Well, false positives aside, yes.

[Bug fortran/68569] ICE with automatic character object and DATA

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 55635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55635=edit
Patch

This patch fixes the testcases in this PR and regtests OK, except for the
necessary minor adjustments to the patterns in gfortran.dg/data_char_4.f90
and gfortran.dg/data_char_5.f90 (not included).

[Bug c++/84542] missing -Wdeprecated-declarations on a redeclared function template

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

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

--- Comment #4 from Jonathan Wakely  ---
This affects std::random_shuffle in libstdc++, which only warns with clang, not
gcc. The attribute needs to be on the first declaration to work with gcc.

[Bug c++/110802] Missing warning for attribute deprecated on a function template definition with a previous declaration

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

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

--- Comment #2 from Jonathan Wakely  ---
Not sure why that didn't show up when I searched, thanks Andrew!

[Bug fortran/68569] ICE with automatic character object and DATA

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
Nicolas, are you still working on this?

I have played with extensions of your patch that fix the testcases here
as well as the fallout from regression testing.  To be attached later.

[Bug c++/108960] clear tf_partial et al in instantiate_template

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done.

[Bug c++/108960] clear tf_partial et al in instantiate_template

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

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

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

https://gcc.gnu.org/g:39004608e79b68fe7615a026ce58dea646dba20e

commit r14-2765-g39004608e79b68fe7615a026ce58dea646dba20e
Author: Marek Polacek 
Date:   Tue Jul 25 14:36:47 2023 -0400

c++: clear tf_partial et al in instantiate_template [PR108960]

In 
we concluded that we might clear all flags except tf_warning_or_error
when performing instantiate_template.

PR c++/108960

gcc/cp/ChangeLog:

* pt.cc (lookup_and_finish_template_variable): Don't clear
tf_partial
here.
(instantiate_template): Reset all complain flags except
tf_warning_or_error.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to rguent...@suse.de from comment #7)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> > 
> > --- Comment #6 from Kewen Lin  ---
> > (In reply to rguent...@suse.de from comment #5)
> > > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > > 
> > > I think apart from the consideration what a single element vector
> > > is compared to a scalar, a more to-the-point fix is
> > > 
> > >   if (VECTOR_TYPE_P (ltype)
> > >   && memory_access_type != VMAT_ELEMENTWISE)
> > 
> > Thanks for the suggestion! I thought checking lnel can also cover
> > VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems 
> > impossible
> > to have?
> 
> I think so, unless I'm convinced with a testcase ;)

(sorry for being a bit slow - we had a power outage that wasted most of the
day)

Richi's suggested patch fixes build of a cross-build for powerpc-darwin and the
test results look OK too.  A non-expert look at the code suggests that
VMAT_ELEMENTWISE is already accounted for on the write side, so that we should
not see a call to the costing code for the equivalent write-side.

[Bug c++/110810] New: ICE in check_noexcept_r, at cp/except.cc:1068

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 110810
   Summary: ICE in check_noexcept_r, at cp/except.cc:1068
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Created attachment 55634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55634=edit
preprocessed code, zipped

Starting with x86_64 version of gcc 12.1 (linux), and through all newer
versions (including the trunk) on Compiler explorer, I receive an internal
compiler error on the following code:

Some overlap with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 but there
is enough difference that I thought it might still be useful to report.

https://godbolt.org/z/ThTdxqzKG

#include 

struct Foo {
Foo() {}
~Foo() {}
};

struct X {
Foo data[4];
};

template
void f() {
char storage[256];
auto& object = *new(storage) X{};
object.~X();
}

* removing {} in the call to placement new "fixes" it, or replacing with
parenthesis.  Another fix is removing either the default ctor or destructor
from Foo, or making data not be an array, or f() not be a template.  It's a
strange and specific combination.

Output:


source>: In function 'void f()':
:15:36: internal compiler error: in check_noexcept_r, at
cp/except.cc:1068
   15 | auto& object = *new(storage) X{};
  |^
0x246af2e internal_error(char const*, ...)
???:0
0xac8ab6 fancy_abort(char const*, int, char const*)
???:0
0x16d661c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x16d9912 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0xbd04a3 expr_noexcept_p(tree_node*, int)
???:0
0xbd64f0 build_vec_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int)
???:0
0xbd6a1e build_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int, int)
???:0
0xb8c5cc cxx_maybe_build_cleanup(tree_node*, int)
???:0
0xaf6b55 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xaf78e7 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xbde5fc build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xcae89f c_parse_file()
???:0
0xdee919 c_common_parse_file()
???:0
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.

[Bug c++/110809] ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2023-07-25

--- Comment #1 from Marek Polacek  ---
Confirmed.  Even 11 ICEs; 10 gives errors.

[Bug c++/110809] New: ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 110809
   Summary: ICE: in unify, at cp/pt.cc:25226 with floating-point
NTTPs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

#include 
using A = double;
template struct S {};
auto x = boost::hana::make_map(
boost::hana::make_pair(boost::hana::type_c>, 1),
boost::hana::make_pair(boost::hana::type_c>, 2))[
boost::hana::type_c>];

/opt/compiler-explorer/libs/boost_1_82_0/boost/hana/detail/hash_table.hpp:51:62:
internal compiler error: in unify, at cp/pt.cc:25226
   51 | using type =
decltype(detail::find_indices_impl(std::declval()));
  |  
~~~^
0x246af2e internal_error(char const*, ...)
???:0
0xac8ab6 fancy_abort(char const*, int, char const*)
???:0
0xd01e11 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xaf7db9 build_new_function_call(tree_node*, vec**, int)
???:0
0xd2379c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xcddfef tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcde6fc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd06d50 instantiate_class_template(tree_node*)
???:0
0xd5954f complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xcdf1a7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcde6fc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd06d50 instantiate_class_template(tree_node*)
???:0
0xd5954f complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xcdf1a7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcde6fc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcd6618 instantiate_decl(tree_node*, bool, bool)
???:0
0xbb8461 maybe_instantiate_decl(tree_node*)
???:0
0xbb9ebf mark_used(tree_node*, int)
???:0
0xaf673e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xd22eaf finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0

Changing `A` to `int` makes it compile, so this is a problem with
floating-point NTTPs.

[Bug c++/110808] [modules] Internal Compiler Error in check_mergeable_decl

[mihi32 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Silviu Vrinceanu  ---
Created attachment 55633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55633=edit
Archive with preprocessed files *.ii

[Bug c++/110808] New: [modules] Internal Compiler Error in check_mergeable_decl

[mihi32 at gmail dot com via Gcc-bugs]

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

Bug ID: 110808
   Summary: [modules] Internal Compiler Error in
check_mergeable_decl
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mihi32 at gmail dot com
  Target Milestone: ---

Created attachment 55632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55632=edit
Archive with the 3 cpp files that reproduce the error.

// tres.cpp
export module group:tres;

int mul()
{
return 0;
}

// group.cpp
export module group;
export import :tres;

// main.cpp
import group:tres;

int main() 
{
return mul();
}

$ g++-12 -freport-bug -std=c++20 -fmodules-ts tres.cpp group.cpp main.cpp -o
main

main.cpp: In function ‘int main()’:
main.cpp:5:16: internal compiler error: Segmentation fault
5 | return mul();
  |^~~
0xd910e3 crash_signal
../../src/gcc/toplev.cc:322
0x7facc691751f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x76fc34 ovl_iterator::operator*() const
../../src/gcc/cp/cp-tree.h:842
0x76fc34 check_mergeable_decl
../../src/gcc/cp/module.cc:10570
0x792150 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../src/gcc/cp/module.cc:10805
0x794f14 trees_in::decl_value()
../../src/gcc/cp/module.cc:7921
0x78fa77 trees_in::tree_node(bool)
../../src/gcc/cp/module.cc:9172
0x795b4b module_state::read_cluster(unsigned int)
../../src/gcc/cp/module.cc:14838
0x7960a5 module_state::load_section(unsigned int, binding_slot*)
../../src/gcc/cp/module.cc:18109
0x796237 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../src/gcc/cp/module.cc:18801
0x7a3ec4 name_lookup::search_namespace_only(tree_node*)
../../src/gcc/cp/name-lookup.cc:919
0x7a523b name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../src/gcc/cp/name-lookup.cc:1142
0x7a6fab lookup_name(tree_node*, LOOK_where, LOOK_want)
../../src/gcc/cp/name-lookup.cc:7774
0x7aee01 lookup_name(tree_node*, LOOK_want)
../../src/gcc/cp/name-lookup.h:404
0x7aee01 cp_parser_lookup_name
../../src/gcc/cp/parser.cc:30605
0x7dd045 cp_parser_class_name
../../src/gcc/cp/parser.cc:25693
0x7dd31c cp_parser_type_name
../../src/gcc/cp/parser.cc:20140
0x7ebee0 cp_parser_simple_type_specifier
../../src/gcc/cp/parser.cc:19831
0x7d27fa cp_parser_postfix_expression
../../src/gcc/cp/parser.cc:7573
0x7bc7c6 cp_parser_binary_expression
../../src/gcc/cp/parser.cc:10035
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
-
$ g++-12 -v
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)

[Bug c++/110807] New: Copy list initialisation of a vector raises a warning with -O2

[twic at urchin dot earth.li via Gcc-bugs]

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

Bug ID: 110807
   Summary: Copy list initialisation of a vector raises a
warning with -O2
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: twic at urchin dot earth.li
  Target Milestone: ---

Created attachment 55631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55631=edit
the source coded needed to reproduce the problem

If you have a class with a vector member:

struct Foo {
std::vector byCallSpread;
};

And try to initialise it with copy list initialisation:

Foo() { byCallSpread = {true, false}; }

Then that works fine with the default optimisation level, but gets a warning at
-O2 saying:

/usr/local/include/c++/13.1.0/bits/stl_algobase.h:437:30: warning: 'void*
__builtin_memmove(void*, const void*, long unsigned int)' writing between 9 and
9223372036854775807 bytes into a region of size 8 overflows the destination
[-Wstringop-overflow=]
  437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~

(i believe this is the relevant error - i am not very good at reading error
messages, so apologies if not)

The warning goes away if the initialisation uses an explicit constructor:

Foo() { byCallSpread = std::vector({true, false}); }

I did not get this warning with GCC 7.2.0. According to Compiler Explorer, it
does not occur with GCC 12.3.

Here is a transcript of a self-contained session using the GCC 13.1.0 official
Docker image (official for Docker, perhaps not for GCC!) which demonstrates the
problem:

$ sudo docker run -it gcc:13.1.0
root@4694030a8bea:/# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/13.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC) 
root@4694030a8bea:/# cat >foo.cpp
#include 

struct Foo {
std::vector byCallSpread;

Foo() { byCallSpread = {true, false}; }
};

Foo f;

int main(int argc, char** argv) {}
root@4694030a8bea:/# g++ foo.cpp 
root@4694030a8bea:/# g++ -O2 foo.cpp 
In file included from /usr/local/include/c++/13.1.0/vector:62,
 from foo.cpp:1:
In static member function 'static _Up* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = long
unsigned int; _Up = long unsigned int; bool _IsMove = false]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = long unsigned int*; _OI = long unsigned int*]' at
/usr/local/include/c++/13.1.0/bits/stl_algobase.h:506:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
false; _II = long unsigned int*; _OI = long unsigned int*]' at
/usr/local/include/c++/13.1.0/bits/stl_algobase.h:533:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = long unsigned int*; _OI = long unsigned int*]' at
/usr/local/include/c++/13.1.0/bits/stl_algobase.h:540:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II = long unsigned int*;
_OI = long unsigned int*]' at
/usr/local/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'std::vector::iterator std::vector::_M_copy_aligned(const_iterator, const_iterator, iterator) [with _Alloc
= std::allocator]' at
/usr/local/include/c++/13.1.0/bits/stl_bvector.h:1303:28,
inlined from 'void std::vector::_M_insert_range(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = const bool*; _Alloc = std::allocator]' at
/usr/local/include/c++/13.1.0/bits/vector.tcc:915:33,
inlined from 'std::vector::iterator std::vector::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = const bool*;  = void; _Alloc =
std::allocator]' at
/usr/local/include/c++/13.1.0/bits/stl_bvector.h:1180:19,
inlined from 'void std::vector::_M_assign_aux(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const bool*; _Alloc =
std::allocator]' at
/usr/local/include/c++/13.1.0/bits/stl_bvector.h:1440:14,
inlined from 'void std::vector::assign(_InputIterator,
_InputIterator) [with _InputIterator = const bool*;  =
void; _Alloc = std::allocator]' at
/usr/local/include/c++/13.1.0/bits/stl_bvector.h:935:17,
inlined from 'std::vector& std::vector::operator=(std::initializer_list) [with _Alloc =
std::allocator]' at
/usr/local/include/c++/13.1.0/bits/stl_bvector.h:915:14,
inlined from 'Foo::Foo()' at foo.cpp:6:40,
inlined from 'void __static_initialization_and_destruction_0()' at
foo.cpp:9:5,

[Bug c++/110382] [13 Regression] internal compiler error: in verify_ctor_sanity

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[13/14 Regression] internal |[13 Regression] internal
   |compiler error: in  |compiler error: in
   |verify_ctor_sanity  |verify_ctor_sanity

--- Comment #5 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/110382] [13/14 Regression] internal compiler error: in verify_ctor_sanity

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

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

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

https://gcc.gnu.org/g:6e424febfbcb27c21a7fe3a137e614765f9cf9d2

commit r14-2762-g6e424febfbcb27c21a7fe3a137e614765f9cf9d2
Author: Marek Polacek 
Date:   Fri Jul 21 17:48:37 2023 -0400

c++: fix ICE with constexpr ARRAY_REF [PR110382]

This code in cxx_eval_array_reference has been hard to get right.
In r12-2304 I added some code; in r13-5693 I removed some of it.

Here the problematic line is "S s = arr[0];" which causes a crash
on the assert in verify_ctor_sanity:

  gcc_assert (!ctx->object || !DECL_P (ctx->object)
  || ctx->global->get_value (ctx->object) == ctx->ctor);

ctx->object is the VAR_DECL 's', which is correct here.  The second
line points to the problem: we replaced ctx->ctor in
cxx_eval_array_reference:

  new_ctx.ctor = build_constructor (elem_type, NULL); // #1

which I think we shouldn't have; the CONSTRUCTOR we created in
cxx_eval_constant_expression/DECL_EXPR

  new_ctx.ctor = build_constructor (TREE_TYPE (r), NULL);

had the right type.

We still need #1 though.  E.g., in constexpr-96241.C, we never
set ctx.ctor/object before calling cxx_eval_array_reference, so
we have to build a CONSTRUCTOR there.  And in constexpr-101371-2.C
we have a ctx.ctor, but it has the wrong type, so we need a new one.

We can fix the problem by always clearing the object, and, as an
optimization, only create/free a new ctor when actually needed.

PR c++/110382

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_array_reference): Create a new constructor
only when we don't already have a matching one.  Clear the object
when the type is non-scalar.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-110382.C: New test.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #10 from Thiago Jung Bauermann  
---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Richard Earnshaw from comment #6)
> > Is the exception status supposed to be in a defined state when the test
> > runs?  Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
> > start of the test?
> 
> Isn't the exception status guaranteed to be defined (and not signaling) when
> the program starts?
> 
> But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could
> not hurt, for sure.

I tried adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() but it
didn't make a difference.

[Bug c++/110806] Suggest this-> for dependent base classes in more contexts

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug c++/110806] New: Suggest this-> for dependent base classes in more contexts

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 110806
   Summary: Suggest this-> for dependent base classes in more
contexts
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this [broken] program:

template 
struct Outer {
struct Inner {
template 
void wait(F f);
};

struct InnerD : Inner {
template 
void advance(F f) {
wait(f);
}
};

#ifdef OUTER
template 
void wait(F f);
#endif
};

void f(Outer::InnerD i) {
i.advance(42);
}

gcc's compile error is:

: In instantiation of 'void Outer::InnerD::advance(F) [with F = int;
T = int]':
:22:14:   required from here
:11:17: error: 'wait' was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
   11 | wait(f);
  | ^~~
:11:17: note: declarations in dependent base 'Outer::Inner' are
not found by unqualified lookup
:11:17: note: use 'this->wait' instead

This is pretty good - indicates what the problem is and suggests the correct
fix.

However, if you compile with -DOUTER, such that lookup for wait(f) ends up
finding Outer::f, you get this error:

: In instantiation of 'void Outer::InnerD::advance(F) [with F = int;
T = int]':
:22:14:   required from here
:11:17: error: cannot call member function 'void Outer::wait(F)
[with F = int; T = int]' without object
   11 | wait(f);
  | ^~~

If we had the exact same note in this context too, that'd be very helpful -
since if what you meant to call was Inner::wait, the fact that you cannot call
Outer::wait isn't really useful. Plus when the names of these types are a
little longer, the error message can be pretty confusing if you gloss over the
fact that the error is reporting that you tried to call void Outer::wait and
not void Outer::Inner::wait!

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #9 from Richard Earnshaw  ---
proc add_options_for_ieee { flags } {
if { [istarget alpha*-*-*]
 || [istarget sh*-*-*] } {
   return "$flags -mieee"
}
if { [istarget rx-*-*] } {
   return "$flags -mnofpu"
}
return $flags
}

So it looks like this isn't expecting to add anything in most cases.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #8 from Francois-Xavier Coudert  ---
(In reply to Richard Earnshaw from comment #6)
> Is the exception status supposed to be in a defined state when the test
> runs?  Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the
> start of the test?

Isn't the exception status guaranteed to be defined (and not signaling) when
the program starts?

But adding feclearexcept (FE_ALL_EXCEPT); at the beginning of main() could not
hurt, for sure.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #7 from Thiago Jung Bauermann  
---
(In reply to Francois-Xavier Coudert from comment #5)
> OK, so it signals FE_INVALID on the first test. Can you run this with the
> same options, and see what happens?

It ran normally:

thiago.bauermann@tcwg-jade-03-dev:~/tmp$ cat test-1.c
#include 
#include 

void
ftrue (float x, float y)
{
if (!__builtin_iseqsig (x, y))
__builtin_abort ();
}

int
main ()
{
volatile float f1, f2;

f1 = 0.f; f2 = 0.f;
if (fetestexcept (FE_INVALID)) printf("Invalid 1\n");
ftrue (f1, f2);
if (fetestexcept (FE_INVALID)) printf("Invalid 2\n");

return 0;
}
thiago.bauermann@tcwg-jade-03-dev:~/tmp$
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/ test-1.c 
-fdiagnostics-plain-output-Os  -fsignaling-nans -ggdb3  -lm  -o ./test-1
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ ./test-1
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ echo $?
0
thiago.bauermann@tcwg-jade-03-dev:~/tmp$

> One surprising thing is that the directive "dg-add-options ieee" in the test
> did not apparently add any other option for IEEE conformance…

Ah, that's an interesting thread to pull. I'll investigate if there's any
option we should be adding.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #6 from Richard Earnshaw  ---
Is the exception status supposed to be in a defined state when the test runs? 
Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the start of the
test?

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[alice at ayaya dot dev via Gcc-bugs]

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

psykose  changed:

   What|Removed |Added

 CC||alice at ayaya dot dev

--- Comment #10 from psykose  ---
with 13-20230722 i can reproduce the exact same failures

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #5 from Francois-Xavier Coudert  ---
OK, so it signals FE_INVALID on the first test. Can you run this with the same
options, and see what happens?

---
#include 
#include 

void
ftrue (float x, float y)
{
  if (!__builtin_iseqsig (x, y))
__builtin_abort ();
}

int
main ()
{
  volatile float f1, f2;

  f1 = 0.f; f2 = 0.f;
  if (fetestexcept (FE_INVALID)) printf("Invalid 1\n");
  ftrue (f1, f2);
  if (fetestexcept (FE_INVALID)) printf("Invalid 2\n");

  return 0;
}
---

One surprising thing is that the directive "dg-add-options ieee" in the test
did not apparently add any other option for IEEE conformance…

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Jung Bauermann  
---
Thanks for looking into this.

(In reply to Francois-Xavier Coudert from comment #3)
> Do the failure only occur at -Os?

Only at -Os. The FAILs I mentioned in the bug report are the only ones that
occur.

> Does it pass at -O0, -O1, -O2?

Yes.

> And could you possibly run builtin-iseqsig-1.c under gdb and obtain a
> backtrace?

Here it is:

thiago.bauermann@tcwg-jade-03-dev:~/tmp$
/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/xgcc
-B/home/thiago.bauermann/.cache/builds/gcc-native-aarch32/gcc/
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c
   -fdiagnostics-plain-output-Os  -fsignaling-nans -ggdb3  -lm  -o
./builtin-iseqsig-1.exe
thiago.bauermann@tcwg-jade-03-dev:~/tmp$ gdb builtin-iseqsig-1.exe
Reading symbols from builtin-iseqsig-1.exe...
(gdb) r
Starting program: /home/thiago.bauermann/tmp/builtin-iseqsig-1.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or
directory.
(gdb) bt
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xf7e8d2ca in __pthread_kill_implementation (threadid=4160625664,
signo=signo@entry=6,
no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xf7e8d30c in __pthread_kill_internal (signo=6, threadid=)
at pthread_kill.c:78
#3  0xf7e5c840 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0xf7e4d5e4 in __GI_abort () at abort.c:79
#5  0x00010426 in main ()
at
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c:30
(gdb) frame 5
#5  0x00010426 in main ()
at
/home/thiago.bauermann/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-iseqsig-1.c:30
30if (fetestexcept (FE_INVALID)) __builtin_abort ();
(gdb)

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||malat at debian dot org

--- Comment #4 from Mathieu Malaterre  ---
@psykose if you have access to an aarch64 system, could you also check #110643
?

[Bug c++/110805] New: g++ crash on modules with exported class providing string constant with obscure content

[jo.hiller+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 110805
   Summary: g++ crash on modules with exported class providing
string constant with obscure content
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jo.hiller+gcc at gmail dot com
  Target Milestone: ---

Created attachment 55630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55630=edit
output of -freport-bug

// Info
gcc-13 --version
gcc-13 (Homebrew GCC 13.1.0) 13.1.0
macOS 13.5, arm64, Apple M1 MAX

// Steps to reproduce
* use a C++20 module with exported class providing obscure string constant
* gcc 13.1 crash with "m.cc:3:8: internal compiler error: Segmentation fault:
11"

// m.cc
module;
#include 
export module m;
export class Constants {
 public:
  inline static const std::string CONST_CRASH_1 = "Bundle-Activator";
};

// build
gcc-13 -freport-bug -std=c++20 -xc++ -fmodules-ts -fmodule-only -Wall -Wextra
m.cc
# see attached output file ccRJ91Vu.out

// notes
* exported string constants outside exported class do work
* string constants with different types/values do work as well, see different
string value, very obscure
  static constexpr std::string_view CONST_OK_1 = "Bundle-Activator";
  inline static const std::string CONST_OK_2 = "bundleactivator";
  inline static const std::string CONST_OK_3 = "Bundle-Activato";
  inline static const std::string CONST_OK_4 = "undle-Activator";
  inline static const std::string CONST_OK_5 = "xxxXactivatorll";
* these string constants do fail as well
  inline static const std::string CONST_CRASH_2 = "xxxbundleXactivatorlll";
  inline static const std::string CONST_CRASH_3 = "xxxXactivatorlll";
  inline static const std::string CONST_CRASH_4 = "xxxXactivatorlll";
* it seems this pattern ".*.activator.*" triggeres special handling in gcc-13,
lower/upper case seems not to be relevant, but number of characters
before/after

[Bug c++/84542] missing -Wdeprecated-declarations on a redeclared function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug c++/110802] Missing warning for attribute deprecated on a function template definition with a previous declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 84542.

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

[Bug c++/84542] missing -Wdeprecated-declarations on a redeclared function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

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

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

--- Comment #3 from psykose  ---
oh wow, completely identical! i didn't find that somehow, thanks

[Bug testsuite/110803] new test case gcc.c-torture/execute/pr109986.c in r14-2751-g2a3556376c69a1 fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-07-25
 Status|UNCONFIRMED |NEW
   Host|powerpc64le-linux-gnu   |
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu
   ||aarch64-*-* arm*-*
  Build|powerpc64le-linux-gnu   |
   Keywords||testsuite-fail

--- Comment #1 from Andrew Pinski  ---
Oh the problem is `char` in gcc/testsuite/gcc.dg/tree-ssa/pr109986.c really
should be `signed char` .

Confirmed. If I get some time I will commit the obvious patch to fix that ...

[Bug tree-optimization/110280] [13/14 Regression] internal compiler error: in const_unop, at fold-const.cc:1884

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||alice at ayaya dot dev

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

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
Do the failure only occur at -Os? Does it pass at -O0, -O1, -O2?
And could you possibly run builtin-iseqsig-1.c under gdb and obtain a
backtrace?

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #11 from Roger Sayle  ---
Mine.  Alas the obvious fix of adding an early clobber to the rotate doubleword
from memory alternative generates some truly terrible code (spills via memory
to SSE registers!?), but I've come up with a better solution, forcing reload to
read the operand from memory before the rotate, which appears to fix the
problem without the adverse performance impact.

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

--- Comment #1 from psykose  ---
forgot to mention, but this is on alpine linux.

i can't seem to reproduce this with g++13 '13.1.0' on debian sid

[Bug c++/110804] New: [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

Bug ID: 110804
   Summary: [13 regression] eliminate_stmt ICE on aarch64
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alice at ayaya dot dev
  Target Milestone: ---

Created attachment 55629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55629=edit
minimised repro, crashes with -O2

using the latest of the gcc13 snapshots (presently 13-20230722, but this is
present since 13 i think), i noticed that the swizzle_test.cc of the google
highway library fails to compile on version 1.0.5.

for reference, the test file is
https://github.com/google/highway/blob/1.0.5/hwy/tests/swizzle_test.cc

the compiler failure looks like

[127/130] Linking CXX executable tests/arithmetic_test
ninja: job failed: /usr/lib/ccache/bin/g++ -DGTEST_LINKED_AS_SHARED_LIBRARY=1
-DHWY_SHARED_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H
-I/home/demon/src/aports/community/highway/src/highway-1.0.5 -Os
-fstack-clash-protection -Wformat -Werror=format-security
-D_GLIBCXX_ASSERTIONS=1 -flto=auto -O2 -DNDEBUG -fPIE -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-builtin-macro-redefined
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla
-Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -MD -MT
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -MF
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o.d -o
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -c
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc
during GIMPLE pass: fre
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc:
In function
'hwy::N_SVE::TestPer4LaneBlockShuffle::TestTblLookupPer4LaneBlkShuf >(hwy::N_SVE::Simd, unsigned long,
hwy::N_SVE::Simd::T const*, hwy::N_SVE::Simd::T*)void':
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc:393:1:
internal compiler error: in const_unop, at fold-const.cc:1884
  393 | }  // namespace hwy
  | ^

then i went to minimise it using cvise. i forgot to correctly check that i got
the same ICE error, so i ended up with one in eliminate_stmt. minimised repro
attached. it only crashes with -O2 (not with -O1).

i'm not sure if this is the same crash as the original const_unop, it might be
a separate case.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55596|0   |1
is obsolete||

--- Comment #88 from Jakub Jelinek  ---
Created attachment 55628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55628=edit
gcc14-bitint-wip.patch

Updated version which passes all the __builtin_*_overflow{,_p} tests.  I also
used
gcov on gimple-lower-bitint.cc to make sure testsuite coverage covers almost
everything in the file.

[Bug testsuite/110803] New: new test case gcc.c-torture/execute/pr109986.c in r14-2751-g2a3556376c69a1 fails

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

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

Bug ID: 110803
   Summary: new test case gcc.c-torture/execute/pr109986.c in
r14-2751-g2a3556376c69a1 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:2a3556376c69a1fb588dcf25225950575e42784f, r14-2751-g2a3556376c69a1
make  -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr109986.c"
FAIL: gcc.c-torture/execute/pr109986.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/pr109986.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
# of expected passes7
# of unexpected failures7


(gdb) where
#0  0x77c696f8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so
#1  0x77c43ff4 in abort () from /lib64/glibc-hwcaps/power9/libc-2.28.so
#2  0x15a4 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/execute/pr109986.c:10


I believe it is this line:
  if (t3 (127, 99) != -100) __builtin_abort ();


commit 2a3556376c69a1fb588dcf25225950575e42784f (HEAD)
Author: Drew Ross 
Date:   Mon Jul 24 17:51:28 2023 +0200

match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
(In reply to Richard Biener from comment #1)
> We consider introducing load data races OK, what's the difference here? 
> There are other passes that would do similar things but in practice the
> loads would be considered to possibly trap so the real-world impact might be
> limited?

What are the examples of other transforms that can introduce data races?

This trips Valgrind's data race detector (valgrind --tool=helgrind) too. So I
don't think checking SANITIZE_THREAD is the correct approach.

[Bug c++/102493] non-type template specialization for member pointer to field and function reports leads to unexpected conflict

[jehelset at gmail dot com via Gcc-bugs]

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

--- Comment #1 from John Eivind Helset  ---
ran into this today as well with:
```cpp
struct X{
  void f(char){}
};

template
struct Y{};
template
struct Y{};
template
struct Y{};

Y<::f> y;
```
using gcc 13.1.1, clang trunk accepted same code.

[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'

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

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

--- Comment #7 from Tobias Burnus  ---
Fortran
===
Should be complete with:

* the commit r14-2754-g2e31fe431b08b0 in comment 5
  (checking for tailing executable statements + tailing)

* A follow-up testcase fix in commit r14-2759-g50656980497d77

* the commit r14-2761-g09dda270380fe1 in comment 6
  (also rejecting declarations before 'teams').

C/C++ - unimplemented
=
For C/C++, something similar to Fortran is needed. Including rejecting bare ';'
statements while properly handling lambdas, templates etc.

[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r14-2761-g09dda270380fe13e7b4722305cb1122df1f779a0
Author: Tobias Burnus 
Date:   Tue Jul 25 15:43:58 2023 +0200

OpenMP/Fortran: Reject declarations between target + teams

While commit r14-2754-g2e31fe431b08b0302e1fa8a1c18ee51adafd41df
detected executable statements, declarations do not show up as
executable statements.  Hence, we now check whether the first
statement after TARGET is TEAMS - such that we can detect data
statements like type or variable declarations.  Fortran semantics
ensures that only executable directives/statemens can come after
'!$omp end teams' such that those can be detected with the
previous check.

Note that statements returning ST_NONE such as 'omp nothing' or
'omp error at(compilation)' will still slip through.

PR fortran/110725
PR middle-end/71065

gcc/fortran/ChangeLog:

* gfortran.h (gfc_omp_clauses): Add target_first_st_is_teams.
* parse.cc (parse_omp_structured_block): Set it if the first
statement in the structured block of a TARGET is TEAMS or
a combined/composite starting with TEAMS.
* openmp.cc (resolve_omp_target): Also show an error for
contains_teams_construct without target_first_st_is_teams.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/teams-6.f90: New test.

[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r14-2761-g09dda270380fe13e7b4722305cb1122df1f779a0
Author: Tobias Burnus 
Date:   Tue Jul 25 15:43:58 2023 +0200

OpenMP/Fortran: Reject declarations between target + teams

While commit r14-2754-g2e31fe431b08b0302e1fa8a1c18ee51adafd41df
detected executable statements, declarations do not show up as
executable statements.  Hence, we now check whether the first
statement after TARGET is TEAMS - such that we can detect data
statements like type or variable declarations.  Fortran semantics
ensures that only executable directives/statemens can come after
'!$omp end teams' such that those can be detected with the
previous check.

Note that statements returning ST_NONE such as 'omp nothing' or
'omp error at(compilation)' will still slip through.

PR fortran/110725
PR middle-end/71065

gcc/fortran/ChangeLog:

* gfortran.h (gfc_omp_clauses): Add target_first_st_is_teams.
* parse.cc (parse_omp_structured_block): Set it if the first
statement in the structured block of a TARGET is TEAMS or
a combined/composite starting with TEAMS.
* openmp.cc (resolve_omp_target): Also show an error for
contains_teams_construct without target_first_st_is_teams.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/teams-6.f90: New test.

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 25 Jul 2023, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
> 
> --- Comment #2 from Tom de Vries  ---
> (In reply to Richard Biener from comment #1)
> > We consider introducing load data races OK, what's the difference here? 
> 
> This is a load vs. store data race.
> 
> > There are other passes that would do similar things but in practice the
> > loads would be considered to possibly trap so the real-world impact might be
> > limited?
> 
> If you're suggesting to fix this in a more generic way, I'm all for it.

I'm suggesting to not fix it ;)  That said, is TSAN a useful vehicle?

[Bug c++/110802] New: Missing warning for attribute deprecated on a function template definition with a previous declaration

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

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

Bug ID: 110802
   Summary: Missing warning for attribute deprecated on a function
template definition with a previous declaration
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template
void
random_shuffle(RAIter, RAIter);

template
__attribute__ ((deprecated))
void
random_shuffle(RAIter, RAIter) { }

int main()
{
  int* p = 0;
  random_shuffle(p, p);
}


This is based on std::random_shuffle in libstdc++, which I noticed warns with
Clang but not with GCC.

I added the attribute in r12-2700-g7f2f4b87910506 but it's never warned with
GCC. This doesn't seem to be a regression, as GCC 4.1.2 doesn't warn either.

[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #5 from Roger Sayle  ---
I'll add this testcase to the testsuite, when I apply a corrected version of my
QImode offset patch to mainline.  On the bright side, we'll be generating more
efficient code for gmp's refmpn_tstbit by using the x86's bt instruction (it
just needs to use setc not setnc in this case).

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> 
> --- Comment #6 from Kewen Lin  ---
> (In reply to rguent...@suse.de from comment #5)
> > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > 
> > I think apart from the consideration what a single element vector
> > is compared to a scalar, a more to-the-point fix is
> > 
> >   if (VECTOR_TYPE_P (ltype)
> >   && memory_access_type != VMAT_ELEMENTWISE)
> 
> Thanks for the suggestion! I thought checking lnel can also cover
> VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
> to have?

I think so, unless I'm convinced with a testcase ;)

[Bug libstdc++/110801] New: std::format code runs slower than equivalent {fmt} code

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

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

Bug ID: 110801
   Summary: std::format code runs slower than equivalent {fmt}
code
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Using the benchmark from
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0645r10.html#Benchmarks
and adding:

#if __has_include()
#include 
#endif

#ifdef __cpp_lib_format
void std_format(benchmark::State& s) {
  size_t result = 0;
  while (s.KeepRunning()) {
for (auto i: data)
  result += std::format("{}", i).size();
  }
  benchmark::DoNotOptimize(result);
}
BENCHMARK(std_format);

void std_format_to(benchmark::State& s) {
  size_t result = 0;
  while (s.KeepRunning()) {
for (auto i: data) {
  char buffer[12];
  result += std::format_to(buffer, "{}", i) - buffer;
}
  }
  benchmark::DoNotOptimize(result);
}
BENCHMARK(std_format_to);
#endif

I get:

Benchmark  Time CPU   Iterations

sprintf   708600 ns   706474 ns  946
ostringstream1216025 ns  1210087 ns  589
to_string 178579 ns   178088 ns 3824
format306344 ns   305365 ns 2345
format_to 145606 ns   145223 ns 4940
std_format514969 ns   513563 ns 1376
std_format_to 436502 ns   435402 ns 1567

The std::to_string performance is good, but std::format is much slower than
fmt::format.

[Bug libstdc++/110739] std::format for chrono types compiles very slowly

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

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

--- Comment #3 from Jonathan Wakely  ---
Explicit instantiation declarations+definitions might help, both in 
and .

[Bug c++/108099] [12 Regression] ICE with type alias with `signed __int128_t`

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||13958014620 at 139 dot com

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

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
   Keywords|needs-bisection |

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> I almost positive this was fixed by r14-159-g03cebd304955a6 which was
> backported to GCC 13 branch r13-7277-ga713aa4f47ac1e (for 13.2.0) .

Yes, bisection confirms it. So this is a dup.

Aside: I'm not sure I'd call this a wrong-code bug. The testcase would be
simpler if it used static_assert instead of assert, which would make it
accepts-invalid / rejects-valid instead.

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

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to miles from comment #0)
> typedef char ch_t;
> assert( sizeof(unsigned char) == 1); //right
> assert( sizeof(ch_t) == 1 ); //right
> assert( sizeof(unsigned ch_t) == 1); //the only one right

This is not valid C++, you can't use 'signed' and 'unsigned' with typedefs.

Use std::make_unsigned_t

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

--- Comment #3 from Jakub Jelinek  ---
The data race is harmless as we don't use the value.
&& (flag_sanitize & SANITIZE_THREAD) == 0
is not right, it should be
&& !sanitize_flags_p (SANITIZE_THREAD)
or so.

[Bug target/110800] [gcn] ICE (segfault) 'during RTL pass: jump' in delete_trivially_dead_insns -> count_reg_usage when C++ exceptions are enabled + used

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

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[gcn] ICE (segfault)|[gcn] ICE (segfault)
   |'during RTL pass: jump' in  |'during RTL pass: jump' in
   |delete_trivially_dead_insns |delete_trivially_dead_insns
   |-> count_reg_usage  |-> count_reg_usage when C++
   ||exceptions are enabled +
   ||used

--- Comment #1 from Tobias Burnus  ---
The ICE is turned into plenty of linker errors (such as 'undefined symbol:
operator delete[](void*)') when compiling with:

   -fno-exceptions

It seems as if something goes wrong when exceptions are encountered. Still, an
ICE is wrong.

For the sister testcase, test_target_struct_obj_access.cpp (same pull request),
it fails with tons of:
  cc45cyOP.mkoffload.2.s:2601:1: error: symbol '.LEHE1' is already defined

That's actually how I found the -fno-exception as LEHE is added in
  gcc/except.cc:  ASM_GENERATE_INTERNAL_LABEL (reg_start_lab, "LEHB",
call_site_base + i);
  gcc/final.cc: ASM_OUTPUT_DEBUG_LABEL (asm_out_file, "LEHB",

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> We consider introducing load data races OK, what's the difference here? 

This is a load vs. store data race.

> There are other passes that would do similar things but in practice the
> loads would be considered to possibly trap so the real-world impact might be
> limited?

If you're suggesting to fix this in a more generic way, I'm all for it.

[Bug target/110800] New: [gcn] ICE (segfault) 'during RTL pass: jump' in delete_trivially_dead_insns -> count_reg_usage

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

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

Bug ID: 110800
   Summary: [gcn] ICE (segfault) 'during RTL pass: jump' in
delete_trivially_dead_insns -> count_reg_usage
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: grahams at gcc dot gnu.org
  Target Milestone: ---
Target: amdgcn-amdhsa

Testcase is test_target_PureVirDestr.cpp at
https://github.com/SOLLVE/sollve_vv/pull/751

Simply go to any sollve_vv directory, run "wget" on
https://raw.githubusercontent.com/SOLLVE/sollve_vv/a3be96d534124e744acc979e2e33b402a1b330cd/tests/5.2/unified_shared_mem/test_target_PureVirDestr.cpp


And then compile, e.g. as follows. (Tested with mainline; comments in the pull
request indicate that OG13 fails identically.)

g++ -foffload-options=-march=gfx90a -fopenmp -I ompvv/ -DVERBOSE_MODE=1
test_target_PureVirDestr.cpp



The segfault happens for:

#0  0x019175cc in count_reg_usage (x=, counts=0x2e618e0,
dest=, incr=1) at gcc/rtl.h:1934
1934  return REG_CHECK (x)->regno;

which is called (same function) as

1511  return XEXP (insn, 3);

which is called in

#2  0x0191c86b in delete_trivially_dead_insns (insns=,
nreg=514)at gcc/cse.cc:7012
7012  count_reg_usage (insn, counts, NULL_RTX, 1);
(gdb) p debug_rtx(insn)
(insn 132 133 119 7 (set (reg:DI 508)
(reg:DI -1)) "test_target_PureVirDestr.cpp":57:5 8 {*movdi_insn}
 (nil))



The ICE is:

during RTL pass: jump
test_target_PureVirDestr.cpp: In member function '__ct_base ':
test_target_PureVirDestr.cpp:57:5: internal compiler error: Segmentation fault
   57 | }
  | ^
0x101ad9f crash_signal  gcc/toplev.cc:314
0x7f463959408f ???  sysv/linux/x86_64/sigaction.c:0
0x19175cc count_reg_usage  gcc/cse.cc:6748
0x19173ea count_reg_usage  gcc/cse.cc:6788
0x191c86a delete_trivially_dead_insns(rtx_insn*, int)
gcc/cse.cc:7012
0x18dc5c6 execute  gcc/cfgcleanup.cc:3237
...
gcn mkoffload: fatal error:
../../install/bin/x86_64-none-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit
status
compilation terminated.
lto-wrapper: fatal error:
.../install/libexec/gcc/x86_64-none-linux-gnu/14.0.0//accel/amdgcn-amdhsa/mkoffload
returned 1 exit status

[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
We consider introducing load data races OK, what's the difference here?  There
are other passes that would do similar things but in practice the loads would
be considered to possibly trap so the real-world impact might be limited?

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||13.1.1, 14.0

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #15 from Roger Sayle  ---
Hi Richard,
There's another patch awaiting review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625282.html
and I've another follow-up after that currently regression testing...

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

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

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

--- Comment #14 from Richard Biener  ---
compile-time is back to the first jump caused by r14-2337-g37a231cc7594d1,
thanks Roger.  We still have

 LRA non-specific   :   3.53 ( 75%)

at -O0 here which Rogers followup patch will improve (but not generally
solve the issue).

At -O1 combine dominates, at -O2 we see other parts of RA being slow:

 integrated RA  :   7.10 ( 23%) 
 LRA non-specific   :   1.56 (  5%)
 LRA virtuals elimination   :   0.07 (  0%)
 LRA reload inheritance :   1.02 (  3%)
 LRA create live ranges :   0.88 (  3%)
 LRA hard reg assignment:   8.22 ( 27%)
 LRA coalesce pseudo regs   :   0.00 (  0%)
 LRA rematerialization  :   0.18 (  1%)

Samples: 124K of event 'cycles:u', Event count (approx.): 164730867020  
Overhead   Samples  Command  Shared Object   Symbol 
  16.60% 20660  cc1  cc1 [.] find_hard_regno_for_1
  11.90% 14742  cc1  cc1 [.] bitmap_set_bit
   6.47%  7973  cc1  cc1 [.] color_allocnos
   3.31%  4023  cc1  cc1 [.] bitmap_bit_p
   3.07%  3791  cc1  cc1 [.]
remove_allocno_from_bucket_and_push
   2.77%  3435  cc1  cc1 [.] assign_hard_reg
   2.54%  3138  cc1  cc1 [.] ira_build_conflicts

in find_hard_regno_for_1 the loop over live ranges is what's costly, esp.
because it seems the conditionals in the loops depend on (indirect) memory
and that no longer fits nicely into caches.

Maybe regno_allocno_class_array can be shrunk from 'enum reg_class'
(unsigned int) to something smaller.  It looks like this array is a
memory optimization since reg_allocno_class would perform a much sparser
access.

[Bug c++/110797] template keyword used as a distinguisher with concept to reject for auto usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107188
   Last reconfirmed||2023-07-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed. Very much related to PR 107188 .

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

[13958014620 at 139 dot com via Gcc-bugs]

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

--- Comment #2 from miles <13958014620 at 139 dot com> ---
(In reply to Andrew Pinski from comment #1)
> I almost positive this was fixed by r14-159-g03cebd304955a6 which was
> backported to GCC 13 branch r13-7277-ga713aa4f47ac1e (for 13.2.0) .

OK,Andrew
Thx for reply

[Bug c++/110797] template keyword used as a distinguisher with concept to reject for auto usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|GCC rejects std::template   |template keyword used as a
   |same_as form   |distinguisher with concept
   ||to reject for auto usage
   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
namespace tt {
template
concept t = true;
}

tt::template t auto i = 0;
```

[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #22 from JuzheZhong  ---
(In reply to rsand...@gcc.gnu.org from comment #20)
> (In reply to Richard Biener from comment #19)
> > Sure, I can kind of see the usefulness elsewhere.  Just for this particular
> > issue it doesn't seem necessary to sit down and design this when we can
> > represent it like we do for MASK_LOAD (omit the 'else' value).
> Yeah, that's fair.
> 
> For the ifn->optab interface, I think it'd be natural to use an actual rtx
> rather than a null pointer, since e.g. predicates are not set up to handle
> nulls.  So perhaps we should start the process there.  We could add an UNDEF
> rtl code that is initially only used for the ifn->optab interface, and
> expand it as we find new use cases.  We can grow the semantics based on
> those use cases and based on LLVM's experience.
> 
> > In other context we discussed specifying zero for MASK_LOAD masked elements
> > so we can for example CSE better.  CSE with UNDEF might be possible as well,
> > but I'm not sure what LLVM's undef would allow and whether it's defined
> > rigidly enough.
> One of the main optimisations I wanted from that was:
>   a = IFN_MASK_LOAD (…, mask)
>   b = VEC_COND_EXPR 
> →
>   a = IFN_MASK_LOAD (…, mask)
>   b = a
> which wouldn't be valid for undef.

In RVV, we define a "undef" rtx which is:

(unspec:V256HF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)


So, RVV pattern as defined as follows:

(define_insn "@pred_"
  [(set (match_operand:VI 0 "register_operand"  "=vd,vd, vr, vr")
(if_then_else:VI
  (unspec:
[(match_operand: 1 "vector_mask_operand" "vm,vm,Wc1,Wc1")
 (match_operand 4 "vector_length_operand""rK,rK, rK, rK")
 (match_operand 5 "const_int_operand"" i, i,  i,  i")
 (match_operand 6 "const_int_operand"" i, i,  i,  i")
 (match_operand 7 "const_int_operand"" i, i,  i,  i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
  (any_int_unop:VI
(match_operand:VI 3 "register_operand"   "vr,vr, vr, vr"))
  (match_operand:VI 2 "vector_merge_operand" "vu, 0, vu,  0")))]
  "TARGET_VECTOR"
  "v.v\t%0,%3%p1"
  [(set_attr "type" "vialu")
   (set_attr "mode" "")
   (set_attr "vl_op_idx" "4")
   (set (attr "ta") (symbol_ref "riscv_vector::get_ta(operands[5])"))
   (set (attr "ma") (symbol_ref "riscv_vector::get_ma(operands[6])"))
   (set (attr "avl_type") (symbol_ref "INTVAL (operands[7])"))])

You can see operand:

(match_operand:VI 2 "vector_merge_operand" "vu, 0, vu,  0")


There is a constraint "vu": 

(define_constraint "vu"
  "A undefined vector value."
  (and (match_code "unspec")
   (match_test "XINT (op, 1) == UNSPEC_VUNDEF")))


RA will match constraint "vu" for "undef" else value.

(insn 10 9 0 2 (set (mem:V256HF (reg/v/f:DI 136 [ out ]) [1 MEM[(v256hf
*)out_4(D)]+0 S512 A128])
(if_then_else:V256HF (unspec:V256BI [
(const_vector:V256BI [
(const_int 1 [0x1]) repeated x256
])
(reg:DI 138)
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(reg/v:V256HF 134 [ v ])
(unspec:V256HF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) "rvv.c":18:17 1156 {pred_movv256hf}
 (nil))

You can see:
(unspec:V256HF [
(reg:SI 0 zero)
] UNSPEC_VUNDEF)


Then such operand will not consume a register.

This is currently how RVV model "undef" in RTL backend.

[Bug sanitizer/110799] New: [tsan] False positive due to -fhoist-adjacent-loads

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

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

Bug ID: 110799
   Summary: [tsan] False positive due to -fhoist-adjacent-loads
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I build gdb with -O2 -fsanitizer=thread, and ran into a false positive due to
-fhoist-adjacent-loads.

Minimal example:
...
$ cat race.c
#include 
#include 

int c;

struct s
{
  int a;
  int b;
};

struct s v1;

int v3;

void *
thread1 (void *x)
{
  v1.a = 1;
  return NULL;
}

void *
thread2 (void *x)
{
  v3 = c ? v1.a : v1.b;
  return NULL;
}

int
main (void)
{
  pthread_t t[2];

  pthread_create([0], NULL, thread1, NULL);
  pthread_create([1], NULL, thread2, NULL);

  pthread_join(t[0], NULL);
  pthread_join(t[1], NULL);

  return 0;
}
...

With O0, runs fine:
...
$ gcc race.c -fsanitize=thread -g
$ ./a.out 
$
...

With O2, a race is reported:
...
$ gcc race.c -fsanitize=thread -g -O2
$ ./a.out 
==
WARNING: ThreadSanitizer: data race (pid=24538)
  Read of size 4 at 0x00404060 by thread T2:
#0 thread2 /data/vries/gdb/race.c:26 (a.out+0x401299) (BuildId:
295673549b1e99c73c70a2a8d26944f177f88c15)
#1   (libtsan.so.2+0x3c329) (BuildId:
8f2a9be581a0fcb3d7109755a6067408093b9dbd)

  Previous write of size 4 at 0x00404060 by thread T1:
#0 thread1 /data/vries/gdb/race.c:19 (a.out+0x401257) (BuildId:
295673549b1e99c73c70a2a8d26944f177f88c15)
#1   (libtsan.so.2+0x3c329) (BuildId:
8f2a9be581a0fcb3d7109755a6067408093b9dbd)
...

With -fno-hoist-adjacent-loads, it's fine again:
...
$ gcc race.c -fsanitize=thread -g -O2 -fno-hoist-adjacent-loads
$ ./a.out 
$
...

The optimization transforms these loads:
...
  v3 = c ? v1.a : v1.b;
...
into:
...
  int tmp_a = v1.a;
  int tmp_b = v1.b;
  v3 = c ? tmp_a : tmp_b
...
which introduces the false positive.

So I wonder if there should be a change like this:
...
 static bool
 gate_hoist_loads (void)
 {
   return (flag_hoist_adjacent_loads == 1
+  && (flag_sanitize & SANITIZE_THREAD) == 0
   && param_l1_cache_line_size
   && HAVE_conditional_move);
 }
...

[Bug c++/110798] [12 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12/13 Regression] The  |[12 Regression] The reusult
   |reusult of sizeof operator  |of sizeof operator followed
   |followed with an 'unsigned  |with an 'unsigned
   |typedef-ed generic integer' |typedef-ed generic integer'
   |type is alway 4 |type is alway 4
   |bytes（except char）  |bytes（except char）
  Known to work||13.1.1

--- Comment #1 from Andrew Pinski  ---
I almost positive this was fixed by r14-159-g03cebd304955a6 which was
backported to GCC 13 branch r13-7277-ga713aa4f47ac1e (for 13.2.0) .

[Bug c++/110798] [12/13 Regression] The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
   Keywords||needs-bisection
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108099

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

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

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

--- Comment #6 from Kewen Lin  ---
(In reply to rguent...@suse.de from comment #5)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> 
> I think apart from the consideration what a single element vector
> is compared to a scalar, a more to-the-point fix is
> 
>   if (VECTOR_TYPE_P (ltype)
>   && memory_access_type != VMAT_ELEMENTWISE)

Thanks for the suggestion! I thought checking lnel can also cover
VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
to have?  Then it's more clear with explicit VMAT_ELEMENTWISE checking.

[Bug c++/110798] New: The reusult of sizeof operator followed with an 'unsigned typedef-ed generic integer' type is alway 4 bytes（except char）

[13958014620 at 139 dot com via Gcc-bugs]

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

Bug ID: 110798
   Summary: The reusult of sizeof operator followed with an
'unsigned typedef-ed generic integer' type is alway 4
bytes（except char）
   Product: gcc
   Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 13958014620 at 139 dot com
  Target Milestone: ---

Some issues arised when doing some tests.
The reusult of sizeof operator followed with an 'unsigned typedef-ed generic
integer' type is always 4 bytes（except char）.

The following example had run in fedora 37 OS with gcc_12.3.1 and
gcc_13.1.0(compiled myself), both versions of gcc show the same issue.


#include 
int main(int argc, char ** argv){
int ret=0;

typedef char ch_t;
assert( sizeof(unsigned char) == 1); //right
assert( sizeof(ch_t) == 1 ); //right
assert( sizeof(unsigned ch_t) == 1); //the only one right

typedef signed char sch;
assert( sizeof(unsigned char) == 1); //right
assert( sizeof(sch) == 1 ); //right
assert( sizeof(unsigned sch) == 4); //wrong, which should be 1

typedef short sint;
assert( sizeof(unsigned short) == 2 ); //right
assert( sizeof(sint) == 2 ); //right
assert( sizeof(unsigned sint) == 4); //wrong, which should be 8

typedef long lint;
assert( sizeof(unsigned long) == 8); //right
assert( sizeof(lint) == 8 ); //right
assert( sizeof(unsigned lint) == 4); //wrong, which should be 8

typedef long long llint;
assert( sizeof(unsigned long long) == 8); //right
assert( sizeof(llint) == 8 ); //right
assert( sizeof(unsigned llint) ==4); //wrong, which should be 8

/* The same errors as: 
   'typedef signed short ssint', 
   'typedef signed long slint', 
   'typedef signed long long sllint', 
   'typedef unsigned short usint', 
   'typedef unsigned long ulint', 
   'typedef unsigned long long ullint', 
so that seems all sizeof(unsigned ) == 4, 
except typedef char ch_t;
*/
return ret;
}
--- or a version outputting the result on the terminal --

#include 
#include 
using namespace std;
int main(int argc, char ** argv){
int ret=0;

typedef char ch_t;
cout << "typedef char ch_t;"<) == 4,
\n\
except typedef char ch_t;" << endl;
return ret;
}

These issues can't reproduce in pure C language with GCC 12 and 13.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> 
> Kewen Lin  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #3 from Kewen Lin  ---
> The failure exposed one special case: there is one stmt 
> 
> # VUSE <.MEM_404>
> _15 = *_14;
> 
> its STMT_VINFO_STRIDED_P (stmt_info) is set, memory_access_type is
> VMAT_ELEMENTWISE and alignment_support_scheme is dr_unaligned_supported, its
> vector type is "vector(1) long int", so in the handling it's taken as:
> 
>   /* Load vector(1) scalar_type if it's 1 element-wise vectype.  */
>   else if (nloads == 1)
> ltype = vectype;
> 
> as its ltype is vector type, we cost it with 
> 
>   if (VECTOR_TYPE_P (ltype))
> vect_get_load_cost (vinfo, stmt_info, 1,
> alignment_support_scheme, 
> misalignment,
> false, _cost, nullptr, 
> cost_vec,
> cost_vec, true);
> 
> as it's dr_unaligned_supported, it's costed as unaligned_load then causes the
> ICE. One idea is to teach rs6000_builtin_vectorization_cost about one single
> lane vector unaligned load as scalar_load. But I think it's simple to treat
> single lane vector load as scalar_load, as I expect veclower will lower it
> later.
> 
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index 4622d6a04ef..bdf4c12cd03 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -9985,7 +9985,9 @@ vectorizable_load (vec_info *vinfo,
>  {
>if (costing_p)
>  {
> -  if (VECTOR_TYPE_P (ltype))
> +  /* For a single lane vector type, we should cost it as
> + scalar_load to avoid ICE, see PR110776.  */
> +  if (VECTOR_TYPE_P (ltype) && lnel > 1)
>  vect_get_load_cost (vinfo, stmt_info, 1,
>  alignment_support_scheme,
> misalignment,
>  false, _cost, nullptr,
> cost_vec,
> 
> Hi Richi, what do you think of this?

I think apart from the consideration what a single element vector
is compared to a scalar, a more to-the-point fix is

  if (VECTOR_TYPE_P (ltype)
  && memory_access_type != VMAT_ELEMENTWISE)

[Bug c++/110797] New: GCC rejects std::template same_as form

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 110797
   Summary: GCC rejects std::template same_as form
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

[[maybe_unused]] std::template same_as auto i = 0;

I accidentally found that GCC rejected the above code, not sure if this is
valid code.

https://godbolt.org/z/edd6zx5df