[Bug lto/96591] [8/9/10/11 Regression] ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96591 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- I will have a look.
[Bug target/98997] New: Linking mismatched -fcf-protection objects generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997
Bug ID: 98997
Summary: Linking mismatched -fcf-protection objects generates
incorrect code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
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.
$ cat cet1.c
#include
void test(jmp_buf buf)
{
__builtin_longjmp(buf, 1);
}
$ cat cet2.c
#include
void test(jmp_buf buf);
int main()
{
jmp_buf buf;
if (__builtin_setjmp(buf) == 0)
test(buf);
return 0;
}
$ gcc -c -O2 cet1.c -fcf-protection=full
$ gcc -c -O2 cet2.c
$ gcc -o cet -O2 cet1.o cet2.o
$ ./cet
Illegal instruction (core dumped)
Presumably the magic CET fixup in the builtin setjmp/longjmp requires that
matching code is generated for both. I'm testing on a non-CET system.
I haven't even tried to figure out if anything sensible happens to the CET GNU
property, but I think the current GCC behavior is impolite at best. I think
GCC should do one of a few things:
1. Generate working code.
2. Fail to link.
3. At least document this pitfall very clearly.
I really hope this doesn't affect shared objects.
[Bug libstdc++/98466] Debug Mode iterators for unordered containers do not implement N3644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98466 François Dumont changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from François Dumont --- Fully fixed
[Bug libstdc++/70303] Value-initialized debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303 François Dumont changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #7 from François Dumont --- Main issue fixed as part of PR 98466 and 33a1e511b57465d898429740377466894a0b247d fixed the last part for deque::iterator - operator.
[Bug target/98532] Use load/store pairs for 2-element vector in memory permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98532 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-02-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Related to PR 93237. I am going to fix this for GCC 12. I have a few patches which already improve this
[Bug ada/98996] New: mips64 ada ftbfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98996 Bug ID: 98996 Summary: mips64 ada ftbfs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: syq at debian dot org Target Milestone: --- /usr/bin/mips64el-linux-gnuabi64-ld: a-nbnbin.o: in function `ada__numerics__big_numbers__big_integers__from_string': s-genbig.adb:(.text+0x6778): undefined reference to `system__val_llli__impl__value_integer' /usr/bin/mips64el-linux-gnuabi64-ld: s-genbig.adb:(.text+0x6780): undefined reference to `system__val_llli__impl__value_integer' https://buildd.debian.org/status/fetch.php?pkg=gcc-11=mips64el=11-20210130-1=1612321109=0 With add $(GNATRTL_128BIT_PAIRS) and $(GNATRTL_128BIT_OBJS), the problem is now: s-pack96.adb: In function 'System.Pack_96.Getu_96': s-pack96.adb:170:8: error: unrecognizable insn: (insn 377 376 378 16 (set (reg:DI 499) (unspec:DI [ (mem:BLK (plus:DI (reg/f:DI 216 [ _65 ]) (const_int 8 [0x8])) [0 +8 S4 A8]) (mem:QI (plus:DI (reg/f:DI 216 [ _65 ]) (const_int 11 [0xb])) [0 +11 S1 A8]) ] UNSPEC_LOAD_LEFT)) "s-pack96.adb":160:23 -1 (nil)) during RTL pass: vregs
[Bug target/98532] Use load/store pairs for 2-element vector in memory permutes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98532 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement CC||pinskia at gcc dot gnu.org
[Bug c++/98995] New: Copy elision not applied to members declared with [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995
Bug ID: 98995
Summary: Copy elision not applied to members declared with
[[no_unique_address]]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit is rejected by gcc 11:
```
struct non_movable {
non_movable() = default;
non_movable(non_movable &&) = delete;
};
struct wrapper {
constexpr explicit wrapper(auto function):
m(function())
{
}
[[no_unique_address]] non_movable m;
};
constexpr auto w = wrapper{[]{ return non_movable(); }};
```
with the error message
```
: In instantiation of 'constexpr wrapper::wrapper(auto:1) [with auto:1
= ]':
:15:55: required from here
:8:17: error: use of deleted function
'non_movable::non_movable(non_movable&&)'
8 | m(function())
| ^
:3:9: note: declared here
3 | non_movable(non_movable &&) = delete;
| ^~~
Compiler returned: 1
```
See it live: https://godbolt.org/z/o1TbY9
This was accepted in gcc 10.2.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #8) > (In reply to Jerry DeLisle from comment #6) > > (In reply to Bill Long from comment #5) > > > Is this fixed in a release version of GCC? > > > > Submitting patch for approval and will backport as the fix is simple. How > > far back shall we go? 10 for sure. Eyeballing the time lines, it does not > > look like 9 will have any more releases. If someone knows otherwise, let me > > know. > > While putting together a test case, I found another problem. > > program test > use, intrinsic :: ieee_arithmetic, only : & > &ieee_class, & > &ieee_class_type, & > &ieee_negative_normal, & > &ieee_positive_normal, & > &operator(.eq.) > ! use, intrinsic :: ieee_arithmetic > real(4) r4 > type(ieee_class_type) class1 > r4 = 1.0 > class1 = ieee_class(r4) > if (class1 .eq. ieee_positive_normal) print *, 'yes' > if (class1 .ne. ieee_negative_normal) print *, 'yes' > r4 = -1.0 > class1 = ieee_class(r4) > if (class1 .eq. ieee_negative_normal) print *, 'yes' > if (class1 .ne. ieee_positive_normal) print *, 'yes' > end program test > > $ gfc pr95647.f90 > pr95647.f90:14:6: > >14 | if (class1 .ne. ieee_negative_normal) print *, 'yes' > | 1 > Error: Operands of comparison operator ‘.ne.’ at (1) are > TYPE(ieee_class_type)/TYPE(ieee_class_type) > pr95647.f90:18:6: > >18 | if (class1 .ne. ieee_positive_normal) print *, 'yes' > | 1 > Error: Operands of comparison operator ‘.ne.’ at (1) are > TYPE(ieee_class_type)/TYPE(ieee_class_type) > > There is more to the story apparently gfortran is correct to issue an error. You forgot to include 'operator(.ne.)' in the only clause of your test program. Neither '.ne.' nor '==' are overloaded for the class.
[Bug c++/98994] New: Empty type with [[no_unique_address]] in union with constructor is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98994
Bug ID: 98994
Summary: Empty type with [[no_unique_address]] in union with
constructor is not a constant expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit:
```
struct empty {};
union U {
constexpr U():
a()
{
}
[[no_unique_address]] empty a;
};
constexpr U u;
```
is incorrectly rejected by gcc 11 with the error:
```
:12:13: error: 'U()' is not a constant expression
12 | constexpr U u;
| ^
:12:13: error: 'U()' is not a constant expression because it refers to
an incompletely initialized variable
Compiler returned: 1
```
See it live: https://godbolt.org/z/PWcco3
This code was accepted in gcc 10.2.
[Bug c++/98993] New: Potential memory problem in GCC compiled with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98993
Bug ID: 98993
Summary: Potential memory problem in GCC compiled with ASAN on
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50141=edit
poc.cc
Hi all,
Hope I do not bother too much.
I got a crafted program which will trigger an internal compiler error in GCC
10.2.0 compiled with ASAN. Note that it means the GCC is compiled with ASAN,
instead of GCC compiling the crafted program with ASAN.
The crafted program is named as poc.cc, and the ICE can be triggered by "g++
poc.cc".
It is also noting that when the GCC is not compiled with ASAN, the ICE cannot
be reproduced. As such, I guess there is a potential memory problem. Maybe I
did something wrong here, and it is very appreciated if anyone can correct me.
Again, I do hope I do not bother too much, and apologize in advance.
Followings are the detailed information.
--- poc.cc starts ---
constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
--- poc.cc ends ---
--- md5 of poc.cc starts ---
b3b9e2c84ed1d7ea07b0ead058e3340d
--- md5 of poc.cc ends ---
--- error trace starts ---
$ ./xg++ poc.cc
poc.cc:1:11: error: ISO C++ forbids declaration of ‘_’ with no type
[-fpermissive]
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^
poc.cc: In lambda function:
poc.cc:1:55: error: expected ‘;’ before ‘union’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^~
| ;
poc.cc:1:64: error: conflicting declaration of C function ‘::s
__builtin_unre0c00ble()’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
|
^
poc.cc:1:25: note: previous declaration ‘::v __builtin_unre0c00ble()’
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
| ^
poc.cc:1:88: internal compiler error: Segmentation fault
1 | constexpr _([]{struct v __builtin_unre0c00ble();goto l union s
__builtin_unre0c00ble();l:
|
^
0x1b279d0 crash_signal(int)
../../gcc/gcc/toplev.c:328
0xd999f8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3407
0xea9b02 decl_jump_unsafe(tree_node*)
../../gcc/gcc/cp/decl.c:3235
0xf0b630 check_previous_goto_1(tree_node*, cp_binding_level*, tree_node*, bool,
unsigned int const*)
../../gcc/gcc/cp/decl.c:3299
0xf0b4c0 check_previous_goto(tree_node*, named_label_use_entry*)
../../gcc/gcc/cp/decl.c:3382
0xec233f define_label_1(unsigned int, tree_node*)
../../gcc/gcc/cp/decl.c:3569
0xec206b define_label(unsigned int, tree_node*)
../../gcc/gcc/cp/decl.c:3582
0x11349eb finish_label_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:1721
0x101c468 cp_parser_label_for_labeled_statement(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11634
0x101bc43 cp_parser_statement(cp_parser*, tree_node*, bool, bool*,
vec*, unsigned int*)
../../gcc/gcc/cp/parser.c:11430
0x101b91a cp_parser_statement_seq_opt(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11843
0x101b647 cp_parser_compound_statement(cp_parser*, tree_node*, int, bool)
../../gcc/gcc/cp/parser.c:11793
0x1025da4 cp_parser_function_body(cp_parser*, bool)
../../gcc/gcc/cp/parser.c:23079
0x102deb9 cp_parser_lambda_body(cp_parser*, tree_node*)
../../gcc/gcc/cp/parser.c:11223
0x101a145 cp_parser_lambda_expression(cp_parser*)
../../gcc/gcc/cp/parser.c:10593
0x1017e01 cp_parser_primary_expression(cp_parser*, bool, bool, bool, bool,
cp_id_kind*)
../../gcc/gcc/cp/parser.c:5416
0x101258c cp_parser_postfix_expression(cp_parser*, bool, bool, bool, bool,
cp_id_kind*)
../../gcc/gcc/cp/parser.c:7257
0x1006c52 cp_parser_unary_expression(cp_parser*, cp_id_kind*, bool, bool, bool)
../../gcc/gcc/cp/parser.c:8560
0x100595e cp_parser_cast_expression(cp_parser*, bool, bool, bool, cp_id_kind*)
../../gcc/gcc/cp/parser.c:9458
0x1002dd5 cp_parser_binary_expression(cp_parser*, bool, bool, bool,
cp_parser_prec, cp_id_kind*)
../../gcc/gcc/cp/parser.c:9561
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any
[Bug middle-end/98989] missing -Wfree-nonheap-object freeing std::strings over 15 bytes long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98989 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98992 --- Comment #3 from Martin Sebor --- Bug 98992 shows that associating a member deallocator function with an allocator doesn't work in GCC 11.
[Bug c++/98992] New: attribute malloc error associating a member deallocator with an allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98992
Bug ID: 98992
Summary: attribute malloc error associating a member
deallocator with an allocator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The new attribute malloc is rejected on declarations of member function:
$ cat t.C && /build/gcc-master/gcc/xg++ -B /build/gcc-master/gcc -S -Wall t.C
struct A
{
void dealloc (void*);
__attribute__ ((malloc (dealloc)))
void* alloc ();
};
t.C:6:16: error: ‘malloc’ attribute argument 1 does not name a function
6 | void* alloc ();
|^
The attribute handler is prepared for FUNCTION_DECL and OVERLOAD but not for
how a member function is represented here:
VOID
align:1 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea9532a0
pointer_to_this
reference_to_this >
arg:0 context
full-name "struct S"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
arg:0
constant
arg:0
constant>>>
arg:1
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea96a690 method basetype
arg-types
chain
chain
functions
used public private external decl_3 QI /build/tmp/t.C:8:8 align:16
warn_if_not_align:0 context
full-name "void S::m_dealloc(char*)" chain >
binfo
public private bases:0 offset >
access_binfo >
/build/tmp/t.C:9:27 start: /build/tmp/t.C:9:27 finish: /build/tmp/t.C:9:35>
[Bug c++/98991] New: ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
Bug ID: 98991
Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50140=edit
poc.cc
Hi all,
I am not sure whether it is indeed an ICE, so I do apologize in advance for any
possible inconvenience.
I have a file generated by my little toy fuzzer, named poc.cc.
When I compile it with: "g++ poc.cc -fpermissive", I got an "internal compiler
error: Max. number of generated reload insns per insn is achieved (90)".
Followings are the detailed information.
--- poc.cc starts ---
namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
--- poc.cc ends ---
--- md5 of poc.cc starts ---
c11f34bb78474a2a8bdcb5c5de6d19a2
--- md5 of poc.cc ends ---
--- error trace starts ---
$ ./xg++ poc.cc -fpermissive
poc.cc:1:11: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~~
poc.cc:1:42: warning: ISO C++ forbids declaration of ‘n’ with no type
[-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^
poc.cc:1:44: warning: ‘e’ attribute directive ignored [-Wattributes]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
|^
poc.cc: In function ‘int {anonymous}::n()’:
poc.cc:1:46: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~
poc.cc:1:50: warning: declaration does not declare anything [-fpermissive]
1 | namespace{thread_local;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
| ^~~~
poc.cc:1:237: warning: using rvalue as lvalue [-fpermissive]
1 | ocal;__attribute((e()))n(){int;long;float
f;__attribute(())__builtin_constant_p(0)))==0));try{}catch(int){}sizeof(reinterpret_cast(0));asm("":"=rmf"(f),"=d"([t(reinterpret_cast(0))]{}):"0"(((0))),""((0)));static_assert(1);__attribute(())class{}t;{__builtin_unreachable;int{reinterpret_cast(0)};();}}y(){float;}}short;namespace{int;templatef(){}}struct
s;
|
^
poc.cc:1:338: warning: no return statement in function returning non-void
[-Wreturn-type]
1 |
[Bug middle-end/98989] missing -Wfree-nonheap-object freeing std::strings over 15 bytes long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98989
--- Comment #2 from Martin Sebor ---
Not having to annotate _M_create is also helpful when the call isn't inlined.
For example, neither of the following functions is diagnosed because in both
cases GCC emits a call equivalent to:
std::__cxx11::basic_string::_M_construct.isra (, "abc", [(void *)"abc" + 3B]);
and from that there's no way for the warning to determine how the string buffer
was allocated.
#include
void f ()
{
std::string str ("abc");
char *p = [0];
__builtin_free (p);
}
void g ()
{
std::string str ("def");
char *p = [0];
__builtin_free (p);
}
The IL for both f() and g() ends up looking alike (below) but in both cases the
calls to free() and operator delete() are evidently made with the same pointer.
(Technically, the use of str._M_dataplus._M_p in the assignment right after
the call to free() will be grounds for issuing -Wuse-after-free once the
warning is implemented.)
void f ()
{
struct string str;
char * _7;
char * _9;
long unsigned int _11;
long unsigned int _12;
[local count: 1073741824]:
MEM[(struct basic_string *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)]._M_p = _M_local_buf;
std::__cxx11::basic_string::_M_construct.isra (, "abc", [(void *)"abc" + 3B]);
_7 = str._M_dataplus._M_p;
__builtin_free (_7);
_9 = str._M_dataplus._M_p;
if (_M_local_buf != _9)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 574129753]:
_11 = str.D.24447._M_allocated_capacity;
_12 = _11 + 1;
operator delete (_9, _12);
[local count: 1073741824]:
str ={v} {CLOBBER};
str ={v} {CLOBBER};
return;
}
[Bug middle-end/98989] missing -Wfree-nonheap-object freeing std::strings over 15 bytes long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98989
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Martin Sebor ---
The reason the invalid call isn't diagnosed is because the allocation call is
"hidden" behind the call to std::__cxx11::basic_string::_M_create(), and
_M_create isn't annotated as an allocation function (with attribute malloc).
In this case, though, the optimized IL shows that besides free() the function
also calls operator delete() on the same pointer. That's almost certainly
wrong regardless of the control flow and so the warning could trigger simply on
that basis.
annotating _M_create() shouldn't be necessary
;; Function f (_Z1fv, funcdef_no=1194, decl_uid=32383, cgraph_uid=317,
symbol_order=347)
Removing basic block 5
void f ()
{
size_type __dnew;
struct string str;
char * _7;
char * _9;
long unsigned int _11;
long unsigned int _12;
char * _19;
long unsigned int __dnew.6_20;
long unsigned int __dnew.7_22;
char * _23;
char * _24;
[local count: 1073741824]:
MEM[(struct basic_string *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)] ={v} {CLOBBER};
MEM[(struct _Alloc_hider *)]._M_p = _M_local_buf;
__dnew = 16;
_19 = std::__cxx11::basic_string::_M_create (, &__dnew, 0);
str._M_dataplus._M_p = _19;
__dnew.6_20 = __dnew;
str.D.24447._M_allocated_capacity = __dnew.6_20;
__builtin_memcpy (_19, "abcdefghijklmnop", 16);
__dnew.7_22 = __dnew;
str._M_string_length = __dnew.7_22;
_23 = str._M_dataplus._M_p;
_24 = _23 + __dnew.7_22;
MEM[(char_type &)_24] = 0;
__dnew ={v} {CLOBBER};
_7 = str._M_dataplus._M_p;
free (_7);
_9 = str._M_dataplus._M_p;
if (_M_local_buf != _9)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 574129753]:
_11 = str.D.24447._M_allocated_capacity;
_12 = _11 + 1;
operator delete (_9, _12);
[local count: 1073741824]:
str ={v} {CLOBBER};
str ={v} {CLOBBER};
return;
}
[Bug c++/98990] Internal compiler error when two overloaded functions return `auto &&` and one accepts an `auto` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 David Stone changed: What|Removed |Added CC||david at doublewise dot net --- Comment #1 from David Stone --- To trigger this bug, the return type can be declared `auto &&`, `auto const &`, or `auto &`. If it is `auto` or `decltype(auto)`, the bug is not triggered. Whichever form is used, the same form must be used for both declarations.
[Bug c++/98990] New: Internal compiler error when two overloaded functions return `auto &&` and one accepts an `auto` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990
Bug ID: 98990
Summary: Internal compiler error when two overloaded functions
return `auto &&` and one accepts an `auto` parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit
```
constexpr int x = 0;
constexpr auto && f() {
return x;
}
constexpr auto && f(auto) {
return x;
}
```
causes gcc to crash with
```
:6:25: internal compiler error: same canonical type node for different
types 'auto&&' and 'auto&&'
6 | constexpr auto && f(auto) {
| ^
0x1ce6f09 internal_error(char const*, ...)
???:0
0x9c60ce comptypes(tree_node*, tree_node*, int)
???:0
0x78ef77 decls_match(tree_node*, tree_node*, bool)
???:0
0x7c003c cplus_decl_attributes(tree_node**, tree_node*, int)
???:0
0x79f277 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x7a3916 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
???:0
0x8de23d c_parse_file()
???:0
0xa5b7c2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/98989] New: missing -Wfree-nonheap-object freeing std::strings over 15 bytes long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98989
Bug ID: 98989
Summary: missing -Wfree-nonheap-object freeing std::strings
over 15 bytes long
Product: gcc
Version: 11.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: ---
Given the test case below, -Wfree-nonheap-object detects the invalid attempt to
free the std::string buffer provided the string constant it's initialized with
is no more than 15 characters long (plus the terminating nul). But the option
fails to diagnose the invalid call once the string length is 16 or more.
#include
void f ()
{
std::string str (STR);
char *p = [0];
free (p);
}
$ g++ -DSTR='"abcdefghijklmno"' -O2 -S -Wall t.C
t.C: In function ‘void f()’:
t.C:7:8: warning: ‘void free(void*)’ called on unallocated object ‘str’
[-Wfree-nonheap-object]
7 | free (p);
| ~^~~
t.C:5:15: note: declared here
5 | std::string str (STR);
| ^~~
[Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
Bug ID: 98988
Summary: delete is not a constant expression with
-fsanitize=undefined
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit:
```
constexpr bool f() {
auto ptr = new int();
delete ptr;
return true;
}
static_assert(f());
```
is incorrectly rejected when compiled with `-fsanitize=undefined`, complaining
about
```
:7:16: error: non-constant condition for static assertion
7 | static_assert(f());
| ~^~
:7:16: in 'constexpr' expansion of 'f()'
:3:9: error: '(((int*)(& heap )) != 0)' is not a constant expression
3 | delete ptr;
| ^~
Compiler returned: 1
```
See it live: https://godbolt.org/z/Yf67G7
[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959 --- Comment #14 from Bill Schmidt --- We should definitely not be allowing the AltiVec "& ~16" flavors into these patterns. I'm not certain whether your fix is the best way to achieve that, but it could well be; I'll defer to Segher on that.
[Bug c++/79751] Concept placeholder on another concept does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79751 David Stone changed: What|Removed |Added CC||david at doublewise dot net --- Comment #2 from David Stone --- Resolved in gcc 10.1. It now correctly rejects this code.
[Bug c++/98987] New: Concept subsumption doesn't work with by-value vs. by-reference parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98987
Bug ID: 98987
Summary: Concept subsumption doesn't work with by-value vs.
by-reference parameters
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following translation unit
```
template
concept A = true;
template
concept B = A and true;
constexpr bool f(A auto) {
return false;
}
constexpr bool f(B auto const &) {
return true;
}
static_assert(f(0));
```
should compile successfully. Instead, gcc reports
```
:15:18: error: call of overloaded 'f(int)' is ambiguous
15 | static_assert(f(0));
| ^
:7:16: note: candidate: 'constexpr bool f(auto:1) [with auto:1 = int]'
7 | constexpr bool f(A auto) {
|^
:11:16: note: candidate: 'constexpr bool f(const auto:2&) [with auto:2
= int]'
11 | constexpr bool f(B auto const &) {
|^
Compiler returned: 1
```
Changing the first `f` overload to accept `A auto const &` or changing the
second to accept `B auto` resolves the ambiguity error.
See it live: https://godbolt.org/z/9aYo64
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #29 from cqwrteur --- (In reply to Mikael Pettersson from comment #25) > Created attachment 50138 [details] > do not default to dwarf5 on Windows > > I have the same problem with gcc-11 bootstrap failures due to Exec format > errors post stage 1 on Cygwin64, even with current binutils master. I don't > know if it's a bug in binutils or a limitation in Windows, but DWARF5 > clearly does not work there, so this patch disables it. Works for me on > Cygwin64. Can someone please test it on mingw-w64? test success. you can merge it to master now
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #13 from Jakub Jelinek --- I got that with dejagnu 1.6.1.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #12 from Ian Lance Taylor --- Other than the timeout issue, DejaGNU appears to work as expected on my system. After 300 seconds, it will run the shell command "kill -2 $spid" which kills the program. The program issue19182.go does nothing special with SIGINT, and in my testing it simply exits. In any case, if the program does not exist after the "kill -2", DejaGNU waits 5 seconds and does a "kill -15", then waits another 5 seconds and does a "kill -9". In short, I can't recreate the problem and I don't see where the bug is. What version of DejaGNU is in use on the system where the problem occurs? I'm testing with DejaGNU 1.6.2.
[Bug rtl-optimization/98986] New: Try matching both orders of commutative RTX operations when there is no canonical order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
Bug ID: 98986
Summary: Try matching both orders of commutative RTX operations
when there is no canonical order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
The motivating aarch64 testcase is this:
#include
int32x4_t
foo (int16x4_t a, int16x4_t b)
{
int16x4_t tmp = vdup_n_s16 (vget_lane_s16 (b, 3));
return vmull_s16 (tmp, a);
}
int32x4_t
foo2 (int16x4_t a, int16x4_t b)
{
int16x4_t tmp = vdup_n_s16 (vget_lane_s16 (b, 3));
return vmull_s16 (a, tmp);
}
Both functions should generate the widening-mult-by-lane form:
smull v0.4s, v0.4h, v1.h[3] // 13 [c=16 l=4]
aarch64_vec_smult_lane_v4hi
However only the second function foo2 manages to match it.
We have a pattern for this in aarch64-simd.md:
(define_insn "aarch64_vec_mult_lane"
[(set (match_operand: 0 "register_operand" "=w")
(mult:
(ANY_EXTEND:
(match_operand: 1 "register_operand" "w"))
(ANY_EXTEND:
(vec_duplicate:
(vec_select:
(match_operand:VDQHS 2 "register_operand" "")
(parallel [(match_operand:SI 3 "immediate_operand" "i")]))]
"TARGET_SIMD"
{
operands[3] = aarch64_endian_lane_rtx (mode, INTVAL (operands[3]));
return "mull\\t%0., %1., %2.[%3]";
}
[(set_attr "type" "neon_mul__scalar_long")]
)
For foo combine tries and fails to match the vec_select in the first arm of the
mult:
(set (reg:V4SI 93 [ ])
(mult:V4SI (sign_extend:V4SI (vec_duplicate:V4HI (vec_select:HI (reg:V4HI
99)
(parallel:V4HI [
(const_int 3 [0x3])
]
(sign_extend:V4SI (reg:V4HI 98
Unfortunately, due to the sign_extends on both arm of the mult there is no
canonical order for these expressions as both arms of the MULT are RTX_UNARY
expressions and swap_commutative_operands_p doesn't try to swap them around.
I guess we can work around this by adding more patterns in the backend to match
the two different orders we can get in this situation, but we've got
so many similar patterns in the backend...
Do you think it's feasible to get recog or combine to try out both permutations
of such commutative operations when matching without blowing up compile time?
Any other ideas for resolving this are welcome
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #8 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #6) > (In reply to Bill Long from comment #5) > > Is this fixed in a release version of GCC? > > Submitting patch for approval and will backport as the fix is simple. How > far back shall we go? 10 for sure. Eyeballing the time lines, it does not > look like 9 will have any more releases. If someone knows otherwise, let me > know. While putting together a test case, I found another problem. program test use, intrinsic :: ieee_arithmetic, only : & &ieee_class, & &ieee_class_type, & &ieee_negative_normal, & &ieee_positive_normal, & &operator(.eq.) ! use, intrinsic :: ieee_arithmetic real(4) r4 type(ieee_class_type) class1 r4 = 1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_positive_normal) print *, 'yes' if (class1 .ne. ieee_negative_normal) print *, 'yes' r4 = -1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_negative_normal) print *, 'yes' if (class1 .ne. ieee_positive_normal) print *, 'yes' end program test $ gfc pr95647.f90 pr95647.f90:14:6: 14 | if (class1 .ne. ieee_negative_normal) print *, 'yes' | 1 Error: Operands of comparison operator ‘.ne.’ at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) pr95647.f90:18:6: 18 | if (class1 .ne. ieee_positive_normal) print *, 'yes' | 1 Error: Operands of comparison operator ‘.ne.’ at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) There is more to the story apparently
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #11 from Ian Lance Taylor --- I'm just noting that DejaGNU appears to have a bug in the standard_wait procedure: http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=lib/remote.exp;h=1c9971a076415adc2fcdc04ab8f78cc832ce1098;hb=HEAD#l1162 The code seems to assume that the parameter timeout will set the timeout for the remote_expect. But as far as I can tell, when running under expect, "timeout" is always a global variable. So the $timeout that appears in the function refers to the global variable named "timeout", not the parameter named "timeout". This means that although the DejaGNU procedure unix_load appears to set the timeout to the value of the global variable "test_timeout", and logs various messages to that effect, in fact that variable has no effect. Only the variable "timeout" matters. However, this DejaGNU bug is not important in the larger scheme of things and does not seem to affect this issue.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #28 from Mikael Pettersson --- (In reply to Brecht Sanders from comment #27) > @Mikael Pettersson, should a similar patch be applied to > gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64? cygming.h is used for both mingw and cygwin, so no additional patch should be needed.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #7 from Bill Long --- For our purposes, 10 will be fine.
[Bug libstdc++/98985] New: libstdc++: filesystem::rename not overwriting files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985 Bug ID: 98985 Summary: libstdc++: filesystem::rename not overwriting files on Windows Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: m.heinzler at heinzler dot de Target Milestone: --- Created attachment 50139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50139=edit Proposed fix filesystem::rename must replace existing files and currently does so on most platforms by simply calling posix::rename. But on Windows (specifically MinGW), posix::rename refers to Microsoft's MSVCRT which does not overwrite files. See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=msvc-160 I attached a patch that falls back to the WinAPI in this case and tested it successfully. This is also how Microsoft implements filesystem::rename. As I'm not familiar with the codebase I wasn't able to add a simple test case for this. If someone could give me a hint which files to touch I could also work on that.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from Jerry DeLisle --- (In reply to Bill Long from comment #5) > Is this fixed in a release version of GCC? Submitting patch for approval and will backport as the fix is simple. How far back shall we go? 10 for sure. Eyeballing the time lines, it does not look like 9 will have any more releases. If someone knows otherwise, let me know.
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #4 from Brecht Sanders --- Found a smaller project to reproduce the issue with: building BLAKE3 v0.3.7 from https://github.com/BLAKE3-team/BLAKE3 also has the issue when building with GCC11 for 32-bit MinGW-w64. Here I noticed that compiling with -O0 works around the problem, so the issue must be in the compiler optimization for i686.
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #3 from Brecht Sanders --- Issue is till present in GCC 11 snapshot 20210131. When building GCC 11 with GCC 11 the error is still there when trying to build fortran. I also noticed the same error when using GCC 11 to build ccache 4.2. Any updates on this issue?
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to Arnaud Charlet from comment #9) > The problem is somehow specific to m68k, for some unknown reason. There is > nothing target specific in the change, no assumption is made on the > underlying target. > > What we need now is a debugging session from someone who has a setup to > reproduce. See here on how to set up a qemu environment: https://wiki.debian.org/M68k/QemuSystemM68k
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #9 from Arnaud Charlet --- The problem is somehow specific to m68k, for some unknown reason. There is nothing target specific in the change, no assumption is made on the underlying target. What we need now is a debugging session from someone who has a setup to reproduce.
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Arnaud Charlet from comment #7) > In other words, the bisect result isn't very useful here and I'd recommend > investigating this change from scratch, getting a useful backtrace from gdb > and understanding where this is crashing and then why. I can certainly generate a backtrace in GDB, but I'm not an Ada expert which is why I reported the issue and hoped that the author of the change would be able to understand what the problem is. It could also be possible that the change makes some assumptions of the underlying ABI that may well be true for x86_64 but not m68k.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #27 from Brecht Sanders --- @Mikael Pettersson, should a similar patch be applied to gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?
