[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug bootstrap/98318] [11 Regression] libcody breaks DragonFly bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318 --- Comment #14 from Rimvydas (RJ) --- Nathan, It has come to our attention that some of c++ modules tests are failing if the kernel has IPV6 support disabled as per bootstrap tools policies. Are there guarantees that local two stage bootstrap will remain possible without need for a functional (non blocked/filtered) network stack? Also, two possible typos in: gcc/cp/mapper-client.cc#L252 should be "= -1"? This avoids timeouts in the testsuite. int fd = 01; #if CODY_NETWORKING fd = Cody::OpenInet6 (, name.c_str (), port); #endif gcc/cp/module.cc:#if NETWORKING vs c++tools/server.cc:#ifdef NETWORKING
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from David Malcolm --- The false positive should be fixed by the above commit. As noted above, this is just a workaround, and PR analyzer/99260 tracks "properly" implementing realloc(3). Marking this bug as resolved.
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 --- Comment #8 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a6baafcac5308be1a5d92c0b2a179495b7a24b52 commit r11-7381-ga6baafcac5308be1a5d92c0b2a179495b7a24b52 Author: David Malcolm Date: Wed Feb 24 19:55:40 2021 -0500 analyzer: fix false positive on realloc [PR99193] PR analyzer/99193 describes various false positives from -Wanalyzer-mismatching-deallocation on realloc(3) calls of the form: | 31 | void *p = malloc (1024); | | ^ | | | | | (1) allocated here (expects deallocation with âfreeâ) | 32 | void *q = realloc (p, 4096); | | ~ | | | | | (2) deallocated with âreallocâ here; allocation at (1) expects deallocation with âfreeâ | The underlying issue is that the analyzer has no knowledge of realloc(3), and realloc has awkward semantics. Unfortunately, the analyzer is currently structured so that each call statement can only have at most one successor state; there is no way to "bifurcate" the state, or have N-way splits into multiple outcomes. The existing "on_stmt" code works on a copy of the next state, updating it in place, rather than copying it and making any necessary changes. I did this as an optimization to avoid unnecessary copying of state objects, but it makes it hard to support multiple outcomes. (ideally our state objects would be immutable and thus support trivial copying, alternatively, C++11 move semantics may help here) I attempted a few approaches to implementing bifurcation within the existing state-update framework, but they were messy and thus likely buggy; a proper implementation would rework state-updating to generate copies, but this would be a major change, and seems too late for GCC 11. As a workaround, this patch implements enough of realloc(3) to suppress the false positives. This fixes the false positives in PR analyzer/99193. I've filed PR analyzer/99260 to track "properly" implementing realloc(3). gcc/analyzer/ChangeLog: PR analyzer/99193 * region-model-impl-calls.cc (region_model::impl_call_realloc): New. * region-model.cc (region_model::on_call_pre): Call it. * region-model.h (region_model::impl_call_realloc): New decl. * sm-malloc.cc (enum wording): Add WORDING_REALLOCATED. (malloc_state_machine::m_realloc): New field. (use_after_free::describe_state_change): Add case for WORDING_REALLOCATED. (use_after_free::describe_final_event): Likewise. (malloc_state_machine::malloc_state_machine): Initialize m_realloc. (malloc_state_machine::on_stmt): Handle realloc by calling... (malloc_state_machine::on_realloc_call): New. gcc/testsuite/ChangeLog: PR analyzer/99193 * gcc.dg/analyzer/pr99193-1.c: New test. * gcc.dg/analyzer/pr99193-2.c: New test. * gcc.dg/analyzer/pr99193-3.c: New test. * gcc.dg/analyzer/realloc-1.c: New test.
[Bug analyzer/99260] analyzer does not track outcomes of realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a6baafcac5308be1a5d92c0b2a179495b7a24b52 commit r11-7381-ga6baafcac5308be1a5d92c0b2a179495b7a24b52 Author: David Malcolm Date: Wed Feb 24 19:55:40 2021 -0500 analyzer: fix false positive on realloc [PR99193] PR analyzer/99193 describes various false positives from -Wanalyzer-mismatching-deallocation on realloc(3) calls of the form: | 31 | void *p = malloc (1024); | | ^ | | | | | (1) allocated here (expects deallocation with âfreeâ) | 32 | void *q = realloc (p, 4096); | | ~ | | | | | (2) deallocated with âreallocâ here; allocation at (1) expects deallocation with âfreeâ | The underlying issue is that the analyzer has no knowledge of realloc(3), and realloc has awkward semantics. Unfortunately, the analyzer is currently structured so that each call statement can only have at most one successor state; there is no way to "bifurcate" the state, or have N-way splits into multiple outcomes. The existing "on_stmt" code works on a copy of the next state, updating it in place, rather than copying it and making any necessary changes. I did this as an optimization to avoid unnecessary copying of state objects, but it makes it hard to support multiple outcomes. (ideally our state objects would be immutable and thus support trivial copying, alternatively, C++11 move semantics may help here) I attempted a few approaches to implementing bifurcation within the existing state-update framework, but they were messy and thus likely buggy; a proper implementation would rework state-updating to generate copies, but this would be a major change, and seems too late for GCC 11. As a workaround, this patch implements enough of realloc(3) to suppress the false positives. This fixes the false positives in PR analyzer/99193. I've filed PR analyzer/99260 to track "properly" implementing realloc(3). gcc/analyzer/ChangeLog: PR analyzer/99193 * region-model-impl-calls.cc (region_model::impl_call_realloc): New. * region-model.cc (region_model::on_call_pre): Call it. * region-model.h (region_model::impl_call_realloc): New decl. * sm-malloc.cc (enum wording): Add WORDING_REALLOCATED. (malloc_state_machine::m_realloc): New field. (use_after_free::describe_state_change): Add case for WORDING_REALLOCATED. (use_after_free::describe_final_event): Likewise. (malloc_state_machine::malloc_state_machine): Initialize m_realloc. (malloc_state_machine::on_stmt): Handle realloc by calling... (malloc_state_machine::on_realloc_call): New. gcc/testsuite/ChangeLog: PR analyzer/99193 * gcc.dg/analyzer/pr99193-1.c: New test. * gcc.dg/analyzer/pr99193-2.c: New test. * gcc.dg/analyzer/pr99193-3.c: New test. * gcc.dg/analyzer/realloc-1.c: New test.
[Bug libstdc++/99261] [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- I did see the failure, but thought it was due to PR 98384. Fixed now, and with Patrick's r11-7378 it also passes for -mabi=ieeelongdouble
[Bug libstdc++/99261] [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:94bfe81afedb6dbba877ee7c9f047375366f8996 commit r11-7379-g94bfe81afedb6dbba877ee7c9f047375366f8996 Author: Jonathan Wakely Date: Wed Feb 24 22:25:31 2021 + libstdc++: Fix order of arguments to sprintf [PR 99261] libstdc++-v3/ChangeLog: PR libstdc++/99261 * src/c++17/floating_to_chars.cc (sprintf_ld): Add extra args before value to be printed.
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565824.html
[Bug libstdc++/99261] [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261
--- Comment #3 from seurer at gcc dot gnu.org ---
char to_chars_buffer[output_length];
auto result = to_chars(to_chars_buffer,
to_chars_buffer+output_length,
value, fmt, precision);
VERIFY( result.ec == errc{} );
VERIFY( !memcmp(printf_buffer, to_chars_buffer, output_length) );
Dumping out the values of things on the VERIFY that fails I see
output_length: 8
printf_buffer: 1.00
to_chars_buffer: 0???
There is another PR for the long_double test cases but that is something
different unless this fix triggers the other thing.
[Bug other/99261] [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |11.0 --- Comment #2 from Jonathan Wakely --- Huh, no, the failure is new for LE.
[Bug other/99261] [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261 --- Comment #1 from Jonathan Wakely --- Wasn't it already failing?
[Bug other/99261] New: [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99261 Bug ID: 99261 Summary: [11 regression] 20_util/to_chars/long_double.cc fails after r11-7365 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- f90027d18a94d02ba8f3b7503c5f0835f432a89e, r11-7365 make -k check RUNTESTFLAGS="conformance.exp=20_util/to_chars/long_double.cc" FAIL: 20_util/to_chars/long_double.cc execution test # of expected passes1 # of unexpected failures1 /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:171: void test02(): Assertion '!memcmp(printf_buffer, to_chars_buffer, output_length)' failed. FAIL: 20_util/to_chars/long_double.cc execution test
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 --- Comment #7 from David Malcolm --- I'm testing a workaround for this; I've filed bug 99260 to cover other issues with realloc(3) in the analyzer.
[Bug analyzer/99260] New: analyzer does not track outcomes of realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260 Bug ID: 99260 Summary: analyzer does not track outcomes of realloc Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The analyzer currently has no knowledge of the behavior of "realloc" (leading e.g. to bug 99193). For example, it currently fails to issue a warning for the classic "self-assignment realloc" gotcha, code of the form: p = realloc (p, 4096); e.g. void *p = malloc (1024); p = realloc (p, 4096); free (p); which ought to be reported as a leak (for the case where the realloc fails, losing the ptr to the original buffer). Ideally, the analyzer would track various possible outcomes of realloc: - buffer grew successfully in-place - buffer was successfully moved to a larger allocation - buffer was successfully contracted - realloc failed, returning NULL, without freeing existing buffer. or simply: - success: non-NULL is returned - failure: NULL is returned, existing buffer is not freed. Unfortunately, the analyzer is currently structured so that each call statement can only have at most one successor state; there is no way to "bifurcate" the state, or have N-way splits into multiple outcomes. The existing "on_stmt" code works on a copy of the next state, updating it in place, rather than copying it and making any necessary changes. I did this as an optimization to avoid unnecessary copying of state objects, but it makes it hard to support multiple outcomes. (ideally our state objects would be immutable and thus support trivial copying, alternatively, C++11 move semantics may help here)
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- a13be187cb2 2021-02-24 | c++: modules & -fpreprocessed [PR 99072]
[Bug inline-asm/99259] aarch64 inline asm: miscompilation depending on function parameters order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99259 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- v0 wasn't used for x and y, but for acc and x. As you said, when acc is both input and output, you need +w or "=w" (acc) . "0" (acc), but even if it was output only and couldn't clash with x or y, you'd need early-clobber - "=" which would make sure that the input operands get different registers from that output one.
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718 --- Comment #3 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:f207eed69e2421695e240aaf47bf881c09cbdd8a commit r11-7377-gf207eed69e2421695e240aaf47bf881c09cbdd8a Author: Nathan Sidwell Date: Wed Feb 24 12:32:23 2021 -0800 c++: Macro location fixes [PR 98718] This fixes some issues with macro maps. We were incorrectly calculating the number of macro expansions in a location span, and I had a workaround that partially covered that up. Further, while macro location spans are monotonic, that is not true of ordinary location spans. Thus we need to insert an indirection array when binary searching the latter. (We load ordinary locations before loading imports, but macro locations afterwards. We make sure an import location is de-macrofied, if needed.) PR c++/98718 gcc/cp/ * module.cc (ool): New indirection vector. (loc_spans::maybe_propagate): Location is not optional. (loc_spans::open): Likewise. Assert monotonically advancing. (module_for_ordinary_loc): Use ool indirection vector. (module_state::write_prepare_maps): Do not count empty macro expansions. Elide empty spans. (module_state::write_macro_maps): Skip empty expansions. (ool_cmp): New qsort comparator. (module_state::write): Create and destroy ool vector. (name_pending_imports): Fix dump push/pop. (preprocess_module): Likewise. Add more dumping. (preprocessed_module): Likewise. libcpp/ * include/line-map.h * line-map.c gcc/testsuite/ * g++.dg/modules/pr98718_a.C: New. * g++.dg/modules/pr98718_b.C: New.
[Bug inline-asm/99259] aarch64 inline asm: miscompilation depending on function parameters order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99259 Benoit Jacob changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Benoit Jacob --- Sorry, as Craig mentioned on the LLVM bug, I had the wrong constraint (=w instead of +w).
[Bug inline-asm/99259] New: aarch64 inline asm: miscompilation depending on function parameters order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99259
Bug ID: 99259
Summary: aarch64 inline asm: miscompilation depending on
function parameters order
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jacob.benoit.1 at gmail dot com
Target Milestone: ---
compiler explorer link: https://godbolt.org/z/9oE5Ta
Note: Clang has the same bug: https://bugs.llvm.org/show_bug.cgi?id=49343
code:
#include
// output:
// smlal v0.4s, v1.4h, v2.4h
int32x4_t good(int32x4_t acc, int16x4_t x, int16x4_t y) {
asm("smlal %[acc].4s, %[x].4h, %[y].4h"
: [acc]"=w"(acc)
: [x]"w"(x),
[y]"w"(y)
:);
return acc;
}
// output:
// smlal v0.4s, v0.4h, v1.4h
// bug: v0 is used for both x and y arguments!
int32x4_t bad(int16x4_t x, int16x4_t y, int32x4_t acc) {
asm("smlal %[acc].4s, %[x].4h, %[y].4h"
: [acc]"=w"(acc)
: [x]"w"(x),
[y]"w"(y)
:);
return acc;
}
[Bug c++/99170] [modules] ICE in get_merge_kind with std::string NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99170
--- Comment #2 from Nathan Sidwell ---
Thanks for checking this didn't seem a duplicate!
Reduced tescase:
// 99170_a.H
namespace STD {
class string {
public:
template
string (const T *);
};
}
// 99170_b.C
export module test;
import "99170_a.H";
export class A {
STD::string str{"ayyy"};
};
./cc1plus -fmodule-header -quiet -std=c++17 99170_a.H && ./cc1plus -fmodules-ts
-quiet -std=c++17 99170_b.C
99170_b.C:1:8: internal compiler error: in get_merge_kind, at
cp/module.cc:10169
1 | export module test;
|^~
0xcc98a8 trees_out::get_merge_kind(tree_node*, depset*)
../../../src/gcc/cp/module.cc:10169
0xcbd290 trees_out::decl_value(tree_node*, depset*)
../../../src/gcc/cp/module.cc:7629
0xcc2b15 trees_out::decl_node(tree_node*, walk_kind)
../../../src/gcc/cp/module.cc:8624
0xcc507f trees_out::tree_node(tree_node*)
[Bug libgcc/99236] Undefined behaviour in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed in GCC 11, IMHO not worth backporting.
[Bug fortran/99226] [11 Regression] ICE in expand_expr_real_1, at expr.c:10279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99226
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9d2a69106beb346be1c511a9c1a61a256b697868
commit r11-7375-g9d2a69106beb346be1c511a9c1a61a256b697868
Author: Jakub Jelinek
Date: Wed Feb 24 20:11:11 2021 +0100
openmp: Diagnose invalid teams nested in target construct [PR99226]
The OpenMP standard says:
"A teams region can only be strictly nested within the implicit parallel
region
or a target region. If a teams construct is nested within a target
construct,
that target construct must contain no statements, declarations or
directives
outside of the teams construct."
We weren't diagnosing that restriction, because we need to allow e.g.
#pragma omp target
{{
#pragma omp teams
;
}}
and as target doesn't need to have teams nested in it, using some special
parser of the target body didn't feel right. And after the parsing,
the question is if e.g. already parsing of the clauses doesn't add some
statements before the teams statement (gimplification certainly will).
As we now have a bugreport where we ICE on the invalid code, this just
diagnoses a subset of the invalid programs, in particular those where
nest to the teams strictly nested in targets the target region contains
some other OpenMP construct.
2021-02-24 Jakub Jelinek
PR fortran/99226
* omp-low.c (struct omp_context): Add teams_nested_p and
nonteams_nested_p members.
(scan_omp_target): Diagnose teams nested inside of target with
other
directives strictly nested inside of the same target.
(check_omp_nesting_restrictions): Set ctx->teams_nested_p or
ctx->nonteams_nested_p as needed.
* c-c++-common/gomp/pr99226.c: New test.
* gfortran.dg/gomp/pr99226.f90: New test.
[Bug libgcc/99236] Undefined behaviour in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:35da095d7e0614235cb0e241685c5e1a240dc882 commit r11-7374-g35da095d7e0614235cb0e241685c5e1a240dc882 Author: Jakub Jelinek Date: Wed Feb 24 20:07:38 2021 +0100 libgcc: Avoid signed negation overflow in __powi?f2 [PR99236] When these functions are called with integer minimum, there is UB on the libgcc side. Fixed in the obvious way, the code in the end wants ABSU_EXPR behavior. 2021-02-24 Jakub Jelinek PR libgcc/99236 * libgcc2.c (__powisf2, __powidf2, __powitf2, __powixf2): Perform negation of m in unsigned type.
[Bug c++/99170] [modules] ICE in get_merge_kind with std::string NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99170 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-02-24
[Bug tree-optimization/99258] volatile struct access optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99258 --- Comment #1 from Andrew Pinski --- Related to PR 47409 and PR 84699.
[Bug inline-asm/99123] [8/9/10/11 Regression] ICE in decompose_normal_address, at rtlanal.c:6710
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99123 --- Comment #3 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:b6680c2084521d2612c3a08aa01b274078c4f3e3 commit r11-7373-gb6680c2084521d2612c3a08aa01b274078c4f3e3 Author: Vladimir N. Makarov Date: Wed Feb 24 13:54:10 2021 -0500 [PR99123] inline-asm: Don't use decompose_mem_address to find used hard regs Inline asm in question has empty constraint which means anything including memory with invalid address. To check used hard regs we used decompose_mem_address which assumes memory with valid address. The patch implements the same semantics without assuming valid addresses. gcc/ChangeLog: PR inline-asm/99123 * lra-constraints.c (uses_hard_regs_p): Don't use decompose_mem_address. gcc/testsuite/ChangeLog: PR inline-asm/99123 * gcc.target/i386/pr99123.c: New.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #10 from Jonathan Wakely --- (In reply to ctice from comment #7) > I thought I was maintaining it too! :-) OK, thanks. I guess I mistook "doesn't need much work" for "unmaintained".
[Bug tree-optimization/99258] New: volatile struct access optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99258
Bug ID: 99258
Summary: volatile struct access optimized away
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: borysp at invisiblethingslab dot com
Target Milestone: ---
Access to a volatile struct is optimized away, if the size of the struct is
>16B (at least on x64 cpu with sse). Small repro:
[borys@mowmiwuju test]$ cat a.c
struct A {
long a;
long b;
};
struct B {
long a;
long b;
long c;
};
void f(volatile struct A* x) {
*x;
}
void g(volatile struct B* x) {
*x;
}
[borys@mowmiwuju test]$ gcc --version
gcc (GCC) 10.2.0
[borys@mowmiwuju test]$ gcc -Wall -Wextra -std=c11 -O2 -c a.c
[borys@mowmiwuju test]$ objdump -d -Mintel a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
:
0: f3 0f 6f 07 movdqu xmm0,XMMWORD PTR [rdi]
4: c3 ret
5: 66 66 2e 0f 1f 84 00data16 cs nop WORD PTR [rax+rax*1+0x0]
c: 00 00 00 00
0010 :
10: c3 ret
Testing on https://godbolt.org/ indicates this issue is present in all gcc
versions. clang emits correct code for this test case.
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Martin Sebor changed: What|Removed |Added Depends on||74762 --- Comment #2 from Martin Sebor --- The reason why there's no warning for cl3::g() is because the result of the cast is not dereferenced in the same expression (the -Wnonnull warning is issued for the call, and the call is in the next statement). The reason why there's no warning for the parenthesized cast in cl3::h() is due to pr74762: the C++ front end sets the no-warning bit on the parenthesized expression. The warning sees this IL: cl2::h (((struct cl3 *) this)->p != 0B ? (struct cl2 *) __dynamic_cast (this->p, &_ZTI3cl1, &_ZTI3cl2, 0) : 0B) where both the COND_EXPR (?:) and the NE_EXPR (!=) have the no-warning bit set and the warning code uses the first bit to suppress it. The reason why there is a warning for cl3::i() is because the no-warning bit is set only on the NE_EXPR and not on the COND_EXPR as above, and the warning code only tests the latter. Finally, the reason why the warning is not issued for a similar static_cast (where the argument has to be checked for equality to null in order for the result to stay null) is because of the fix for pr96003 that set the no-warning bit even on the COND_EXPR but didn't make the corresponding change in ifnonnull() in cp/rtti.c. What a mess. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 [Bug 74762] [8/9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
[Bug fortran/99257] New: ICE in build_field, at fortran/trans-common.c:303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99257 Bug ID: 99257 Summary: ICE in build_field, at fortran/trans-common.c:303 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Presumably valid code, affects versions down to at least r5. In module m2 variable a is visible, b and c are not. $ cat z1.f90 module m integer :: a = 1 integer :: b = 2 integer :: c equivalence (b, c) end module m2 use m, only : a contains subroutine b end end $ cat z2.f90 module m private integer, public :: a = 1 integer :: b = 2 integer :: c equivalence (b, c) end module m2 use m contains subroutine b end end $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: Segmentation fault 0xda031f crash_signal ../../gcc/toplev.c:327 0xa1b95b contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3462 0xa1b95b size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*) ../../gcc/fold-const.c:1900 0x793cea build_field ../../gcc/fortran/trans-common.c:303 0x793cea create_common ../../gcc/fortran/trans-common.c:669 0x796387 finish_equivalences ../../gcc/fortran/trans-common.c:1349 0x796387 gfc_trans_common(gfc_namespace*) ../../gcc/fortran/trans-common.c:1386 0x7a92d7 gfc_generate_module_vars(gfc_namespace*) ../../gcc/fortran/trans-decl.c:5835 0x776bf1 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2296 0x720821 translate_all_program_units ../../gcc/fortran/parse.c:6338 0x720821 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x76dbcf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99256] New: ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256 Bug ID: 99256 Summary: ICE in variable_check, at fortran/check.c:1012 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p call move_alloc (*1, *1) 1 stop end $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc060ef crash_signal ../../gcc/toplev.c:327 0x6551b4 variable_check ../../gcc/fortran/check.c:1012 0x65c328 gfc_check_move_alloc(gfc_expr*, gfc_expr*) ../../gcc/fortran/check.c:4213 0x6a420c do_check ../../gcc/fortran/intrinsic.c:5129 0x6a420c gfc_intrinsic_sub_interface(gfc_code*, int) ../../gcc/fortran/intrinsic.c:5124 0x6fb649 resolve_unknown_s ../../gcc/fortran/resolve.c:3621 0x6fb649 resolve_call ../../gcc/fortran/resolve.c:3737 0x6f84dc gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12032 0x6fa9a7 resolve_codes ../../gcc/fortran/resolve.c:17378 0x6faa6e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17413 0x6e2fb4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e2fb4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x72f98f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99255] New: ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 Bug ID: 99255 Summary: ICE in gfc_dt_upper_string, at fortran/module.c:441 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5, with a missing attribute allocatable or pointer : (follow-up of pr95980) $ cat z1.f90 program p type t character(:), allocatable :: c end type class(t) :: x select type (y => x) end select end $ cat z2.f90 program p type t character(:), allocatable :: c(:) end type class(t) :: x select type (y => x) end select end $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: Segmentation fault 0xda031f crash_signal ../../gcc/toplev.c:327 0x6fecd0 gfc_dt_upper_string(char const*) ../../gcc/fortran/module.c:441 0x69e74a get_unique_type_string ../../gcc/fortran/class.c:490 0x69f191 get_unique_hashed_string ../../gcc/fortran/class.c:524 0x6a2678 gfc_build_class_symbol(gfc_typespec*, symbol_attribute*, gfc_array_spec**) ../../gcc/fortran/class.c:672 0x6f9393 gfc_match_select_type() ../../gcc/fortran/match.c:6449 0x719244 match_word ../../gcc/fortran/parse.c:65 0x719244 decode_statement ../../gcc/fortran/parse.c:428 0x71aa7c next_free ../../gcc/fortran/parse.c:1316 0x71aa7c next_statement ../../gcc/fortran/parse.c:1548 0x71c0eb parse_spec ../../gcc/fortran/parse.c:3967 0x71eebc parse_progunit ../../gcc/fortran/parse.c:5896 0x7205b1 gfc_parse_file() ../../gcc/fortran/parse.c:6437 0x76dbcf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99254] ICE in select_rank_set_tmp, at fortran/match.c:6568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99254 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Following z3 is correct, z2 is detected : $ cat z2.f90 subroutine s class(*), allocatable :: x(..) select rank (y => x) rank (1) end select end $ cat z3.f90 subroutine s(x) class(*) :: x(..) select rank (y => x) rank (1) end select end $ gfortran-11-20210221 -c z3.f90 $ gfortran-11-20210221 -c z2.f90 z2.f90:2:33: 2 |class(*), allocatable :: x(..) | 1 Error: Assumed-rank array at (1) must be a dummy argument
[Bug fortran/99254] New: ICE in select_rank_set_tmp, at fortran/match.c:6568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99254 Bug ID: 99254 Summary: ICE in select_rank_set_tmp, at fortran/match.c:6568 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20190825 and 20190901, affects r10/r11 : $ cat z1.f90 subroutine s class(*) :: x(..) select rank (y => x) rank (1) end select end $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: Segmentation fault 0xda031f crash_signal ../../gcc/toplev.c:327 0x6fa137 select_rank_set_tmp ../../gcc/fortran/match.c:6568 0x6fa137 gfc_match_rank_is() ../../gcc/fortran/match.c:7076 0x715ac1 match_word ../../gcc/fortran/parse.c:65 0x71a562 decode_statement ../../gcc/fortran/parse.c:550 0x71aa7c next_free ../../gcc/fortran/parse.c:1316 0x71aa7c next_statement ../../gcc/fortran/parse.c:1548 0x71dbee parse_select_rank_block ../../gcc/fortran/parse.c:4421 0x71dbee parse_executable ../../gcc/fortran/parse.c:5540 0x71ef5f parse_progunit ../../gcc/fortran/parse.c:5922 0x720960 gfc_parse_file() ../../gcc/fortran/parse.c:6444 0x76dbcf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #19 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:70aa0e6eef9d65744f37adc2a3cffef1a8217dc1 commit r11-7367-g70aa0e6eef9d65744f37adc2a3cffef1a8217dc1 Author: Patrick Palka Date: Wed Feb 24 12:24:43 2021 -0500 libstdc++: Robustify long double std::to_chars testcase [PR98384] The long double std::to_chars testcase currently verifies the correctness of its output by comparing it to that of printf, so if there's a mismatch between to_chars and printf, the test FAILs. This works well for the scientific, fixed and general formatting modes, because the corresponding printf conversion specifiers (%e, %f and %g) are rigidly specified. But this doesn't work well for the hex formatting mode because the corresponding printf conversion specifier %a is more flexibly specified. For instance, the hexadecimal forms 0x1p+0, 0x2p-1, 0x4p-2 and 0x8p-3 are all equivalent and valid outputs of the %a specifier for the number 1. The apparent freedom here is the choice of leading hex digit -- the standard just requires that the leading hex digit is nonzero for normalized numbers. Currently, our hexadecimal formatting implementation uses 0/1/2 as the leading hex digit for floating point types that have an implicit leading mantissa bit which in practice means all supported floating point types except x86 long double. The latter type has a 64 bit mantissa with an explicit leading mantissa bit, and for this type our implementation uses the most significant four bits of the mantissa as leading hex digit. This seems to be consistent with most printf implementations, but not all, as PR98384 illustrates. In order to avoid false-positive FAILs due to arbitrary disagreement between to_chars and printf about the choice of leading hex digit, this patch makes the testcase's verification via printf conditional on the leading hex digits first agreeing. An additional verification step is also added: round-tripping the output of to_chars through from_chars should recover the value exactly. libstdc++-v3/ChangeLog: PR libstdc++/98384 * testsuite/20_util/to_chars/long_double.cc: Include . (test01): Simplify verifying the nearby values by using a 2-iteration loop and a dedicated output buffer to check that the nearby values are different. Factor out the printf-based verification into a local function, and check that the leading hex digits agree before comparing to the output of printf. Also verify the output by round-tripping it through from_chars.
[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072 Nathan Sidwell changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nathan Sidwell --- a13be187cb2 2021-02-24 | c++: modules & -fpreprocessed [PR 99072]
[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072 --- Comment #6 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:a13be187cb2987db851b3f096f5319d5fe3a7301 commit r11-7366-ga13be187cb2987db851b3f096f5319d5fe3a7301 Author: Nathan Sidwell Date: Wed Feb 24 05:50:12 2021 -0800 c++: modules & -fpreprocessed [PR 99072] When we read preprocessed source, we deal with a couple of special location lines at the start of the file. These provide information about the original filename of the source and the current directory, so we can process the source in the same manner. When updating that code, I had a somewhat philosophical question: Should the line table contain evidence of the filename the user provided to the compiler? I figured to leave it there, as it did no harm. But this defect shows an issue. It's in the line table and our (non optimizing) line table serializer emits that filename. Which means if one re-preprocesses the original source to a differently-named intermediate file, the resultant CMI is different. Boo. That's a difference that doesn't matter, except the CRC matching then fails. We should elide the filename, so that one can preprocess to mktemp intermediate filenames for whatever reason. This patch takes the approach of expunging it from the line table -- so the line table will end up with exactly the same form. That seems a better bet than trying to fix up mismatching line tables in CMI emission. PR c++/99072 libcpp/ * init.c (read_original_filename): Expunge all evidence of the original filename. gcc/testsuite/ * g++.dg/modules/pr99072.H: New.
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251 Martin Sebor changed: What|Removed |Added Blocks||95507 Last reconfirmed||2021-02-24 Keywords||diagnostic Summary|Strange -Wnonnull warning |[11 Regression] |behaviour with dynamic_cast |inconsistent -Wnonnull ||warning behaviour with ||dynamic_cast Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- We discussed this instance of the warning in pr98646 and decided that even though issuing it for an access to the result of dynamic_cast was strictly a false positive when the operand was guaranteed to be nonnull by a prior test, the workaround to cast to a reference rather than a pointer was simple enough and made the intent clearer: return dynamic_cast(*p).i(); But the inconsistency exhibited in this test case is not a good thing (enclosing the cast in parentheses certainly shouldn't make a difference) and suggests the decision should be revisited. The warning for the dynamic_cast should either be issued consistently or not at all. Let me look into it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #9 from ctice at gcc dot gnu.org --- I will work on fixing that.
[Bug tree-optimization/99253] New: tree-vect-loop wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
Bug ID: 99253
Summary: tree-vect-loop wrong code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390x, x86_64-*-*
int a = 0;
static int b = 0;
long c = 0;
int
main() {
for (int d = 0; d < 8; d++) {
a ^= c;
b = a;
a ^= 1;
}
if (b != 1)
__builtin_abort();
return 0;
}
Aborts when built with:
gcc -O3 t.c
Bisection stops at commit 04bff1bbfc11a974342c0eb0c0d65d902e36e82e on IBM Z and
at commit b7ff7cef5005721e78d6936bed3ae1c059b4e8d2 on x86 ¯\_(ツ)_/¯
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed now.
[Bug target/99252] SVE: ICE in maybe_legitimize_operand with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99252 ktkachov at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||10.2.1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-24 CC||ktkachov at gcc dot gnu.org Target Milestone|--- |10.3 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f90027d18a94d02ba8f3b7503c5f0835f432a89e commit r11-7365-gf90027d18a94d02ba8f3b7503c5f0835f432a89e Author: Jonathan Wakely Date: Fri Feb 19 13:36:41 2021 + libstdc++: Define std::to_chars overloads for __ieee128 [PR 98389] This adds overloads of std::to_chars for powerpc64's __ieee128, so that std::to_chars can be used for long double when -mabi=ieeelongdouble is in used. Eventually we'll want to extend these new overloads to work for __float128 on all targets that support that type. For now, we're only doing it for powerpc64 when the new long double type is supported in parallel to the old long double type. Additionally the existing std::to_chars overloads for long double are given the right symbol version, resolving PR libstdc++/98389. libstdc++-v3/ChangeLog: PR libstdc++/98389 * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Do not match to_chars symbols for long double arguments mangled as 'g'. * config/os/gnu-linux/ldbl-extra.ver: Likewise. * config/os/gnu-linux/ldbl-ieee128-extra.ver: Likewise. * src/c++17/Makefile.am [GLIBCXX_LDBL_ALT128_COMPAT_TRUE]: Use -mabi=ibmlongdouble for floating_to_chars.cc. * src/c++17/Makefile.in: Regenerate. * src/c++17/floating_to_chars.cc (floating_type_traits_binary128): New type defining type traits of IEEE binary128 format. (floating_type_traits<__float128>): Define specialization. (floating_type_traits): Define in terms of floating_type_traits_binary128 when appropriate. (floating_to_shortest_scientific): Handle __float128. (sprintf_ld): New function template for printing a long double or __ieee128 value using sprintf. (__floating_to_chars_shortest, __floating_to_chars_precision): Use sprintf_ld. (to_chars): Define overloads for __float128.
[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- On x86_64-linux I can reproduce the *.gimple dump discrepancies with -O2 -fcompare-debug --param logical-op-non-short-circuit=0 diff -up pr83527.c.006t.gimple pr83527.gk.c.006t.gimple --- pr83527.c.006t.gimple 2021-02-24 17:56:57.066963901 +0100 +++ pr83527.gk.c.006t.gimple2021-02-24 17:56:57.536958750 +0100 @@ -3,23 +3,31 @@ void fn1 () int c; short int d; + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT a.0_1 = a; switch (a.0_1) , case 32769: , case 32771: , case 32772: , case 32782: , case 32800: > : + # DEBUG BEGIN_STMT fn2 (); : + # DEBUG BEGIN_STMT b = 0; : : : + # DEBUG BEGIN_STMT fn3 (); : - if (d != 0) goto ; else goto ; - : - if (c != 0) goto ; else goto ; + # DEBUG BEGIN_STMT + if (d != 0) goto ; else goto ; : - : + if (c != 0) goto ; else goto ; : + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT + : } which looks to me incorrect. Without that param, diff -up pr83527.c.006t.gimple pr83527.gk.c.006t.gimple --- pr83527.c.006t.gimple 2021-02-24 17:58:39.484841634 +0100 +++ pr83527.gk.c.006t.gimple2021-02-24 17:58:39.967836342 +0100 @@ -3,22 +3,31 @@ void fn1 () int c; short int d; + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT a.0_1 = a; switch (a.0_1) , case 32769: , case 32771: , case 32772: , case 32782: , case 32800: > : + # DEBUG BEGIN_STMT fn2 (); : + # DEBUG BEGIN_STMT b = 0; : : : + # DEBUG BEGIN_STMT fn3 (); : + # DEBUG BEGIN_STMT _2 = d != 0; _3 = c != 0; _4 = _2 | _3; if (_4 != 0) goto ; else goto ; : + # DEBUG BEGIN_STMT + # DEBUG BEGIN_STMT : } looks good. But probably cris and x86_64 has different cswitch lowering later.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #8 from gcc-user at riseup dot net --- > Is there something here that you want/need me to take care of? If you can make it so that -lvtv is never passed to libtool so that slibtool will also work with --enable-vtable-verify as described in this issue it would be very much appreciated.
[Bug target/99252] New: SVE: ICE in maybe_legitimize_operand with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99252
Bug ID: 99252
Summary: SVE: ICE in maybe_legitimize_operand with LTO
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Presumably related to PR99216 since we fail to compile a simpler call to svaddv
with LTO there (although we're ICEing in a different place).
$ cat test.cc
#include
int main() {
return svaddv(svptrue_b8(), svadd_z(svptrue_b8(), svdup_s64(0),
svdup_s64(0)));
}
$ aarch64-linux-gnu-gcc -march=armv8.2-a+sve -flto test.cc
during RTL pass: expand
test.cc: In function ‘main’:
test.cc:3:16: internal compiler error: in maybe_legitimize_operand, at
optabs.c:7622
3 | return svaddv(svptrue_b8(), svadd_z(svptrue_b8(), svdup_s64(0),
svdup_s64(0)));
|^
0xb855b3 maybe_legitimize_operand
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7621
0xb855b3 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7758
0xb85926 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:
0xb85b42 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7820
0xb850d9 expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7851
0x1194a47 aarch64_sve::function_expander::generate_insn(insn_code)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:2883
0x11953e1 aarch64_sve::function_expander::use_exact_insn(insn_code)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3031
0x1196101 aarch64_sve::function_expander::expand()
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3318
0x1197242 aarch64_sve::expand_builtin(unsigned int, tree_node*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:3607
0x10f62eb aarch64_expand_builtin
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:13568
0x74b79a expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/builtins.c:9518
0x8c51cc expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:11276
0x8c6779 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:8513
0x8cfc1c store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5886
0x8d1927 expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5622
0x780d7c expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:2838
0x780d7c expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3844
0x780d7c expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4008
0x78a5a7 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6045
0x78bc61 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #18 from Patrick Palka ---
FWIW, here's a complete corrected version of the Solaris test in comment #13
which should be fully free of warnings:
#include
int main() {
printf("%La\n", 1.0L); // trailing zeros present (not nonconforming, but
unexpected by the libstdc++ testcase)
printf("%.1000Lf\n", 1.0L); // output contains e+00 (nonconforming?)
printf("%Lf\n", 1e1000L); // output is in scientific notation
(nonconforming?)
}
(In reply to Iain Sandoe from comment #17)
> (In reply to Patrick Palka from comment #16)
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > > > --- Comment #13 from Patrick Palka ---
>
> [..]
> > > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> > > be omitted".
> >
> > Ack.
>
> Darwin also produces the trailing zeros.
>
> For the #c13 test with Jakub's correction (x86_64-darwin16):
>
> 0x8p-3
Thanks. Trailing zeros in the second line of output are expected (and
required). It's the hex form (on the first line of output) that the libstdc++
testcase doesn't expect to contain trailing zeros, so I don't anticipate any
issues with printf on Darwin. So my hope is that the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html resolves
the long_double.cc FAIL on 64-bit Darwin as well.
[Bug fortran/95868] Derived-type deferred-length character component handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868 --- Comment #3 from Tobias Burnus --- The patch of comment 0 re-appeared in slightly different flavor for PR99125 (https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565768.html); thus, that part is now fixed. Still, the tests in the testcase still fail as before. (Except: sub2 fails with '4' not '1' (typo) and '(2)' does not segfault at run time (at the moment) but just fails with 'stop 4'.)
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 ctice at gcc dot gnu.org changed: What|Removed |Added CC||ctice at gcc dot gnu.org --- Comment #7 from ctice at gcc dot gnu.org --- I thought I was maintaining it too! :-) Is there something here that you want/need me to take care of?
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #17 from Iain Sandoe --- (In reply to Patrick Palka from comment #16) > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > > > --- Comment #13 from Patrick Palka --- [..] > > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may > > be omitted". > > Ack. Darwin also produces the trailing zeros. For the #c13 test with Jakub's correction (x86_64-darwin16): 0x8p-3 1. 52125389249491778072998734723901065658344854339911180645920036689145962141728255198944006625782458697361398052188320725945500187466736263651898402197281418601194861141374063921039465940694425297734391186956329793278702145800491525011614855026496394750516638651904325014181425162549141603722458358502273813778558432028264124895510532783859455600293977100020266523133500964588581678409272735947471110282714656752958320295462700796860257717072319132149129951852089814871685652019158129352457876413077731822944690893023783688156197557228348257706445069058168217860984489364449216192153697464386313372616125802493006313011849107453714600675828600445923171763793130115636080004121099460216359522049035859262314715833943305021976057857853126510419437495501816388939228067001371011547274042754738463678560481977277814562542528910043287233881513857018892008936293030725951345023187328378120620598203530289119602404678381135515657024501288339144721058539176378789830725427845326462393386911535328986994985182586470400.00
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #5 from Vadim Zeitlin --- > Works fine on x86_64-linux. Yes, I mentioned this :-/ > Can you attach preprocessed source (most developers don't have access to > Windows) If you can install MinGW cross-compiler and Wine, you don't need Windows to reproduce this, but here is the (compressed, as it's unfortunately quite big after the standard headers expansion) preprocessed output. > and -fdump-tree-optimized dump Also attached. > and assembly you get? Attached too. The register I mentioned in the original message is xmm6. Thanks for looking at this!
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #4 from Vadim Zeitlin --- Created attachment 50252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50252=edit Assembly output (-S)
[Bug c++/99251] New: Strange -Wnonnull warning behaviour with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251
Bug ID: 99251
Summary: Strange -Wnonnull warning behaviour with dynamic_cast
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
With this testcase:
class cl1 {
virtual void m();
};
class cl2 : public cl1 {
public:
int g();
int h();
int i();
};
class cl3 {
cl1 *p;
int g();
int h();
int i();
};
int cl3::g() {
if (!p)
return 0;
cl2 *x = dynamic_cast(p);
return x->g();
}
int cl3::h() {
if (!p)
return 0;
return (dynamic_cast(p))->h();
}
int cl3::i() {
if (!p)
return 0;
return dynamic_cast(p)->i();
}
compiled with g++-trunk@r11-7356 -Wnonnull this warning is issued:
testcase.cpp: In member function 'int cl3::i()':
testcase.cpp:30:36: warning: 'this' pointer is null [-Wnonnull]
30 | return dynamic_cast(p)->i();
|^
testcase.cpp:8:7: note: in a call to non-static member function 'int cl2::i()'
8 | int i();
| ^
I believe there should be no warning for cl3::i() like with g++-10.2.
[Bug libstdc++/87193] symbols in have inconsistent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193 Jonathan Wakely changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 91480 has been marked as a duplicate of this bug. ***
[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Jonathan Wakely --- There's already a bug about the int vs long definitions. *** This bug has been marked as a duplicate of bug 87193 ***
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #3 from Vadim Zeitlin --- Created attachment 50251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50251=edit File created by -fdump-tree-optimized
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #2 from Vadim Zeitlin --- Created attachment 50250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50250=edit Compressed output of the preprocessor (-E)
[Bug libstdc++/86934] Feature test macros in should respect _GLIBCXX_HOSTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.4 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- I think this is fixed since r277849 for gcc-10.1 and has been backported to the gcc-9 branch.
[Bug fortran/97977] Fortran deferred length strings incompatible with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97977 Tobias Burnus changed: What|Removed |Added Depends on||97084 --- Comment #3 from Tobias Burnus --- Found the other issue: PR97084 – I did not check whether they are identical or only closely related, though. Hence, I mark them as depends on. Additionally, the different subject lines makes it easier to find either. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97084 [Bug 97084] Openmp + Allocatable String Crashes
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #16 from Patrick Palka ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from Patrick Palka ---
> [...]
> > So:
> >
> > 1. The hex-form conversion specifier doesn't trim trailing zeroes.
>
> Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> be omitted".
Ack.
>
> > 2. The fixed-form conversion specifier sometimes outputs the
> > scientific-notation suffix "e+00".
>
> This is unexpected indeed.
>
> > 3. The fixed-form conversion specifier sometimes outputs the scientific
> > form.
>
> Same. However, g++ -Wall complains:
>
> pr98384.cc: In function ‘int main()’:
> pr98384.cc:5:13: warning: unknown conversion type character ‘.’ in format
> [-Wformat=]
> 5 | printf("%L.1000f\n", 1.0L);
> | ^
> pr98384.cc:5:10: warning: too many arguments for format [-Wformat-extra-args]
> 5 | printf("%L.1000f\n", 1.0L);
> | ^~~~
Whoops, that line should say printf("%.1000Lf\n", 1.0L) as Jakub pointed out.
With that change the testcase in #c13 should be valid, and the unexpected
"e+00" suffix is still present in the output.
>
> Compiling the equivalent C version with Studio 12.6 cc gives:
>
> "pr98384.c", line 6: warning: conversion of hex floating-point constant
> cannot be represented exactly in its evaluation format
>
> > Each of the to_chars/printf mismatches I've looked at seem to be caused by
> > one
> > of these three issues. Should we just XFAIL the test on Solaris?
>
> Only if it's clear that those outputs are in violation of the standard
> and the inputs are valid: the warnings above cast some doubt upon the
> latter.
It seems the second and third issue alone make the printf implementation
nonconforming (but not the first issue as you pointed out). Ideally the
libstdc++ testcase ought to not assume the 'a' printf specifier trims trailing
zeros, but even with that fixed it seems we still might have to XFAIL on
Solaris due to the second and third issue?
(In reply to Jakub Jelinek from comment #15)
> printf("%L.1000f\n", 1.0L);
>
> The length modifier needs to come after precision, not before it, so
> you should be using
> printf("%.1000Lf\n", 1.0L);
> instead.
> But the test nor libstdc++ itself doesn't do that, does it?
Fortunately not, I just messed up transforming 'print("%.*Lf", 1000, ...)' into
'printf("%.1000Lf", ...)' inline in the #c13 testcase :)
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Christophe Lyon --- Now fixed on trunk and gcc-10. Thanks for the report & patch.
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:fcfd5cc0f428262fcce874a4c3b41e06d1296901 commit r10-9388-gfcfd5cc0f428262fcce874a4c3b41e06d1296901 Author: Christophe Lyon Date: Wed Feb 24 15:51:52 2021 + arm: Fix CMSE support detection in libgcc (PR target/99157) As discussed in the PR, the Makefile fragment lacks a double '$' to get the return-code from GCC invocation, resulting is CMSE support missing from multilibs. I checked that the simple patch proposed in the PR fixes the problem. 2021-02-23 Christophe Lyon Hau Hsu PR target/99157 libgcc/ * config/arm/t-arm: Fix cmse support detection. (cherry picked from commit be30dd89926d5dd19d72f90c1586b0e2557fde43)
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #5 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:5159b88ef1a1774ec8851c6b92794ae2bf6e0b74 commit r11-7362-g5159b88ef1a1774ec8851c6b92794ae2bf6e0b74 Author: Paul Thomas Date: Wed Feb 24 16:00:51 2021 + Fortran: Fix memory problems with assumed rank formal args [PR98342]. 2021-02-24 Paul Thomas gcc/fortran PR fortran/98342 * trans-expr.c (gfc_conv_derived_to_class): Add optional arg. 'derived_array' to hold the fixed, parmse expr in the case of assumed rank formal arguments. Deal with optional arguments. (gfc_conv_procedure_call): Null 'derived' array for each actual argument. Add its address to the call to gfc_conv_derived_to_ class. Access the 'data' field of scalar descriptors before deallocating allocatable components. Also strip NOPs before the calls to gfc_deallocate_alloc_comp. Use 'derived' array as the input to gfc_deallocate_alloc_comp if it is available. * trans.h : Include the optional argument 'derived_array' to the prototype of gfc_conv_derived_to_class. The default value is NULL_TREE. gcc/testsuite/ PR fortran/98342 * gfortran.dg/assumed_rank_21.f90 : New test.
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #35 from Martin Sebor --- r11-7360 clears the bounds in the arg spec attribute. Hopefully this is the last fix.
[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157 --- Comment #6 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:be30dd89926d5dd19d72f90c1586b0e2557fde43 commit r11-7361-gbe30dd89926d5dd19d72f90c1586b0e2557fde43 Author: Christophe Lyon Date: Wed Feb 24 15:51:52 2021 + arm: Fix CMSE support detection in libgcc (PR target/99157) As discussed in the PR, the Makefile fragment lacks a double '$' to get the return-code from GCC invocation, resulting is CMSE support missing from multilibs. I checked that the simple patch proposed in the PR fixes the problem. 2021-02-23 Christophe Lyon Hau Hsu PR target/99157 libgcc/ * config/arm/t-arm: Fix cmse support detection.
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #34 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:ea5a82df9ba0c9d23e386290d24fc920968a8695 commit r11-7360-gea5a82df9ba0c9d23e386290d24fc920968a8695 Author: Martin Sebor Date: Wed Feb 24 08:57:59 2021 -0700 PR middle-end/97172 - ICE: tree code 'ssa_name' is not supported in LTO streams gcc/ChangeLog: PR middle-end/97172 * attribs.c (attr_access::free_lang_data): Clear attribute arg spec from function arguments. gcc/c/ChangeLog: PR middle-end/97172 * c-decl.c (free_attr_access_data): Clear attribute arg spec. gcc/testsuite/ChangeLog: PR middle-end/97172 * gcc.dg/pr97172-2.c: New test.
[Bug fortran/97977] Fortran deferred length strings incompatible with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97977 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- I think we had the issue in some other PR. The problem is that 'string1' consists of two variables – 'string1' itself + a hidden variable which contains the string length. The hidden variable needs to get a data-sharing attribute and it gets the wrong one. I think the same issue occurs with mapping to a target region. – Not that trivial to fix, unfortunately :-(
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Works fine on x86_64-linux. Can you attach preprocessed source (most developers don't have access to Windows) and -fdump-tree-optimized dump and assembly you get?
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #15 from Jakub Jelinek ---
printf("%L.1000f\n", 1.0L);
The length modifier needs to come after precision, not before it, so
you should be using
printf("%.1000Lf\n", 1.0L);
instead.
But the test nor libstdc++ itself doesn't do that, does it?
[Bug fortran/99250] New: [F2018] coshape intrinsic is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250 Bug ID: 99250 Summary: [F2018] coshape intrinsic is missing Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- While working on something else, I observed that gfortran doesn't implement the coshape intrinsic -- it's treated like a regular call to an undeclared function, and a quick grep of the sources turned up nothing.
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Patrick Palka ---
[...]
> So:
>
> 1. The hex-form conversion specifier doesn't trim trailing zeroes.
Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
be omitted".
> 2. The fixed-form conversion specifier sometimes outputs the
> scientific-notation suffix "e+00".
This is unexpected indeed.
> 3. The fixed-form conversion specifier sometimes outputs the scientific form.
Same. However, g++ -Wall complains:
pr98384.cc: In function ‘int main()’:
pr98384.cc:5:13: warning: unknown conversion type character ‘.’ in format
[-Wformat=]
5 | printf("%L.1000f\n", 1.0L);
| ^
pr98384.cc:5:10: warning: too many arguments for format [-Wformat-extra-args]
5 | printf("%L.1000f\n", 1.0L);
| ^~~~
Compiling the equivalent C version with Studio 12.6 cc gives:
"pr98384.c", line 6: warning: conversion of hex floating-point constant cannot
be represented exactly in its evaluation format
> Each of the to_chars/printf mismatches I've looked at seem to be caused by one
> of these three issues. Should we just XFAIL the test on Solaris?
Only if it's clear that those outputs are in violation of the standard
and the inputs are valid: the warnings above cast some doubt upon the
latter.
[Bug target/95798] [10/11 Regression] Initialization code --- suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95798 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 50249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50249=edit gcc11-pr95798.patch Untested fix. The #c4 qux case above is not fixed by it, but it isn't a regression, so I think we should defer that one for GCC 12 (file a separate PR for that). And, it would work (if done e.g. at expansion time) only when there is signed integer overflow, so not for -fwrapv nor when e.g. the narrower type is unsigned, so I think we need the single_use match.pd case because after those changes, there is no way to undo that.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #6 from Iain Sandoe ---
(In reply to Nils Gladitz from comment #5)
> Apparently when the coroutine happens to be a member function (even a static
> one) printing *frame_ptr results in "{}".
>
> Ideally I'd want to have non-static member coroutines and would like to be
> able to inspect the "this" pointer during debugging.
.. 'this' gets translated into a reference to the original object for
coroutines... hmm have to see if there's any useful advice at this stage.
> I was also wondering if "frame_ptr" as a non-reserved name isn't problematic
> in case there happens to be e.g. a local variable with that name.
the local variables in the ramp are prefixed with 'coro.' which makes them not
a legal user identifiers. So it's actually coro.frame_ptr.
(where there is potential for clashes, frame variables named are pushed into
the implementation space e.g. __ or _CapitalLetter).
===
I should check in the actor/destroyer if there is scope for a clash (since the
variables are local, they are named xactor:frame_ptr)
.. and would be distinct from any var named frame_ptr in the original source ..
which would become xactor:frame_ptr->frame_ptr :)
However, when implementing the "idea" described above, I think that might
expose the issue - so prefixing with __ or changing the name to _Frame_ptr
might be necessary.
Of course, I didn't make a test case to prove this, .. but will try it
sometime.
[Bug tree-optimization/99220] [11 Regression] ICE during vectorization when multiple instances do the same calculation but have different num lanes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99220 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tamar Christina --- Fixed on master
[Bug fortran/99226] [11 Regression] ICE in expand_expr_real_1, at expr.c:10279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99226
--- Comment #5 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #3)
> So, either we diagnose ... in check_omp_nesting_restrictions.
See comment 4.
* * *
Only for completeness,
the ICE is itself is due to: '.omp_data_i' showing up in 'sub' and not only in
'sub_._omp_fn.0'. This only occurs with -O1 (and higher) and
-fdump-tree-omplower shows:
void sub (integer(kind=4) & restrict n)
{
integer(kind=4) i;
{
D.3961 = .omp_data_i->D.3941; // <<< WRONG!!!
Codewise, the '!optimize' occurs via gimplify.c's lookup_tmp_var
if is_formal=true – as called by 'get_formal_tmp_var'.
[Bug tree-optimization/99220] [11 Regression] ICE during vectorization when multiple instances do the same calculation but have different num lanes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99220
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:6c35e79b47ab582e18d851f6c5df776bac766eaf
commit r11-7359-g6c35e79b47ab582e18d851f6c5df776bac766eaf
Author: Tamar Christina
Date: Wed Feb 24 15:16:23 2021 +
slp: fix accidental resource re-use of slp_tree (PR99220)
The attached testcase shows a bug where two nodes end up with the same
pointer.
During the loop that analyzes all the instances
in optimize_load_redistribution_1 we do
if (value)
{
SLP_TREE_REF_COUNT (value)++;
SLP_TREE_CHILDREN (root)[i] = value;
vect_free_slp_tree (node);
}
when doing a replacement. When this is done and the refcount for the node
reaches 0, the node is removed, which allows the libc to return the pointer
again in the next call to new, which it does..
First instance
note: node 0x5325f48 (max_nunits=1, refcnt=2)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] 0[2] 1[3] }
note: children 0x5325db0 0x5325200
Second instance
note: node 0x5325f48 (max_nunits=1, refcnt=1)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] }
note: children 0x53255b8 0x5325530
This will end up with the illegal construction of
note: node 0x53258e8 (max_nunits=2, refcnt=2)
note: op template: slp_patt_57 = .COMPLEX_MUL (_16, _16);
note: stmt 0 _16 = _14 - _15;
note: stmt 1 _23 = _17 + _22;
note: children 0x53257d8 0x5325d28
note: node 0x53257d8 (max_nunits=2, refcnt=3)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 }
note: node 0x5325d28 (max_nunits=2, refcnt=8)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: stmt 2 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 3 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 0 1 }
To prevent this we remove the node from the load_map if it's
about to be deleted.
gcc/ChangeLog:
PR tree-optimization/99220
* tree-vect-slp.c (optimize_load_redistribution_1): Remove
node from cache when it's about to be deleted.
gcc/testsuite/ChangeLog:
PR tree-optimization/99220
* g++.dg/vect/pr99220.cc: New test.
[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #13 from Patrick Palka ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #12)
> > --- Comment #11 from Patrick Palka ---
> > I posted a patch at
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that
> > does
> > this, but also salvages the verification via printf by first checking if the
> > leading hex digit of the printf output agrees with that of to_chars.
> > Conveniently, the patch sidesteps the question of choosing a consistent
> > representation vs shortest representation :)
>
> I've just tested the patch on both i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 (32 and 64-bit each): as before, the 32-bit test
> XFAILs while the 64-bit test continues to FAIL:
>
> before:
>
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
> long_double.cc:104: void test01(): Assertion '!strcmp(to_chars_buffer,
> printf_buffer+strlen("0x"))' failed.
>
> now:
>
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
> long_double.cc:192: void test02(): Assertion '!memcmp(printf_buffer,
> to_chars_buffer, output_length)' failed.
Thanks for testing. I was able to reproduce the 64-bit execution FAIL on
sparc-sun-solaris2.11 (using the gcc211 compile farm machine).
Digging deeper, it seems the test is failing ultimately due to pecularities
with the system printf implementation. For example, when I compile+run the
following
#include
int main() {
printf("%La\n", 1.0L);
printf("%L.1000f\n", 1.0L);
printf("%Lf\n", 0x1.13492ffd6ec7341068e0176a737dp+3384L);
}
the output I get is
0x1.p+0
1.e+00
5.212539e+1018
So:
1. The hex-form conversion specifier doesn't trim trailing zeroes.
2. The fixed-form conversion specifier sometimes outputs the
scientific-notation suffix "e+00".
3. The fixed-form conversion specifier sometimes outputs the scientific form.
Each of the to_chars/printf mismatches I've looked at seem to be caused by one
of these three issues. Should we just XFAIL the test on Solaris?
[Bug tree-optimization/99101] optimization bug with -ffinite-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #12 from Richard Biener ---
So we can massage post-dom compute to make control dependence which is defined
in terms of pdom do what we want. We have
void
dom_info::calc_dfs_tree ()
{
...
/* In the post-dom case we may have nodes without a path to EXIT_BLOCK.
They are reverse-unreachable. In the dom-case we disallow such
nodes, but in post-dom we have to deal with them.
There are two situations in which this occurs. First, noreturn
functions. Second, infinite loops. In the first case we need to
pretend that there is an edge to the exit block. In the second
case, we wind up with a forest. We need to process all noreturn
blocks before we know if we've got any infinite loops. */
which then first visits blocks w/o successors, breaking our expectations.
So with that in mind indeed connecting infinite loops to exit would
circumvent the issue, but connect_infinite_loops_to_exit does not
reliably avoid making the edge from the noreturn block (if that came first),
dfs_find_deadend also likes noreturn blocks very much.
Heuristically one could use loop info, but that fails to work for irreducible
regions. One could also use marked backedges from a forward DFS walk
(blocks with just backedges outgoing).
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #5 from Nils Gladitz ---
Apparently when the coroutine happens to be a member function (even a static
one) printing *frame_ptr results in "{}".
Ideally I'd want to have non-static member coroutines and would like to be able
to inspect the "this" pointer during debugging.
I was also wondering if "frame_ptr" as a non-reserved name isn't problematic in
case there happens to be e.g. a local variable with that name.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 Ignacio Fernández Galván changed: What|Removed |Added CC||jellby at yahoo dot com --- Comment #2 from Ignacio Fernández Galván --- May I add that it's probably similarly pointless to issue this warning for large arrays in a module (as module variables, not in a procedure)?
[Bug tree-optimization/99149] [11 Regression] ICE during vectorization when shared trees contain different complex patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99149 --- Comment #3 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:96c5a8589e0dd22819bae34cac3381ad381d3989 commit r11-7358-g96c5a8589e0dd22819bae34cac3381ad381d3989 Author: Tamar Christina Date: Wed Feb 24 14:57:08 2021 + [comitted] Testsuite: Disable PR99149 test on big-endian This patch disables the test for PR99149 on Big-endian where for standard AArch64 the patterns are disabled. gcc/testsuite/ChangeLog: PR tree-optimization/99149 * g++.dg/vect/pr99149.cc: Disabled on BE.
[Bug tree-optimization/99101] optimization bug with -ffinite-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #11 from Richard Biener --- (In reply to Richard Biener from comment #10) > Created attachment 50248 [details] > dot of the CFG as CD-DCE sees it (gdb) p debug_dominance_info (CDI_POST_DOMINATORS) 2 3 3 11 4 6 5 9 6 7 7 1 9 11 11 4 12 3
[Bug tree-optimization/99101] optimization bug with -ffinite-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #10 from Richard Biener --- Created attachment 50248 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50248=edit dot of the CFG as CD-DCE sees it
[Bug tree-optimization/99101] optimization bug with -ffinite-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #9 from Richard Biener ---
Another fix for the finite-loop issue would be to avoid considering loops not
post-dominated by the exit block as finite. Like with the imperfect
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 3817ec423e7..388c03ee6fc 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -2865,6 +2865,16 @@ finite_loop_p (class loop *loop)
FOR_EACH_VEC_ELT (exits, i, ex)
if (!(ex->flags & (EDGE_EH | EDGE_ABNORMAL | EDGE_FAKE)))
{
+ /* But do not count noreturn regions as exit.
+ ??? This is a to simple check, we'd have to either
+ use post-dominance by the exit block (which isn't
+ computed) or a DFS walk. See PR99101 where the
+ the fact that control dependence (and post-dominance)
+ is not well-defined for not backward reachable regions
+ causes issues otherwise. */
+ if (ex->dest->index != EXIT_BLOCK
+ && EDGE_COUNT (ex->dest->succs) == 0)
+ continue;
if (dump_file)
fprintf (dump_file, "Assume loop %i to be finite: it has an exit
"
"and -ffinite-loops is on.\n", loop->num);
but that still leaves post-dominance and thus control dependence not
well-defined in not backwards reachable regions and thus possibly "bogus"
control-dependent DCE decisions in those. Note even with the above
CD-DCE will then use control-dependence to make the loop control necessary:
FOR_EACH_LOOP (loop, 0)
if (!finite_loop_p (loop))
{
if (dump_file)
fprintf (dump_file, "cannot prove finiteness of loop %i\n",
loop->num);
mark_control_dependent_edges_necessary (loop->latch, false);
}
Which means to be absolutely sure we could use non-CD DCE whenever there
are not backwards reachable blocks in the function.
[Bug fortran/99226] [11 Regression] ICE in expand_expr_real_1, at expr.c:10279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99226 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-24 --- Comment #4 from Jakub Jelinek --- Created attachment 50247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50247=edit gcc11-pr99226.patch Like this.
[Bug tree-optimization/99101] optimization bug with -ffinite-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #8 from Richard Biener ---
The following reduced testcase fails in the described way at -O2 with the C++
FE and with the C FE if you specify -ffinite-loops in addition to -O2. Already
CDDCE1 does the problematic transform which means the first breakpoint
hit on perform_tree_ssa_dce is the problematic one easing further
investigation.
volatile int xx;
int main()
{
int read_finish_ = 1;
int jobs_ = 1;
int at_eof_ = 0;
while (1)
{
int num_job = jobs_;
for (int i = 0; i < jobs_; i++)
{
if (at_eof_) continue;
if (read_finish_)
{
at_eof_ = 1;
__builtin_printf ("1\n");
if (xx)
__builtin_abort ();
}
}
jobs_ -= num_job;
}
return 0;
}
[Bug libgcc/99236] Undefined behaviour in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236 --- Comment #2 from Vittorio Zecca --- After patching libgcc2.c the test case runs fine without sanitizer messages.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 Eric Gallager changed: What|Removed |Added CC||cmtice at google dot com, ||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > (In reply to gcc-user from comment #2) > > Briefly it explained that -lvtv comes from -fvtable-verify=std in a gcc spec > > file and is propogated to Makefile.in by gcc/Makefile.def. > > The -fvtable-verify=std doesn't come from the spec file, it comes from using > --enable-vtable-verify to configure gcc. That adds -fvtable-verify=std and > the spec file turns that into -lvtv. > > I don't know why you want to use --enable-vtable-verify but it's not really > maintained as far as I can see. I thought Caroline Tice was maintaining it.
[Bug c++/99237] [modules] internal compiler error: in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99237 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #1 from Nathan Sidwell --- Possibly dup of 98718
[Bug c++/98707] ICE using std::string in a module partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98707 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- thanks for the update, closing
[Bug fortran/99124] [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- It helps to mark it as fixed :-)
[Bug fortran/99124] [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124 --- Comment #5 from Paul Thomas --- Fixed on all three branches. Thanks for the report. I hope that the constraint on class-valued elemental functions doesn't spoil any code. Cheers Paul
[Bug libgcc/99236] Undefined behaviour in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236 --- Comment #1 from Jakub Jelinek --- Created attachment 50246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50246=edit gcc11-pr99236.patch Untested fix.
[Bug libgcc/99236] Undefined behaviour in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99236 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-02-24 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org
[Bug fortran/99124] [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99124 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:cd34d8b7b50f0f3592deb76983191c3d9a5dbcb9 commit r9-9249-gcd34d8b7b50f0f3592deb76983191c3d9a5dbcb9 Author: Paul Thomas Date: Tue Feb 23 19:29:04 2021 + Fortran: Fix for class defined operators [PR99124]. 2021-02-23 Paul Thomas gcc/fortran PR fortran/99124 * resolve.c (resolve_fl_procedure): Include class results in the test for F2018, C15100. * trans-array.c (get_class_info_from_ss): Do not use the saved descriptor to obtain the class expression for variables. Use gfc_get_class_from_expr instead. gcc/testsuite/ PR fortran/99124 * gfortran.dg/class_defined_operator_2.f03 : New test. * gfortran.dg/elemental_result_2.f90 : New test. * gfortran.dg/class_assign_4.f90: Correct the non-conforming elemental function with an allocatable result with an operator interface with array dummies and result. (cherry picked from commit 29a5298955f777c539c628f51e78b75d8e586c44)
[Bug target/99249] SVE: ICE in aarch64_expand_sve_const_vector (during RTL pass: early_remat)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.2.1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org Target Milestone|--- |10.3 Last reconfirmed||2021-02-24 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed on the 10 branch as well.
[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #9 from Iain Sandoe --- so fixed on master.
[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 --- Comment #8 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:f13d9e48eeca7ed8f8df55c9a62fc9980d5606ad commit r11-7357-gf13d9e48eeca7ed8f8df55c9a62fc9980d5606ad Author: Iain Sandoe Date: Tue Feb 23 12:54:26 2021 + coroutines : Adjust error handling for type-dependent coroutines [PR96251]. Although coroutines are not permitted to be constexpr, generic lambdas are implicitly from C++17 and, because of this, a generic coroutine lambda can be marked as potentially constexpr. As per the PR, this then fails when type substitution is attempted because the check disallowing constexpr in the coroutines code was overly restrictive. This changes the error handing to mark the function as 'invalid_constexpr' but suppresses the error in the case that we are instantiating a constexpr. gcc/cp/ChangeLog: PR c++/96251 * coroutines.cc (coro_common_keyword_context_valid_p): Suppress error reporting when instantiating for a constexpr. gcc/testsuite/ChangeLog: PR c++/96251 * g++.dg/coroutines/pr96251.C: New test.
[Bug target/99249] New: SVE: ICE in aarch64_expand_sve_const_vector (during RTL pass: early_remat)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99249
Bug ID: 99249
Summary: SVE: ICE in aarch64_expand_sve_const_vector (during
RTL pass: early_remat)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.cc
#include
extern char b[];
int x;
void f() {
while (x) {
x = svaddv(
svnot_z(svnot_z(svptrue_pat_b8(SV_VL6),
svmov_z(svptrue_pat_b8(SV_VL1),
svptrue_pat_b16(SV_VL3))),
svptrue_pat_b64(SV_VL2)),
svdup_s32(8193));
for (int j = x; j; j++)
b[j] = 0;
}
}
$ aarch64-linux-gnu-gcc -c -march=armv8.2-a+sve -Os test.cc
during RTL pass: early_remat
test.cc: In function ‘void f()’:
test.cc:15:1: internal compiler error: in aarch64_expand_sve_const_vector, at
config/aarch64/aarch64.c:4956
15 | }
| ^
0x14ffb66 aarch64_expand_sve_const_vector
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:4956
0x15019b1 aarch64_expand_mov_immediate(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:5395
0x19afb10 gen_movvnx16qi(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve.md:662
0xcab8e6 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0xcab8e6 emit_move_insn_1(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3766
0xcabe37 emit_move_insn(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3936
0xc7e694 force_reg(machine_mode, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/explow.c:677
0x14ffc4f aarch64_expand_sve_const_vector
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:4964
0x15019b1 aarch64_expand_mov_immediate(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:5395
0x19afb10 gen_movvnx16qi(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-sve.md:662
0xcab8e6 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0xcab8e6 emit_move_insn_1(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3766
0xcabe37 emit_move_insn(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3936
0xc7e614 copy_to_mode_reg(machine_mode, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/explow.c:653
0xf69b69 maybe_legitimize_operand
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7626
0xf69b69 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7758
0xf69e52 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:
0xf6a06e maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7820
0xf69605 expand_insn(insn_code, unsigned int, expand_operand*)
/home/alecop01/toolchain/src/gcc/gcc/optabs.c:7851
0x14d45d2 aarch64_sve_emit_int_cmp
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:3920
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
