[Bug c/105557] New: -Wtautological-compare doesn't warn about bitwise expressions that always evaluate to true or false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105557
Bug ID: 105557
Summary: -Wtautological-compare doesn't warn about bitwise
expressions that always evaluate to true or false
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: garsilva at embeddedor dot com
Target Milestone: ---
Clang[1] emits warnings on the following code, which contains bitwise
expressions that always evaluate to true:
#include
enum Flags {
FLAG_A = 0b001,
FLAG_B = 0b010,
FLAG_C = 0b100,
};
void a();
void b();
void c();
void f(enum Flags f) {
if (!!(f | FLAG_A)) {
a();
} else if (!!(f | FLAG_B)) {
b();
} else if (!!(f | FLAG_C)) {
c();
} else {
abort();
}
}
and it seems that GCC is not able to detect the above tautological expressions.
[1] https://godbolt.org/z/ax6vhczP1
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #3 from Jerry DeLisle --- This is probably not the right place, but all gfortranners, try fpm if you have not already done so. It makes building and running the tests in this example so easy. Not to mention your own applications.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #2 from Damian Rouson --- Thanks for trying this, Jerry. Brad encountered a similar issue, which I think he resolved so I'll I'll ask him to comment here.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Yes, it is always usefule to have tests available. I cloned the repository. fpm build is happy. $ fpm test compiler_test.f90 done. usage_test.f90 done. main.f90 done. reference-counter-test done. [100%] Project compiled successfully. Running Tests Test that The compiler finalizes a non-allocatable object on the LHS of an intrinsic assignment finalizes an allocated allocatable LHS of an intrinsic assignment finalizes a target when the associated pointer is deallocated finalizes an object upon explicit deallocation finalizes a non-pointer non-allocatable array object at the END statement finalizes a non-pointer non-allocatable object at the end of a block construct finalizes a function reference on the RHS of an intrinsic assignment finalizes a specification expression function result finalizes an intent(out) derived type dummy argument finalizes an allocatable component object Using a reference-counted object creates a resource when constructed removes the resource when it goes out of scope a copy points to the same resource A total of 13 test cases At line 42 of file test/usage_test.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 'the_resource' Execution failed for object " reference-counter-test " *cmd_run*:stopping due to failed executions STOP 1 Am I missing a step? This is with gfortran 12.
[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414 --- Comment #11 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:344e425340e3c8e4539b43bf8f661e02c5a5b9a0 commit r13-280-g344e425340e3c8e4539b43bf8f661e02c5a5b9a0 Author: Haochen Gui Date: Mon May 9 17:34:23 2022 +0800 This patch skips constant folding for fmin/max when either argument is sNaN. According to C standard, fmin(sNaN, sNaNï¼= qNaN, fmin(sNaN, NaN) = qNaN. gcc/ PR target/105414 * match.pd (minmax): Skip constant folding for fmin/fmax when both arguments are sNaN or one is sNaN and another is NaN. gcc/testsuite/ PR target/105414 * gcc.dg/pr105414.c: New.
[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541
--- Comment #4 from Jason Merrill ---
Simpler:
static_assert(requires { []{}; });
[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Jason Merrill changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Priority|P3 |P1 Status|NEW |ASSIGNED --- Comment #3 from Jason Merrill --- P1 then. Broken by my r12-7997-g1de6612d994ada.
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 --- Comment #7 from Kees Cook --- Right, perhaps I should rename this bug? The much more surprising thing is the lack of warning about the uninit use. With or without -ftrivial-auto-var-init, I'd want to have the diagnostic that a UB may have happened.
[Bug target/105546] [11/12/13 Regression] ifconversion introduces many compares with loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target||x86_64-linux-gnu Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-10 Target Milestone|--- |11.4 Summary|load introduction when |[11/12/13 Regression] |initializing a struct |ifconversion introduces ||many compares with loads Component|middle-end |target --- Comment #2 from Andrew Pinski --- This is ifconversion changing: if (g_344.0_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870912]: [local count: 1073741824]: # _16 = PHI <4499926296329723445(2), -6(3)> # _18 = PHI <3(2), 3409572933270154779(3)> # _20 = PHI <171(2), 161(3)> # _22 = PHI <-1(2), -8(3)> # _24 = PHI <27943(2), 1(3)> # _26 = PHI <2738(2), 65526(3)> Into straight line code but keeps the load around. THis is a target issue.
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Peter Bergner changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-May/594 ||481.html --- Comment #2 from Peter Bergner --- Patch submitted.
[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Peter Bergner changed: What|Removed |Added Last reconfirmed||2022-05-10 Ever confirmed|0 |1 Known to fail||12.0, 13.0 Known to work||10.0, 11.0 CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Target||powerpc*-*-* --- Comment #1 from Peter Bergner --- Mine. I have a patch.
[Bug target/105556] New: RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105556 Bug ID: 105556 Summary: RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- With current trunk and GCC 12, the MMA optimized dgemm kernel in OpenBLAS is seeing a performance regression compared to GCC 11 and GCC 10. The problem is that the core loop in dgemm uses 8 accumulator variables, which want to use all 8 accumulator registers. Using the 8 accumulators means we should not use the vs0 thru vs31 vector registers for the MMA instruction's normal vector input operands. However with trunk and GCC 12, the register allocator is assigning one vector input to one of the vs0-vs31 registers leading us to spill one of the accumulators and that causes a bad performance loss. The trunk and GCC 12 asm for the core loop looks like: .L5: lxvp 0,0(10) lxv 40,0(9) addi 10,10,64 addi 9,9,64 lxv 41,-48(9) lxv 42,-32(9) lxv 43,-16(9) lxvp 2,32(1) lxvp 32,-32(10) xvf64gerpp 4,0,40 xvf64gerpp 6,0,41 xvf64gerpp 3,0,42 xvf64gerpp 2,0,43 lxvp 0,64(1) xvf64gerpp 5,32,40 xvf64gerpp 7,32,41 xvf64gerpp 1,32,42 xxmtacc 0 xvf64gerpp 0,32,43 xxmfacc 0 stxvp 2,32(1) stxvp 0,64(1) bdnz .L5 Note the use of vs0 in the MMA instructions which forces the spilling of ACC0. The "better" GCC 11 and GCC 10 code looks like: .L5: lxvp 44,0(10) lxvp 32,32(10) addi 9,9,64 addi 10,10,64 lxv 39,-64(9) lxv 40,-48(9) lxv 41,-32(9) lxv 42,-16(9) xvf64gerpp 4,44,39 xvf64gerpp 5,32,39 xvf64gerpp 6,44,40 xvf64gerpp 7,32,40 xvf64gerpp 3,44,41 xvf64gerpp 1,32,41 xvf64gerpp 2,44,42 xvf64gerpp 0,32,42 bdnz .L5
[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from H.J. Lu --- Fixed.
[Bug c/105555] New: ICE: in fold_offsetof, at c-family/c-common.cc:6815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: ICE: in fold_offsetof, at c-family/c-common.cc:6815
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenyang.xu at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.lx931ugYgb-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220510 (experimental) [master -gbb2921ab8] (GCC)
$ cat mutant_93391780_1648415763714.c
a() {
&__imag *(_Complex *)a
$ gcc-trunk -O3 -g -Wall -Wextra -c mutant_93391780_1648415763714.c
mutant_93391780_1648415763714.c:1:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
1 | a() {
| ^
mutant_93391780_1648415763714.c: In function ‘a’:
mutant_93391780_1648415763714.c:2:3: internal compiler error: in fold_offsetof,
at c-family/c-common.cc:6815
2 | &__imag *(_Complex *)a
| ^
0x6dc39a fold_offsetof(tree_node*, tree_node*, tree_code)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c-family/c-common.cc:6815
0x9c345e build_unary_op(unsigned int, tree_code, tree_node*, bool)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-typeck.cc:4915
0x9d09fe parser_build_unary_op(unsigned int, tree_code, c_expr)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-typeck.cc:3771
0x9ec947 c_parser_unary_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:8170
0x9edd6f c_parser_cast_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:8103
0x9ee01f c_parser_binary_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7906
0x9ef51e c_parser_conditional_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7606
0x9efdc0 c_parser_expr_no_commas
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:7521
0x9f0051 c_parser_expression
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:10697
0x9f0827 c_parser_expression_conv
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:10736
0xa05ff7 c_parser_statement_after_labels
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:6263
0xa08374 c_parser_compound_statement_nostart
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:5800
0xa08a64 c_parser_compound_statement
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:5609
0xa0a443 c_parser_declaration_or_fndef
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:2544
0xa133e3 c_parser_external_declaration
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:1779
0xa13e4b c_parser_translation_unit
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:1652
0xa13e4b c_parse_file()
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c/c-parser.cc:23357
0xa77029 c_common_parse_file()
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/c-family/c-opts.cc:1235
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/105554] New: ICE: in emit_block_move_hints, at expr.cc:1829
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
Bug ID: 105554
Summary: ICE: in emit_block_move_hints, at expr.cc:1829
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenyang.xu at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.lx931ugYgb-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220510 (experimental) [master -gbb2921ab8] (GCC)
$ cat mutant_133870291_1648466141340.c
__attribute__((target_clones("arch=core-avx2", "default")))
a(__attribute__((__vector_size__(4 * sizeof(long long) {}
$ gcc-trunk -O3 -g -Wall -Wextra -c mutant_133870291_1648466141340.c
mutant_133870291_1648466141340.c:2:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
mutant_133870291_1648466141340.c: In function ‘a’:
mutant_133870291_1648466141340.c:2:1: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
mutant_133870291_1648466141340.c:2:61: warning: control reaches end of non-void
function [-Wreturn-type]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
mutant_133870291_1648466141340.c:2:1: warning: AVX vector argument without AVX
enabled changes the ABI [-Wpsabi]
2 | a(__attribute__((__vector_size__(4 * sizeof(long long) {}
| ^
during RTL pass: expand
mutant_133870291_1648466141340.c:2:1: internal compiler error: in
emit_block_move_hints, at expr.cc:1829
0x726cd5 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long, bool, bool*,
bool)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/expr.cc:1829
0xc29395 emit_block_move(rtx_def*, rtx_def*, rtx_def*, block_op_methods)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/expr.cc:1915
0xc8dc82 assign_parm_setup_block
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:3124
0xc8dc82 assign_parms
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:3705
0xc8f602 expand_function_start(tree_node*)
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/function.cc:5161
0xafda98 execute
/tmp/tmp.lx931ugYgb-gcc-builder/gcc/gcc/cfgexpand.cc:6691
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|12.2|11.4 Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 11.4 and 12.2, thanks for the report.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1572e41d759950e7699d14779aae49b892f12f8b commit r11-9977-g1572e41d759950e7699d14779aae49b892f12f8b Author: Jonathan Wakely Date: Tue May 10 13:03:14 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/syncstream (basic_syncbuf, basic_osyncstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: New test. * testsuite/27_io/headers/iosfwd/types.cc: New test. (cherry picked from commit 1807e07825a86916bbfddca470708c5a8f613612)
[Bug fortran/105230] [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230
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 ---
(In reply to kargl from comment #1)
> Started with 22015e77d3e4.
No, it didn't start with that commit. That commit missed the present
situation.
The ICE is pre-existing.
> upper is NULL and later in 1634 it is dereferenced. This patch fixes
> the problem, but the above logic likely needs fixing.
That's right. Shorter fix:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 86d61fed302..be94c18c836 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1595,8 +1595,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
if ((begin && begin->expr_type != EXPR_CONSTANT)
|| (finish && finish->expr_type != EXPR_CONSTANT)
|| (step && step->expr_type != EXPR_CONSTANT)
- || (!begin && !lower)
- || (!finish && !upper))
+ || !lower
+ || !upper)
{
t = false;
goto cleanup;
[Bug c++/105553] New: Deduction when attempting to create an array with an element type that is an abstract class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105553
Bug ID: 105553
Summary: Deduction when attempting to create an array with an
element type that is an abstract class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glenjofe at gmail dot com
Target Milestone: ---
Starting with GCC11, the following definition of a trait to check if a type is
abstract no longer works in any standard mode:
template
class is_abstract {
template
static char ((U(*)[1]))[2];
template
static char check(...);
public:
static const bool value = sizeof(check(0)) == sizeof(char);
};
struct abstract {
virtual void function() = 0;
};
static_assert(is_abstract::value, "ok");
The static assertion trigger on GCC11 and above, even in older standard modes.
It compiles fine on GCC10 and below.
Various libraries in Boost use the above definition of is_abstract especially
in C++03. The basis was the following wording in [temp.deduct] until C++17:
"Type deduction may fail for the following reasons:
- Attempting to create an array with an element type that is void, a function
type, a reference type, or an abstract class type, or attempting to create an
array with a size that is zero or negative."
The "or an abstract class type" was absent in C++03, added by CWG337.
[Bug fortran/105543] Function returning a class array with contiguous attribute rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105543 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-10 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The code is accepted if you *don't* use the result clause, as in: function create() class(a), dimension(:), contiguous, pointer :: create end function create There are a couple PRs about declarations involving CLASS where attributes are specified separately. There could be a relation.
[Bug fortran/105526] [Coarray] Missing checks for arguments of type TEAM_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105526 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed for gcc-13.
[Bug fortran/105526] [Coarray] Missing checks for arguments of type TEAM_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105526 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5edd0802696f94012731306c704eaf61d184e09c commit r13-277-g5edd0802696f94012731306c704eaf61d184e09c Author: Harald Anlauf Date: Mon May 9 22:14:21 2022 +0200 Fortran: check TEAM arguments to coarray intrinsics TEAM arguments to coarray intrinsics must be scalar expressions of type TEAM_TYPE of intrinsic module ISO_FORTRAN_ENV. gcc/fortran/ChangeLog: PR fortran/105526 * resolve.cc (check_team): New. (gfc_resolve_code): Add checks for arguments to coarray intrinsics FORM TEAM, CHANGE TEAM, and SYNC TEAM. gcc/testsuite/ChangeLog: PR fortran/105526 * gfortran.dg/coarray_50.f90: New test.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cc93971399ad9719b5bda878630e69c5914f2202 commit r12-8365-gcc93971399ad9719b5bda878630e69c5914f2202 Author: Jonathan Wakely Date: Tue May 10 13:06:47 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/spanstream (basic_spanbuf, basic_ispanstream) (basic_ospanstream, basic_spanstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: Add declarations. * testsuite/27_io/headers/iosfwd/types.cc: Check default arguments. (cherry picked from commit ca97c87758d450a946cac31b0db43da0039fabf1)
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3e6067bdcab5f677526d80325b9b8dc03f49024d commit r12-8364-g3e6067bdcab5f677526d80325b9b8dc03f49024d Author: Jonathan Wakely Date: Tue May 10 13:03:14 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/syncstream (basic_syncbuf, basic_osyncstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: New test. * testsuite/27_io/headers/iosfwd/types.cc: New test. (cherry picked from commit 1807e07825a86916bbfddca470708c5a8f613612)
[Bug target/105552] New: munmap_chunk(): invalid pointer in __gmp_default_free on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105552
Bug ID: 105552
Summary: munmap_chunk(): invalid pointer in __gmp_default_free
on ia64
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matoro_gcc_bugzilla at matoro dot tk
Target Milestone: ---
I am unsure if this one is specifically gcc's fault because it also traverses
mpfr and gmp codepaths. Since I don't have a standalone call into either of
those libs that reproduces though I believe it may be specific to how gcc calls
into them. Tested with gcc-11.3.0, gcc-12.1.0.
The warnings are irrelevant, adding simple fixes to them (including math.h,
specifying void return) do not fix the crash.
I can provide live ssh access to the system in question if that would be
helpful. Simply email me at this address.
The minimized example is as follows:
$ cat testcairo.i
draw_3circles() { sin(3.1415926535897932384626433832795028841971693993751); }
$ gcc -c testcairo.i
testcairo.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^
testcairo.i: In function ‘draw_3circles’:
testcairo.i:1:19: warning: implicit declaration of function ‘sin’
[-Wimplicit-function-declaration]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^~~
testcairo.i:1: note: include ‘’ or provide a declaration of ‘sin’
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
testcairo.i:1:19: warning: incompatible implicit declaration of built-in
function ‘sin’ [-Wbuiltin-declaration-mismatch]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^~~
testcairo.i:1:19: note: include ‘’ or provide a declaration of ‘sin’
munmap_chunk(): invalid pointer
testcairo.i:1:1: internal compiler error: Aborted
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^
linux-gate.so.1: Bad address
$ gdb -q --args gcc -c testcairo.i
Reading symbols from gcc...
Reading symbols from
/usr/lib/debug//usr/ia64-unknown-linux-gnu/gcc-bin/12.1.0/ia64-unknown-linux-gnu-gcc.debug...
(gdb) set follow-fork-mode child
(gdb) r
Starting program: /usr/bin/gcc -c testcairo.i
Failed to read a valid object file image from memory.
warning: Can't read pathname for load map.
warning: Can't read pathname for load map.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[Attaching after Thread 0x20204d60 (LWP 27400) vfork to child process
27402]
[New inferior 2 (process 27402)]
warning: Can't read pathname for load map.
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[Detaching vfork parent process 27400 after child exec]
[Inferior 1 (process 27400) detached]
process 27402 is executing new program:
/usr/libexec/gcc/ia64-unknown-linux-gnu/12.1.0/cc1
warning: Can't read pathname for load map.
warning: Can't read pathname for load map.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
testcairo.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^
testcairo.i: In function ‘draw_3circles’:
testcairo.i:1:19: warning: implicit declaration of function ‘sin’
[-Wimplicit-function-declaration]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^~~
testcairo.i:1: note: include ‘’ or provide a declaration of ‘sin’
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
testcairo.i:1:19: warning: incompatible implicit declaration of built-in
function ‘sin’ [-Wbuiltin-declaration-mismatch]
1 | draw_3circles() {
sin(3.1415926535897932384626433832795028841971693993751); }
| ^~~
testcairo.i:1:19: note: include ‘’ or provide a declaration of ‘sin’
munmap_chunk(): invalid pointer
Thread 2.1 "cc1" received signal SIGABRT, Aborted.
[Switching to Thread 0x20516ba0 (LWP 27402)]
0xa0040721 in ?? ()
(gdb) bt
#0 0xa0040721 in ?? ()
#1 0x20a3c240 in __pthread_kill_implementation () from
/lib/libc.so.6.1
#2 0x20991c40 in raise () from /lib/libc.so.6.1
#3 0x2095eb70 in abort () from /lib/libc.so.6.1
#4 0x20a1b960 in __libc_message () from /lib/libc.so.6.1
#5 0x20a56c70 in malloc_printerr () from /lib/libc.so.6.1
#6 0x20a57290 in munmap_chunk () from /lib/libc.so.6.1
#7 0x20a61870 in
[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:6b5ca56fec4f713add424a5131350b28ce81e9da commit r11-9976-g6b5ca56fec4f713add424a5131350b28ce81e9da Author: H.J. Lu Date: Fri May 6 10:55:53 2022 -0700 x86: Add .note.GNU-stack section only for Linux Add .note.GNU-stack section only for Linux since it may not be supported on non-Linux OSes. __ELF__ isn't checked since these tests can only run on Linux/x86 ELF systems. PR target/105472 * gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack section only for Linux. * gcc.target/x86_64/abi/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise. * gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise. (cherry picked from commit 71eae0fd3dd7a5f30067ea26a06a8774355fd5cc)
[Bug tree-optimization/105528] [11/12/13 Regression] ICE: in expand_expr_real_2, at expr.cc:10290 with -O2 -mavx512f since r11-8059-g5240c5ca2e2b1f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105528 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/105528] [11/12/13 Regression] ICE: in expand_expr_real_2, at expr.cc:10290 with -O2 -mavx512f since r11-8059-g5240c5ca2e2b1f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105528 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:03f73056bf688da31b649fd04e70c9d7a0dcc001 commit r11-9975-g03f73056bf688da31b649fd04e70c9d7a0dcc001 Author: Jakub Jelinek Date: Tue May 10 18:34:08 2022 +0200 isel: Fix up gimple_expand_vec_set_expr [PR105528] The following testcase ICEs (and only without -g), because we don't replace one VEC_COND_EXPR with .VCOND* call. We don't do that because gimple_expand_vec_set_expr adds some stmts before *gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator to the next stmt and in the caller we then do gsi_next before looking at another stmt, which means we can skip processing of one stmt, which in this case happened to be a VEC_COND_EXPR but with -g is some debug stmt in between. As we always emit some stmts before it, it is easy to update the iterator to the last stmt emitted there, so that caller continues really with the next stmt. 2022-05-10 Jakub Jelinek PR tree-optimization/105528 * gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove set *gsi to gsi_for_stmt (ass_stmt). Fix up function comment. * gcc.dg/pr105528.c: New test. (cherry picked from commit ddd46293e2b508b260eefe1adbad6720df7a5dd2)
[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ab8a8d053734d6abc6ee9c5bfb772ff95ba74fc9 commit r12-8363-gab8a8d053734d6abc6ee9c5bfb772ff95ba74fc9 Author: H.J. Lu Date: Fri May 6 10:55:53 2022 -0700 x86: Add .note.GNU-stack section only for Linux Add .note.GNU-stack section only for Linux since it may not be supported on non-Linux OSes. __ELF__ isn't checked since these tests can only run on Linux/x86 ELF systems. PR target/105472 * gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack section only for Linux. * gcc.target/x86_64/abi/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise. * gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise. (cherry picked from commit 71eae0fd3dd7a5f30067ea26a06a8774355fd5cc)
[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105472 --- Comment #5 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:71eae0fd3dd7a5f30067ea26a06a8774355fd5cc commit r13-276-g71eae0fd3dd7a5f30067ea26a06a8774355fd5cc Author: H.J. Lu Date: Fri May 6 10:55:53 2022 -0700 x86: Add .note.GNU-stack section only for Linux Add .note.GNU-stack section only for Linux since it may not be supported on non-Linux OSes. __ELF__ isn't checked since these tests can only run on Linux/x86 ELF systems. PR target/105472 * gcc.target/i386/iamcu/asm-support.S: Add .note.GNU-stack section only for Linux. * gcc.target/x86_64/abi/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512f/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m256h/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx512fp16/m512h/asm-support.S: Likewise. * gcc.target/x86_64/abi/ms-sysv/do-test.S: Likewise.
[Bug tree-optimization/105528] [11/12/13 Regression] ICE: in expand_expr_real_2, at expr.cc:10290 with -O2 -mavx512f since r11-8059-g5240c5ca2e2b1f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105528 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9468cc35daca9fd6a0ec479217bb40a77616fb25 commit r12-8362-g9468cc35daca9fd6a0ec479217bb40a77616fb25 Author: Jakub Jelinek Date: Tue May 10 18:34:08 2022 +0200 isel: Fix up gimple_expand_vec_set_expr [PR105528] The following testcase ICEs (and only without -g), because we don't replace one VEC_COND_EXPR with .VCOND* call. We don't do that because gimple_expand_vec_set_expr adds some stmts before *gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator to the next stmt and in the caller we then do gsi_next before looking at another stmt, which means we can skip processing of one stmt, which in this case happened to be a VEC_COND_EXPR but with -g is some debug stmt in between. As we always emit some stmts before it, it is easy to update the iterator to the last stmt emitted there, so that caller continues really with the next stmt. 2022-05-10 Jakub Jelinek PR tree-optimization/105528 * gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove set *gsi to gsi_for_stmt (ass_stmt). Fix up function comment. * gcc.dg/pr105528.c: New test. (cherry picked from commit ddd46293e2b508b260eefe1adbad6720df7a5dd2)
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #5)
> I am a little confused:
>
> with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there
> are two issues:
>
> 1. the early uninitialized analysis didn't catch the uninitialized usage of
> y;
>
>
> 2. the ccp optimization deletes the if (z) statement completely:
>
> [opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
>
> ;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
>
> Removing basic block 3
> Merging blocks 2 and 4
> int x (int z)
> {
> int y;
>
>:
> return 10;
>
> }
>
> are the above two bugs?
Is this because that "y" is uninitialized, so the behavior of this program is
undefined? then the above 2 is okay, but 1 is still an issue?
[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
--- Comment #5 from qinzhao at gcc dot gnu.org ---
I am a little confused:
with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there are
two issues:
1. the early uninitialized analysis didn't catch the uninitialized usage of y;
2. the ccp optimization deletes the if (z) statement completely:
[opc@qinzhao-aarch64-ol8 105539]$ cat t.c.034t.ccp1
;; Function x (x, funcdef_no=0, decl_uid=3591, cgraph_uid=1, symbol_order=0)
Removing basic block 3
Merging blocks 2 and 4
int x (int z)
{
int y;
:
return 10;
}
are the above two bugs?
[Bug tree-optimization/105528] [11/12/13 Regression] ICE: in expand_expr_real_2, at expr.cc:10290 with -O2 -mavx512f since r11-8059-g5240c5ca2e2b1f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105528 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ddd46293e2b508b260eefe1adbad6720df7a5dd2 commit r13-275-gddd46293e2b508b260eefe1adbad6720df7a5dd2 Author: Jakub Jelinek Date: Tue May 10 18:34:08 2022 +0200 isel: Fix up gimple_expand_vec_set_expr [PR105528] The following testcase ICEs (and only without -g), because we don't replace one VEC_COND_EXPR with .VCOND* call. We don't do that because gimple_expand_vec_set_expr adds some stmts before *gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator to the next stmt and in the caller we then do gsi_next before looking at another stmt, which means we can skip processing of one stmt, which in this case happened to be a VEC_COND_EXPR but with -g is some debug stmt in between. As we always emit some stmts before it, it is easy to update the iterator to the last stmt emitted there, so that caller continues really with the next stmt. 2022-05-10 Jakub Jelinek PR tree-optimization/105528 * gimple-isel.cc (gimple_expand_vec_set_expr): After gsi_remove set *gsi to gsi_for_stmt (ass_stmt). Fix up function comment. * gcc.dg/pr105528.c: New test.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #4 from Jonathan Wakely --- Fixed on trunk, backports to follow.
[Bug c++/105550] Missing copy elision with conditional operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550
Marek Polacek changed:
What|Removed |Added
Summary|Missing copy elision with |Missing copy elision with
|conditional operator in |conditional operator
|NSDMI |
--- Comment #1 from Marek Polacek ---
This is not tied to NSDMIs; this one fails the same:
struct A {
const A* p = this;
};
constexpr A a = true ? A{} : A{};
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ca97c87758d450a946cac31b0db43da0039fabf1 commit r13-271-gca97c87758d450a946cac31b0db43da0039fabf1 Author: Jonathan Wakely Date: Tue May 10 13:06:47 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/spanstream (basic_spanbuf, basic_ispanstream) (basic_ospanstream, basic_spanstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: Add declarations. * testsuite/27_io/headers/iosfwd/types.cc: Check default arguments.
[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105284 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1807e07825a86916bbfddca470708c5a8f613612 commit r13-270-g1807e07825a86916bbfddca470708c5a8f613612 Author: Jonathan Wakely Date: Tue May 10 13:03:14 2022 +0100 libstdc++: Add declarations to [PR105284] libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/syncstream (basic_syncbuf, basic_osyncstream): Remove default template arguments. * testsuite/27_io/headers/iosfwd/synopsis.cc: New test. * testsuite/27_io/headers/iosfwd/types.cc: New test.
[Bug bootstrap/105551] [13 Regression] [nvptx] ICE in final_scan_insn_1, at final.cc:2629 when building libgcc2.c since r13-259-g76db543db88727789a6c117608a23edc2eace713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |13.0 Summary|[nvptx] ICE in |[13 Regression] [nvptx] ICE |final_scan_insn_1, at |in final_scan_insn_1, at |final.cc:2629 when building |final.cc:2629 when building |libgcc2.c since |libgcc2.c since |r13-259-g76db543db88727789a |r13-259-g76db543db88727789a |6c117608a23edc2eace713 |6c117608a23edc2eace713 --- Comment #1 from Tobias Burnus --- Glancing at the current patch, it seems as if the || debug_hooks->var_location == do_nothing_debug_hooks.var_location) check got lost.
[Bug bootstrap/105551] New: [nvptx] ICE in final_scan_insn_1, at final.cc:2629 when building libgcc2.c since r13-259-g76db543db88727789a6c117608a23edc2eace713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551 Bug ID: 105551 Summary: [nvptx] ICE in final_scan_insn_1, at final.cc:2629 when building libgcc2.c since r13-259-g76db543db88727789a6c117608a23edc2eace713 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: rguenth at gcc dot gnu.org, tschwinge at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Target: nvptx-none /gcc/xgcc \ -B.../gcc/ -B.../nvptx-none/bin/ -B.../nvptx-none/lib/ -isystem .../nvptx-none/include -isystem .../nvptx-none/sys-include --sysroot=.../nvptx-none -g -O2 -mgomp -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I.../src/gcc-mainline/libgcc -I.../src/gcc-mainline/libgcc/. -I.../src/gcc-mainline/libgcc/../gcc -I.../src/gcc-mainline/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c .../src/gcc-mainline/libgcc/libgcc2.c during RTL pass: final .../src/gcc-mainline/libgcc/libgcc2.c: In function '__multi3': .../src/gcc-mainline/libgcc/libgcc2.c:538:1: internal compiler error: in final_scan_insn_1, at final.cc:2629 538 | } | ^ 0x9a6288 final_scan_insn_1 .../src/gcc-mainline/gcc/final.cc:2629 0x9a642b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) .../src/gcc-mainline/gcc/final.cc:2940 0x9a6545 final_1 .../src/gcc-mainline/gcc/final.cc:1997 0x9a7564 rest_of_handle_final .../src/gcc-mainline/gcc/final.cc:4285 0x9a7564 execute .../src/gcc-mainline/gcc/final.cc:4363 Please submit a full bug report, with preprocessed source (by using -freport-bug). Bisecting points to r13-259-g76db543db88727789a6c117608a23edc2eace713 commit 76db543db88727789a6c117608a23edc2eace713 Author: Richard Biener Date: Tue May 10 11:44:40 2022 +0200 middle-end/105537 - debug processing The following makes sure to have a consistent state of flag_var_tracking_assignments with the distributed handling in process_options and finish_options by moving everything to finish_options which also restores diagnostics for -g0 -fvar-tracking which was lost with previous changes. 2022-05-10 Richard Biener PR middle-end/105537 * toplev.cc (process_options): Move flag_var_tracking handling ... * opts.cc (finish_options): ... here. * gcc.dg/torture/pr105537.c: New testcase.
[Bug c/103881] Wconversion false positive when using |= and &= with two rvalues in binary op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed for 10.4 as well, not going to backport it further.
[Bug c++/105550] Missing copy elision with conditional operator in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Last reconfirmed||2022-05-10 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Blocks||100252 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252 [Bug 100252] [9/10/11/12/13 Regression] Internal compiler error during template instantiation
[Bug c++/105550] New: Missing copy elision with conditional operator in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550
Bug ID: 105550
Summary: Missing copy elision with conditional operator in
NSDMI
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Consider:
struct A {
const A* p = this;
};
struct E {
A a = true ? A{} : A{};
};
constexpr E e{};
$ ./cc1plus -quiet q.C
q.C:9:15: error: ‘E{A{((const A*)(&))}}’ is not a constant
expression
9 | constexpr E e{};
| ^
The ?: shouldn't preclude copy elision. 'e' must be static for this to work.
Bug 96004 with a similar title doesn't seem to be a duplicate of this one.
[Bug libstdc++/102994] std::atomic::wait is not marked const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Thomas Rodgers --- Committed to GCC12 and backported to GCC11
[Bug target/105549] aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Christophe Lyon changed: What|Removed |Added Known to fail||8.5.0, 9.4.1 --- Comment #1 from Christophe Lyon --- It already failed with gcc-9. With gcc-8 only the 2nd check failed.
[Bug c++/105541] [12/13 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-10 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug target/105549] aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Christophe Lyon changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org Severity|major |normal Target||aarch64
[Bug target/105549] New: aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Bug ID: 105549
Summary: aarch64: Wrong va_arg alignment handling
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. I reduced the problem to:
/* This test is derived from a case generated by struct-layout-1.exp: */
enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 };
typedef enum E6 Tal16E6 __attribute__((aligned (16)));
typedef unsigned int Tuint;
int fails;
union S2844 {
Tuint a:10) - 1) & 31) + 1);
Tal16E6 __attribute__((aligned (2), packed)) b:31;
struct{}c[0];
} ;
union S2844 s2844;
union S2844 a2844[5];
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
void check2844va (int z, ...) {
union S2844 arg, *p;
va_list ap;
__builtin_va_start(ap,z);
if (__builtin_va_arg(ap,double) != 1.0)
printf ("fail %d.%d\n", 2844, 0), ++fails;
p =
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 1), ++fails;
if (__builtin_va_arg(ap,long long) != 3LL)
printf ("fail %d.%d\n", 2844, 2), ++fails;
p = [2];
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 3), ++fails;
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 4), ++fails;
__builtin_va_end(ap);
}
int main (void) {
int i, j;
memset (, '\0', sizeof (s2844));
memset (a2844, '\0', sizeof (a2844));
s2844.a = 799U;
a2844[2].a = 586U;
check2844va (1, 1.0, s2844, 2LL, a2844[2], a2844[2]);
exit (fails != 0);
}
This is a tough case mixing bitfields and alignment, where
aarch64_gimplify_va_arg_expr did not follow the exact same rule as
aarch64_layout_arg. When the va_arg parameter uses only one general
register, we do not want to introduce double-word alignment.
[Bug middle-end/100400] ICE in visit_loops_in_gang_single_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100400 --- Comment #7 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:da6305558bab9e24943848e4fc5bd8738d7e8f9b commit r13-262-gda6305558bab9e24943848e4fc5bd8738d7e8f9b Author: Thomas Schwinge Date: Mon May 2 15:15:26 2022 +0200 Make 'c-c++-common/goacc/kernels-decompose-pr100400-1-*.c' behave consistently, regardless of checking level Fix-up for commit c14ea6a72fb1ae66e3d32ac8329558497c6e4403 "Catch 'GIMPLE_DEBUG' misbehavior in OpenACC 'kernels' decomposition [PR100400, PR103836, PR104061]". For C++ compilation of 'c-c++-common/goacc/kernels-decompose-pr100400-1-2.c', we first emit a 'sorry' diagnostic, and then a 'gcc_unreachable' (or 'internal_error', see below) diagnostic, but for example, for '--enable-checking=release' (thus, '!CHECKING_P'), the second one may actually be turned into a 'confused by earlier errors, bailing out' diagnostic. (See 'gcc/diagnostic.cc:diagnostic_report_diagnostic': "When not checking, ICEs are converted to fatal errors when an error has already occurred.") Thus, make 'c-c++-common/goacc/kernels-decompose-pr100400-1-2.c' behave consistently via '-Wfatal-errors', and thus only matching the 'sorry' diagnostic. For example, for '--enable-checking=no' (thus, '!ENABLE_ASSERT_CHECKING'), a call to 'gcc_unreachable' cannot be assumed emit an 'internal_error'-like diagnostic, so explicitly call 'internal_error' in 'gcc/omp-oacc-kernels-decompose.cc:visit_loops_in_gang_single_region', in the 'GIMPLE_OMP_FOR' case, to avoid regressing 'c-c++-common/goacc/kernels-decompose-pr100400-1-3.c', and 'c-c++-common/goacc/kernels-decompose-pr100400-1-4.c'. PR middle-end/100400 gcc/ * omp-oacc-kernels-decompose.cc (visit_loops_in_gang_single_region) : Explicitly call 'internal_error'. gcc/testsuite/ * c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Specify '-Wfatal-errors'.
[Bug other/105548] New: -frounding-math description contains an misleading sentence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105548 Bug ID: 105548 Summary: -frounding-math description contains an misleading sentence Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html has -frounding-math Disable transformations and optimizations that assume default floating-point rounding behavior. This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations. This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode. This option disables constant folding of floating-point expressions at compile time (which may be affected by rounding mode) and arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes. However, the sentence "This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations." is misleading, because even code with no rounding in the source code may be affected (e.g. PR102498, due to code generated by GCC to load particular floating-point constants). This sentence doesn't bring anything useful and should be removed (in short, if some part of the code runs in non-default rounding mode, then -frounding-math should be used, whatever the operations involved in the source code). Note also that "round-to-zero for all floating point to integer conversions" probably doesn't concern the user (or are there languages with dynamic FP-to-integer rounding modes?). Possibly add "(round-to-nearest)" at the end of the first sentence.
[Bug target/105485] ICE: Segmentation fault in pcrel-opt.md:get_insn_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485 --- Comment #4 from Kewen Lin --- Created attachment 52949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52949=edit untested patch This attached patch can get it fixed. Will test it further and add one test case.
[Bug target/105485] ICE: Segmentation fault in pcrel-opt.md:get_insn_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485
--- Comment #3 from Kewen Lin ---
This issue can happen for any bif which supports overloading.
for example, same ICE for:
typedef __attribute__ ((altivec (vector__))) signed int T;
template void __builtin_vec_splats ();
T b (T i)
{
return __builtin_vec_splats (i);
}
[Bug c++/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 Jonathan Wakely changed: What|Removed |Added Summary|[12/13 Regression] |[12/13 Regression] Warning |Compiling string assignment |for string assignment with |with _GLIBCXX_ASSERTIONS|_GLIBCXX_ASSERTIONS since |fails since |r12-3347-g8af8abfbbace49e6 |r12-3347-g8af8abfbbace49e6 | Keywords||diagnostic --- Comment #2 from Jonathan Wakely --- (In reply to John Buddery from comment #0) >g++ -m64 -c -std=gnu++17 -Wall -O3 -Werror -D_GLIBCXX_ASSERTIONS x.cpp This is only a warning. It fails because you asked it to, with -Werror. Reporting that compilation fails when you turn warnings into errors isn't very interesting, that's the point of -Werror :-) So the bug here is a bogus warning, not that compilation fails. Summary adjusted accordingly.
[Bug target/105485] ICE: Segmentation fault in pcrel-opt.md:get_insn_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Kewen Lin --- I was wrong, the local branch which I used as old bif support isn't the one before new bif support. The bisection showed it's a regression and started from r12-5752 (new bif support). By looking to the old bif support, I noticed that it's expected that this function won't be resolved, but we need to emit one error message during expanding. With old bif support, __builtin_vec_vslv is binded to the normal (primary) bif enum (bif code), it needs overloaded resolver (target hook) to resolve it into the overloaded bif enum; while with new bif support, __builtin_vec_vslv is binded to the overload bif enum, it needs overloaded resolver to resolve it into the one defined in rs6000-builtins.def (one instance of overloaded). In new bif support, rs6000_gimple_fold_builtin won't be able to handle the unresolved overloaded bif. Note that it doesn't in old bif support, but both primary and overloaded code shares the same table, so it's fine and no ICEs. With new bif support, overloaded bif code has its own table.
[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605 --- Comment #8 from Segher Boessenkool --- (In reply to jos...@codesourcery.com from comment #4) > > xsmindp > > The minimum of a QNaN and any value is that value. The minimum of any value > > and > > an SNaN is that SNaN converted to a QNaN. > > xsmindp(NaN, 3.0) = 3.0 xsmindp(3.0, NaN) = NaN > > That seems right for fmin, provided that (QNaN, SNaN) arguments in either > order produce a QNaN result (with "invalid" raised). They do, and they return a QNaN with the payload of the first operand, in both cases.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #3 from Martin Liška --- Information for package glibc: -- Repository : Main Repository (OSS) Name : glibc Version: 2.35-2.1 Arch : x86_64 Vendor : openSUSE Installed Size : 7.0 MiB Installed : Yes Status : up-to-date Source package : glibc-2.35-2.1.src Upstream URL : http://www.gnu.org/software/libc/libc.html Summary: Standard Shared Libraries (from the GNU C Library)
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #2 from ibuclaw at gcc dot gnu.org --- What version of glibc are you using? Not encountered this myself from debian's gcc packages. $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-9 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-10 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-11 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-12 -c -x d - 2099
[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498 --- Comment #14 from Vincent Lefèvre --- Sorry, I wasn't using -frounding-math (which matters to have the optimization disabled).
[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #1 from Mikael Morin ---
In parse.cc, we avoid emitting an error if an other has been emitted.
But it uses the total error count, not the number of errors since we started
matching the current statement.
597 if (!gfc_error_check ())
598{
599 int ecnt;
600 gfc_get_errors (NULL, );
601 if (ecnt <= 0)
602gfc_error_now ("Unclassifiable statement at %C");
603}
[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498 --- Comment #13 from Vincent Lefèvre --- Strange. I still get this bug with gcc-11 (Debian 11.3.0-1) 11.3.0.
[Bug fortran/105547] New: No further "Unclassifiable statement" after the first one if multiple syntax errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547 Bug ID: 105547 Summary: No further "Unclassifiable statement" after the first one if multiple syntax errors. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Testcase as reported by Harald here: https://gcc.gnu.org/pipermail/fortran/2022-May/057841.html subroutine a errorstop end subroutine b errorstop end This gives only one error as output instead of two: xxx.f90:2:3: 2 | errorstop | 1 Error: Unclassifiable statement at (1)
[Bug rtl-optimization/105546] load introduction when initializing a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546 --- Comment #1 from absoler at smail dot nju.edu.cn --- and it's the load of g_344 that we care about.
[Bug rtl-optimization/105546] New: load introduction when copying a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546
Bug ID: 105546
Summary: load introduction when copying a struct
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
Created attachment 52948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52948=edit
case file
Hi, here's the code:
...
struct S0 {
unsigned short f0;
unsigned short f1;
short f2;
unsigned char f3;
long long f4;
long long f5;
};
short g_344 = 0xC307L;
struct S0 func_1(void)
{
struct S0 l_346 = {65526UL,1UL,-8L,0xA1L,0x2F513C84A35AAE1BLL,-6L};
if (g_344)
{
struct S0 l_345 = {0x0AB2L,0x6D27L,-1L,0xABL,3L,0x3E72F31FF82C1E35LL};
return l_345;
}
else
{
return l_346;
}
}
...
with option -O1, gcc-11.3.0 generate the following code:
Dump of assembler code for function func_1:
0x00401126 <+0>: mov%rdi,%rax
0x00401129 <+3>: cmpw $0x1,0x2eff(%rip)# 0x404030
0x00401131 <+11>:sbb%edi,%edi
0x00401133 <+13>:and$0xf544,%di
0x00401138 <+18>:add$0xab2,%di
0x0040113d <+23>:cmpw $0x1,0x2eeb(%rip)# 0x404030
0x00401145 <+31>:sbb%esi,%esi
0x00401147 <+33>:and$0x92da,%si
0x0040114c <+38>:add$0x6d27,%si
0x00401151 <+43>:cmpw $0x1,0x2ed7(%rip)# 0x404030
0x00401159 <+51>:sbb%ecx,%ecx
0x0040115b <+53>:and$0xfff9,%ecx
0x0040115e <+56>:sub$0x1,%ecx
0x00401161 <+59>:cmpw $0x1,0x2ec7(%rip)# 0x404030
0x00401169 <+67>:sbb%edx,%edx
0x0040116b <+69>:and$0xfff6,%edx
0x0040116e <+72>:sub$0x55,%edx
0x00401171 <+75>:cmpw $0x0,0x2eb7(%rip)# 0x404030
0x00401179 <+83>:movabs $0x2f513c84a35aae1b,%r9
0x00401183 <+93>:mov$0x3,%r8d
0x00401189 <+99>:cmovne %r8,%r9
0x0040118d <+103>: movabs $0x3e72f31ff82c1e35,%r10
0x00401197 <+113>: mov$0xfffa,%r8
0x0040119e <+120>: cmovne %r10,%r8
0x004011a2 <+124>: mov%di,(%rax)
0x004011a5 <+127>: mov%si,0x2(%rax)
0x004011a9 <+131>: mov%cx,0x4(%rax)
0x004011ad <+135>: mov%dl,0x6(%rax)
0x004011b0 <+138>: mov%r9,0x8(%rax)
0x004011b4 <+142>: mov%r8,0x10(%rax)
0x004011b8 <+146>: retq
it seems the last 4 loads are unneed and can be optimized away, which bring
vulnerabilities when facing concurrency and may decrease performance
[Bug gcov-profile/105500] [Gcov]wrong freqency for the while loop with struct in the expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105500 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Martin Liška --- Fixed with r8-253-g6e49961ce47b8c55.
[Bug c++/105545] [12/13 Regression] Compiling string assignment with _GLIBCXX_ASSERTIONS fails since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.2 Last reconfirmed||2022-05-10 CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|Compiling string assignment |[12/13 Regression] |with _GLIBCXX_ASSERTIONS|Compiling string assignment |defined fails in 12.1.0,|with _GLIBCXX_ASSERTIONS |works in 11.1.0 |fails since ||r12-3347-g8af8abfbbace49e6 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-3347-g8af8abfbbace49e6.
[Bug c++/105545] New: Compiling string assignment with _GLIBCXX_ASSERTIONS defined fails in 12.1.0, works in 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
Bug ID: 105545
Summary: Compiling string assignment with _GLIBCXX_ASSERTIONS
defined fails in 12.1.0, works in 11.1.0
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jvb at cyberscience dot com
Target Milestone: ---
Compiling using -D_GLIBCXX_ASSERTIONS fails in gcc 12.1.0, worked in 11.1.0:
#include
extern std::string a();
std::string a()
{
std::string x;
x.assign( "Z" );
return x;
}
using command line:
g++ -m64 -c -std=gnu++17 -Wall -O3 -Werror -D_GLIBCXX_ASSERTIONS x.cpp
fails with:
In file included from /usr/local/gcc-12.1.0/include/c++/12.1.0/string:40,
from x.cpp:14:
In static member function ??static std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)??,
inlined from ??static void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.h:423:21,
inlined from ??std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_replace(size_type,
size_type, const _CharT*, size_type) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.tcc:532:22,
inlined from ??std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]?? at
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/basic_string.h:1647:19,
inlined from ??std::string a()?? at x.cpp:22:12:
/usr/local/gcc-12.1.0/include/c++/12.1.0/bits/char_traits.h:431:56: error:
??void* __builtin_memcpy(void*, const void*, long unsigned int)?? accessing
9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 17
may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict]
431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
|
^
cc1plus: all warnings being treated as errors
[Bug tree-optimization/105537] [12 Regression] ICE: cannot update SSA form (error: statement uses released SSA name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105537 Richard Biener changed: What|Removed |Added Known to work||13.0 --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/105537] [12 Regression] ICE: cannot update SSA form (error: statement uses released SSA name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105537 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:76db543db88727789a6c117608a23edc2eace713 commit r13-259-g76db543db88727789a6c117608a23edc2eace713 Author: Richard Biener Date: Tue May 10 11:44:40 2022 +0200 middle-end/105537 - debug processing The following makes sure to have a consistent state of flag_var_tracking_assignments with the distributed handling in process_options and finish_options by moving everything to finish_options which also restores diagnostics for -g0 -fvar-tracking which was lost with previous changes. 2022-05-10 Richard Biener PR middle-end/105537 * toplev.cc (process_options): Move flag_var_tracking handling ... * opts.cc (finish_options): ... here. * gcc.dg/torture/pr105537.c: New testcase.
[Bug tree-optimization/105537] [12 Regression] ICE: cannot update SSA form (error: statement uses released SSA name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105537 Richard Biener changed: What|Removed |Added Summary|ICE: cannot update SSA form |[12 Regression] ICE: cannot |(error: statement uses |update SSA form (error: |released SSA name) |statement uses released SSA ||name) Target Milestone|--- |12.2 Priority|P3 |P2
[Bug gcov-profile/105535] GCOV analysis on 16-bit target systems impossible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105535 Martin Liška changed: What|Removed |Added Known to work||13.0 --- Comment #4 from Martin Liška --- Fixed on master so far.
[Bug gcov-profile/105535] GCOV analysis on 16-bit target systems impossible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105535 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:1bac97ad0436afcbce24c82e6d57f11471cd8f10 commit r13-258-g1bac97ad0436afcbce24c82e6d57f11471cd8f10 Author: Martin Liska Date: Tue May 10 10:52:19 2022 +0200 libgcov: use proper type for n_functions gcov_info::n_functions type is initialized by generated code in build_info_type: /* n_functions */ field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE, get_gcov_unsigned_t ()); It uses gcov_unsigned_t, but the struct definition in libgcov.h uses unsigned type. That brings troubled on 16-bit targets. PR gcov-profile/105535 libgcc/ChangeLog: * libgcov.h (struct gcov_info): Use gcov_unsigned_t for n_functions. Co-Authored-By: Hans-Peter Helfert
[Bug rtl-optimization/100342] [10 Regression] wrong code with -O2 -fno-dse -fno-forward-propagate -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug rtl-optimization/105333] [10 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -Og -fno-tree-coalesce-vars -fno-tree-fre since r10-1094-g9919f5fe87a3def1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105333 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug tree-optimization/105094] [10 Regression] UBSAN in clear_bit_region(unsigned char*, unsigned int, unsigned int) (gimple-ssa-store-merging.cc:1834)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105094 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/105061] [10 Regression] [c++2a+] anonymous bitfield templated offset rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105061 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug target/104910] [10 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104910 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug rtl-optimization/104814] [10 Regression] ifcvt: Deleting live variable in IF-CASE-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/104568] [10 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552 -fharden-compares -fno-ipa-pure-const and returns_twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 Bug 103845 depends on bug 104263, which changed state. Bug 104263 Summary: [10 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/104263] [10 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104263 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/104055] Temporary with consteval constructor does not cause the deconstructor to be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104055 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 103912, which changed state. Bug 103912 Summary: ICE in a consteval function which returns a lambda which takes a "non-POD" argument and the consteval has other code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103912 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103912] ICE in a consteval function which returns a lambda which takes a "non-POD" argument and the consteval has other code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103912 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c/103587] [10 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850 since r10-4633-g4e03c3a7c1149a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103587 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/103480] [10 Regression] -Werror=useless-cast with constexpr destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103480 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug debug/102441] [10 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/100580] [10 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 Martin Liška changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-10
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #1 from Fabian Vogt --- Forgot to mention: Happens with gdc 10, 11 and 12 the same way.
[Bug d/105544] New: gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 Bug ID: 105544 Summary: gdc fails to compile d source from stdin Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: fab...@ritter-vogt.de Target Milestone: --- Reading code from stdin doesn't work. strace shows that it attempts to read from a file "" repeatedly. ~> echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc -x d - :2:1: error: Outside Unicode code space :2:1: error: Outside Unicode code space :2:1: error: Outside Unicode code space :2:1: error: Outside Unicode code space ... :2: error: no identifier for declarator ���... Expected behaviour: ~> echo "pragma(msg, int(__VERSION__));" > ver.d; /usr/bin/gdc-11 -x d /tmp/ver.d 2076 /usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/Scrt1.o: in function `_start': /home/abuild/rpmbuild/BUILD/glibc-2.35/csu/../sysdeps/x86_64/start.S:103: undefined reference to `main' collect2: error: ld returned 1 exit status
[Bug c++/104503] [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104503 Ivan Sorokin changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #4 from Ivan Sorokin --- Could you please review the resolution? In 2.cpp nothing requires . Getting an error message about something that is not even used in the file can't be right.
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #57 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #56) > Right, some hosts need to be changed. > Looks like only darwin and linux was fixed. Yeah, I said that clearly that other ports need to be changed if they want to take advantage of it. I don't have access to those targets, can't test and am not familiar with them, it is up to the maintainers of those targets or anyone that is willing to test it...
[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498 --- Comment #12 from Paul Zimmermann --- I confirm this is fixed with gcc version 11.3.0 (Debian 11.3.0-1).
[Bug testsuite/100422] [12 regression] g++.dg/gomp/clause-3.C fails after r12-438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100422 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e9af866262068845d89ca8c464773716882909f8 commit r10-10713-ge9af866262068845d89ca8c464773716882909f8 Author: Tobias Burnus Date: Wed May 5 08:50:15 2021 +0200 g++.dg/gomp/clause-3.C: Fix - missing in r12-438-g1580fc7 [PR100422] gcc/testsuite/ PR testsuite/100422 * g++.dg/gomp/clause-3.C: Use 'reduction(&:..)' instead of '...(&&:..)'. (cherry picked from commit af4e4d35f0b84d7c2f57a7b682a09116e9911142)
[Bug sanitizer/105396] [9/10 Regression] missed stack-buffer-overflow by -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105396 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e3df97908818aa0915166c91fda27febe6f19dde commit r10-10712-ge3df97908818aa0915166c91fda27febe6f19dde Author: Jakub Jelinek Date: Wed Apr 27 08:34:18 2022 +0200 asan: Fix up asan_redzone_buffer::emit_redzone_byte [PR105396] On the following testcase, we have in main's frame 3 variables, some red zone padding, 4 byte d, followed by 12 bytes of red zone padding, then 8 byte b followed by 24 bytes of red zone padding, then 40 bytes c followed by some red zone padding. The intended content of shadow memory for that is (note, each byte describes 8 bytes of memory): f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3 left redd mr b middle r c right red zone f1 is left red zone magic f2 is middle red zone magic f3 is right red zone magic 00 when all 8 bytes are accessible 01-07 when only 1 to 7 bytes are accessible followed by inaccessible bytes The -fdump-rtl-expand-details dump makes it clear that it misbehaves: Flushing rzbuffer at offset -160 with: f1 f1 f1 f1 Flushing rzbuffer at offset -128 with: 04 f2 00 00 Flushing rzbuffer at offset -128 with: 00 00 00 f2 Flushing rzbuffer at offset -96 with: f2 f2 00 00 Flushing rzbuffer at offset -64 with: 00 00 00 f3 Flushing rzbuffer at offset -32 with: f3 f3 f3 f3 In the end we end up with f1 f1 f1 f1 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3 shadow bytes because at offset -128 there are 2 overlapping stores as asan_redzone_buffer::emit_redzone_byte has flushed the temporary 4 byte buffer in the middle. The function is called with an offset and value. If the passed offset is consecutive with the prev_offset + buffer size (off == offset), then we handle it correctly, similarly if the new offset is far enough from the old one (we then flush whatever was in the buffer and if needed add up to 3 bytes of 00 before actually pushing value. But what isn't handled correctly is when the offset isn't consecutive to what has been added last time, but it is in the same 4 byte word of shadow memory (32 bytes of actual memory), like the above case where we have consecutive 04 f2 and then skip one shadow memory byte (aka 8 bytes of real memory) and then want to emit f2. Emitting that as a store of little-endian 0xf204 followed by a store of 0xf200 to the same address doesn't work, we want to emit 0xf200f204. The following patch does that by pushing 1 or 2 00 bytes. Additionally, as a small cleanup, instead of using m_shadow_bytes.safe_push (value); flush_if_full (); in all of if, else if and else bodies it sinks those 2 stmts to the end of function as all do the same thing. 2022-04-27 Jakub Jelinek PR sanitizer/105396 * asan.c (asan_redzone_buffer::emit_redzone_byte): Handle the case where offset is bigger than off but smaller than m_prev_offset + 32 bits by pushing one or more 0 bytes. Sink the m_shadow_bytes.safe_push (value); flush_if_full (); statements from all cases to the end of the function. * gcc.dg/asan/pr105396.c: New test. (cherry picked from commit 9715f10c0651c9549b479b69d67be50ac4bd98a6)
[Bug rtl-optimization/105333] [10 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -Og -fno-tree-coalesce-vars -fno-tree-fre since r10-1094-g9919f5fe87a3def1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105333 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:daf9bd6c5c7835bdbca47c8f798bd110cc8f5be8 commit r10-10711-gdaf9bd6c5c7835bdbca47c8f798bd110cc8f5be8 Author: Jakub Jelinek Date: Fri Apr 22 13:38:11 2022 +0200 rtlanal: Fix up replace_rtx [PR105333] The following testcase FAILs, because replace_rtx replaces a REG with CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation because a SUBREG relies on SUBREG_REG having non-VOIDmode but CONST_WIDE_INT has VOIDmode. replace_rtx already has code to deal with it, but it was doing it only for CONST_INTs. The following patch does it also for VOIDmode CONST_DOUBLE or CONST_WIDE_INT. 2022-04-22 Jakub Jelinek PR rtl-optimization/105333 * rtlanal.c (replace_rtx): Use simplify_subreg or simplify_unary_operation if CONST_SCALAR_INT_P rather than just CONST_INT_P. * gcc.dg/pr105333.c: New test. (cherry picked from commit 7092b7aea122a91824d048aeb23834cf1d19b1a1)
[Bug target/105257] [9/10 regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105257 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9978dc376c03a6c599b9cbd385baec9611f79ba3 commit r10-10710-g9978dc376c03a6c599b9cbd385baec9611f79ba3 Author: Jakub Jelinek Date: Tue Apr 19 18:58:59 2022 +0200 sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257] The following testcase ICEs, because the pic register is (reg:DI 24 %i0 [109]) and is used in the delay slot of a return. We invoke epilogue_renumber and that changes it to (reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p predicate, so we don't recognize the insn anymore. The following patch fixes that by preserving ORIGINAL_REGNO if specified, so we get (reg:DI 8 %o0 [109]) instead. 2022-04-19 Jakub Jelinek PR target/105257 * config/sparc/sparc.c (epilogue_renumber): If ORIGINAL_REGNO, use gen_raw_REG instead of gen_rtx_REG and copy over also ORIGINAL_REGNO. Use return 0; instead of /* fallthrough */. * gcc.dg/pr105257.c: New test. (cherry picked from commit eeca2b8bd03f57c59c6cf48bf6b9bd6dc86924f6)
[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256 --- Comment #35 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f8a34b4da971e6565a8d80e638c475bcfc06023f commit r10-10709-gf8a34b4da971e6565a8d80e638c475bcfc06023f Author: Jakub Jelinek Date: Tue Apr 19 18:27:41 2022 +0200 c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256] The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should be replaced by different objects or subobjects. The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs though, we don't replace the placeholders in there at all, because CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL ctor, but on a ctor nested in such a ctor. replace_placeholders should be run on the whole TARGET_EXPR slot. So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only if it is closely nested, if there is some other tree sandwiched in between, it doesn't do it). 2022-04-19 Jakub Jelinek PR c++/105256 * typeck2.c (process_init_constructor_array, process_init_constructor_record, process_init_constructor_union): Move CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the containing CONSTRUCTOR. * g++.dg/cpp0x/pr105256.C: New test. (cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)
[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:39a2a85e96bc8c9f82807d143dbf8421d8a93091 commit r10-10708-g39a2a85e96bc8c9f82807d143dbf8421d8a93091 Author: Jakub Jelinek Date: Tue Apr 12 09:19:11 2022 +0200 i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214] The following testcase ICEs, because ix86_emit_i387_log1p attempts to emit something like if (cond) some_code1; else some_code2; and emits a conditional jump using emit_jump_insn (standard way in the file) and an unconditional jump using emit_jump. The problem with that is that if there is pending stack adjustment, it isn't emitted before the conditional jump, but is before the unconditional jump and therefore stack is adjusted only conditionally (at the end of some_code1 above), which makes dwarf2 pass unhappy about it but is a serious wrong-code even if it doesn't ICE. This can be fixed either by emitting pending stack adjust before the conditional jump as the following patch does, or by not using emit_jump (label2); and instead hand inlining what that function does except for the pending stack adjustment, like: emit_jump_insn (targetm.gen_jump (label2)); emit_barrier (); In that case there will be no stack adjustment in the sequence and it will be done later on somewhere else. 2022-04-12 Jakub Jelinek PR target/105214 * config/i386/i386-expand.c (ix86_emit_i387_log1p): Call do_pending_stack_adjust. * gcc.dg/asan/pr105214.c: New test. (cherry picked from commit d481d13786cb84f6294833538133dbd6f39d2e55)
[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105211
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b2a09805d7df2d3ba3b8f27161cc37809f37d27a
commit r10-10707-gb2a09805d7df2d3ba3b8f27161cc37809f37d27a
Author: Jakub Jelinek
Date: Tue Apr 12 09:16:06 2022 +0200
builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.
This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it
honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.
2022-04-11 Jakub Jelinek
PR rtl-optimization/105211
* builtins.c (expand_builtin_int_roundingfn_2): If
mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.
* gcc.dg/pr105211.c: New test.
(cherry picked from commit 91a38e8a848c61b2e23ee277306dc8cd194d135b)
