[Bug c++/57775] default argument for template parameter error for friend definition in template

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 6+.

[Bug c++/61260] Issue with instantiates of variadic templates inside other templates (possibly name lookup problem)

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61260

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.1.0
   Target Milestone|--- |8.0
  Known to fail||7.5.0

--- Comment #3 from Andrew Pinski  ---
This is fixed in GCC 8+.

[Bug c++/61260] Issue with instantiates of variadic templates inside other templates (possibly name lookup problem)

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61260

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
.

[Bug c++/68313] "using" shadows declaration

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||5.1.0, 5.5.0
 Status|UNCONFIRMED |RESOLVED
  Known to work||6.1.0, 7.1.0
   Target Milestone|--- |6.0
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 6+.

[Bug c++/66606] missing diagnostic on using function main

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66606

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2015-08-19 00:00:00 |2021-8-5

--- Comment #2 from Andrew Pinski  ---
These are the ones which we don't catch right now:

#include 

int main () { }

typedef decltype (main) F; // xfail

F& foo () { return main; } // { dg-error "" }

int bar () { return main (); } // xfail

const std::type_info &ti = typeid (main); // xfail

const bool e = noexcept (main); // xfail

const int i = (main, 0); // xfail

template  struct A { };
A a; // { dg-error "" }

template  struct B { };
B b; // { dg-error "" }

[Bug c++/46381] G++ doesn't catch duplicate members produced by template instantiation

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46381

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1

[Bug c++/67080] Access to private using declaration incorrectly allowed

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67080

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.5.0, 6.4.0
   Target Milestone|--- |7.0
  Known to work||7.1.0

[Bug c++/67080] Access to private using declaration incorrectly allowed

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67080

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 7.

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

[Bug c++/66475] Access checking in templates circumvented with 'using' (C++11)

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66475

Andrew Pinski  changed:

   What|Removed |Added

 CC||mwarusz at gmail dot com

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

[Bug c++/80877] Derived template class can access base class's private constexpr/const static fields

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80877

--- Comment #1 from Andrew Pinski  ---
This seems fixed in GCC 11+.

[Bug other/101787] New: There's no document for cond_ashr/ashl/lshr which is introduce by r10-2540

2021-08-05 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101787

Bug ID: 101787
   Summary: There's no document for cond_ashr/ashl/lshr which is
introduce by r10-2540
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

[Bug c++/80877] Derived template class can access base class's private constexpr/const static fields

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80877

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/47346] access control for nested type is ignored in class template

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346

Andrew Pinski  changed:

   What|Removed |Added

 CC||tomasz.jankowski at nokia dot 
com

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

[Bug c++/78923] [C++98/11/14] bad error message about missing template argument

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78923

Andrew Pinski  changed:

   What|Removed |Added

Summary|bad error message about |[C++98/11/14] bad error
   |missing template argument   |message about missing
   ||template argument

