[Bug c++/95935] New: ICE : Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
Bug ID: 95935
Summary: ICE : Segmentation fault
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE with Segmentation
fault.
$cat bug.cc
enum struct a;
template enum struct a {
$g++ bug.cc
bug.cc:2:36: error: expected ‘}’ before ‘;’ token
2 | template ’ before ‘;’ token
bug.cc:2:36: error: expected unqualified-id before ‘;’ token
bug.cc:4: error: expected identifier at end of input
bug.cc:4: error: expected ‘}’ at end of input
bug.cc:3:27: note: to match this ‘{’
3 | template <> enum struct a {
| ^
bug.cc:2:35: internal compiler error: Segmentation fault
2 | template https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug lto/95928] LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #5 from Andi Kleen --- It doesn't seem to be the plugin itself, I compiled trunk with the gcc-7 lto-plugin.c and it fails too.
[Bug lto/95928] LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #4 from Andi Kleen --- Reproduced on trunk too 11.0-200626 e74c281bf4955eea7fdc5f21b43e29fa0235a5b0
[Bug bootstrap/95934] New: bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95934 Bug ID: 95934 Summary: bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org Target Milestone: --- commit e74c281bf4955eea7fdc5f21b43e29fa0235a5b0 (HEAD -> trunk, origin/trunk, origin/master, origin/HEAD) make bootstrap fails with ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:336:30: note: in expansion of macro 'IMPL_COMPILER_ASSERT' 336 | #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) | ^~~~ ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1442:3: note: in expansion of macro 'COMPILER_CHECK' 1442 | COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *)NULL)->MEMBER) == \ | ^~ ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:1136:1: note: in expansion of macro 'CHECK_SIZE_AND_OFFSET' 1136 | CHECK_SIZE_AND_OFFSET(ipc_perm, mode); | ^ Works fine when I comment out the assert. There already is a ifdef checking for lots of cases, seems it doesn't work on mine either. This is with a recent glibc-2.31-5.9.x86_64 (opensuse glibc) Perhaps the assert should just be disabled like this? (patch is likely white space damaged) diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp index b4f8f67b664..bb6377b70cb 100644 --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp @@ -1133,7 +1133,7 @@ CHECK_SIZE_AND_OFFSET(ipc_perm, cgid); /* On aarch64 glibc 2.20 and earlier provided incorrect mode field. */ /* On Arm newer glibc provide a different mode field, it's hard to detect so just disable the check. */ -CHECK_SIZE_AND_OFFSET(ipc_perm, mode); +//CHECK_SIZE_AND_OFFSET(ipc_perm, mode); #endif CHECK_TYPE_SIZE(shmid_ds);
[Bug c++/95933] New: pointer variables in template classes admit arbitrary assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95933
Bug ID: 95933
Summary: pointer variables in template classes admit arbitrary
assignments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jaime.a.rosal at gmail dot com
Target Milestone: ---
I recently found some strange behavior in GCC 9.3 . For some reason pointer
variables in templated classes seem to admit assignments to arbitrary types,
i.e. the following code:
template struct Bar {
int * E;
void Foo () {
E = new double[1000]; // wait, what?
}
};
Bar<1> T;
compiles without error with 'g++ -c bug.cpp'. This seems to be true for any
combination of types and template parameters.
[Bug c++/95932] New: ICE in redeclare_class_template, at cp/pt.c:6231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
Bug ID: 95932
Summary: ICE in redeclare_class_template, at cp/pt.c:6231
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
template > struct a < class b{}, struct b {
$g++ bug.cc
bug.cc:1:19: error: expected ‘<’ before ‘>>’ token
1 | template > struct a < class b{}, struct b {
| ^~
bug.cc:1:19: error: expected identifier before ‘>>’ token
bug.cc:1:19: error: expected ‘>’ before ‘>>’ token
bug.cc:1:19: error: expected ‘class’ or ‘typename’ before ‘>>’ token
bug.cc:1:19: error: expected identifier before ‘>>’ token
bug.cc:1:19: error: expected ‘>’ before ‘>>’ token
bug.cc:1:29: error: ‘a’ is not a class template
1 | template > struct a < class b{}, struct b {
| ^
bug.cc:1:40: error: types may not be defined in template arguments
1 | template > struct a < class b{}, struct b {
|^
bug.cc:1:51: internal compiler error: in redeclare_class_template, at
cp/pt.c:6231
1 | template > struct a < class b{}, struct b {
| ^
0x652319 redeclare_class_template(tree_node*, tree_node*, tree_node*)
../../gcc/cp/pt.c:6231
0x8fb2e7 xref_tag_1
../../gcc/cp/decl.c:15043
0x8fb440 xref_tag(tag_types, tree_node*, tag_scope, bool)
../../gcc/cp/decl.c:15085
0x9a1584 cp_parser_class_head
../../gcc/cp/parser.c:24658
0x9a1584 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23880
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9b6b53 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:22439
0x9afa94 cp_parser_type_id_1
../../gcc/cp/parser.c:22256
0x9b2603 cp_parser_template_type_arg
../../gcc/cp/parser.c:22347
0x9b6ccf cp_parser_template_argument
../../gcc/cp/parser.c:17235
0x9b6ccf cp_parser_template_argument_list
../../gcc/cp/parser.c:17146
0x9b6ccf cp_parser_enclosed_template_argument_list
../../gcc/cp/parser.c:29832
0x9b8cd0 cp_parser_check_for_invalid_template_id
../../gcc/cp/parser.c:3202
0x99ff18 cp_parser_check_for_invalid_template_id
../../gcc/cp/parser.c:3181
0x99ff18 cp_parser_class_head
../../gcc/cp/parser.c:24437
0x99ff18 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23880
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95931] New: ICE in dependent_type_p, at cp/pt.c:26326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931
Bug ID: 95931
Summary: ICE in dependent_type_p, at cp/pt.c:26326
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: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.
$cat bug.cc
void a { [] (auto, volatile b
$g++ bug.cc
bug.cc:1:6: error: variable or field ‘a’ declared void
1 | void a { [] (auto, volatile b
| ^
bug.cc:1:29: error: ‘b’ does not name a type
1 | void a { [] (auto, volatile b
| ^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:30: error: expected ‘)’ at end of input
1 | void a { [] (auto, volatile b
| ~^
| )
bug.cc:2: internal compiler error: in dependent_type_p, at cp/pt.c:26326
0x6551ca dependent_type_p(tree_node*)
../../gcc/cp/pt.c:26326
0x8fc1bb require_complete_types_for_parms
../../gcc/cp/decl.c:13832
0x8fc1bb check_function_type
../../gcc/cp/decl.c:16043
0x8fc1bb start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:16257
0x956a15 start_lambda_function(tree_node*, tree_node*)
../../gcc/cp/lambda.c:1425
0x9a912b cp_parser_lambda_body
../../gcc/cp/parser.c:11264
0x9a912b cp_parser_lambda_expression
../../gcc/cp/parser.c:10640
0x9a912b cp_parser_primary_expression
../../gcc/cp/parser.c:5443
0x9b2960 cp_parser_postfix_expression
../../gcc/cp/parser.c:7296
0x99564a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0x9971ae cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0x995f6d cp_parser_constant_expression
../../gcc/cp/parser.c:10208
0x9966d1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23272
0x99683a cp_parser_initializer_list
../../gcc/cp/parser.c:23550
0x99683a cp_parser_braced_list
../../gcc/cp/parser.c:23311
0x99aa3a cp_parser_initializer
../../gcc/cp/parser.c:23228
0x9c259b cp_parser_init_declarator
../../gcc/cp/parser.c:20903
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug c++/95930] New: ICE: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930
Bug ID: 95930
Summary: ICE: Segmentation fault signal terminated program
cc1plus
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE with Segmentation
fault signal terminated program cc1plus.
$cat bug.cc
long a = [] ( class {
$g++ bug.cc
bug.cc:1:24: error: types may not be defined in parameter types
1 | long a = [] ( class {
|^
bug.cc:2: error: expected ‘}’ at end of input
bug.cc:1:24: note: to match this ‘{’
1 | long a = [] ( class {
|^
bug.cc:2: error: expected ‘,’ or ‘...’ at end of input
bug.cc:1:25: error: expected ‘)’ at end of input
1 | long a = [] ( class {
|~^
| )
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug tree-optimization/95929] New: Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929
Bug ID: 95929
Summary: Failure to optimize tautological comparisons of
comparisons to a single one
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int a, int b)
{
return (((b != 0) & (a == 0)) | ((a != 0) & (b == 0)));
}
This can be optimized to `(a != 0) ^ (b != 0)`. I originally found this while
compiling this code :
inline bool nand(bool a, bool b)
{
return !(a && b);
}
int f(int a, int b)
{
return nand(nand(b, nand(a, a)), nand(a, nand(b, b)));
}
Which GCC compiles to the above example, and that LLVM optimizes with the
transformation I gave (strangely, LLVM does not seem to optimize the example at
the top of this bug report to the transformed version if directly given the top
example, which is why I'm giving these details as I'm thinking there could be
some kind of UB weirdness or something like that with the transformations here)
[Bug lto/95928] LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #3 from Andi Kleen --- Versions reproduced: gcc version 10.1.1 20200507 [revision dd38686d9c810cecbaa80bb82ed91caaa58ad635] (SUSE Linux) gcc-9 (SUSE Linux) 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2] Version which worked correctly: gcc version 7.5.0 (SUSE Linux) binutils: GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1
[Bug lto/95928] LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #1 from Andi Kleen --- Created attachment 48792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48792=edit sys_ni.i
[Bug lto/95928] LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 --- Comment #2 from Andi Kleen --- Created attachment 48793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48793=edit capability.i
[Bug lto/95928] New: LTO through ar breaks weak function resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95928 Bug ID: 95928 Summary: LTO through ar breaks weak function resolution Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org CC: marxin at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux Created attachment 48791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48791=edit dummy.c With the attached test case (extracted from the Linux kernel) the expected behavior is that the strong version of __x64_sys_capget overrides the weak version in sys_ni.i This works with LTO when the object files are linked directly, but doesn't work (weak version of function is output) when the linking is through a .a file. Works gcc -flto -c sys_ni.i gcc -flto -c capability.i gcc -O2 -flto dummy.c sys_ni.o capability.o # sys_ni_syscall doesn't appear, so the strong version is chosen objdump --disassemble=__x64_sys_capget | grep sys_ni_syscall Breaks: gcc -flto -c sys_ni.i gcc -flto -c capability.i rm -f x.a gcc-ar q x.a sys_ni.o capability.o gcc -O2 -flto dummy.c x.a # sys_ni_syscall appears, so the weak version is incorrectly chosen objdump --disassemble=__x64_sys_capget | grep sys_ni_syscall This seems to be a regression, it worked on gcc-7, but breaks on gcc 9/10. Don't have any immediate versions to test.
[Bug c++/95927] New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
Bug ID: 95927
Summary: ICE in cp_lexer_new_from_tokens, at cp/parser.c:701
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code, bug.cc, reduced by C-Reduce, makes GCC ICE.
$cat bug.cc
class {
struct a < struct { b ( {
$g++ bug.cc
bug.cc:2:8: error: ‘a’ is not a class template
2 | struct a < struct { b ( {
|^
bug.cc:2:19: error: types may not be defined in template arguments
2 | struct a < struct { b ( {
| ^
bug.cc:2:25: error: expected identifier before ‘{’ token
2 | struct a < struct { b ( {
| ^
bug.cc:2:24: error: expected ‘)’ before ‘{’ token
2 | struct a < struct { b ( {
| ~^~
|)
bug.cc:2:21: error: ISO C++ forbids declaration of ‘b’ with no type
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-fpermissive-fpermissive]8;;]
2 | struct a < struct { b ( {
| ^
bug.cc:3: error: expected ‘}’ at end of input
bug.cc:2:19: note: to match this ‘{’
2 | struct a < struct { b ( {
| ^
bug.cc:3: error: expected template-argument at end of input
bug.cc:3: error: expected ‘>’ at end of input
bug.cc:3: error: expected ‘{’ or ‘:’ at end of input
bug.cc:3: error: expected ‘{’ at end of input
bug.cc:3: error: expected unqualified-id at end of input
bug.cc:3: error: expected ‘}’ at end of input
bug.cc:1:7: note: to match this ‘{’
1 | class {
| ^
bug.cc:3: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:701
0x641d4d cp_parser_push_lexer_for_tokens
../../gcc/cp/parser.c:701
0x9c2bc5 cp_parser_late_parsing_for_member
../../gcc/cp/parser.c:29944
0x9a0ccb cp_parser_class_specifier_1
../../gcc/cp/parser.c:24230
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9a35c1 cp_parser_simple_declaration
../../gcc/cp/parser.c:13664
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
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.
[Bug tree-optimization/95926] New: Failure to optimize xor pattern when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926
Bug ID: 95926
Summary: Failure to optimize xor pattern when
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(bool a, bool b)
{
bool tmp = a & b;
return (tmp ^ b) | (tmp ^ a);
}
This code does not optimize as well as this code :
bool f(bool a, bool b)
{
return ((a & b) ^ b) | ((a & b) ^ a);
}
which optimizes to `return a ^ b;`. This seems rather odd considering that they
are equivalent and the first example is just a simplification of the second
(i.e. made more readable).
[Bug c++/95925] New: ICE in xref_basetypes, at cp/decl.c:15169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925 Bug ID: 95925 Summary: ICE in xref_basetypes, at cp/decl.c:15169 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code, bug.cc, reduced by C-Reduce, makes GCC ICE. $cat bug.cc class a; template https://gcc.gnu.org/bugs/> for instructions. $g++ --version g++ (GCC) 11.0.0 20200626 (experimental) 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.
[Bug tree-optimization/95924] New: Failure to optimize some bit magic to one of the operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924
Bug ID: 95924
Summary: Failure to optimize some bit magic to one of the
operands
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(bool a, bool b)
{
return (a | !b) ? (~a & b) ? 0 : a : 0;
}
This can be optimized to `return a;`. This transformation is done by LLVM, but
not by GCC.
[Bug tree-optimization/95923] New: Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923
Bug ID: 95923
Summary: Failure to optimize bool checks into and
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(bool a, bool b)
{
if (!a && !b)
return 0;
if (!a && b)
return 0;
if (a && !b)
return 0;
return 1;
}
This can be optimized to `return a & b;`. This transformation is done by LLVM,
but not by GCC.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #11 from John Zwinck ---
Jeffrey, when I compile with -fno-isolate-erroneous-paths-dereference I am
asking the compiler not to insert traps. I filed this issue in hopes that GCC
can better optimize when it is told not to insert traps.
I think the default behavior of inserting a trap is sort of OK ("sort of"
because it seems pointless to trap when not trapping would dereference 0x0,
which in my mind is also a good way to end a program that dereferences a null
pointer). But when I tell GCC not to insert traps, I definitely want the
simplest, fastest code.
[Bug tree-optimization/95922] New: Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95922
Bug ID: 95922
Summary: Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) |
(b & c)` the right way on architectures with andnot
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int a, int b, int c)
{
return ((b ^ a) & c) ^ a;
}
This can be optimized to `return (a & ~c) | (b & c);` on processors that have
andnot instructions (at least according to LLVM, which does this transformation
on x86 with -mbmi).
[Bug target/95655] -mfentry -pg generates extra push/pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from H.J. Lu --- Fixed for GCC 11.
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 Bug 93492 depends on bug 95655, which changed state. Bug 95655 Summary: -mfentry -pg generates extra push/pop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/95655] -mfentry -pg generates extra push/pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95655 --- Comment #4 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:727efd27da90fe09ed393c7bb44bba071ae0e0d3 commit r11-1680-g727efd27da90fe09ed393c7bb44bba071ae0e0d3 Author: H.J. Lu Date: Fri Jun 12 05:44:59 2020 -0700 Linux/i386: Remove SUBTARGET_FRAME_POINTER_REQUIRED config/i386/gnu-user.h has #define SUBTARGET_FRAME_POINTER_REQUIRED crtl->profile ix86_frame_pointer_required() has /* Several x86 os'es need a frame pointer for other reasons, usually pertaining to setjmp. */ if (SUBTARGET_FRAME_POINTER_REQUIRED) return true; ... if (crtl->profile && !flag_fentry) return true; A frame pointer is needed only for -pg, not for -mfentry -pg. Remove SUBTARGET_FRAME_POINTER_REQUIRED from gnu-user.h to make i386 GCC behave the same as x86-64 GCC. This fixes FAIL: gcc.target/i386/pr93492-3.c scan-assembler \t.cfi_startproc\n\tendbr(32|64)\n.*.LPFE1:\n\tnop\n1:\tcall\t__fentry__\n\tret\n FAIL: gcc.target/i386/pr93492-5.c scan-assembler \t.cfi_startproc\n.*.LPFE1:\n\tnop\n1:\tcall\t__fentry__\n\tret\n on Linux/i386. PR target/95655 * config/i386/gnu-user.h (SUBTARGET_FRAME_POINTER_REQUIRED): Removed. * config/i386/i386.c (ix86_frame_pointer_required): Update comments.
[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #1 from Rich Felker ---
I wonder if the fact that GCC thinks the output of the insn is already double
suggests other similar bugs in the m68k backend, though... If extended
precision were working correctly, I'd think it would at least expect the result
to have extended precision and be trying to drop the excess precision
separately. But it's not; it's just returning. Here's my test case:
double my_sqrt(double x)
{
return __builtin_sqrt(x);
}
with -O2 -std=c11 -fno-math-errno -fomit-frame-pointer
The last 2 options are non-critical (GCC still uses the inline insn even with
-fmath-errno and branches only for the exceptional case) but clean up the
output so it's more clear what's going on.
[Bug target/95921] New: [m68k] invalid codegen for __builtin_sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921 Bug ID: 95921 Summary: [m68k] invalid codegen for __builtin_sqrt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- On ISA levels below 68040, __builtin_sqrt expands to code that performs an extended-precision sqrt operation rather than a double-precision one. Not only does this give the wrong result; it enables further cascadingly-wrong optimization ala #93806 and related bugs, because the compiler thinks the value in the output register is a double, but it's not. I think the right fix is making the rtl in m68k.md only allow long double operands unless ISA level is at least 68040, in which case the correctly-rounding instruction can be used. Then the standard function will be used instead of a builtin definition, and it can patch up the result accordingly.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- trap is much stronger than an unreachable. If you hit a gcc_unreachable location at runtime, execution just continues onward with no indication something terrible has happened. It's literally just a marker in our IL and results in no generated code. I think it's fundamentally broken from a security standpoint. __builtin_trap emits an actual trap into the instruction stream which halts the process immediately which is *much* better from a security standpoint
[Bug target/95674] Unnecessary move when doing division-by-multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674 --- Comment #3 from Vladimir Makarov --- I looked at this problem. All assignments are done in IRA (LRA does not change them). We can not make a better assignment because scratches do not permit to store any preferences from instruction constraints (pseudo-registers permits to do this). So storing and getting this info for scratches is the first step to solving the problem. LRA changes scratches to pseudo-registers to generate the correct code satisfying the insn constraints and turn them back to scratches when the corresponding pseudo-registers do not get hard registers. Moving change of scratches to pseudo-regs from LRA to IRA could help but it is a big work. Another solution is to not use scratches in machine-descriptions and use pseudo-registers instead. Scratches are bad and should be avoided as much as possible. I expressed this several times. Besides it is not possible to keep hard register preferences for them, they also can not be taken into account in conflict graph and this results in overoptimistic assignments which LRA has to correct.
[Bug tree-optimization/95863] Failure to detect table-based ctz implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863 --- Comment #3 from H.J. Lu --- Created attachment 48790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48790=edit A patch
[Bug libfortran/95920] New: Implicit declaration of function 'feenableexcept' in fpu-target.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95920 Bug ID: 95920 Summary: Implicit declaration of function 'feenableexcept' in fpu-target.h Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- I am seeing these implicit declaration errors when building gcc for arm-none-eabi targets. In file src/gcc/libgfortran/runtime/fpu.c:29 : ./fpu-target.h: In function 'set_fpu_trap_exceptions': ./fpu-target.h:90:3: efedisableexceptrror: implicit declaration of function 'feenableexcept'; did you mean 'feraiseexcept'? [-Werror=implicit-function-declaration] 90 | feenableexcept (mode_set); | ^~ | feraiseexcept ./fpu-target.h:91:3: error: implicit declaration of function 'fedisableexcept'; did you mean 'feraiseexcept'? [-Werror=implicit-function-declaration] 91 | fedisableexcept (mode_clr); | ^~~ | feraiseexcept ./fpu-target.h: In function 'get_fpu_trap_exceptions': ./fpu-target.h:98:20: error: implicit declaration of function 'fegetexcept'; did you mean 'fetestexcept'? [-Werror=implicit-function-declaration] 98 | int exceptions = fegetexcept (); |^~~ |fetestexcept
[Bug tree-optimization/95863] Failure to detect table-based ctz implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863 H.J. Lu changed: What|Removed |Added CC||polacek at redhat dot com, ||ubizjak at gmail dot com --- Comment #2 from H.J. Lu --- When BMI support was added by commit 91afcfa30c1a15d759f8f59c9d1df403f196a5b6 (HEAD) Author: Quentin Neill Date: Wed Nov 10 22:02:23 2010 + Add support for BMI. 2010-11-10 Quentin Neill it defined: /* The value at zero is only defined for the BMI instructions LZCNT and TZCNT, not the BSR/BSF insns in the original isa. */ #define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI) #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI) and commit 1068ced544257c6c2f804bb231c032e0fda90756 Author: Marek Polacek Date: Tue Aug 19 16:45:07 2014 + alpha.h (CLZ_DEFINED_VALUE_AT_ZERO, [...]): Return 0/1 rather than bool. * config/alpha/alpha.h (CLZ_DEFINED_VALUE_AT_ZERO, CTZ_DEFINED_VALUE_AT_ZERO): Return 0/1 rather than bool. * config/i386/i386.h (CLZ_DEFINED_VALUE_AT_ZERO, CTZ_DEFINED_VALUE_AT_ZERO): Return 0/1 rather than bool. didn't help: -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) A C expression that indicates whether the architecture defines a value for 'clz' or 'ctz' with a zero operand. A result of '0' indicates the value is undefined. If the value is defined for only the RTL expression, the macro should evaluate to '1'; if the value applies also to the corresponding optab entry (which is normally the case if it expands directly into the corresponding RTL), then the macro should evaluate to '2'. In the cases where the value is defined, VALUE should be set to this value. This patch does the trick: diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index d6b57562a53..44a811534a2 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -2933,9 +2933,9 @@ extern void debug_dispatch_window (int); /* The value at zero is only defined for the BMI instructions LZCNT and TZCNT, not the BSR/BSF insns in the original isa. */ #define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ - ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI ? 1 : 0) + ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI ? 2 : 0) #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ - ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_LZCNT ? 1 : 0) + ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_LZCNT ? 2 : 0)
[Bug tree-optimization/95906] Failure to recognize max pattern with mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906 --- Comment #1 from Marc Glisse --- I'd say generate a (vec_)cond_expr, not directly a max. That is, replace the comparison with any truth_valued_p (hmm, that function probably stopped working for vectors when all comparisons were wrapped in vec_cond for avx512).
[Bug target/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-June/54 ||9001.html Status|REOPENED|NEW Keywords||patch --- Comment #4 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549001.html
[Bug fortran/95919] New: new test base gfortran.dg/char4-subscript.f90 in r11-1654 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95919
Bug ID: 95919
Summary: new test base gfortran.dg/char4-subscript.f90 in
r11-1654 fails on BE
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at linux dot vnet.ibm.com
Target Milestone: ---
g:f48bffe70cba310461ec19ffcd07c573a6b86575, r11-1654
gfortran.dg/char4-subscript.f90 works fine on powerpc64 LE but fails on BE:
FAIL: gfortran.dg/char4-subscript.f90 -O0 scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -O0 scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O0 scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O0 scan-tree-dump original "
__builtin_memmove \\(\\(void \\*\\) &\\(\\*var.str2\\)\\[2\\]{lb: 1 sz: 4},
\\(void \\*\\) &.ex00x00x00fx00x00.\\[1\\]{lb: 1 sz: 4},
8\\);"
FAIL: gfortran.dg/char4-subscript.f90 -O1 scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -O1 scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O1 scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O1 scan-tree-dump original "
__builtin_memmove \\(\\(void \\*\\) &\\(\\*var.str2\\)\\[2\\]{lb: 1 sz: 4},
\\(void \\*\\) &.ex00x00x00fx00x00.\\[1\\]{lb: 1 sz: 4},
8\\);"
FAIL: gfortran.dg/char4-subscript.f90 -O2 scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -O2 scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O2 scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O2 scan-tree-dump original "
__builtin_memmove \\(\\(void \\*\\) &\\(\\*var.str2\\)\\[2\\]{lb: 1 sz: 4},
\\(void \\*\\) &.ex00x00x00fx00x00.\\[1\\]{lb: 1 sz: 4},
8\\);"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions scan-tree-dump original "
__builtin_memmove \\(\\(void \\*\\) &\\(\\*var.str2\\)\\[2\\]{lb: 1 sz: 4},
\\(void \\*\\) &.ex00x00x00fx00x00.\\[1\\]{lb: 1 sz: 4},
8\\);"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -g scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -g scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -g scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -O3 -g scan-tree-dump original "
__builtin_memmove \\(\\(void \\*\\) &\\(\\*var.str2\\)\\[2\\]{lb: 1 sz: 4},
\\(void \\*\\) &.ex00x00x00fx00x00.\\[1\\]{lb: 1 sz: 4},
8\\);"
FAIL: gfortran.dg/char4-subscript.f90 -Os scan-tree-dump original "
\\(\\*var.str2\\)\\[4\\]{lb: 1 sz: 4} = .x00xf6x01.\\[1\\]{lb: 1
sz: 4};"
FAIL: gfortran.dg/char4-subscript.f90 -Os scan-tree-dump original "
\\(\\*var.str2\\)\\[5\\]{lb: 1 sz: 4} = .bxf6x01.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -Os scan-tree-dump original "
\\(\\*var\\.str2\\)\\[1\\]{lb: 1 sz: 4} = .dx00x00.\\[1\\]{lb: 1 sz:
4};"
FAIL: gfortran.dg/char4-subscript.f90 -Os scan-tree-dump original "
Coverage not generated with fork/execve
[Please keep me in CC as I'm not subscribed to this mailing list] Hello, I recently implemented an external process management tool and cannot get coverage report of the code that runs right before execve after calling fork. It is specified in the GCC doc that it should work given gnu++11 flag has been specified, which is the case here. However when reading the generated coverage report, the code between fork and execve is identified as not called on the codecov report: (see line 196 of the following link https://codecov.io/gh/BlockProject3D/Framework/src/ProcessManagement/Base/src/Framework/System/Process.cpp). I tried to specify the flag directly in cmake with target_compile_options but still nothing more. I even tried to call directly __gcov_flush() before execve and in the error case of execve but for some reasons gcc complains that it is not a known name. Thanks by advance, Yuri6037
[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-26 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug fortran/95918] New: gfortran.dg/char4-subscript.f90 fails for BE architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918 Bug ID: 95918 Summary: gfortran.dg/char4-subscript.f90 fails for BE architectures Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org CC: burnus at gcc dot gnu.org, krebbel at gcc dot gnu.org, segher at gcc dot gnu.org Depends on: 95837 Target Milestone: --- Target: powerpc64-linux, powerpc-ibm-aix, s390x-linux The new gfortran.dg/char4-subscript.f90 testcase fails on all big endian targets. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837 [Bug 95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)
[Bug tree-optimization/95863] Failure to detect table-based ctz implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95863 H.J. Lu changed: What|Removed |Added CC||craig.topper at gmail dot com, ||crazylht at gmail dot com, ||wwwhhhyyy333 at gmail dot com Last reconfirmed||2020-06-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It doesn't work on x86.
[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054633.html
[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the report. The const-qualified transform_view::begin() member has as its constraints constexpr _Iterator begin() const requires range && regular_invocable>. So as part of overload resolution of the implicit call to 'transform_view::begin', we end up evaluating 'is_invocable_v'. But because the lambda's return type is omitted and because evaluation of 'is_invocable_v' requires knowing the return type, we have to instantiate the body of the lambda in order to deduce its return type. And instantiation leads to a hard error from the failed static_assert. So noe workaround here is to give the lambda an explicit return type.
[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
With the patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6fa34caec54..55f57e2769b 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -15170,6 +15170,7 @@ resolve_symbol (gfc_symbol *sym)
if (flag_coarray == GFC_FCOARRAY_LIB && sym->ts.type == BT_CLASS
&& sym->ts.u.derived && CLASS_DATA (sym)
&& CLASS_DATA (sym)->attr.codimension
+ && CLASS_DATA (sym)->ts.u.derived
&& (CLASS_DATA (sym)->ts.u.derived->attr.alloc_comp
|| CLASS_DATA (sym)->ts.u.derived->attr.pointer_comp))
{
I get the error:
pr95881.f90:5:16:
5 |class(t) :: x
|1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 --- Comment #6 from fdlbxtqi --- (In reply to Iain Sandoe from comment #4) > (In reply to fdlbxtqi from comment #3) > > Jonathan. I am MAD at you. This is absolutely your fault. I told you to > > always write inline and you guys do not then allow Herb Sutter to ban me. > > Here is the fault in your own controlled codebase. Are you satisfied? > > > > https://github.com/isocpp/CppCoreGuidelines/issues/1630 > > > > YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual > > functions as plagues. > > 1. jonathan did not write this header - I did, > 2. we all make mistakes, shouting at folks isn't the optimum way to get them > fixed > 3. this bloat can only occur IF you include a header you are NOT using. > > i.e. > #include > in a source that has no coroutines. Iain, you did a great job on implementing coroutines. I am here to show the examples. https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux.cc https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux.s https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux_writev.cc https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux_writev.s Of course, I disabled exceptions and RTTI. I can compile this on one computer and fail on another since it introduced libsupc++ again with std:: bad_alloc, global new for examples. This is serious if people are using C++ for making operating systems.
[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95827 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- FIXED on master for gcc-11, and on 10-branch. Thanks for the report!
[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95826 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:32613b6af830f12ee5b6ef97edd782666f47cbb8 commit r10-8375-g32613b6af830f12ee5b6ef97edd782666f47cbb8 Author: Harald Anlauf Date: Thu Jun 25 20:32:13 2020 +0200 PR fortran/95826 - Buffer overflows with PDTs and long symbols With PDTs (parameterized derived types), name mangling results in variably long internal symbols. Use a dynamic buffer instead of a fixed-size one. gcc/fortran/ PR fortran/95826 * decl.c (gfc_match_decl_type_spec): Replace a fixed size buffer by a pointer and reallocate if necessary. (cherry picked from commit 35a335a159216548fc77263ac5df71ff29d3f448)
[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5e00a2d1aa68f92e413fec01ce912401bcfcf44f commit r10-8374-g5e00a2d1aa68f92e413fec01ce912401bcfcf44f Author: Harald Anlauf Date: Thu Jun 25 20:34:48 2020 +0200 PR fortran/95828 - Buffer overflows with SELECT RANK With SELECT RANK, name mangling results in long internal symbols that overflows internal buffers. Fix that. gcc/fortran/ PR fortran/95828 * match.c (select_rank_set_tmp): Enlarge internal buffer used in generating a mangled name. * resolve.c (resolve_select_rank): Likewise. (cherry picked from commit 77d455ee81ec3a23f8b20259a31ab963716f8e82)
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 --- Comment #5 from fdlbxtqi --- (In reply to Iain Sandoe from comment #4) > (In reply to fdlbxtqi from comment #3) > > Jonathan. I am MAD at you. This is absolutely your fault. I told you to > > always write inline and you guys do not then allow Herb Sutter to ban me. > > Here is the fault in your own controlled codebase. Are you satisfied? > > > > https://github.com/isocpp/CppCoreGuidelines/issues/1630 > > > > YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual > > functions as plagues. > > 1. jonathan did not write this header - I did, > 2. we all make mistakes, shouting at folks isn't the optimum way to get them > fixed > 3. this bloat can only occur IF you include a header you are NOT using. > > i.e. > #include > in a source that has no coroutines. Sorry. It is not your fault. What I am complaining about is that GCC now has the exactly the problem I talked about 10 days ago and he and Herb Sutter banned me on C++ Core Guideline. C++ Core Guideline is absolutely wrong here.
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 --- Comment #4 from Iain Sandoe --- (In reply to fdlbxtqi from comment #3) > Jonathan. I am MAD at you. This is absolutely your fault. I told you to > always write inline and you guys do not then allow Herb Sutter to ban me. > Here is the fault in your own controlled codebase. Are you satisfied? > > https://github.com/isocpp/CppCoreGuidelines/issues/1630 > > YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual > functions as plagues. 1. jonathan did not write this header - I did, 2. we all make mistakes, shouting at folks isn't the optimum way to get them fixed 3. this bloat can only occur IF you include a header you are NOT using. i.e. #include in a source that has no coroutines.
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 --- Comment #3 from fdlbxtqi --- Jonathan. I am MAD at you. This is absolutely your fault. I told you to always write inline and you guys do not then allow Herb Sutter to ban me. Here is the fault in your own controlled codebase. Are you satisfied? https://github.com/isocpp/CppCoreGuidelines/issues/1630 YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual functions as plagues.
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 --- Comment #2 from fdlbxtqi --- This makes me mad. I compiled this under freestanding mode. Now coroutine causes binary bloat which is completely unacceptable for me. The problem of C++ is that you have to always write inline to undo the brain damage of the extern static shit of WG21.
[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #1 from fdlbxtqi ---
void __dummy_resume_destroy() __attribute__((__weak__));
void __dummy_resume_destroy() {}
struct __noop_coro_frame
{
void (*__r)() = __dummy_resume_destroy;
void (*__d)() = __dummy_resume_destroy;
struct noop_coroutine_promise __p;
} __noop_coro_fr __attribute__((__weak__));
Please inline ALL your functions.
inline this variable PLEASE.
[Bug c++/95917] New: coroutine functions leak under freestanding mode causing dependencies and binary bloat.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917 Bug ID: 95917 Summary: coroutine functions leak under freestanding mode causing dependencies and binary bloat. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: euloanty at live dot com Target Milestone: --- .file "helloworld_linux_writev.cc" .text .p2align 4 .weak _ZNSt7__n486122__dummy_resume_destroyEv .type _ZNSt7__n486122__dummy_resume_destroyEv, @function _ZNSt7__n486122__dummy_resume_destroyEv: .LFB13483: .cfi_startproc ret .cfi_endproc .LFE13483: .size _ZNSt7__n486122__dummy_resume_destroyEv, .-_ZNSt7__n486122__dummy_resume_destroyEv .section .text._ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_,"axG",@progbits,_ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_,comdat .p2align 4 .weak _ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_ .type _ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_, @function _ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_: .LFB14746: .file "helloworld_linux_writev.cc" .text .p2align 4 .weak _ZNSt7__n486122__dummy_resume_destroyEv .type _ZNSt7__n486122__dummy_resume_destroyEv, @function _ZNSt7__n486122__dummy_resume_destroyEv: .LFB13480:
[Bug libstdc++/95915] [10/11 Regression] std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 Jonathan Wakely changed: What|Removed |Added Summary|std::variant doesn't like |[10/11 Regression] |types with a defaulted |std::variant doesn't like |virtual destructor |types with a defaulted ||virtual destructor Known to work||9.3.0 Keywords||rejects-valid Target Milestone|--- |10.2 Known to fail||10.1.0, 11.0
[Bug tree-optimization/95916] ICE during GIMPLE pass: slp : verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95916 --- Comment #1 from Vsevolod Livinskiy --- This bug might be related to bug 95761
[Bug tree-optimization/95916] New: ICE during GIMPLE pass: slp : verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95916
Bug ID: 95916
Summary: ICE during GIMPLE pass: slp : verify_ssa failed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
Error:
>$ g++ -c -O3 func.cpp
func.cpp: In function ‘void test()’:
func.cpp:5:6: error: definition in block 3 follows the use
5 | void test() {
| ^~~~
for SSA_NAME: var_5.3_5 in statement:
vect__6.8_50 = vect__4.7_58 << var_5.3_5;
during GIMPLE pass: slp
func.cpp:5:6: internal compiler error: verify_ssa failed
0x1339a82 verify_ssa(bool, bool)
gcc/tree-ssa.c:1208
0x1025705 execute_function_todo
gcc/passes.c:1992
0x10263de execute_todo
gcc/passes.c:2039
Reproducer:
extern short var_3, var_8;
extern int var_5;
extern char var_10;
extern int arr_99[][16];
void test() {
for (; 0 < var_10;)
for (long a(var_8);; a++)
arr_99[4][a] = var_3 << var_5;
}
GCC version:
11.0.0 20200625 (77d455ee81ec3a23f8b20259a31ab963716f8e82)
[Bug ipa/95913] Capturing lambdas inlining behavior changed in GCC 10.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95913 --- Comment #1 from Andrew Pinski --- Most likely a heurstic changes caused this.
[Bug c++/94553] Revise [basic.scope.declarative]/4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94553
--- Comment #6 from Marek Polacek ---
I think it would make sense to detect this too:
struct E { };
template concept E = false;
template concept F = false;
struct F { };
[Bug target/95030] Conflicting report about VIA eden's AVX capabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95030 --- Comment #1 from Mingye Wang --- Thanks to tcl_de in sourceware bz[1], a CPUID dump from eden-x4 is available: http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls6FE_CNR_Isaiah_CPUID.txt MOVBE, POPCNT, AES, PCLMUL, FSGSBASE, RDRND, BMI, BMI2 and F16C are also supported on eden-x4. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=23249#c12
[Bug c++/86353] g++7 -std=c++17 ICEs as internal compiler error: in gimplify_expr, at gimplify.c:12201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86353 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Sergei Trofimovich --- Let's declare fixed as it works with gcc-8 and above.
[Bug c++/82953] ICE in tree_check() ../../gcc/gcc/tree.h:3087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82953 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from Sergei Trofimovich --- Given that gcc-8 works let's close as obsolete.
[Bug libstdc++/95915] std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915 Ville Voutilainen changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-26 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com
[Bug libstdc++/95915] New: std::variant doesn't like types with a defaulted virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95915
Bug ID: 95915
Summary: std::variant doesn't like types with a defaulted
virtual destructor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
>From Patrice Roy:
The following code compiled in C++17 but seems broken in C++20, at least
according the Clang and gcc:
#include
struct X {
virtual ~X() = default;
};
int main() {
std::variant v;
}
This is because variant's storage uses an _Uninitialized type that hacks
around a compiler bug, where the type X above wasn't literal. Now that it
is, the hack breaks. Since variant's other base-layers handle triviality
of special member functions properly, this hack can now be removed.
[Bug c++/95892] Wrong line number in "-Wsign-conversion" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892 --- Comment #5 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #4) > Yes, thanks, I've closed that one as a duplicate too. Ok, you are so welcome. By the way, could you please check other diagnostic issues (bug95871, bug95872, bug95873, and bug95875) if you are convenient? I guess those might be real bugs and I tried to find DUP ones but failed. Thank you very much!
[Bug target/95914] New: Failure to optimize saturated add properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95914
Bug ID: 95914
Summary: Failure to optimize saturated add properly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
uint16_t add16(uint16_t a, uint16_t b)
{
uint16_t c = a + b;
return c < a ? -1 : c;
}
With -O3, LLVM outputs this on x86 :
add16(unsigned short, unsigned short):
add di, si
mov eax, 65535
cmovae eax, edi
ret
GCC outputs this :
add16(unsigned short, unsigned short):
xor eax, eax
add si, di
jc .L8
.L2:
test ax, ax
mov eax, -1
cmove eax, esi
ret
.L8:
mov eax, 1
jmp .L2
I don't know if this doesn't also occur on also architectures but the output
seems rather crippled on x86, at least.
[Bug other/95913] New: Capturing lambdas inlining behavior changed in GCC 10.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95913 Bug ID: 95913 Summary: Capturing lambdas inlining behavior changed in GCC 10.x Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: leonid.satanovsky at gmail dot com Target Milestone: --- Greetings! There is a bug suspicion, and I wanted to report it by the following example. https://godbolt.org/z/m6g3Ug GCCs 9.x and older inline capturing lambdas for the case in example even on -O1 GCC 10.1 always inlines only on -O3. On -O2 inlines it only if capturing lambda is called < 3 times in a row. Best regards, Leonid.
[Bug d/95173] [D] ICE on some architecture targets when trying to use unknown attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Done
[Bug d/95250] [D] ICE instead of error when trying to use bad template type inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Done
[Bug target/95907] ICE in unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95907 --- Comment #1 from Segher Boessenkool --- Confirmed (in C, with _Bool). This is yet another case of enabling some insns but disabling many other insns: our power10 support requires insns we enable on power9 and later only (set[n]bc[r] is a special case of isel). We should make it impossible for people to enable -mpower10 (without doing -mcpu=power10) somehow.
[Bug c++/95911] [8/9/10/11] returning && makes an error without any warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911 --- Comment #2 from Jonathan Wakely --- As I noted in Bug 49974 comment 17, if you actually try to us the variable after it's been destroyed then GCC *does* warn. And if you use -fsanitize=address then you get an error at runtime.
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #17 from Jonathan Wakely ---
95911 boils down to this:
#include
struct X { int i = 0; };
X&& f(X&& x) { return std::move(x); }
int main()
{
X&& x = f(X{});
return x.i;
}
With recent releases we get a -Wuninitialized warning, which isn't entirely
correct, but at least suggests a problem:
49974.cc: In function 'int main()':
49974.cc:10:12: warning: '.X::i' is used uninitialized
[-Wuninitialized]
10 | return x.i;
|^
49974.cc:9:15: note: '' declared here
9 | X&& x = f(X{});
| ^
(the note is new in GCC 11).
With -fsanitize=address we get a nice stack-use-after-scope error:
==3088273==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fff976ed520 at pc 0x00401100 bp 0x7fff976ed4f0 sp 0x7fff976ed4e8
READ of size 4 at 0x7fff976ed520 thread T0
#0 0x4010ff in main /tmp/49974.cc:10
#1 0x7fd157d181a2 in __libc_start_main ../csu/libc-start.c:308
#2 0x40116d in _start (/tmp/a.out+0x40116d)
[Bug d/95173] [D] ICE on some architecture targets when trying to use unknown attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:53bc489468c3bf2958151ba624679cadff403ce8 commit r9-8700-g53bc489468c3bf2958151ba624679cadff403ce8 Author: Iain Buclaw Date: Tue Jun 23 16:25:29 2020 +0200 d: Fix ICE in uda_attribute_p when looking up unknown attribute The target attribute table is not guaranteed to be set in all backends. gcc/d/ChangeLog: PR d/95173 * d-attribs.cc (uda_attribute_p): Don't search target attribute table if NULL. gcc/testsuite/ChangeLog: PR d/95173 * gdc.dg/pr95173.d: New test. (cherry picked from commit 62e02c8729a75c4a859edc18e0bcafb87d717f46)
[Bug d/95250] [D] ICE instead of error when trying to use bad template type inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:57096f5c52be8c5f0c29663234f31845bb172216 commit r9-8701-g57096f5c52be8c5f0c29663234f31845bb172216 Author: Iain Buclaw Date: Tue Jun 23 22:43:27 2020 +0200 d: Fix ICE during error recovery in semantic pass Fixes a regression caused by an incomplete backport of converting the Expression semantic pass to a Visitor. gcc/d/ChangeLog: PR d/95250 * dmd/expressionsem.c (class ExpressionSemanticVisitor): Return early if error occurred during semantic of DivExp. gcc/testsuite/ChangeLog: PR d/95250 * gdc.dg/pr95250.d: New test. (cherry picked from commit 1d19c9cd3dd99ba8885c0fc93223918399f73939)
[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237 Jakub Jelinek changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #19 from Jakub Jelinek --- *** Bug 95912 has been marked as a duplicate of this bug. ***
[Bug c++/95911] [8/9/10/11] returning && makes an error without any warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- (In reply to 。 from comment #0) > In my > comprehension of c++, the second class A veriable should not be deleted. Your comprehension is wrong. The temporary is bound to the parameter of bug(A&&) but that does not extend its lifetime, so the temporary is destroyed at the end of the full expression. That leaves 'b' as a dangling reference. In general it's not possible to warn about this code because the compiler doesn't know that bug(newA()) returns a reference to a temporary (if the function isn't inlined, it's impossible to know that). > When double using function bug(see the .ii file), you can find it was not > deleted so early. No, it's deleted at exactly the same time (the end of the full expression). Code like this is buggy and dangerous. We already have Bug 49974 requesting a warning for it. *** This bug has been marked as a duplicate of bug 49974 ***
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974 Jonathan Wakely changed: What|Removed |Added CC||570070308 at qq dot com --- Comment #16 from Jonathan Wakely --- *** Bug 95911 has been marked as a duplicate of this bug. ***
[Bug target/95912] internal compiler error: in execute, at adjust-alignment.c:74 with 'ICE on '-m32 -mpreferred-stack-boundary=2''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95912 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 95237 ***
[Bug d/95173] [D] ICE on some architecture targets when trying to use unknown attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95173 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:3e1af1d0be13e4615e001fb19e294c8d28d69f94 commit r10-8372-g3e1af1d0be13e4615e001fb19e294c8d28d69f94 Author: Iain Buclaw Date: Tue Jun 23 16:25:29 2020 +0200 d: Fix ICE in uda_attribute_p when looking up unknown attribute The target attribute table is not guaranteed to be set in all backends. gcc/d/ChangeLog: PR d/95173 * d-attribs.cc (uda_attribute_p): Don't search target attribute table if NULL. gcc/testsuite/ChangeLog: PR d/95173 * gdc.dg/pr95173.d: New test. (cherry picked from commit 62e02c8729a75c4a859edc18e0bcafb87d717f46)
[Bug d/95250] [D] ICE instead of error when trying to use bad template type inside template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95250 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:95f5dc7f70b09def9f2002f5cbef986b21d456e3 commit r10-8373-g95f5dc7f70b09def9f2002f5cbef986b21d456e3 Author: Iain Buclaw Date: Tue Jun 23 22:43:27 2020 +0200 d: Fix ICE during error recovery in semantic pass Fixes a regression caused by an incomplete backport of converting the Expression semantic pass to a Visitor. gcc/d/ChangeLog: PR d/95250 * dmd/expressionsem.c (class ExpressionSemanticVisitor): Return early if error occurred during semantic of DivExp. gcc/testsuite/ChangeLog: PR d/95250 * gdc.dg/pr95250.d: New test. (cherry picked from commit 1d19c9cd3dd99ba8885c0fc93223918399f73939)
[Bug c++/95892] Wrong line number in "-Wsign-conversion" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95892 --- Comment #4 from Jonathan Wakely --- Yes, thanks, I've closed that one as a duplicate too.
[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568 --- Comment #5 from Jonathan Wakely --- *** Bug 95831 has been marked as a duplicate of this bug. ***
[Bug c++/95831] Wrong line number in " -Wconversion" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95831 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 86568 ***
[Bug target/95912] New: internal compiler error: in execute, at adjust-alignment.c:74 with 'ICE on '-m32 -mpreferred-stack-boundary=2''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95912
Bug ID: 95912
Summary: internal compiler error: in execute, at
adjust-alignment.c:74 with 'ICE on '-m32
-mpreferred-stack-boundary=2''
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Originally ICE happened when I attempted to compile valgrind-3.16.1.
Minimal reproducer is very simple:
$ cat bug.c
a() { long long b; }
$ LANG=C gcc-11.0.0 a.c -c -m32 -mpreferred-stack-boundary=2
bug.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | a() { long long b; }
| ^
during GIMPLE pass: adjust_alignment
bug.c: In function 'a':
bug.c:1:1: internal compiler error: in execute, at adjust-alignment.c:74
0x7f9fcda79d49 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
GCC was configured as:
$ /home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
-B/home/slyfox/dev/git/gcc-native-quick/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200626 (experimental) (GCC)
[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Michael Bruck from comment #3) > > Some of the abort messages in main were not updated after copy/paste > > "Failed to call one of the ... cases" > > I made individual test-cases for each promise entry, I'm not sure what's not > working? ah .. OK I see :) I'll fix that up (but the test cases do not rely on those messages to function, the abort() is what matters).
[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95809 --- Comment #4 from Nathan Sidwell --- The code is invalid due to DR2061
[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 --- Comment #4 from Iain Sandoe --- (In reply to Michael Bruck from comment #3) > Some of the abort messages in main were not updated after copy/paste > "Failed to call one of the ... cases" I made individual test-cases for each promise entry, I'm not sure what's not working?
[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 --- Comment #3 from Michael Bruck --- Some of the abort messages in main were not updated after copy/paste "Failed to call one of the ... cases"
[Bug target/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu --- (In reply to Martin Liška from comment #2) > So it's really problem as with LTO we don't put the large array into .lbss > section: > > LTO: > .file "" > .text > .local a > .comm a,2830270464,32 This should be .largecomm. [hjl@gnu-cfl-2 tmp]$ cat x.s .local a .largecomm a,2830270464,32 [hjl@gnu-cfl-2 tmp]$ gcc -c x.s [hjl@gnu-cfl-2 tmp]$ readelf -SsW x.o There are 9 section headers, starting at offset 0x160: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 40 00 00 AX 0 0 1 [ 2] .data PROGBITS 40 00 00 WA 0 0 1 [ 3] .bss NOBITS 40 00 00 WA 0 0 1 [ 4] .lbss NOBITS 40 a8b28000 00 WAl 0 0 32 [ 5] .note.gnu.property NOTE 40 30 00 A 0 0 8 [ 6] .symtab SYMTAB 70 a8 18 7 7 8 [ 7] .strtab STRTAB 000118 03 00 0 0 1 [ 8] .shstrtab STRTAB 00011b 45 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) Symbol table '.symtab' contains 7 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 2: 0 SECTION LOCAL DEFAULT2 3: 0 SECTION LOCAL DEFAULT3 4: 0xa8b28000 OBJECT LOCAL DEFAULT4 a 5: 0 SECTION LOCAL DEFAULT4 6: 0 SECTION LOCAL DEFAULT5 [hjl@gnu-cfl-2 tmp]$
[Bug c++/95911] New: [8/9/10/11] returning && makes an error without any warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95911
Bug ID: 95911
Summary: [8/9/10/11] returning && makes an error without any
warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 570070308 at qq dot com
Target Milestone: ---
Created attachment 48789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48789=edit
the .ii file
class A
{
public:
A()
{
printf("A create.\n");
}
A(const A)
{
printf("A copy create.\n");
}
A(A&)
{
printf("A move create.\n");
}
~A()
{
printf("A delete.\n");
}
};
A newA()
{
A a;
return a;
}
A&& bug(A&& x)
{
printf("bug\n");
return std::move(x);
}
int main()
{
A &=newA(); //ok
printf("--\n");
A &=bug(newA()); //error
printf("--\n");
A c=bug(newA()); //ok
printf("--\n");
return 0;
}
runing the code, the result is:
A create.
--
A create.
bug
A delete.
--
A create.
bug
A move create.
A delete.
--
A delete.
A delete.
In main function create three class A veriables, but only two class A veriables
are deleted at last. But the compiler do not give any warning. I have try -Wall
-Wextra but it still have no warning. I have tried with
-fno-elide-constructors, -O3 and -O0, the result is the same. In my
comprehension of c++, the second class A veriable should not be deleted. When
double using function bug(see the .ii file), you can find it was not deleted so
early. If it should be deleted, that means the code is dangerous and compiler
should give a warning. There is no warning in g++ 8/9/10/11, and also no
warning in clang++.
[Bug c++/95910] New: transform view in combination with single view calls const qualified begin even if it is not const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95910
Bug ID: 95910
Summary: transform view in combination with single view calls
const qualified begin even if it is not const
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Hi gcc team,
I am wondering why the following code results in an static assert:
```cpp
#include
#include
#include
auto transform_v = [] (auto && v)
{
static_assert(std::same_as);
return v;
};
using range_t = decltype(std::views::single(0)); // falsely calls const
qualified begin somewhere in stack
// using range_t = std::vector; // OK, everyting as expected.
using transformed_view_t = decltype(std::declval() |
std::views::transform(transform_v));
using ref_t = std::ranges::range_reference_t;
```
Here is the example on https://godbolt.org/z/QWvYue.
It seems, that somewhere in the stack the transform view is promoted to a const
view even though it should not, shouldn't it?
Sorry, if I got something wrong.
[Bug debug/95909] New: Wrong line information at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95909
Bug ID: 95909
Summary: Wrong line information at Og
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: massarelli at diag dot uniroma1.it
Target Milestone: ---
After executing function a, line 9 is wrongly hit.
$ cat -n a.c
cat -n aa.c
1 int d;
2 char a() { return 0; }
3 char f(b, c) {}
4 void e() {
5int h;
6if (a()) {
7 char g;
8 d = 0;
9 h = (f(g, 7));
10}
11 }
12 int main() { e(); }
$ cat -n a.c
int d;
char a() { return 0; }
char f(b, c) {}
void e() {
int h;
if (a()) {
char g;
d = 0;
h = (f(g, 7));
}
}
int main() { e(); }
$ gcc -v
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200624 (experimental) (GCC)
$ gcc -Og -g -o opt a.c
$ gdb opt
(gdb) b main
Breakpoint 1 at 0x4004a6: file a.c, line 12.
(gdb) r
Starting program: opt
Breakpoint 1, main () at /home/stepping/output/a.c:12
12 int main() { e(); }
(gdb) s
e () at /home/stepping/output/a.c:6
6 if (a()) {
(gdb) s
a () at /home/stepping/output/a.c:2
2 char a() { return 0; }
(gdb) s
e () at /home/stepping/output/a.c:9
9 h = (f(g, 7));
(gdb) s
0x77a05b97 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)
[Bug target/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95620 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.2 Keywords|rejects-valid |link-failure, ||missed-optimization
[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.5
[Bug c++/95388] [11 Regression] C++20 & 17 Lambda capture of *this by Value causes ICE "in tsubst_decl at cp/pt.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95388 Richard Biener changed: What|Removed |Added Known to fail||11.0 Summary|[Regression 10/11]C++20 & |[11 Regression] C++20 & 17 |17 Lambda capture of *this |Lambda capture of *this by |by Value causes ICE "in |Value causes ICE "in |tsubst_decl at cp/pt.c" |tsubst_decl at cp/pt.c" Target Milestone|--- |11.0 Known to work||10.1.0
[Bug fortran/95068] [10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95068 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.2
[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 Richard Biener changed: What|Removed |Added Keywords||build Target Milestone|--- |8.5
[Bug tree-optimization/94335] [10/11 Regression] False positive -Wstringop-overflow warning with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |10.2
[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:e74c76073092f4715007584edb1fe6b7a17274db commit r11-1673-ge74c76073092f4715007584edb1fe6b7a17274db Author: Iain Sandoe Date: Fri Jun 26 10:48:35 2020 +0100 coroutines: Handle non-method promise expressions [PR95519] The PR points out that the standard does not restrict promise expressions to methods, but the current implementation does. The patch factors out the building of a general promise expression, and then uses it in a fairly mechanical replacement of each case that we need such an expressions. This extends the handling for p.xx() expressions to cover the cases where the promise member is some form callable. Tests are added for each of the promise expressions. It's somewhat tortuous to find good uses for this for the get-return-object and get-return-object-on-allocation-failure cases, but they are included anyway. gcc/cp/ChangeLog: PR c++/95519 * coroutines.cc (struct coroutine_info):Add a field to hold computed p.return_void expressions. (coro_build_promise_expression): New. (get_coroutine_return_void_expr): New. (finish_co_yield_expr): Build the promise expression using coro_build_promise_expression. (finish_co_return_stmt): Likewise. (build_init_or_final_await): Likewise. (morph_fn_to_coro): Likewise, for several cases. gcc/testsuite/ChangeLog: PR c++/95519 * g++.dg/coroutines/torture/pr95519-00-return_void.C: New test. * g++.dg/coroutines/torture/pr95519-01-initial-suspend.C: New test. * g++.dg/coroutines/torture/pr95519-02-final_suspend.C: New test. * g++.dg/coroutines/torture/pr95519-03-return-value.C: New test. * g++.dg/coroutines/torture/pr95519-04-yield-value.C: New test. * g++.dg/coroutines/torture/pr95519-05-gro.C: New test. * g++.dg/coroutines/torture/pr95519-06-grooaf.C: New test. * g++.dg/coroutines/torture/pr95519-07-unhandled-exception.C: New test.
[Bug middle-end/95903] gcc 10: wrong code with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95903 --- Comment #9 from Markus F.X.J. Oberhumer --- [ Just for reference, created bug 95908 ]
[Bug target/95908] New: [AArch64] wrong code with ILP32 and -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908
Bug ID: 95908
Summary: [AArch64] wrong code with ILP32 and -fwrapv
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at oberhumer dot com
Target Milestone: ---
[this issue has been extraced from bug 95903]
Link at Compiler Explorer: https://gcc.godbolt.org/z/mRf2kd
The function below does compute the address in 64 (and not in 32) bits, which
seems wrong when using "-fwrapv -fwrapv-pointer".
As discussed in bug 95903 some feedback from the target maintainer
would be welcome.
// arm64-linux-gcc -mabi=ilp32 -O2 -fwrapv -fwrapv-pointer
char get_byte(const char* ptr, int off)
{
off += 2147483647;
return ptr[off];
}
[Bug middle-end/95830] [11 regression][MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12247 start with gcc-11-1445-g502d63b6d61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830 --- Comment #8 from Richard Biener --- Possibly simply a disconnect in the mips expanders for vcond vs vcmp.
[Bug middle-end/95830] [11 regression][MIPS/MSA] internal compiler error: in do_store_flag, at expr.c:12247 start with gcc-11-1445-g502d63b6d61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
--- Comment #7 from rguenther at suse dot de ---
On Fri, 26 Jun 2020, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95830
>
> --- Comment #6 from Martin Liška ---
> Thanks for reduction, I can confirm that. What happens:
>
> mips-ps-5.c.171t.loopdone:
>
> _34 = vect__1.7_28 == vect__3.11_33;
> vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
>
> which is fine. But then during veclower21 we lower the first comparison to:
>
> _24 = (void *) ivtmp.17_4;
> vect__1.7_28 = MEM[base: _24, offset: 0B];
> _23 = (void *) ivtmp.20_1;
> vect__2.10_31 = MEM[base: _23, offset: 0B];
> vect__3.11_33 = vect__2.10_31 + vect_cst__32;
> _26 = BIT_FIELD_REF ;
> _27 = BIT_FIELD_REF ;
> _29 = _26 == _27 ? -1 : 0;
> _30 = BIT_FIELD_REF ;
> _36 = BIT_FIELD_REF ;
> _37 = _30 == _36 ? -1 : 0;
> _34 = {_29, _37};
> vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
>
> which is undesired. So similarly to isel we need to mark all SSA_NAMEs that
> are
> first args of a VEC_COND_EXPR and ignore these from vect lowering.
> Richi?
We can't ignore them unless VEC_COND_EXPR lowering will process them.
That is, we have to check whether we can expand all instances of the
compares. This basically means we need to run "isel" on them but
not actually commit the IL change but instead lower all cases we
could not process. The question is what to do about for example
_34 = vect__1.7_28 == vect__3.11_33;
vect_iftmp.12_35 = VEC_COND_EXPR <_34, vect__1.7_28, vect__2.10_31>;
foo (_34);
where we can ISEL the VEC_COND_EXPR together with _34 but _34 is
live anyway. Do we want to both lower _34 (for the use in foo)
and keep it (for the purpose of VEC_COND_EXPR expansion)? I guess so.
OTOH if the target an expand VEC_COND_EXPR <_1 == _2, ...>
then it can expand _1 == _2 as VEC_COND_EXPR <_1 == _2, {-1,-1,-1},
{0,0,0}> so this is exactly the case why I thought applying ISEL
on both together makes sense. Looks like it actually happens ...
Which means we don't actually need to lower the compare since
we can expand it as VEC_COND_EXPR?
