[Bug libstdc++/96063] New: mismatched-tags warnings in stdlib headers

[ian.s.mcinerney at ieee dot org]

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

Bug ID: 96063
   Summary: mismatched-tags warnings in stdlib headers
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian.s.mcinerney at ieee dot org
  Target Milestone: ---

There are several places in the library headers where warnings can be emitted
for mismatched-tags (this was found when a mingw g++ compile misbehaved and
printed warnings for system headers for some reason). I am still not sure why
the compiler decided to throw the errors in the first place, but these seem
like something that can be cleaned up.

Warnings from building a C++ file that just includes all the headers:

In file included from /usr/include/c++/10/bits/ios_base.h:46,
 from /usr/include/c++/10/ios:42,
 from /usr/include/c++/10/istream:38,
 from /usr/include/c++/10/sstream:38,
 from /usr/include/c++/10/complex:45,
 from main.cpp:7:
/usr/include/c++/10/system_error:54:9: warning: ‘std::error_code’ declared with
a mismatched class-key ‘class’ [-Wmismatched-tags]
   54 |   class error_code;
  | ^~
/usr/include/c++/10/system_error:54:9: note: replace the class-key with
‘struct’
/usr/include/c++/10/system_error:180:10: note: ‘std::error_code’ defined as
‘struct’ here
  180 |   struct error_code
  |  ^~
/usr/include/c++/10/system_error:55:9: warning: ‘std::error_condition’ declared
with a mismatched class-key ‘class’ [-Wmismatched-tags]
   55 |   class error_condition;
  | ^~~
/usr/include/c++/10/system_error:55:9: note: replace the class-key with
‘struct’
/usr/include/c++/10/system_error:278:10: note: ‘std::error_condition’ defined
as ‘struct’ here
  278 |   struct error_condition
  |  ^~~


In file included from /usr/include/c++/10/string:43,
 from /usr/include/c++/10/bitset:47,
 from main.cpp:6:
/usr/include/c++/10/bits/localefwd.h:125:9: warning: ‘std::ctype_base’ declared
with a mismatched class-key ‘class’ [-Wmismatched-tags]
  125 |   class ctype_base;
  | ^~
/usr/include/c++/10/bits/localefwd.h:125:9: note: replace the class-key with
‘struct’
In file included from /usr/include/c++/10/bits/locale_facets.h:41,
 from /usr/include/c++/10/bits/basic_ios.h:37,
 from /usr/include/c++/10/ios:44,
 from /usr/include/c++/10/istream:38,
 from /usr/include/c++/10/sstream:38,
 from /usr/include/c++/10/complex:45,
 from main.cpp:7:
/usr/include/c++/10/x86_64-redhat-linux/bits/ctype_base.h:41:10: note:
‘std::ctype_base’ defined as ‘struct’ here
   41 |   struct ctype_base
  |  ^~


In file included from main.cpp:7:
/usr/include/c++/10/complex:67:32: warning: ‘std::complex<_Tp>’ declared with a
mismatched class-key ‘class’ [-Wmismatched-tags]
   67 |   template class complex;
  |^~~
/usr/include/c++/10/complex:67:32: note: replace the class-key with ‘struct’
/usr/include/c++/10/complex:127:12: note: ‘std::complex<_Tp>’ defined as
‘struct’ here
  127 | struct complex
  |^~~
/usr/include/c++/10/complex:68:20: warning: ‘std::complex’ declared with
a mismatched class-key ‘class’ [-Wmismatched-tags]
   68 |   template<> class complex;
  |^~
/usr/include/c++/10/complex:68:20: note: replace the class-key with ‘struct’
/usr/include/c++/10/complex:1082:12: note: ‘std::complex’ defined as
‘struct’ here
 1082 | struct complex
  |^~
/usr/include/c++/10/complex:69:20: warning: ‘std::complex’ declared
with a mismatched class-key ‘class’ [-Wmismatched-tags]
   69 |   template<> class complex;
  |^~~
/usr/include/c++/10/complex:69:20: note: replace the class-key with ‘struct’
/usr/include/c++/10/complex:1227:12: note: ‘std::complex’ defined as
‘struct’ here
 1227 | struct complex
  |^~~
/usr/include/c++/10/complex:70:20: warning: ‘std::complex’
declared with a mismatched class-key ‘class’ [-Wmismatched-tags]
   70 |   template<> class complex;
  |^~~~