--- Comment #2 from Andrew Pinski  ---
C++17 and C++20 modes give a decent error message:
:11:9: error: class template placeholder 'A' not permitted in this
context
   11 | B::B(A*) { // <-- should be:  B::B(A*) {
  | ^

C++98, 11, and 14 still give the bad one:
:11:8: error: expected constructor, destructor, or type conversion
before '(' token

I don't know how useful this is as GCC 11+ default to C++17.

[Bug target/101505] [10/11 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 0)

2021-08-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101505

--- Comment #7 from Richard Biener  ---
(In reply to David Binderman from comment #5)
> Certainly works for -O3, but doesn't for -O3 -march=bdver2.
> 
> during RTL pass: expand
> ./gcc.dg/vect/pr101505.c: In function ‘w7.simdclone.6’:
> ./gcc.dg/vect/pr101505.c:15:10: internal compiler error: in expand_mult, at
> expm
> ed.c:3585
>15 |   return xb;
>   |  ^~
> 0x91344a expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
>   ../../trunk.git/gcc/expmed.c:3585
> 
> It breaks sometime between git hash 145bc41dae7c7bfa and 14d8a5ae472ca574

This is a different bug though, probably caused by HJs changes, looks like
the fixed PR101742, indeed updating and re-building my dev tree makes the
issue go away.

gcc.dg/vect/pr101505.c:15:10: internal compiler error: in expand_mult, at
expmed.c:3585
0xe14f0a expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
/home/rguenther/src/gcc2/gcc/expmed.c:3585
0xc3584d builtin_memset_gen_str
/home/rguenther/src/gcc2/gcc/builtins.c:4124
0xe25ee4 pieces_addr::adjust(fixed_size_mode, long, by_pieces_prev*)
/home/rguenther/src/gcc2/gcc/expr.c:1036
0xe268a8 op_by_pieces_d::run()
/home/rguenther/src/gcc2/gcc/expr.c:1252
0xe273ed store_by_pieces(rtx_def*, unsigned long, rtx_def* (*)(void*, void*,
long, fixed_size_mode), void*, unsigned int, bool, memop_ret)
/home/rguenther/src/gcc2/gcc/expr.c:1579

[Bug c++/67965] gcc (incorrectly) requires template keyword in non-dependent expression

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67965

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Hmm,
GCC, ICC and clang all reject the code without the template keyword there.

[Bug target/101788] New: [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101788

Bug ID: 101788
   Summary: [12 Regression] ICE in extract_bit_field_1 at
gcc/expmed.c:1857
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Must be a recent regression:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/sve/ext_2.c -O3
-c
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/sve/ext_2.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/sve/ext_2.c:13:5:
internal compiler error: Segmentation fault
   13 |   x = __builtin_shuffle (y, y, (vnx4si) { 1, 2, 3, 4, 5, 6, 7, 8 });
  |   ~~^~~
0xbfecdf crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x8d926c extract_integral_bit_field
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expmed.c:1984
0x8d926c extract_bit_field_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expmed.c:1857
0x8d9460 extract_bit_field(rtx_def*, poly_int<2u, unsigned long>, poly_int<2u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expmed.c:2129
0x8ee982 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:11374
0x8ef4be expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:8713
0x8ef4be expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:10484
0x8fe005 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:8713
0x8fe005 expand_normal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.h:307
0x8fe005 store_field
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:7439
0x8fd4f6 store_constructor
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:7289
0x8fec81 expand_constructor
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:8634
0x8eed72 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:10819
0x8ef4be expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:8713
0x8ef4be expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:10484
0x8f926e expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:8713
0x8f926e store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:6064
0x8fa789 expand_assignment(tree_node*, tree_node*, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:5796
0x7ed16a expand_gimple_stmt_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3945
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101788] [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101788

Martin Liška  changed:

   What|Removed |Added

  Known to fail||12.0
   Last reconfirmed||2021-08-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

[Bug tree-optimization/101626] [12 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2376

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101626

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r12-2755-g4e3129b0caceec008a940aa5eada253cd0f0b3ec
Author: Eric Botcazou 
Date:   Thu Aug 5 10:21:30 2021 +0200

Fix oversight in handling of reverse SSO in SRA pass

The scalar storage order does not apply to pointer and vector components.

gcc/
PR tree-optimization/101626
* tree-sra.c (propagate_subaccesses_from_rhs): Do not set the
reverse scalar storage order on a pointer or vector component.

gcc/testsuite/
* gcc.dg/sso-15.c: New test.

[Bug c++/79668] [c++1z] inconsistent handling of parameter matching in template template arguments

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79668

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/101626] [12 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2376

2021-08-05 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101626

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug c++/80660] Member function pointer optimization affected by incompatible virtual function

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80660

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2017-05-08 00:00:00 |2021-8-5

[Bug c++/71653] error when trying to compile a code with template friend function in a struct

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71653

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-05

--- Comment #3 from Andrew Pinski  ---
Reduced testcase without includes:
template  using C = typename T::InnerType;
template  C f(T &);
class S {
using InnerType = int;
template  friend C f(T &);
};
int main()
{
S s;
f(s);
return 0;
}

[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:91f8a7a34cf29ae7c465603a801326767f1cc7e9

commit r11-8828-g91f8a7a34cf29ae7c465603a801326767f1cc7e9
Author: Martin Liska 
Date:   Thu Aug 5 10:43:17 2021 +0200

sanitizer: cherry pick 414482751452e54710f16bae58458c66298aaf69

The patch is needed in order to support recent glibc (2.34).

libsanitizer/ChangeLog:

PR sanitizer/101749
* sanitizer_common/sanitizer_posix_libcdep.cpp: Prevent
generation of dependency on _cxa_guard for static
initialization.

[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

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

commit r10-10020-g6bbaa64881715b8df2d717e418eeec7b7e974a22
Author: Martin Liska 
Date:   Thu Aug 5 10:43:17 2021 +0200

sanitizer: cherry pick 414482751452e54710f16bae58458c66298aaf69

The patch is needed in order to support recent glibc (2.34).

libsanitizer/ChangeLog:

PR sanitizer/101749
* sanitizer_common/sanitizer_posix_libcdep.cpp: Prevent
generation of dependency on _cxa_guard for static
initialization.

[Bug c++/71653] error when trying to compile a code with template friend function in a struct

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71653

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #4 from Andrew Pinski  ---
If I don't use an alias template in the original declaration of f it works:
template  using C = typename T::InnerType;
template  typename T::InnerType f(T &);
class S {
using InnerType = int;
template  friend C f(T &);
};
int main()
{
S s;
f(s);
return 0;
}

[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:11e2ac8f75060d9be432e8db1f358298a75c98d4

commit r9-9661-g11e2ac8f75060d9be432e8db1f358298a75c98d4
Author: Martin Liska 
Date:   Thu Aug 5 10:43:17 2021 +0200

sanitizer: cherry pick 414482751452e54710f16bae58458c66298aaf69

The patch is needed in order to support recent glibc (2.34).

libsanitizer/ChangeLog:

PR sanitizer/101749
* sanitizer_common/sanitizer_posix_libcdep.cc: Prevent
generation of dependency on _cxa_guard for static
initialization.

[Bug sanitizer/101749] gcc -static-libasan broken because libasan.a needs __cxa_guard_release in libstdc++

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Fixes now on all active branches.

[Bug sanitizer/100114] libasan built against latest glibc doesn't work

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
Bug 100114 depends on bug 101749, which changed state.

Bug 101749 Summary: gcc -static-libasan broken because libasan.a needs 
__cxa_guard_release in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749

   What|Removed |Added

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

[Bug c++/94162] ICE [neg] bad return type in defaulted <=>

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94162

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.1.0
  Known to fail||10.1.0

--- Comment #9 from Andrew Pinski  ---
None of the testcases ICE in GCC 11+

[Bug bootstrap/101776] [12 Regression] Boootstrap broken on s390x

2021-08-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101776

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Target||s390x-linux-gnu

[Bug c++/80771] GCC ignores default template argument declaration in the template definition

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80771

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 65396.

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

[Bug c++/65396] Function template default template arguments not merged

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396

Andrew Pinski  changed:

   What|Removed |Added

 CC||devgs at ukr dot net

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

[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW

2021-08-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101779

Richard Biener  changed:

   What|Removed |Added

 Target||mingw32
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1
   Keywords||build

--- Comment #1 from Richard Biener  ---
It looks like rust-demanlge.c is newer in the binutils repository than in the
GCC repository.  I cannot find the referenced code in the GCC one.  Can you
report the issue to the bugzilla at sourceware.org please?

[Bug c++/93415] Previous declaration of template without default arguments leads to incorrect overload resolution

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93415

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Keywords|accepts-invalid,|
   |rejects-valid   |
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This is a dup of bug 65396 .

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

[Bug c++/65396] Function template default template arguments not merged

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396

Andrew Pinski  changed:

   What|Removed |Added

 CC||Predelnik at gmail dot com

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

[Bug c++/65396] Function template default template arguments not merged

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396

--- Comment #7 from Andrew Pinski  ---
The testcase from PR 93415 shows this can produce wrong code too:
template 
void f (int);
template 
void f (int) {}

template 
void f (char) { __builtin_abort (); }

int main ()
{
f (0);
return 0;
}

[Bug middle-end/101787] There's no document for cond_ashr/ashl/lshr which is introduce by r10-2540

2021-08-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101787

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed, md.texi amendments are missing.

[Bug c++/53360] g++ prints 'invalid use of incomplete type' error when compiling code with -std=gnu++0x and newer

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53360

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #6 from Jonathan Wakely  ---
Fixed by r11-7289:

c++: Tweak PR969626 patch

It occurred to me that other types of conversions use
rvaluedness_matches_p,
but those uses don't affect overload resolution, so we shouldn't look at
the
flag for them.  Fixing that made decltype64.C compile successfully, because
the non-template candidate was a perfect match, so we now wouldn't consider
the broken template.  Changing the argument to const& makes it no longer a
perfect match (because of the added const), so we again get the infinite
recursion.

This illustrates the limited nature of this optimization/recursion break;
it
works for most copy/move constructors because the constructor we're looking
for is almost always a perfect match.  If it happens to help improve
compile
time for other calls, that's just a bonus.

gcc/cp/ChangeLog:

PR c++/96926
* call.c (perfect_conversion_p): Limit rvalueness
test to reference bindings.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype64.C: Change argument to const&.

Which was a follow-up to r11-7287:

c++: Tuple of self-dependent classes [PR96926]

When compiling this testcase, trying to resolve the initialization for the
tuple member ends up recursively considering the same set of tuple
constructor overloads, and since two of them separately depend on
is_constructible, the one we try second fails to instantiate
is_constructible because we're still in the middle of instantiating it the
first time.

Fixed by implementing an optimization that someone suggested we were
already
doing: if we see a non-template candidate that is a perfect match for all
arguments, we can skip considering template candidates at all.  It would be
enough to do this only when LOOKUP_DEFAULTED, but it shouldn't hurt in
other
cases.

gcc/cp/ChangeLog:

PR c++/96926
* call.c (perfect_conversion_p): New.
(perfect_candidate_p): New.
(add_candidates): Ignore templates after a perfect non-template.

gcc/testsuite/ChangeLog:

PR c++/96926
* g++.dg/cpp0x/overload4.C: New test.

Thi might be a dup of PR 96926 but we could add the testcase to be sure.

[Bug c++/81508] Warning: Control reaches end of non-void function - noreturn attribute ignored if nontrivial destructor runs afterwards

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81508

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80032
 Resolution|--- |FIXED
   Keywords||diagnostic
   Target Milestone|--- |7.0

--- Comment #6 from Andrew Pinski  ---
So this was fixed in GCC 7 (and maybe 6.5.0)  only by accident.  In the sense
the patches to fix PR 80032 caused the IR to be enough better that GCC no
longer warns.

[Bug c++/86183] Scoped enumeration instantiated even if not required

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86183

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 49224.

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

[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49224

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

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

[Bug c++/101789] New: Fails to match (re-)declaration of member function of class template when using an alias template for the (dependent) return type

2021-08-05 Thread davveston at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101789

Bug ID: 101789
   Summary: Fails to match (re-)declaration of member function of
class template when using an alias template for the
(dependent) return type
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davveston at gmail dot com
  Target Milestone: ---

(Broken out into a separate report, from my comment to Bug 69348, after prompt
by Andrew Pinski)

---

The following program 

template
struct S {
using type = int;
type f() const;  // #1
};

template
using type_t = typename S::type;

template 
type_t S::f() const { }  // #2a
// error: no declaration matches 'type_t S::f() const'

int main() {}


is rejected e.g. for GCC 11.1.0 for all C++ versions (-std=c++X with X in {11,
17, 2a/2b}), failing to match the (re-)declaration and definition at #2a of the
member function of the class template at #1, when using an alias template for
the dependent return type of the member function. Clang accepts this program.

The program is accepted if we remove the alias template

template 
typename S::type S::f() const { }  // #2b: OK

[Bug c++/69348] alias declarations can not be used inside qualifiers of declarators

2021-08-05 Thread davveston at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69348

--- Comment #5 from David Friberg  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Friberg from comment #2)
> > Another similar but more common (/less contrived) example, rejects-valid
> > e.g. for GCC 10.1.0 for all C++ version (-std=c++X with X in {98, 11, 17,
> > 2a/20}).
> 
> This is a different issue and should be filed seperately.

Thanks for the prompt Andrew. I filed Bug 101789.

[Bug c++/101687] Scoped enumerators of a member enumeration shall not be referred by a class member access expression

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1

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

GCC 4.7.4 used to ICE on this.

[Bug c++/95937] ICE in finish_class_member_access_expr, at cp/typeck.c:3133

2021-08-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937

--- Comment #2 from Andrew Pinski  ---
Note this does not ICE with -std=c++11 or -std=c++98 :).

[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #51260|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Created attachment 51265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51265&action=edit
gcc12-pr100977-2.patch

Here is an updated (but so far only very lightly tested) patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576748.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576749.html
patches, including the pedwarn for "is not in NFC" and testsuite coverage.

[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101779

--- Comment #2 from Jonathan Wakely  ---
Binutils 2.37 has the fix for GCC PR 99935 included, so I suggest adding a
comment to that bug instead.

[Bug demangler/99935] Stack exhaustion demangling rust mangled name

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935

--- Comment #2 from Jonathan Wakely  ---
This patch breaks MinGW, see PR 101779

[Bug c++/88694] constexpr isn't captured correctly in lambda

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694

--- Comment #6 from Jonathan Wakely  ---
Fixed by r11-88:

c++: Avoid inconsistency in lambda fn's this pointer name [pr94807]

* coroutines.cc (morph_fn_to_coro): Just check for
closure_identifier.
* pt.c (tsubst_function_decl): Update lambda fn's this_ptr name.


We could add the testcase from comment 4.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061

--- Comment #5 from Jonathan Wakely  ---
This bug is still present on trunk when -fconcepts-ts is used, even in C++20
mode:

$ g++ -c 68061.C -std=c++20 
$ g++ -c 68061.C -std=c++20 -fconcepts-ts
68061.C:3:1: error: two consecutive ‘[’ shall only introduce an attribute
before ‘[’ token
3 | [[deprecated]] void f(T);
  | ^

It also affects [[nodiscard]] and so caused PR 101782.

[Bug testsuite/101782] [12 regression] Excess errors in g++.dg/cpp2a/concepts-pr67774.C after r12-2729

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101782

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Keywords|rejects-valid   |
  Component|c++ |testsuite
 Depends on||68061

--- Comment #3 from Jonathan Wakely  ---
The FE bug is PR 68061.

Changing component back to testsuite so this bug is only about the failing
test, not the FE bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061
[Bug 68061] Can't use [[deprecated]] with requires clause

[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW

2021-08-05 Thread eliz at gnu dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101779

--- Comment #3 from Eli Zaretskii  ---
(In reply to Jonathan Wakely from comment #2)
> Binutils 2.37 has the fix for GCC PR 99935 included, so I suggest adding a
> comment to that bug instead.

I see that you already reported the issue there (thanks!), so I guess I don't
need to do anything else?

[Bug c++/36961] fails to identify template

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #11 from Jonathan Wakely  ---
Probably fixed by either:

Implement P0522R0, matching of template template arguments.

gcc/c-family/
* c.opt (-fnew-ttp-matching): New flag.
* c-opts.c (c_common_post_options): Default on if -std=c++1z.
gcc/cp/
* pt.c (coerce_template_template_parms): Allow a template argument
that's less specialized than the parameter.
(unify_bound_ttp_args): Adjust parm's args to apply to arg's
template.
(coerce_template_args_for_ttp): Split out from
lookup_template_class_1.
(coerce_ttp_args_for_tta, store_defaulted_ttp)
(lookup_defaulted_ttp, add_defaults_to_ttp): New.
(process_partial_specialization): Set DECL_CONTEXT of
template template-parameters.
(coerce_template_parms): Only inform when complain.
(expand_template_argument_pack): Handle error_mark_node.
(convert_template_argument, template_args_equal, unify): Handle
any_targ_node.
* cp-tree.h (enum cp_tree_index): Add CPTI_ANY_TARG.
(any_targ_node): New.
* decl.c (cxx_init_decl_processing): Set it.
* name-lookup.c (consider_binding_level): Ignore names with
embedded
spaces.

From-SVN: r243871

or:

PR c++/42329 - deducing base template for template template arg

* pt.c (unify_bound_ttp_args): Split out from unify.
(try_class_unification): Handle BOUND_TEMPLATE_TEMPLATE_PARM.
(unify): Check for type/non-type mismatch early.
[BOUND_TEMPLATE_TEMPLATE_PARM]: Try get_template_base.

From-SVN: r243870


I think it's the latter, and this is a dup of PR 42329.

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

[Bug c++/42329] Deduction of template template argument via base class fails

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42329

Jonathan Wakely  changed:

   What|Removed |Added

 CC||igodard at pacbell dot net

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

[Bug c++/61504] Move elision after cast to rvalue reference

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61504

--- Comment #2 from Jonathan Wakely  ---
Fixed by r245538:

PR c++/79533 - C++17 ICE with temporary cast to reference

* call.c (build_over_call): Conversion to a reference prevents copy
elision.

[Bug c++/62293] Obscure error message: declared as an 'inline' field

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62293

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed by r12-1822 and r11-8662 for PR100752

The testsuite/g++.dg/parse/saved1.C previously had a poor "as a non-function"
diagnostic which was changed to "'size_t' has not been declared" which seems to
cover this case as well. So I think we can close this.

[Bug analyzer/101781] make_unique generating a warning with -fanalyzer

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101781

--- Comment #1 from Jonathan Wakely  ---
The analyzer doesn't really support C++ yet.

[Bug testsuite/101782] [12 regression] Excess errors in g++.dg/cpp2a/concepts-pr67774.C after r12-2729

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101782

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #1)
> This is a C++ FE bug.
> 
> This valid C++20 code:
> 
> template concept foo = true;
> 
> template requires foo
> [[nodiscard]]
> int bar(T) { return 1; }
> 
> is rejected with the -fconcepts-ts flag (as both C++20 and C++17):
> 
> conc.C:4:1: error: two consecutive ‘[’ shall only introduce an attribute
> before ‘[’ token
> 4 | [[nodiscard]]
>   | ^
> 
> For C++17 mode, -fconcepts-ts defines __cpp_concepts=201507L so we could use
> that to suppress the [[nodiscard]] attributes when the flag is given.
> 
> But we can't detect it for C++20 mode (which is when the testsuite errors
> happen) because C++20 defines __cpp_concepts=201907L and -fconcepts-ts
> doesn't change that. So I'm not sure what we can do, other than not apply
> the attribute to constrained functions with a requires-clause.

This is because with -fconcepts-ts the requires-clause argument is parsed as
logical-or-expression rather than constraint-logical-or-expression and for the
former the [ could be part of postfix-expression in there.  Bet that is the
reason why constraint-logical-or-expression exists and allows only
primary-expressions mixed with ||s and &&s.
Perhaps the FE could have a hack, set some parser flag when parsing
requires-clause and in postfix-expression parsing if that flag is set instead
of the [[ error in there pretend [ is not there and ends the expression.

[Bug c++/59790] Inner template class specialization has no direct access to outer template class typedefs

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59790

--- Comment #4 from Jonathan Wakely  ---
Fixed by r262637 and r262639

[PR c++/86374] Name lookup failure in enclosing template

https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00701.html
PR c++/86374
* pt.c (lookup_template_class_1): Use tsubst_aggr_type for
contexts that are classes.

PR c++/86374
* g++.dg/pr86374.C: New.

[Bug c++/66484] Exception specification can declare a pointer to incomplete type, which is against C++ standard section 15.1

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66484

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Jonathan Wakely  ---
IMO no, a pedwarn is ok, and we shouldn't waste effort on better support for
dynamic exception specs.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
This is because with -fconcepts-ts the requires-clause argument is parsed as
logical-or-expression rather than constraint-logical-or-expression and for the
former the [ could be part of postfix-expression in there.  Bet that is the
reason why constraint-logical-or-expression exists and allows only
primary-expressions mixed with ||s and &&s.
Perhaps the FE could have a hack, set some parser flag when parsing
requires-clause and in postfix-expression parsing if that flag is set instead
of the [[ error in there pretend [ is not there and ends the expression.

As a workaround,
template 
  requires true
void f [[deprecated]] (T);
works.

[Bug c++/67777] unsigned wchar_t and signed wchar_t should cause compiler errors but do not.

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6

--- Comment #4 from Jonathan Wakely  ---
Yes, it was fixed by r259780

[Bug c++/97475] An unnamed class with a typedef name for linkage purposes having a method.

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475

--- Comment #2 from Jonathan Wakely  ---
Well that's about the linkage of such entities, this is about whether they are
ill-formed.

The rule that makes this ill-formed was added by https://wg21.link/p1766r1 but
was approved as a defect report against previous standards.

[Bug c++/46589] struct member function not declared global

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589

--- Comment #9 from Jonathan Wakely  ---
This code was made ill-formed by https://wg21.link/p1766r1 (new in C++20 but a
DR against previous standards).

So GCC should just reject it (maybe with a switch to allow the old behaviour).
See PR 97475.

[Bug c++/97475] An unnamed class with a typedef name for linkage purposes having a method.

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475

--- Comment #3 from Jonathan Wakely  ---
Maybe we should make this ill-formed for C++20, and a pedwarn otherwise, so
existing code continues to compile using previous standards.

[Bug c++/101780] Missing initializers whereas structure has default initializers

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101780

--- Comment #1 from Jonathan Wakely  ---
(In reply to KL from comment #0)
> Can you confirm it is the intended behavior?

See the documentation for -Wmissing-field-initializers.

It doesn't warn about members being uninitialized, it warns about them not
being explicitly initialized, which is the case here.

The manual does say it doesn't warn about designated initializers, but it seems
the anonymous union is confusing it.

> If so, could we make the message clearer, adding: "the following designated
> fields X,Y,Z will be default initialized. P,Q,R are left uninitialized."

How would P,Q,R be left uninitialized?

> That way, it is much more useful as a warning, instead of making the dev
> fear of undefined behavior, when there is not.

It doesn't say anything about undefined behaviour.

[Bug ipa/101625] [11/12 Regression] ICE in modref_tree::merge with LTO and -m32 since r11-3825-g71dbabccbfb295c8

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101625

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Crashes due to:

│   3120  if (!ignore_stores)
│   3121{
│   3122  if (to_info && callee_info)
│  >3123to_info->stores->merge (callee_info->stores,
&parm_map);

where to_info->stores == NULL. It's likely related to partial linking.
@Honza?

[Bug c++/69302] parentheses cause address of register variable to be requested (c++1y)

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69302

--- Comment #8 from Jonathan Wakely  ---
Fixed by r253266

PR c++/56973, DR 696 - capture constant variables only as needed.

* expr.c (mark_use): Split out from mark_rvalue_use and
mark_lvalue_use.  Handle lambda capture of constant variables.
(mark_lvalue_use_nonread): New.
* semantics.c (process_outer_var_ref): Don't capture a constant
variable until forced.
* pt.c (processing_nonlambda_template): New.
* call.c (build_this): Check it.
* decl2.c (grok_array_decl): Call mark_rvalue_use and
mark_lvalue_use_nonread.
* init.c (constant_value_1): Don't call mark_rvalue_use.
* typeck.c (build_static_cast): Handle lambda capture.

[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r12-2762-gc1cdabe3aab817d95a8db00a8b5e9f6bcdea936f
Author: Richard Earnshaw 
Date:   Thu Jul 29 11:00:31 2021 +0100

arm: reorder assembler architecture directives [PR101723]

A change to the way gas interprets the .fpu directive in binutils-2.34
means that issuing .fpu will clear any features set by .arch_extension
that apply to the floating point or simd units.  This unfortunately
causes problems for more recent versions of the architecture because
we currently emit .arch, .arch_extension and .fpu directives at
different times and try to suppress redundant changes.

This change addresses this by firstly unifying all the places where we
emit these directives to a single block of code and secondly
(re)emitting all the directives if any changes have been made to the
target options.  Whilst this is slightly more than the strict minimum
it should be enough to catch all cases where a change could have
happened.  The new code also emits the directives in the order: .arch,
.fpu, .arch_extension.  This ensures that the additional architectural
extensions are not removed by a later .fpu directive.

Whilst writing this patch I also noticed that in the corner case where
the last function to be compiled had a non-standard set of
architecture flags, the assembler would add an incorrect set of
derived attributes for the file as a whole.  Instead of reflecting the
command-line options it would reflect the flags from the last file in
the function.  To address this I've also added a call to re-emit the
flags from the asm_file_end callback so the assembler will be in the
correct state when it finishes processing the intput.

There's some slight churn to the testsuite as a consequence of this,
because previously we had a hack to suppress emitting a .fpu directive
for one specific case, but with the new order this is no-longer
necessary.

gcc/ChangeLog:

PR target/101723
* config/arm/arm-cpus.in (generic-armv7-a): Add quirk to suppress
writing .cpu directive in asm output.
* config/arm/arm.c (arm_identify_fpu_from_isa): New variable.
(arm_last_printed_arch_string): Delete.
(arm_last-printed_fpu_string): Delete.
(arm_configure_build_target): If use of floating-point/SIMD is
disabled, remove all fp/simd related features from the target ISA.
(last_arm_targ_options): New variable.
(arm_print_asm_arch_directives): Add new parameters.  Change order
of emitted directives and handle all cases here.
(arm_file_start): Always call arm_print_asm_arch_directives, move
all generation of .arch/.arch_extension here.
(arm_file_end): Call arm_print_asm_arch.
(arm_declare_function_name): Call arm_print_asm_arch_directives
instead of printing .arch/.fpu directives directly.

gcc/testsuite/ChangeLog:

PR target/101723
* gcc.target/arm/cortex-m55-nofp-flag-hard.c: Update expected
output.
* gcc.target/arm/cortex-m55-nofp-flag-softfp.c: Likewise.
* gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_fpu1.c: Convert to dg-do
assemble.
Add a non-no-op function body.
* gcc.target/arm/mve/intrinsics/mve_fpu2.c: Likewise.
* gcc.target/arm/pr98636.c (dg-options): Add -mfloat-abi=softfp.
* gcc.target/arm/attr-neon.c: Tighten scan-assembler tests.
* gcc.target/arm/attr-neon2.c: Use -Ofast, convert test to use
check-function-bodies.
* gcc.target/arm/attr-neon3.c: Likewise.
* gcc.target/arm/pr69245.c: Tighten scan-assembler match, but allow
multiple instances.
* gcc.target/arm/pragma_fpu_attribute.c: Likewise.
* gcc.target/arm/pragma_fpu_attribute_2.c: Likewise.

[Bug jit/100613] libgccjit should produce dylib on macOS

2021-08-05 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100613

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|iains at gcc dot gnu.org
   Last reconfirmed||2021-08-05
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.3
 Ever confirmed|0   |1

--- Comment #2 from Iain Sandoe  ---
I have a preference for setting the correct library name when it is created,
and for setting the library versioning information in the 'usual' Darwin way.

The reason being that I have patches in flight for using "@rpath/." for the
library names to fix the issues we have with testing on platforms with SIP
enabled (post 10.11).

Patches are under test.

NOTE there are issues with testing too - namely that the testsuite code is
currently making assumptions about support for --export-dynamic (it should
conditionally use -rdynamic IMO) and also that it assumes dejagnu.h is visible
in the default compiler lookup paths (it isn't on Darwin)... then we reach the
obstacle that the dejagnu.h from at least 1.6.2 has an unused variable in C
compilations + the wait function declaration clashes with the system's decl for
'wait'.

When all these things are fixed, we have two more issues that I've not been
able to address yet - namely that we get bad code-gen when "-g" is on the
command line, and that it seems that sometimes we get hanging tests that are
not killed by the testsuite machinery - so that the whole "make check" hangs.

At least I plan to address the issues for which the solution is clear - for the
last two things I think that more understanding of the processes used by the
Jit will be needed.

[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions

2021-08-05 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226

H.J. Lu  changed:

   What|Removed |Added

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

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

[hjl@gnu-skl-2 gcc]$ ./xgcc -B./ -S -O3 -march=haswell x.cc 
[hjl@gnu-skl-2 gcc]$ cat x.s
.file   "x.cc"
.text
.p2align 4
.globl  _Z5copy1RK9dumb_pairRS_
.type   _Z5copy1RK9dumb_pairRS_, @function
_Z5copy1RK9dumb_pairRS_:
.LFB5664:
.cfi_startproc
vmovdqa (%rdi), %ymm15
vmovdqa %ymm15, (%rsi)
vmovdqa 32(%rdi), %ymm15
vmovdqa %ymm15, 32(%rsi)
vzeroupper
ret
.cfi_endproc
.LFE5664:
.size   _Z5copy1RK9dumb_pairRS_, .-_Z5copy1RK9dumb_pairRS_
.p2align 4
.globl  _Z5copy2RK10smart_pairRS_
.type   _Z5copy2RK10smart_pairRS_, @function
_Z5copy2RK10smart_pairRS_:
.LFB5670:
.cfi_startproc
vmovdqa (%rdi), %ymm0
vmovdqa 32(%rdi), %ymm1
vmovdqa %ymm0, (%rsi)
vmovdqa %ymm1, 32(%rsi)
vzeroupper
ret
.cfi_endproc
.LFE5670:
.size   _Z5copy2RK10smart_pairRS_, .-_Z5copy2RK10smart_pairRS_
.ident  "GCC: (GNU) 12.0.0 20210805 (experimental) [master revision
f7aa81892eb:82bfff3e5fa:c16f21c7cf97ce48967e42d3b5d22ea169a9c2c8]"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-2 gcc]$

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

[Bug middle-end/90773] Improve piecewise operation

2021-08-05 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773

H.J. Lu  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #16 from H.J. Lu  ---
*** Bug 89226 has been marked as a duplicate of this bug. ***

[Bug target/56511] memcpy misses chance to use AVX instructions

2021-08-05 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511

H.J. Lu  changed:

   What|Removed |Added

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

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

[hjl@gnu-skl-2 gcc]$ cat x2.c
#include 

typedef float vec __attribute__((vector_size(32)));
typedef struct S {
  vec v;
  char __attribute__((aligned(__alignof__(vec c[sizeof(vec)];
} S;
void assign_vec(S* s, const vec* v) { s->v = *v; }
void memcpy_vec(S* s, const vec* v) { memcpy(&s->v, v, sizeof(vec)); }
void memcpy_char(S* s, const vec* v) { memcpy(s->c, v, sizeof(vec)); }
[hjl@gnu-skl-2 gcc]$ ./xgcc -B./ -S -O3 -march=haswell x2.c
[hjl@gnu-skl-2 gcc]$ cat x2.s
.file   "x2.c"
.text
.p2align 4
.globl  assign_vec
.type   assign_vec, @function
assign_vec:
.LFB0:
.cfi_startproc
vmovaps (%rsi), %ymm0
vmovaps %ymm0, (%rdi)
vzeroupper
ret
.cfi_endproc
.LFE0:
.size   assign_vec, .-assign_vec
.p2align 4
.globl  memcpy_vec
.type   memcpy_vec, @function
memcpy_vec:
.LFB1:
.cfi_startproc
vmovdqu (%rsi), %ymm15
vmovdqu %ymm15, (%rdi)
vzeroupper
ret
.cfi_endproc
.LFE1:
.size   memcpy_vec, .-memcpy_vec
.p2align 4
.globl  memcpy_char
.type   memcpy_char, @function
memcpy_char:
.LFB2:
.cfi_startproc
vmovdqu (%rsi), %ymm15
vmovdqu %ymm15, 32(%rdi)
vzeroupper
ret
.cfi_endproc
.LFE2:
.size   memcpy_char, .-memcpy_char
.ident  "GCC: (GNU) 12.0.0 20210805 (experimental) [master revision
f7aa81892eb:82bfff3e5fa:c16f21c7cf97ce48967e42d3b5d22ea169a9c2c8]"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-2 gcc]$

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

[Bug middle-end/90773] Improve piecewise operation

2021-08-05 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773

H.J. Lu  changed:

   What|Removed |Added

 CC||jyasskin at gcc dot gnu.org

--- Comment #17 from H.J. Lu  ---
*** Bug 56511 has been marked as a duplicate of this bug. ***

[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c

2021-08-05 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed in GCC 4.6.0 by r0-105460.

[Bug middle-end/101787] There's no document for cond_ashr/ashl/lshr which is introduce by r10-2540

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101787

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r12-2764-gc04bb6d93f3bd009800cb99e56c779a69d832691
Author: Richard Sandiford 
Date:   Thu Aug 5 14:03:24 2021 +0100

doc: Document cond_* shift optabs in md.texi

gcc/
PR middle-end/101787
* doc/md.texi (cond_ashl, cond_ashr, cond_lshr): Document.

[Bug c++/101790] New: ICE on invalid regression in trunk: tree check: expected class 'type', have 'exceptional' (error_mark)

2021-08-05 Thread llvm at rifkin dot dev via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101790

Bug ID: 101790
   Summary: ICE on invalid regression in trunk: tree check:
expected class 'type', have 'exceptional' (error_mark)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

https://godbolt.org/z/9ozxbY5nh


template
concept a=;
int b=a<>;


:2:11: error: expected primary-expression before ';' token
2 | concept a=;
  |   ^
: In function 'void __static_initialization_and_destruction_0(int,
int)':
:3:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
3 | int b=a<>;
  |   ^~~
0x1db4d89 internal_error(char const*, ...)
???:0
0x6a23c3 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xd76e33 useless_type_conversion_p(tree_node*, tree_node*)
???:0
0x136bdf6 tree_ssa_strip_useless_type_conversions(tree_node*)
???:0
0xdbe63f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc14ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc0d3e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdbfe83 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc12b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc12b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc600e gimplify_body(tree_node*, bool)
???:0
0xdc6627 gimplify_function_tree(tree_node*)
???:0
0xbe2ad7 cgraph_node::analyze()
???:0
0xbe6f0d symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/101787] There's no document for cond_ashr/ashl/lshr which is introduce by r10-2540

2021-08-05 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101787

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #3 from Hongtao.liu  ---
.

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744

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

https://gcc.gnu.org/g:72264a639729a5dcc21dbee304717ce22b338bfd

commit r12-2765-g72264a639729a5dcc21dbee304717ce22b338bfd
Author: H.J. Lu 
Date:   Sat Jul 17 07:44:45 2021 -0700

: Add pragma GCC target("general-regs-only")

1. Intrinsics in  only require GPR ISAs.  Add

 #if defined __MMX__ || defined __SSE__
 #pragma GCC push_options
 #pragma GCC target("general-regs-only")
 #define __DISABLE_GENERAL_REGS_ONLY__
 #endif

and

 #ifdef __DISABLE_GENERAL_REGS_ONLY__
 #undef __DISABLE_GENERAL_REGS_ONLY__
 #pragma GCC pop_options
 #endif /* __DISABLE_GENERAL_REGS_ONLY__ */

to  to disable non-GPR ISAs so that they can be used in
functions with __attribute__ ((target("general-regs-only"))).
2. When checking always_inline attribute, if callee only uses GPRs,
ignore MASK_80387 since enable MASK_80387 in caller has no impact on
callee inline.

gcc/

PR target/99744
* config/i386/i386.c (ix86_can_inline_p): Ignore MASK_80387 if
callee only uses GPRs.
* config/i386/ia32intrin.h: Revert commit 5463cee2770.
* config/i386/serializeintrin.h: Revert commit 71958f740f1.
* config/i386/x86gprintrin.h: Add
#pragma GCC target("general-regs-only") and #pragma GCC pop_options
to disable non-GPR ISAs.

gcc/testsuite/

PR target/99744
* gcc.target/i386/pr99744-3.c: New test.
* gcc.target/i386/pr99744-4.c: Likewise.
* gcc.target/i386/pr99744-5.c: Likewise.
* gcc.target/i386/pr99744-6.c: Likewise.
* gcc.target/i386/pr99744-7.c: Likewise.
* gcc.target/i386/pr99744-8.c: Likewise.

[Bug c++/97475] An unnamed class with a typedef name for linkage purposes having a method.

2021-08-05 Thread anders.granlund.0 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475

--- Comment #4 from Anders Granlund  ---
Sounds good to me!

On Thu, 5 Aug 2021, 13:35 redi at gcc dot gnu.org, 
wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
>
> --- Comment #3 from Jonathan Wakely  ---
> Maybe we should make this ill-formed for C++20, and a pedwarn otherwise, so
> existing code continues to compile using previous standards.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/101790] [12 Regression] ICE on invalid regression in trunk: tree check: expected class 'type', have 'exceptional' (error_mark)

2021-08-05 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101790

Martin Liška  changed:

   What|Removed |Added

Summary|ICE on invalid regression   |[12 Regression] ICE on
   |in trunk: tree check:   |invalid regression in
   |expected class 'type', have |trunk: tree check: expected
   |'exceptional' (error_mark)  |class 'type', have
   ||'exceptional' (error_mark)
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-08-05
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-7106-g4e7c24d97dd65083.

[Bug libstdc++/101782] [12 regression] Excess errors in g++.dg/cpp2a/concepts-pr67774.C after r12-2729

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101782

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

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

commit r12-2766-g7b1de3eb9ed3f8dde54732d88520292c5ad1157d
Author: Jonathan Wakely 
Date:   Thu Aug 5 13:34:00 2021 +0100

libstdc++: Move attributes that follow requires-clauses [PR101782]

As explained in the PR, the grammar in the Concepts TS means that a [
token following a requires-clause is parsed as part of the
logical-or-expression rather than the start of an attribute. That makes
the following ill-formed when using -fconcepts-ts:

  template requires foo [[nodiscard]] int f(T);

This change moves all attributes that follow a requires-clause to the
end of the function declarator.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101782
* include/bits/ranges_base.h (ranges::begin, ranges::end)
(ranges::rbegin, ranges::rend, ranges::size, ranges::ssize)
(ranges::empty, ranges::data): Move attribute to the end of
the declarator.
* include/bits/stl_iterator.h (__gnu_cxx::__normal_iterator)
(common_iterator): Likewise for non-member operator functions.
* include/std/ranges (views::all, views::filter)
(views::transform, views::take, views::take_while, views::drop)
(views::drop_while, views::join, views::lazy_split)
(views::split, views::counted, views::common, views::reverse)
(views::elements): Likewise.
* testsuite/std/ranges/access/101782.cc: New test.

[Bug c++/101780] Missing initializers whereas structure has default initializers

2021-08-05 Thread deco33000 at yandex dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101780

--- Comment #2 from KL  ---
(In reply to Jonathan Wakely from comment #1)

Thanks,

I thought that this warning is fine if it helps to assure the developer that
everything is still under control: that if the analyzer sees that a field is
left uninitialized (with no default value), it should tell it in this warning.


> How would P,Q,R be left uninitialized?

Only if the analyzer has the info that, at this stage, there no default value
for the field. 
It could be interesting in the context of a partially initialized struct (by
mistake, intended by the developer?)?

It help with quality of code.

> It doesn't say anything about undefined behaviour.

In case the developer forgot to properly initialize a member, it *can* lead to
undefined behavior. So, it is good from the compiler to warn about it as well.

[Bug c++/101786] P1143R2 constinit implementation is incomplete (joining with thread_local)

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101786

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/101786] P1143R2 constinit implementation is incomplete (joining with thread_local)

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101786

--- Comment #4 from Jakub Jelinek  ---
IMHO clang++ implements it incorrectly, if you compile the testcase I've added
in the patch with clang, then it will properly use _ZTH for the 4th variable
(as it has non-trivial dtor, that dtor needs to be registered and that counts
as dynamic initialization for the purposes of TLS wrappers), but for the case
of incomplete type it doesn't, even when it can't know whether the definition
of the var will have trivial or non-trivial dtor.

[Bug libstdc++/101782] [12 regression] Excess errors in g++.dg/cpp2a/concepts-pr67774.C after r12-2729

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101782

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed by changing the library headers.

[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544

2021-08-05 Thread mcs at ifam dot uni-hannover.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372

--- Comment #5 from Marc C. Steinbach  ---
Thanks for fixing!

I was unable to install any development snapshots,
so I waited for the 11.2.0 release to test my codes.

[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils

2021-08-05 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Here's output from the uninitialized pass patched to show in more detail what's
going on.  Cycles can contribute to false positives.  The chain length greater
messages also show possible reasons for false positives in an unpatched GCC
(the patched pass raises the limits to avoid them).  The note after the warning
shows the condition under which GCC determines the uninitialized variable is
used (it needs improvement).

Examining phi: cmd1_68 = PHI 
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
predicate::predicate (def_bb = 6, use_bb = 3, func_t) initialized from 9
dep_chains:
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 32 
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 18 
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 19 
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 32 
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 18 
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 19 
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 32 
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 18 
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 19 
init_from_control_deps { { 24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 32 }, { 24
-> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 18 }, { 24 -> 8, 8 -> 9, 9 -> 26, 14 ->
15, 15 -> 19 }, { 24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 32 }, {
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 18 }, { 24 -> 8, 8 -> 10,
10 -> 11, 11 -> 27, 14 -> 15, 15 -> 19 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 ->
30, 14 -> 15, 15 -> 32 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15
-> 18 }, { 24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 19 } }:
(empty)
Found unguarded use in bb 3: cmd1_12 = PHI 
cycle detected
cycle detected
cycle detected
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
chain length greater than 5: 6
cycle detected
cycle detected
cycle detected
predicate::predicate (def_bb = 6, use_bb = 20, func_t) initialized from 3
dep_chains:
24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 20 
24 -> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 20 
24 -> 8, 8 -> 10, 10 -> 13, 13 -> 30, 14 -> 15, 15 -> 20 
init_from_control_deps { { 24 -> 8, 8 -> 9, 9 -> 26, 14 -> 15, 15 -> 20 }, { 24
-> 8, 8 -> 10, 10 -> 11, 11 -> 27, 14 -> 15, 15 -> 20 }, { 24 -> 8, 8 -> 10, 10
-> 13, 13 -> 30, 14 -> 15, 15 -> 20 } }:
MEM[(const char *)input_27 + -1B] != 101 && MEM[(const char
*)input_27 + -1B] <= 101) && MEM[(const char *)input_27 + -1B] == 50) &&
MEM[(const char *)input_74 + 1B] == 10) && _72 == 101 || MEM[(const char
*)input_27 + -1B] != 101 && MEM[(const char *)input_27 + -1B] > 101) &&
MEM[(const char *)input_27 + -1B] <= 115) && MEM[(const char *)input_27 + -1B]
> 112) && MEM[(const char *)input_74 + 1B] == 10) && _72 == 101) ||
MEM[(const char *)input_2

[Bug libstdc++/88736] [DR 3484] nullptr_t available without namespace qualification

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88736

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|nullptr_t available without |[DR 3484] nullptr_t
   |namespace qualification |available without namespace
   ||qualification

--- Comment #3 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #1)
> For some reason, GCC's
>  defines nullptr_t in the global namespace (and libstdc++
>  in std).

Because that's exactly what the standard requires.

[depr.c.headers.other] says:

Every C header [...] behaves as if each name placed in the standard library
namespace by the corresponding  header is placed within the global
namespace scope, except for the functions described in 26.8.6,
the declaration of std::byte (17.2.1), and the functions and function templates
described in 17.2.5.

Only the  special functions and std::byte are excluded. std::nullptr_t
is required to be redeclared in the global namespace.

There is an open LWG issue suggesting to remove nullptr_t from :
https://cplusplus.github.io/LWG/issue3484

Until that is resolved (or we at least have consensus to remove it) I'm
suspending this PR.


(In reply to Andrew Pinski from comment #2)
> It looks like it is still needed but I think could pull that into
> libstdc++/include/c_compatibility/stddef.h instead.

No, because that header is not installed in the usual configurations. The
default configuration only installs these wrappers for the C headers:

if GLIBCXX_C_HEADERS_C_GLOBAL
c_compatibility_headers = \
${c_compatibility_srcdir}/complex.h \
${c_compatibility_srcdir}/fenv.h \
${c_compatibility_srcdir}/tgmath.h \
${c_compatibility_srcdir}/math.h \
${c_compatibility_srcdir}/stdlib.h
endif

[Bug c++/86369] constexpr const char* comparison fails

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed||2021-08-05
 Status|UNCONFIRMED |NEW
  Known to work|10.1.0  |

--- Comment #4 from Jonathan Wakely  ---
Confirming as accepts-invalid based on comment 1.


GCC started to accept both comparisons with r270845:

re PR tree-optimization/87314 (pointless comparison of malloc result to a
string not eliminated)

2019-05-03  Richard Biener  

PR middle-end/87314
* match.pd (cmp (convert1?@2 addr@0) (convert2? addr@1)):
Handle STRING_CST vs DECL or STRING_CST.

* gcc.dg/pr87314-1.c: New testcase.

[Bug c++/82204] G++ doesn't connect friend and extern declarations

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82204

--- Comment #4 from Jonathan Wakely  ---
Fixed by r11-3699:

 c++: block-scope externs get an alias [PR95677,PR31775,PR95677]

[Bug c++/86369] constexpr const char* comparison fails

2021-08-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So, either those match.pd rules should be marked #ifdef GIMPLE only, or perhaps
we should have some flag whether C++ constexpr evaluation is in progress and
allow some foldings if GENERIC only if C++ constexpr evaluation is not in
progress?

[Bug c++/61543] static_cast(static_cast(enum_value)) doesn't get an error

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61543

--- Comment #6 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #5)
> GCC 8+ rejects the first "// accepted" in the reduced testcase.

Since r249083

> GCC 9+ rejects both.

Since approximately r267272

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466

--- Comment #20 from Jonathan Wakely  ---
The core issue is still open, for some reason.

[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977

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

https://gcc.gnu.org/g:4805b92a32637b987f924463d6af9dcf95b21f63

commit r12-2771-g4805b92a32637b987f924463d6af9dcf95b21f63
Author: Jakub Jelinek 
Date:   Thu Aug 5 17:34:16 2021 +0200

libcpp: Fix makeucnid bug with combining values [PR100977]

I've noticed in ucnid.h two adjacent lines that had all flags and combine
values identical and as such were supposed to be merged.

This is due to a bug in makeucnid.c, which records last_flag,
last_combine and really_safe of what has just been printed, but
because of a typo mishandles it for last_combine, always compares against
the combining_value[0] which is 0.

This has two effects on the table, one is that often the table is
unnecessarily large, as for non-zero .combine every character has its own
record instead of adjacent characters with the same flags and combine
being merged.  This means larger tables.
The other is that sometimes the last char that has combine set doesn't
actually have it in the tables, because the code is printing entries only
upon seeing the next character and if that character does have
combining_value of 0 and flags are otherwise the same as previously
printed,
it will not print anything.

The following patch fixes that, for clarity what exactly it affects
I've regenerated with the same Unicode files as last time it has
been regenerated.

2021-08-05  Jakub Jelinek  

PR c++/100977
* makeucnid.c (write_table): Fix computation of last_combine.
* ucnid.h: Regenerated using Unicode 6.3.0 files.

[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

2021-08-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977

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

https://gcc.gnu.org/g:4739344d36e6d24764cbedde44a3fff6edc70f6c

commit r12-2772-g4739344d36e6d24764cbedde44a3fff6edc70f6c
Author: Jakub Jelinek 
Date:   Thu Aug 5 17:35:20 2021 +0200

libcpp: Regenerate ucnid.h using Unicode 13.0.0 files [PR100977]

The following patch (incremental to the makeucnid.c fix) regenerates
ucnid.h with https://www.unicode.org/Public/13.0.0/ucd/ files.

2021-08-05  Jakub Jelinek  

PR c++/100977
* ucnid.h: Regenerated using Unicode 13.0.0 files.

[Bug c++/71267] [C++14] recursive metafunction won't compile: no type named 'type'

2021-08-05 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71267

--- Comment #3 from Jonathan Wakely  ---
Accepted since r12-1094 and r11-8714:

c++: argument pack with expansion [PR86355]

This testcase revealed that we were using PACK_EXPANSION_EXTRA_ARGS a lot
more than necessary; use_pack_expansion_extra_args_p meant to use it in the
case of corresponding arguments in different argument packs differing in
whether they are pack expansions, but it was mistakenly also returning true
for the case of a single argument pack containing both expansion and
non-expansion elements.

Surprisingly, just disabling that didn't lead to any regressions in the
testsuite; it seems other changes have prevented us getting to this point
for code that used to exercise it.  So this patch limits the check to
arguments in the same position in the packs, and asserts that we never
actually see a mismatch.

PR c++/86355

gcc/cp/ChangeLog:

* pt.c (use_pack_expansion_extra_args_p): Don't compare
args from the same argument pack.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-variadic2.C: New test.

[Bug middle-end/101791] New: missing warning on a mismatch between scalar and array forms of new and delete

2021-08-05 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791

Bug ID: 101791
   Summary: missing warning on a mismatch between scalar and array
forms of new and delete
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wmismatched-new-delete warning introduced in GCC 11 is meant to diagnose
calls to operator delete with pointers obtained from a mismatched form or
overload of operator new.  A poster child for such a mismatch is the scalar
form of a delete expression with an argument obtained from array new.  GCC 11
diagnoses such mismatches when they involve member operators new and delete (as
in g() below) but it fails to do the same for the default non-member operators
(as in h()).

$ cat t.C && gcc -S -Wall t.Ctypedef __SIZE_TYPE__ size_t;

struct A
{
  void* operator new (size_t);
  void operator delete (void*);

  void* operator new[] (size_t);
  void operator delete[] (void*);
};

void f (void*);

void g ()
{
  A *p = new A[7];
  f (p);
  delete p;// -Wmismatched-new-delete (good)
}

void h ()
{
  int *p = new int[7];
  f (p);
  delete p;// missing warning
}
t.C: In function ‘void g()’:
t.C:18:10: warning: ‘static void A::operator delete(void*)’ called on pointer
returned from a mismatched allocation function [-Wmismatched-new-delete]
   18 |   delete p;// -Wmismatched-new-delete (good)
  |  ^
t.C:16:17: note: returned from ‘static void* A::operator new [](size_t)’
   16 |   A *p = new A[7];
  | ^

[Bug middle-end/101791] missing warning on a mismatch between scalar and array forms of new and delete

2021-08-05 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101791

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Blocks||100406
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
Version|12.0|11.2.1
   Last reconfirmed||2021-08-05
   Keywords||diagnostic
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406
[Bug 100406] bogus/missing -Wmismatched-new-delete

  1   2   >