/usr/include/c++/10/complex:70:20: note: replace the class-key with ‘struct’
/usr/include/c++/10/complex:1372:12: note: ‘std::complex’ defined
as ‘struct’ here
 1372 | struct complex
  |^~~~


In file included from /usr/include/c++/10/string:43,
 from /usr/include/c++/10/bitset:47,
 from main.cpp:6:
/usr/include/c++/10/bits/localefwd.h:203:9: warning: ‘std::messages_base’
declared with a mismatched class-key ‘class’ [-Wmismatche

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Alexander Popov from comment #6)
> >> Could you explain the connection between your attribute for zeroing
> >> registers and 'no_caller_saved_registers' attribute?
> > 
> > We are porting
> > 
> > https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/caller-saved/old
> > 
> > from x86 back-end to middle-end.  no_caller_saved_registers changes what
> > registers zero_call_used_regs can do.  Move no_caller_saved_registers to
> > middle-end has a direct impact on zero_call_used_regs implementation in
> > middle-end.
> 
> Ok. So, as I can understand, your work will enable
> 'no_caller_saved_registers' attribute for all architectures. Am I right?

No.  We are implementing zero_call_used_regs in middle-end.  Someone
can piggyback no_caller_saved_registers on our work.

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[alex.popov at linux dot com]

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

--- Comment #6 from Alexander Popov  ---
>> Could you explain the connection between your attribute for zeroing
>> registers and 'no_caller_saved_registers' attribute?
> 
> We are porting
> 
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/caller-saved/old
> 
> from x86 back-end to middle-end.  no_caller_saved_registers changes what
> registers zero_call_used_regs can do.  Move no_caller_saved_registers to
> middle-end has a direct impact on zero_call_used_regs implementation in
> middle-end.

Ok. So, as I can understand, your work will enable 'no_caller_saved_registers'
attribute for all architectures. Am I right?

If so, good luck to you! Looking forward to your results.

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Alexander Popov from comment #4)
> > Incorrect.  There is also a zero_call_used_regs attribute.
> 
> Thanks, now I've found it in your tree:
> 
> ```
> You can control this behavior for a specific function by using the function
> attribute @code{zero_call_used_regs}.
> ```
> 
> Could you explain the connection between your attribute for zeroing
> registers and 'no_caller_saved_registers' attribute?

We are porting

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/caller-saved/old

from x86 back-end to middle-end.  no_caller_saved_registers changes what
registers zero_call_used_regs can do.  Move no_caller_saved_registers to
middle-end has a direct impact on zero_call_used_regs implementation in
middle-end.

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[alex.popov at linux dot com]

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

--- Comment #4 from Alexander Popov  ---
> Incorrect.  There is also a zero_call_used_regs attribute.

Thanks, now I've found it in your tree:

```
You can control this behavior for a specific function by using the function
attribute @code{zero_call_used_regs}.
```

Could you explain the connection between your attribute for zeroing registers
and 'no_caller_saved_registers' attribute?

[Bug ipa/96040] [10/11 Regression] Compiled code causes SIGBUS at -O2

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Jambor  ---
Fixed.

[Bug ipa/96040] [10/11 Regression] Compiled code causes SIGBUS at -O2

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:56a34e3e1cbb7d3b2f9298c14d4d3a3a030c7755

commit r10-8425-g56a34e3e1cbb7d3b2f9298c14d4d3a3a030c7755
Author: Martin Jambor 
Date:   Sat Jul 4 19:46:52 2020 +0200

ipa-sra: Avoid transitive splits with type mismatches (PR 96040)

PR 96040 revealed IPA-SRA, when checking whether an intended split is
the same as the one in a called function does not also check if the
types match and the transformation code does not handle any resulting
type mismatches.  This patch simply avoids the the split in the case
of mismatches, so that we do not have to be careful about invalid
floating-point values being passed in floating point registers and
related issues.

gcc/ChangeLog:

2020-07-03  Martin Jambor  

PR ipa/96040
* ipa-sra.c (all_callee_accesses_present_p): Do not accept type
mismatched accesses.

gcc/testsuite/ChangeLog:

2020-07-03  Martin Jambor  

PR ipa/96040
* gcc.dg/ipa/pr96040.c: New test.

(cherry picked from commit b9a15a8325ba89b926e3c437b7961829a6b2fa2b)

[Bug target/96062] New: Partial register stall caused by avoidable use of SETcc, and useless MOVZBL

[josephcsible at gmail dot com]

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

Bug ID: 96062
   Summary: Partial register stall caused by avoidable use of
SETcc, and useless MOVZBL
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---
Target: x86_64

Consider this C code:

long ps4_syscall0(long n) {
long ret;
int carry;
__asm__ __volatile__(
"syscall"
: "=a"(ret), "=@ccc"(carry)
: "a"(n)
: "rcx", "r8", "r9", "r10", "r11", "memory"
);
return carry ? -ret : ret;
}

With "-O3", it results in this assembly:

ps4_syscall0:
movq%rdi, %rax
syscall
setc%dl
movq%rax, %rdi
movzbl  %dl, %edx
negq%rdi
testl   %edx, %edx
cmovne  %rdi, %rax
ret

On modern Intel CPUs, doing "setc %dl" creates a false dependency on rdx. Doing
"movzbl %dl, %edx" doesn't do anything to fix that. Here's some ways that we
could improve this code, without having to fall back to a conditional branch:

1. Get rid of "movzbl %dl, %edx" (since it doesn't help), and then do "testb
%dl, %dl" instead of "testl %edx, %edx".
2. Possibly in addition to #1, use dh instead of dl, since high-byte registers
are still renamed.
3. Instead of #1 and #2, replace the whole sequence between "syscall" and "ret"
with this:

sbbq%rcx, %rcx
xorq%rcx, %rax
subq%rcx, %rax

On Intel (but not AMD), the sbb has a false dependency too, but it's still a
lot less shuffling values around.
4. Instead of #1, #2, and #3, replace the whole sequence between "syscall" and
"ret" with this:

leaq-1(%rax), %rcx
notq%rcx
cmovc   %rcx, %rax

I like this one the best. No false dependencies at all, and still way less
shuffling values around.

[Bug fortran/93423] [8/9/10/11 Regression] ICE on invalid with argument list for module procedure

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Backports will have to wait until PR96041 is resolved.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> From several runs
> 
> frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
> [inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
> frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *)
> [inlined] free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
> 
> It seems that some trees are not built properly.

I set breakpoints in gdb in these routines but see nothing special on x86_64.

Maybe some stack/heap corruption issue affecting ref counts?

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Alexander Popov from comment #2)
> > We are working on -fzero-call-used-regs:
> 
> H.J. Lu, thanks for the information!
> 
> However, this flag can't be used per-function, like the attribute.

Incorrect.  There is also a zero_call_used_regs attribute.

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[alex.popov at linux dot com]

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

--- Comment #2 from Alexander Popov  ---
> We are working on -fzero-call-used-regs:

H.J. Lu, thanks for the information!

However, this flag can't be used per-function, like the attribute.
So supporting 'no_caller_saved_registers' attribute for aarch64 (and maybe
other architectures) is desired anyway.

Thanks!

[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> Multi delta should be able to reduce this. Normally reduce which .o files
> are needed and then reduce the .ii files that needed to produce the .o files
> is the way to reduce this ...

I know how to make a reduction of a LTO test-case, but WPA and LTRANS
compilation takes 1 hour. It's waste of time doing such a reduction.

[Bug target/96061] Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-04
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
(In reply to Alexander Popov from comment #0)
> This is an enhancement request.
> 
> GCC currently supports 'no_caller_saved_registers' attribute only for x86.
> Clang supports it for all target architectures.

We are working on -fzero-call-used-regs:

https://gitlab.com/x86-gcc/gcc/-/tree/users/qinzhao/caller-saved/master


They are related.

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
>From several runs

frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17
frame #0: 0x0001000f0b27 f951`::free_sym_tree(gfc_symtree *) [inlined]
free_sym_tree(sym_tree=0x00ce) at symbol.c:3899:17
frame #0: 0x0001000f11ed f951`gfc_free_namespace(gfc_namespace*)
[inlined] free_uop_tree(uop_tree=0x00ce) at symbol.c:3881:17

It seems that some trees are not built properly.

[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Sat, Jul 04, 2020 at 09:29:49AM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
> 
> --- Comment #3 from Dominique d'Humieres  ---
> > The patch in PR 95025 fixes this issue.
> 
> The patch fixes the ICE, but I get the cryptic error
> 
> f951: Fatal Error: Writing module 'm' at line 15 column 14: Bad type in
> constant expression
> compilation terminated.
> 

gfc_fatal_error() is used 17 times in module.c.  This
normally means that gfortran's error handling mechanism
is not available at the time the error occrurred.  It 
also be that in this case, the *.mod file and the namespace
is too corrupted to try to continue.

[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Multi delta should be able to reduce this. Normally reduce which .o files are
needed and then reduce the .ii files that needed to produce the .o files is the
way to reduce this ...

[Bug target/96061] New: Please support 'no_caller_saved_registers' attribute on aarch64 (or maybe on all targets)

[alex.popov at linux dot com]

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

Bug ID: 96061
   Summary: Please support 'no_caller_saved_registers' attribute
on aarch64 (or maybe on all targets)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex.popov at linux dot com
  Target Milestone: ---

This is an enhancement request.

GCC currently supports 'no_caller_saved_registers' attribute only for x86.
Clang supports it for all target architectures.

It would be very useful for Linux kernel, if GCC supported
'no_caller_saved_registers' attribute for at least aarch64. In particular, that
would allow to avoid useless work with caller-saved registers caused by
STACKLEAK GCC plugin instrumentation for the Linux kernel on aarch64.

This kernel patch uses 'no_caller_saved_registers' to fix the described issue
on x86:
https://www.openwall.com/lists/kernel-hardening/2020/06/24/13
(the patch is accepted for the mainline kernel)

That GCC enhancement can be useful for _mcount (gprof) as well.

Thanks!

[Bug target/94506] broken code generate on MIPS

[g...@hauke-m.de]

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

Hauke Mehrtens  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Hauke Mehrtens  ---
This was not a bug in GCC, but in the kernel.

The kernel was not taking care of hazards between mtc0 and mfc0, so a bit set
in the c0_status register was overwritten later on. This problem only happened
with some orderings of the instructions, this made it looks like it depends on
the GCC version.

See here for details: https://www.spinics.net/lists/stable/msg399099.html

[Bug c++/96060] New: ICE with spaceship default operator returning int

[nunoplopes at sapo dot pt]

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

Bug ID: 96060
   Summary: ICE with spaceship default operator returning int
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunoplopes at sapo dot pt
  Target Milestone: ---

```
#include 

struct xx {
int a;
int operator<=>(const xx&) const = default;
};

int f(std::set &x) {
x.emplace(0);
return 0;
}
```

: In instantiation of 'constexpr bool std::less<_Tp>::operator()(const
_Tp&, const _Tp&) const [with _Tp = xx]':

/opt/compiler-explorer/gcc-trunk-20200703/include/c++/11.0.0/bits/stl_tree.h:2101:35:
  required from 'std::pair
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_get_insert_unique_pos(const key_type&) [with _Key = xx; _Val = xx;
_KeyOfValue = std::_Identity; _Compare = std::less; _Alloc =
std::allocator; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::key_type = xx]'

/opt/compiler-explorer/gcc-trunk-20200703/include/c++/11.0.0/bits/stl_tree.h:2419:19:
  required from 'std::pair, bool>
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_emplace_unique(_Args&& ...) [with _Args = {int}; _Key = xx; _Val =
xx; _KeyOfValue = std::_Identity; _Compare = std::less; _Alloc =
std::allocator]'

/opt/compiler-explorer/gcc-trunk-20200703/include/c++/11.0.0/bits/stl_set.h:463:33:
  required from 'std::pair, _Compare, typename
__gnu_cxx::__alloc_traits<_Alloc>::rebind<_Key>::other>::const_iterator, bool>
std::set<_Key, _Compare, _Alloc>::emplace(_Args&& ...) [with _Args = {int};
_Key = xx; _Compare = std::less; _Alloc = std::allocator; typename
std::_Rb_tree<_Key, _Key, std::_Identity<_Tp>, _Compare, typename
__gnu_cxx::__alloc_traits<_Alloc>::rebind<_Key>::other>::const_iterator =
std::_Rb_tree, std::less, std::allocator
>::const_iterator; typename
__gnu_cxx::__alloc_traits<_Alloc>::rebind<_Key>::other = std::allocator;
typename __gnu_cxx::__alloc_traits<_Alloc>::rebind<_Key> =
__gnu_cxx::__alloc_traits, xx>::rebind; typename
_Alloc::value_type = xx]'

:9:16:   required from here

:5:9: internal compiler error: in genericize_spaceship, at
cp/method.c:1050

5 | int operator<=>(const xx&) const = default;

  | ^~~~

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1


https://gcc.godbolt.org/z/ZFjHyd

[Bug ipa/96059] New: ICE: in remove_unreachable_nodes, at ipa.c:575 with -fdevirtualize-at-ltrans

[krzysztof.a.nowicki+gcc at gmail dot com]

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

Bug ID: 96059
   Summary: ICE: in remove_unreachable_nodes, at ipa.c:575 with
-fdevirtualize-at-ltrans
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysztof.a.nowicki+gcc at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When building the ktexteditor-5.71 from the KDE Frameworks with LTO enabled I'm
seeing an ICE when linking libKF5TextEditor.so:

during IPA pass: inline
lto1: internal compiler error: in remove_unreachable_nodes, at ipa.c:575
0xa7e802 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa.c:575
0x19cb14f ipa_inline
   
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa-inline.c:2696
0x19cb702 execute
   
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa-inline.c:3091
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

GDB backtrace:

#0  internal_error (gmsgid=gmsgid@entry=0x233d39a "in %s, at %s:%d") at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/diagnostic.c:1706
#1  0x01b09d9a in fancy_abort (file=file@entry=0x1c07468
"/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa.c",
line=line@entry=575, function=function@entry=0x1c073fc
"remove_unreachable_nodes")
at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/diagnostic.c:1778
#2  0x00a7e803 in symbol_table::remove_unreachable_nodes
(this=0x76e8d100, file=0x0) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa.c:577
#3  0x019cb150 in ipa_inline () at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa-inline.c:2696
#4  0x019cb703 in (anonymous namespace)::pass_ipa_inline::execute
(this=) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/ipa-inline.c:3091
#5  0x00c047a3 in execute_one_pass (pass=pass@entry=0x3edc4a0) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/passes.c:2502
#6  0x00c06052 in execute_ipa_pass_list (pass=0x3edc4a0) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/passes.c:2929
#7  0x006442ac in do_whole_program_analysis () at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/context.h:48
#8  0x006445f7 in lto_main () at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/lto/lto.c:637
#9  0x00d1844d in compile_file () at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/toplev.c:458
#10 0x00d1b891 in do_compile () at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/toplev.c:2277
#11 0x00d1c1fd in toplev::main (this=this@entry=0x7fffd7f6,
argc=, argc@entry=36, argv=,
argv@entry=0x7fffd8f8) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/toplev.c:2416
#12 0x01ae9eeb in main (argc=36, argv=0x7fffd8f8) at
/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/main.c:39

CXXFLAGS: -O2 -pipe -march=skylake -flto=3 -fgraphite-identity
-floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta
-fno-semantic-interposition

The ICE goes away after removing the -fdevirtualize-at-ltrans flag.

The backtrace above was generated from Gentoo-patched version of GCC, but it's
also reproducible with a vanilla version compiled directly from sources.

This is a regression since GCC 10 (reproducible also with latest GCC 11 trunk),
as GCC 9 compiles this package with the same CXXFLAGS without issues.

I've bisected the regression to the following commit:

commit 2bc2379be5c98d34ecbb347b2abf059aa6d94499
Author: Jan Hubicka 
Date:   Mon Nov 4 20:39:52 2019 +0100

ipa-inline-transform.c: Include ipa-utils.h


* ipa-inline-transform.c: Include ipa-utils.h
(inline_call): Set thunk_expansion flag.
* ipa-utils.h (thunk_expansion): Declare.
* ipa-devirt.c (thunk_expansion): New global var.
(devirt_node_removal_hook): Do not invalidate cache while
doing thunk expansion.

From-SVN: r277789

Maybe the "HACK alert" in the commit diff has something to do with it :)

[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> The patch in PR 95025 fixes this issue.

The patch fixes the ICE, but I get the cryptic error

f951: Fatal Error: Writing module 'm' at line 15 column 14: Bad type in
constant expression
compilation terminated.

[Bug fortran/96025] [9/10/11 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> This fixes the ICE.

Confirmed, with the patch I get

Error: Expression at (1) must be of INTEGER type, found CHARACTER

[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-04
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
There's a ltrans file:
https://drive.google.com/file/d/1cddbnb886aVn1vfpJMLIRc1Ue3dyBuTy/view?usp=sharing

The ICE happens with c91e43e9363bd119a695d64505f96539fa451bf2 revision (one
needs zstd compression enabled).

[Bug tree-optimization/96058] New: ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

Bug ID: 96058
   Summary: ICE in c_getstr at gcc/fold-const.c:15475
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

I see the ICE in a LTRANS when using LTO on chrome. So it's unlikely I can
create a reduced-test case:

I'm using GCC 10.1 release:

gcc --version
gcc (SUSE Linux) 10.1.1 20200625 [revision
c91e43e9363bd119a695d64505f96539fa451bf2]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/lib64/gcc/x86_64-suse-linux/10/lto1 -fltrans chrome.ltrans81.o -quiet
during GIMPLE pass: strlen
../../chrome/browser/ui/views/sharing/sharing_icon_view.cc: In member function
‘GetVectorIconBadge’:
../../chrome/browser/ui/views/sharing/sharing_icon_view.cc:146: internal
compiler error: in tree_to_uhwi, at tree.h:4519
0x666aa8 tree_to_uhwi(tree_node const*)
../../gcc/tree.h:4519
0x666aa8 c_getstr(tree_node*, unsigned long*)
../../gcc/fold-const.c:15475
0xf54bf2 get_stridx
../../gcc/tree-ssa-strlen.c:537
0xde690d strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-strlen.c:5832
0xde5e63 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:309
0x1134468 printf_strlen_execute
../../gcc/tree-ssa-strlen.c:5922
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

(gdb) bt
#0  c_getstr (src=0x7fffeffb0e28, strlen=0x0) at ../../gcc/fold-const.c:15475
#1  0x00f54bf3 in get_stridx (exp=0x7fffeffa6480, offrng=0x0,
rvals=0x0) at ../../gcc/tree-ssa-strlen.c:537
#2  0x00de690e in strlen_dom_walker::before_dom_children
(this=0x7fffdfa0, bb=0x7fffeffb70d0) at ../../gcc/gimple.h:4539
#3  0x00de5e64 in dom_walker::walk (this=0x7fffdfa0,
bb=0x7fffeffb70d0) at ../../gcc/domwalk.c:309
#4  0x01134469 in (anonymous namespace)::printf_strlen_execute
(fun=0x70988bb0, warn_only=) at
../../gcc/tree-ssa-strlen.c:5922
#5  0x00d49063 in execute_one_pass (pass=0x1d00a50) at
../../gcc/passes.c:2502
#6  0x00d7e825 in execute_pass_list_1 (pass=0x1d00a50) at
../../gcc/passes.c:2590
#7  execute_pass_list_1 (pass=0x1cfe680) at ../../gcc/passes.c:2591
#8  execute_pass_list (fn=0x70988bb0, pass=) at
../../gcc/passes.c:2601
#9  0x0111bc42 in cgraph_node::expand (this=0x76fbee10) at
../../gcc/cgraphunit.c:2300
#10 0x0110f6a6 in expand_all_functions () at
../../gcc/cgraphunit.c:2471
#11 symbol_table::compile (this=0x77754100) at ../../gcc/cgraphunit.c:2822
#12 0x010fdeab in lto_main () at ../../gcc/lto/lto.c:653
#13 0x010fa1be in compile_file () at ../../gcc/toplev.c:458
#14 0x010c7ffa in do_compile () at ../../gcc/toplev.c:2278
#15 toplev::main (this=this@entry=0x7fffe23e, argc=,
argv=) at ../../gcc/toplev.c:2417
#16 0x010c73cc in main (argc=, argv=) at
../../gcc/main.c:39
(gdb) p debug_tree(exp)
No symbol "exp" in current context.
(gdb) p debug_tree(src)
 
pointer_to_this  reference_to_this
>
BLK
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
domain 
DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffeff55738 precision:64 min  max >>
readonly constant static "\000">
$1 = void

(gdb) p debug_tree(elttype)
No symbol "elttype" in current context.
(gdb) p debug_tree(eltype)
 
pointer_to_this  reference_to_this
>
$2 = void

(gdb) p debug_generic_expr (exp)
&kNoneIcon
(gdb) p debug_function(current_function_decl, 0)
GetVectorIconBadge (const struct SharingIconView * const this)
{
  bool _1;
  const struct VectorIcon * _2;

   [local count: 1073741824]:
  _1 = this_4(D)->should_show_error_;
  if (_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # _2 = PHI <&kNoneIcon(2), &kBlockedBadgeIcon(3)>
  return _2;

}

Will you be Martin able to fix it with the provided info?

[Bug target/96055] avr: atmega324pb not supported

[matwey.kornilov at gmail dot com]

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

--- Comment #2 from Matwey V. Kornilov  ---
(In reply to Andrew Pinski from comment #1)
> Patches should be sent to gcc-patches@ after reading
> https://gcc.gnu.org/contribute.html .

Thanks. I did a month ago, but nobody has answered:

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547312.html

[Bug c++/96057] -Wreturn-type warning message disappears with -O1 to -Os in unnamed namespace definition

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There was another report about static inline where this happens too. The same
reasoning applies here. The function is unused and there for there is no
undefined runtime behavior can happen.

[Bug c++/96057] New: -Wreturn-type warning message disappears with -O1 to -Os in unnamed namespace definition

[haoxintu at gmail dot com]

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

Bug ID: 96057
   Summary: -Wreturn-type warning message disappears with -O1 to
-Os in unnamed namespace definition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This small code, bug.cc, the -Wreturn-type warning disappears when add -O1 or
higher optimization option.

$cat bug.cc
namespace {
int foo() { 1 ? 0 : throw 0 ; }
}

$g++ -c -Wreturn-type -O0 bug.cc
bug.cc: In function 'int {anonymous}::foo()':
bug.cc:2:35: warning: control reaches end of non-void function [-Wreturn-type]
2 | int foo() { 1 ? 0 : throw 0 ; }
  |   

$g++ -c -Wreturn-type -O1 bug.cc
//emit nothing with -O1 to -Os option

While in Clang, the output of -O0 to -Os is the same. For example,

$clang++ -c -Wreturn-type -O1 bug.cc
bug.cc:2:35: warning: non-void function does not return a value [-Wreturn-type]
int foo() { 1 ? 0 : throw 0 ; }
  ^
1 warning generated.


$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200630 (experimental) (GCC)

[Bug target/96056] New: arm v6/v7: Missing acquire barrier for __atomic_compare_exchange(__ATOMIC_RELEASE, __ATOMIC_ACQUIRE)

[izbyshev at ispras dot ru]

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

Bug ID: 96056
   Summary: arm v6/v7: Missing acquire barrier for
__atomic_compare_exchange(__ATOMIC_RELEASE,
__ATOMIC_ACQUIRE)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izbyshev at ispras dot ru
CC: amonakov at gcc dot gnu.org
  Target Milestone: ---

$ cat test.c
void foo(int x, int y, int z) {
__atomic_compare_exchange(&x, &y, &z, 0, __ATOMIC_RELEASE,
__ATOMIC_ACQUIRE);
}

$ arm-linux-gnueabi-gcc-10 -O2 -march=armv7 -S -o - test.c
[...]
sub sp, sp, #8
str r0, [sp, #4]
add r0, sp, #4
dmb ish
.L2:
ldrex   r3, [r0]
cmp r3, r1
bne .L3
strex   ip, r2, [r0]
cmp ip, #0
bne .L2
.L3:
@ <=== missing dmb here
add sp, sp, #8
[...]

Changing __ATOMIC_RELEASE to __ATOMIC_ACQ_REL restores the missing barrier.

The same problem applies to armv6 as well.

I've checked that all GCC versions on gcc.godbolt.org since 5.4.0 behave in the
same way. All Clang versions on godbolt don't have this problem.

[Bug target/96055] avr: atmega324pb not supported

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug other/96055] New: avr: atmega324pb not supported

[matwey.kornilov at gmail dot com]

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

Bug ID: 96055
   Summary: avr: atmega324pb not supported
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matwey.kornilov at gmail dot com
  Target Milestone: ---

Created attachment 48832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48832&action=edit
Patch to resolve the issue

Hello,


Currently, avr-gcc lacks support for Atmega324PB MCU.
This MCU can be found on Evaluation boards (such as
https://www.microchip.com/DevelopmentTools/ProductDetails/ATMEGA324PB-XPRO ).


Attached here is a patch (tested) to introduce Atmega324PB support.