[Bug sanitizer/108510] New: ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510
Bug ID: 108510
Summary: ASAN missed a stack-use-after-scope at -O1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, GCC's ASAN at -O1 missed the stack-use-after-scope,
while other opt levels detected it.
I checked the assembly code, -O1 didn't optimize away the buggy code.
Compiler explorer: https://godbolt.org/z/jWPG8hMWY
% cat a.c
short a;
char b;
short *c = &a, *d;
long e;
int main() {
long *f = &e;
{
int g=0;
d = &g;
}
*d << (b = ((*f)--, c || *d));
}
%
% gcc-tk -fsanitize=address -g -O1 a.c && ./a.out
%
% gcc-tk -fsanitize=address -g -O2 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f0150b00020
at pc 0x004011a4 bp 0x743bc150 sp 0x743bc148
READ of size 2 at 0x7f0150b00020 thread T0
#0 0x4011a3 in main /a.c:11
#1 0x7f01534e6082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40123d in _start (/app/output.s+0x40123d) (BuildId:
2f09fd97ce9e5ec29ed33980daf91dfdd4bb3ebc)
Address 0x7f0150b00020 is located in stack of thread T0 at offset 32 in frame
#0 0x4010bf in main /a.c:5
...
%
[Bug ipa/108511] New: [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511 Bug ID: 108511 Summary: [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: *-*-solaris2.11 Target: *-*-solaris2.11 Build: *-*-solaris2.11 Between 20230120 (99ea0d7611605d2d1a67a6021cb78f0bdd5c609b) and 20230123 (b457cab64038cd9b7a8481594ff673f1822681f6), a lto test regressed on Solaris (both sparc and x86, 32 and 64-bit): +FAIL: g++.dg/lto/pr88049 cp_lto_pr88049_0.o-cp_lto_pr88049_0.o link, -flto -O2 -w (internal compiler error: in possibly_call_in_translation_unit_p, at cgraph.cc:4184) during IPA pass: fnsummary lto1: internal compiler error: in possibly_call_in_translation_unit_p, at cgraph.cc:4184 0x8c9a54d cgraph_edge::possibly_call_in_translation_unit_p() /vol/gcc/src/hg/master/local/gcc/cgraph.cc:4184 0x8f6c80d ipa_read_edge_info /vol/gcc/src/hg/master/local/gcc/ipa-prop.cc:5083 0x8f6cdc7 ipa_read_node_info /vol/gcc/src/hg/master/local/gcc/ipa-prop.cc:5168 0x8f6cdc7 ipa_prop_read_section /vol/gcc/src/hg/master/local/gcc/ipa-prop.cc:5251 0x8f6cdc7 ipa_prop_read_jump_functions() /vol/gcc/src/hg/master/local/gcc/ipa-prop.cc:5278 0x8f230c2 ipa_fn_summary_read /vol/gcc/src/hg/master/local/gcc/ipa-fnsummary.cc:4638 0x90cb1cc ipa_read_summaries_1 /vol/gcc/src/hg/master/local/gcc/passes.cc:3001 0x8bf1eb4 read_cgraph_and_symbols(unsigned int, char const**) /vol/gcc/src/hg/master/local/gcc/lto/lto-common.cc:2936 0x8bd5825 lto_main() /vol/gcc/src/hg/master/local/gcc/lto/lto.cc:654
[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug preprocessor/84583] -fdirectives-only does not handle CRLF properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84583 Boris Kolpackov changed: What|Removed |Added Version|10.2.0 |12.2.0 --- Comment #2 from Boris Kolpackov --- Still present in GCC 12.2.0. Just hit it with SQLite 3.39.4 source code (shell.c): shell.exe.o.i:165900:40: error: unterminated string literal
[Bug fortran/108501] [13 Regression] ICE in get_expr_storage_size, at fortran/interface.cc:2941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108501 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #6 from Richard Biener --- Fixed I assume.
[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108506] bit_cast from 32-byte vector generates worse code than memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
>
> Internals of what is going on:
>
> Gimple IR
> bad (__builtin_bit_cast):
> MEM[(struct Foo *)output_7(D) + ivtmp.13_20 * 1] =
> VIEW_CONVERT_EXPR(_1);
This is an aggregate copy but the RHS is not a load - it's on the border
of invalid^Wunwanted GIMPLE.
> vs good (memcpy):
> MEM [(char * {ref-all})output_7(D) +
> ivtmp.28_20 * 1] = _1;
>
> Both look ok really. Though the first one could be rewritten into the second
> one which would fix the expansion. Though maybe it could be fixed in the
> middle-end while doing the expansion of gimple to RTL.
In other places we said we want V_C_Es on the RHS instead of on the LHS
but here we could consume the V_C_E from the MEM_REF on the LHS since
it's also a nice type to store (beware of extended precision FP types here!).
It's already gimplification / SSA rewrite producing the problematic IL.
[Bug analyzer/108507] [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug rtl-optimization/108508] [13 Regression] ICE in insert_def_after, at rtl-ssa/accesses.cc:622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0
[Bug ipa/108509] [13 Regression] ICE in add, at hash-set.h:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug fortran/108512] New: [13 Regression][OpenMP] ICE for valid loop data-sharing clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512
Bug ID: 108512
Summary: [13 Regression][OpenMP] ICE for valid loop
data-sharing clauses
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jules at gcc dot gnu.org
Target Milestone: ---
I bet this is revealed/"caused" by PR107214's
commit r13-4703-g330b9a8d87dd73e10539da618496ad4964fee26d
even if that commit is not wrong.
The harmlessly looking
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/loop/test_loop_lastprivate.F90
now gives an ICE.
The problem occurs for:
+ gfc_error ("Symbol %qs present on multiple clauses at %L",
+ n->sym->name, &n->where);
There seem to be two issues:
(A) 'n->where' is NULL, causing the ICE.
(B) The code is actually valid.
I think the following patch fixes the 'n->where' problem; I have not checked
whether one could give it a better location.
However, the real problem is that 'x' is now in both OMP_LIST_PRIVATE due to
gfc_resolve_do_iterator and explicitly by the user in the LASTPRIVATE clause.
I have not really understood what the function is doing and whether it is
needed. But the PRIVATE clause part somehow looks "wrong".
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -9225,4 +9225,5 @@ (gfc_code *code, gfc_symbol
p = gfc_get_omp_namelist ();
p->sym = sym;
+ p->where = code->loc;
p->next = omp_clauses->lists[OMP_LIST_PRIVATE];
omp_clauses->lists[OMP_LIST_PRIVATE] = p;
[Bug tree-optimization/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #4 from Richard Biener --- (In reply to Andrew Pinski from comment #3) > assign_dfs_numbers has not changed for years ... [...] > Maybe we can do some bb merging before calculate_dominance_info Unfortunately not (easily). A more sustainable fix would be to avoid the recursion in assign_dfs_numbers in favor of a worklist approach, pushing 'node->son, son' as "iterator" like the cfganal DFS walks do.
[Bug tree-optimization/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #5 from Richard Biener --- Created attachment 54331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54331&action=edit CFG cleanup "early merging" OK, I take that back. For this simple testcase the attached works, delaying the dominance compute until the iterative cleanup phase for blocks with multiple predecessors. I didn't otherwise test it and I think if you add a diamond to the inlined function you will still hit the issue, so it isn't a "fix". It's also going to slow down CFG cleanup a bit. Though it would be nice to not require dominance queries during it since it's inevitably going to do slow queries. That also hints at another possible fix which is to simply not compute those from CFG cleanup (but there's no API entry for that yet).
[Bug tree-optimization/108500] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Created attachment 54332 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54332&action=edit do not compute fast-query from CFG cleanup This is the more obvious workaround (as said, the bug is the recursive DFS number assignment). I'm going to test this variant.
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 --- Comment #5 from CVS Commits --- The master branch has been updated by SRINATH PARVATHANENI : https://gcc.gnu.org/g:275820c09e5f397040cbff69c90012dc1e220faf commit r13-5322-g275820c09e5f397040cbff69c90012dc1e220faf Author: Srinath Parvathaneni Date: Tue Jan 24 09:57:52 2023 + arm: Fix inclusion of arm-mlib.h header more than once (pr108505). The patch fixes the build issue for arm-none-eabi target configured with --with-multilib-list=aprofile,rmprofile, in which case the header file arm/arm-mlib.h is being included more than once and the toolchain build is failing (PR108505). gcc/ChangeLog: 2023-01-24 Srinath Parvathaneni PR target/108505 * config.gcc (tm_file): Move the variable out of loop.
[Bug c++/108513] New: [13 Regression] Bad initializer-list construction of std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108513
Bug ID: 108513
Summary: [13 Regression] Bad initializer-list construction of
std::vector
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
struct OptionTestEntry
{
int test1;
std::vector invalid_vals;
};
int main() {
const OptionTestEntry testm[] = { {1, {-1}} };
if (testm[0].invalid_vals.size() != 1)
__builtin_abort();
};
Aborted (core dumped)
Reducing and bisecting ...
[Bug c++/108513] [13 Regression] Bad initializer-list construction of std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108513 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Oh sorry, Jakub already identified this as PR 108195 *** This bug has been marked as a duplicate of bug 108195 ***
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector since r13-4564-gd081807d8d70e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #6 from Jonathan Wakely --- *** Bug 108513 has been marked as a duplicate of this bug. ***
[Bug fortran/108512] [13 Regression][OpenMP] ICE for valid loop data-sharing clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512 --- Comment #1 from Tobias Burnus --- Correction: I think I linked the wrong file, it should be: https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/loop/test_loop_lastprivate_device.F90 * * * Probably better location is the following, which gives the diagnost shown below + p->where = omp_current_ctx->code->loc; Namely, this gives for 'x' and 'y': 85 | !$omp target parallel num_threads(OMPVV_NUM_THREADS_DEVICE) map(tofrom: a, b, x, y) |1 And for 'x': 48 | !$omp target parallel num_threads(OMPVV_NUM_THREADS_DEVICE) map(tofrom: a, b, x) | 1 Error: Symbol 'x' present on multiple clauses at (1) The latter code is: !$omp target parallel num_threads(OMPVV_NUM_THREADS_DEVICE) map(tofrom: a, b, x) !$omp loop lastprivate(x) DO x = 1, NSIZE a(x) = a(x) + b(x) END DO !$omp end loop !$omp end target parallel
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #9 from Richard Biener ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array.
>
> do you mean for the following example:
>
> typedef struct {
> char pad;
> char data[];
> } F2;
>
> typedef struct {
> unsigned pad;
> F2 flex;
> } S2;
>
> although C standard disallow the above, GCC extension treats S2.flex.data as
> a flex-array?
>
> How about:
>
> typedef struct {
> char pad;
> char data[];
> } F2;
>
> typedef struct {
> F2 flex;
> unsigned pad;
> } S2;
>
> do we have any documentation on this Gcc extension?
GCC handles for example
struct A { char data[1]; };
struct B { int n; struct A a; };
as if the a.data[] array is a flex-array. It also handles
struct C { int n; struct A a; int x; };
as if a.data[] can be up to 4 elements large (we allow an array to extend
flexibly to padding - but only if it is trailing). I see that's not
consistently handled though.
I think the [] syntax should follow the C standard as what testcases are
accepted/rejected by the frontend and any extensions there should be
documented (those are separate from what the former array_at_struct_end_p
allowed semantically and where GCC is careful with optimization because
of code out in the wild).
[Bug target/108505] [13 Regression] Arm: arm-none-eabi toolchain build failing with compiler error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108505 Srinath Parvathaneni changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Srinath Parvathaneni --- Fixed in gcc-trunk.
[Bug modula2/108480] gm2 fails to find SYSTEM module after relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108480 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- I checked and this seems now fixed.
[Bug sanitizer/108514] New: ASAN at -O0 missed a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108514
Bug ID: 108514
Summary: ASAN at -O0 missed a stack-use-after-scope
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, ASAN at -O0 and -Os missed the stack-use-after-scope,
while other opt levels caught it. This issue is really concerning as it appears
at -O0.
Compiler explorer: https://godbolt.org/z/bWGbq6Er9
% cat a.c
int a = 5;
char b, d;
short c, e;
int main() {
int *f = &a;
b = 0;
for (; b != 9; b = 9) {
int g=7;
f = &g;
}
e = (c = d, a) || *f;
return e;
}
%
% gcc-tk -fsanitize=address -g -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -g -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f5faf900020
at pc 0x004011e6 bp 0x7ffc50f70450 sp 0x7ffc50f70448
READ of size 4 at 0x7f5faf900020 thread T0
#0 0x4011e5 in main /a.c:11
#1 0x7f5fb22da082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010bd in _start (/app/output.s+0x4010bd) (BuildId:
99c4c90f86135af6a6c35d4ef1af9a5d7e48c1ed)
Address 0x7f5faf900020 is located in stack of thread T0 at offset 32 in frame
#0 0x401185 in main /a.c:4
This frame has 1 object(s):
[32, 36) 'g' (line 8) <== Memory access at offset 32 is inside this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /a.c:11 in main
Shadow bytes around the buggy address:
...
%
[Bug c++/108474] static structured binding undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108474
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b84e21115700523b4d0ac44275443f7b9c670344
commit r13-5323-gb84e21115700523b4d0ac44275443f7b9c670344
Author: Jakub Jelinek
Date: Tue Jan 24 11:28:00 2023 +0100
c++: Handle structured bindings like anon unions in initializers [PR108474]
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> look through DECL_VALUE_EXPR?
Doing it when emitting the initializers seems to be too late to me,
we in various spots try to put parts of the static var DECL_INITIAL
expressions
into the IL, or e.g. for varpool purposes remember which vars are
referenced
there.
This patch moves it to record_reference, which is called from
varpool_node::analyze
and so about the same time as gimplification of the bodies which also
replaces DECL_VALUE_EXPRs.
2023-01-24 Jakub Jelinek
PR c++/108474
* cgraphbuild.cc: Include gimplify.h.
(record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P
with
their corresponding DECL_VALUE_EXPR expressions after unsharing.
* cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
[Bug target/108515] New: Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Bug ID: 108515 Summary: Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The build for armv7hl-gnueabi recently fails with [ 136s] gcc -c -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables -fasyn chronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIF Y_SOURCE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold -style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic - Wno-long-long -DHAVE_CONFIG_H -I. -I../../../fixincludes -I../include -I../../ ../fixincludes/../include ../../../fixincludes/fixincl.c ... [ 139s] gcc -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables -fasynchr onous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_S OURCE -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o f ixopts.o ../libiberty/libiberty.a [ 139s] /usr/lib/gcc/armv7hl-suse-linux-gnueabi/12/../../../../armv7hl-suse-lin ux-gnueabi/bin/ld: fixincl.o(.text+0x1ac): unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4' [ 139s] collect2: error: ld returned 1 exit status when configured as [ 63s] + ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,go,d,jit --enable-host-shared --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/13 --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/lib --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-13 --without-system-libunwind --with-cpu=generic-armv7-a --with-float=hard --with-abi=aapcs-linux --with-fpu=vfpv3-d16 --disable-sjlj-exceptions --build=armv7hl-suse-linux-gnueabi --host=armv7hl-suse-linux-gnueabi and built with [ 74s] + make -Oline 'STAGE1_CFLAGS=-g -O2' 'BOOT_CFLAGS=-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables -fasynchronous-unwind-tables -fstack-clash- protection -Werror=return-type -g -U_FORTIFY_SOURCE' -j6 where 'gcc' is GCC 12.2.1 as of r12-9008-ge4b5fec75aa8d0
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-24 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org
[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:193f7e62815b4089dfaed4c2bd34fd4f10209e27
commit r12-9061-g193f7e62815b4089dfaed4c2bd34fd4f10209e27
Author: Sergei Trofimovich
Date: Tue Aug 16 12:35:07 2022 +0100
driver: fix environ corruption after putenv() [PR106624]
The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out
jobserver_active_p" slightly changed `putenv()` use from allocating
to non-allocating:
-xputenv (concat ("MAKEFLAGS=", dup, NULL));
+xputenv (jinfo.skipped_makeflags.c_str ());
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2':
execv: Bad address
The change restores memory allocation for `xputenv()` argument.
gcc/
PR driver/106624
* gcc.cc (driver::detect_jobserver): Allocate storage xputenv()
argument using xstrdup().
(cherry picked from commit 2b403297b111c990c331b5bbb6165b061ad2259b)
[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624
--- Comment #14 from CVS Commits ---
The releases/gcc-11 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:9d21cc4edd94f8f2b1a3241fab5cf75649003226
commit r11-10479-g9d21cc4edd94f8f2b1a3241fab5cf75649003226
Author: Sergei Trofimovich
Date: Tue Aug 16 12:35:07 2022 +0100
driver: fix environ corruption after putenv() [PR106624]
The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out
jobserver_active_p" slightly changed `putenv()` use from allocating
to non-allocating:
-xputenv (concat ("MAKEFLAGS=", dup, NULL));
+xputenv (jinfo.skipped_makeflags.c_str ());
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2':
execv: Bad address
The change restores memory allocation for `xputenv()` argument.
gcc/
PR driver/106624
* gcc.c (driver::detect_jobserver): Allocate storage xputenv()
argument using xstrdup().
(cherry picked from commit 2b403297b111c990c331b5bbb6165b061ad2259b)
[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106624
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:6ced00d53d91ea429948b34e6600b4633f962030
commit r10-11172-g6ced00d53d91ea429948b34e6600b4633f962030
Author: Sergei Trofimovich
Date: Tue Aug 16 12:35:07 2022 +0100
driver: fix environ corruption after putenv() [PR106624]
The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out
jobserver_active_p" slightly changed `putenv()` use from allocating
to non-allocating:
-xputenv (concat ("MAKEFLAGS=", dup, NULL));
+xputenv (jinfo.skipped_makeflags.c_str ());
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2':
execv: Bad address
The change restores memory allocation for `xputenv()` argument.
gcc/
PR driver/106624
* gcc.c (driver::detect_jobserver): Allocate storage xputenv()
argument using xstrdup().
(cherry picked from commit 2b403297b111c990c331b5bbb6165b061ad2259b)
[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543 --- Comment #15 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f0cb3368af735e95776769c4f28fa9cbb60eaf8 commit r13-5324-g9f0cb3368af735e95776769c4f28fa9cbb60eaf8 Author: Eric Biggers Date: Tue Jan 24 11:54:41 2023 +0100 options: fix cl_target_option_print_diff() with strings Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2. This bug caused the dump file produced by -fdump-ipa-inline-details to not correctly show the difference in target options when a function could not be inlined due to a target option mismatch. gcc/ChangeLog: PR bootstrap/90543 * optc-save-gen.awk: Fix copy-and-paste error. Signed-off-by: Eric Biggers
[Bug tree-optimization/108499] False positive -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108499 --- Comment #2 from Stephen --- > There is no way to figure out for the compiler that theSize is not zero > either. There is no way for the compiler to figure out that theSize *is* zero. We have warnings -Wmaybe-uninitialized and -Wuninitialized. This warning is -Warray-bounds, not -Wmaybe-array-bounds. This warning should not be emitted.
[Bug rtl-optimization/108516] New: Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516
Bug ID: 108516
Summary: Useless movzx instruction emitted when loading 8 bits
from 24 bit struct
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
This code produces an extra instruction in GCC 11 and 12 (but not 10 or
before):
#include
struct S
{
uint8_t e1;
uint8_t e2;
uint8_t e3;
};
uint32_t f2(S s) { return s.e2; }
The generated code is:
mov eax, edi
movzx eax, ah
movzx eax, al
ret
The movzx from "al" is useless: it zeros the high 24 bits of eax which are
known to be zero after the prior movzx. GCC 10 and earlier do not emit the
useless instruction, and neither do GCC 11 or 12 if the struct contains 4 bytes
instead of 3.
Demo: https://godbolt.org/z/Wajo86GfM
[Bug tree-optimization/108499] False positive -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108499 --- Comment #3 from Stephen --- False positives with this will just lead to proliferation of -Wno-array-bounds, which doesn't help.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 --- Comment #1 from Richard Biener --- binutils is 2.39 btw
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 --- Comment #2 from Richard Biener --- Created attachment 54333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54333&action=edit preprocessed source, assembly and object The linker error also reproduces (besides unresolved symbols) when only linking the fixincl.o file. It's compiled (with GCC 12.2) with /usr/lib/gcc/armv7hl-suse-linux-gnueabi/12/cc1 -fpreprocessed fixincl.i -quiet -dumpbase fixincl.c -dumpbase-ext .c -mcpu=generic-armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mabi=aapcs-linux -mtls-dialect=gnu -marm -mlibarch=armv7-a+fp -march=armv7-a+fp -g -O2 -Werror=return-type -Wextra -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wsuggest-attribute=format -Wno-overlength-strings -Wpedantic -Wno-long-long -version -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -o fixincl.s
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Richard Biener changed: What|Removed |Added Version|13.0|12.2.1 --- Comment #3 from Richard Biener --- And the GCC 12 branch fails the same way for us (with the same GCC 12 compiler), so probably an issue of the GCC 12 compiler (or binutils).
[Bug libstdc++/108517] New: std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Bug ID: 108517 Summary: std::sort of empty range yield "warning: 'this' pointer is null" Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hanicka at hanicka dot net Target Milestone: --- Bug in GCC 11.1-13 (including trunk) https://compiler-explorer.com/z/EEjeaKfv7 I couldn't minimize it further. Lowering optimization level will make the warning gone.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #4 from Richard Biener ---
#include
int main()
{
printf("%p\n", stderr);
return 0;
}
produces the same error
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 --- Comment #5 from Richard Biener --- Symbol table '.symtab' contains 16110 entries: Num:Value Size TypeBind Vis Ndx Name ... 14277: 00190df0 4 OBJECT GLOBAL DEFAULT 31 stderr and '31' is [31] .data PROGBITS001901b0 1801b0 000c50 00 WA 0 0 8 nothing surprising I think.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #6 from Richard Biener ---
same with
extern void *stderr;
int main()
{
volatile void *x = stderr;
}
[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 Jakub Jelinek changed: What|Removed |Added Summary|ppc64 big endian generates |[11/12/13 Regression] ppc64 |uninitialized reads with|big endian generates |-fstore-merging |uninitialized reads with ||-fstore-merging Priority|P3 |P2 Target Milestone|--- |11.4 --- Comment #17 from Jakub Jelinek --- Started with r11-1810-ge362a897655e3b92949b65a2b53e00fb3ab8ded0
[Bug libstdc++/108517] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-24
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||diagnostic
--- Comment #1 from Jonathan Wakely ---
Please provide the code here instead of just a link, as per
https://gcc.gnu.org/bugs/
#include
struct object {
size_t size() const noexcept;
};
struct empty_vec {
object * begin() noexcept {
return nullptr;
}
object * end() noexcept {
return nullptr;
}
};
int main() {
auto sort_by_size = [](const auto & lhs, const auto & rhs) { return
lhs.size() < rhs.size(); };
empty_vec vec{};
std::sort(vec.begin(), vec.end(), sort_by_size);
}
$ g++ -O2 sort.cc -c -Wall
In lambda function,
inlined from 'constexpr bool
__gnu_cxx::__ops::_Iter_comp_iter<_Compare>::operator()(_Iterator1, _Iterator2)
[with _Iterator1 = object*; _Iterator2 = object*; _Compare =
main()::]' at
/usr/include/c++/12/bits/predefined_ops.h:158:30,
inlined from 'void std::__insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = object*;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter >]' at /usr/include/c++/12/bits/stl_algo.h:1809:14:
sort.cc:17:94: warning: 'this' pointer is null [-Wnonnull]
17 | auto sort_by_size = [](const auto & lhs, const auto & rhs) { return
lhs.size() < rhs.size(); };
|
^~
sort.cc: In function 'void std::__insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = object*;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter >]':
sort.cc:4:12: note: in a call to non-static member function 'size_t
object::size() const'
4 | size_t size() const noexcept;
|^~~~
In file included from /usr/include/c++/12/algorithm:60,
from sort.cc:1:
In static member function 'static _Tp* std::__copy_move_backward<_IsMove, true,
std::random_access_iterator_tag>::__copy_move_b(const _Tp*, const _Tp*, _Tp*)
[with _Tp = object; bool _IsMove = true]',
inlined from '_BI2 std::__copy_move_backward_a2(_BI1, _BI1, _BI2) [with
bool _IsMove = true; _BI1 = object*; _BI2 = object*]' at
/usr/include/c++/12/bits/stl_algobase.h:760:37,
inlined from '_BI2 std::__copy_move_backward_a1(_BI1, _BI1, _BI2) [with
bool _IsMove = true; _BI1 = object*; _BI2 = object*]' at
/usr/include/c++/12/bits/stl_algobase.h:769:51,
inlined from '_OI std::__copy_move_backward_a(_II, _II, _OI) [with bool
_IsMove = true; _II = object*; _OI = object*]' at
/usr/include/c++/12/bits/stl_algobase.h:798:31,
inlined from '_BI2 std::move_backward(_BI1, _BI1, _BI2) [with _BI1 =
object*; _BI2 = object*]' at /usr/include/c++/12/bits/stl_algobase.h:892:47,
inlined from 'void std::__insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = object*;
_Compare = __gnu_cxx::__ops::_Iter_comp_iter >]' at /usr/include/c++/12/bits/stl_algo.h:1813:8:
/usr/include/c++/12/bits/stl_algobase.h:742:30: warning: argument 2 null where
non-null expected [-Wnonnull]
742 | __builtin_memmove(__result - _Num, __first, sizeof(_Tp) *
_Num);
|
~^~
/usr/include/c++/12/bits/stl_algobase.h:742:30: note: in a call to built-in
function 'void* __builtin_memmove(void*, const void*, long unsigned int)'
This looks related to PR 105705. Before gcc-12 the warning was already present,
but only when using -Wsystem-headers
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 --- Comment #7 from Andreas Schwab --- Are you sure this isn't due to the binutils patch?
[Bug libstdc++/108517] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > This looks related to PR 105705. Before gcc-12 the warning was already > present, but only when using -Wsystem-headers Sorry, meant to say the *second* warning was already present. The first one seems new in gcc-11.1.0 and is not affected by -Wsystem-headers before that.
[Bug tree-optimization/108500] [11/12/13 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 Richard Biener changed: What|Removed |Added Summary|-O -finline-small-functions |[11/12/13 Regression] -O |results in "internal|-finline-small-functions |compiler error: |results in "internal |Segmentation fault" on a|compiler error: |very large program (700k|Segmentation fault" on a |function calls) |very large program (700k ||function calls) Target Milestone|--- |11.4 Known to work||10.4.0, 7.5.0, 9.3.1 --- Comment #7 from Richard Biener --- It works with GCC 10 for me but I'm sure that makes it a regression only because of the size of the testcase, it still inlines everything and removes 1399835 blocks.
[Bug c++/108517] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #3 from Jonathan Wakely --- Changing component, as libstdc++ isn't causing this. The compiler is probably creating an unreachable branch via jump threading, and then warning about it.
[Bug c++/108517] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
--- Comment #4 from Jonathan Wakely ---
Libstdc++ isn't causing it, but we can give the compiler enough information to
make it shut up:
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -1814,6 +1814,10 @@ _GLIBCXX_END_INLINE_ABI_NAMESPACE(_V2)
{
if (__first == __last) return;
+ if (__first == _RandomAccessIterator()
+|| __last == _RandomAccessIterator())
+__builtin_unreachable();
+
for (_RandomAccessIterator __i = __first + 1; __i != __last; ++__i)
{
if (__comp(__i, __first))
As you can see there, we already return early and never reach line 1819 where
the dereference happens. We can tell the compiler that it's impossible to get
to that that dereference with a value-initialized iterator, because if one is
null the other must be, and so we'd already have returned.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Richard Biener changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 from Richard Biener --- (In reply to Andreas Schwab from comment #7) > Are you sure this isn't due to the binutils patch? There were successful builds in December, so I thought that arm32-avoid-copyreloc.patch was already in? Are you refering to that?
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 --- Comment #9 from Martin Liška --- (In reply to Richard Biener from comment #8) > (In reply to Andreas Schwab from comment #7) > > Are you sure this isn't due to the binutils patch? > > There were successful builds in December, so I thought that > arm32-avoid-copyreloc.patch was already in? Are you refering to that? This was added 4 days ago https://build.opensuse.org/request/show/1060005 with the following comment: I'll accept this, but note that the arm32 patch might be broken: from https://sourceware.org/bugzilla/show_bug.cgi?id=16177 : Nick Clifton 2022-10-17 10:34:16 UTC The patch still suffers from the problem triggered by the example in comment #12
[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
--- Comment #18 from Jakub Jelinek ---
Slightly adjusted testcase for -O2 which actually aborts at runtime quite
reliably:
struct A
{
signed char a1;
int a2;
};
struct B
{
struct A b1;
unsigned char b2:1, b3:1, b4:2, b5:1, b6:1, b7[4];
};
struct C
{
unsigned char c1;
char c2;
signed char c3;
unsigned char c4, c5[4], c6:1, c7:1, c8:1, c9:3, c10:1;
struct A c11;
struct B c12[3];
};
static inline struct C
foo (unsigned char a, unsigned b, int c, struct A d,
unsigned e, struct B f, struct B g, struct B h)
{
struct C x
= { .c1 = b, .c2 = 0, .c3 = c, .c6 = a, .c4 = e, .c7 = 0,
.c8 = 0, .c9 = 7, .c10 = 0, .c5 = {0, 1, 2, 3}, .c11 = d,
.c12 = {f, g, h} };
return x;
}
static inline struct A
bar (int a, int b)
{
struct A x = { .a1 = a, .a2 = b };
return x;
}
static inline struct B
baz (struct A b1)
{
struct B x = { .b1 = b1, .b6 = 0, .b5 = 0, .b7 = {0, 1, 2, 3}, .b2 = 0 };
return x;
}
struct C
qux (void)
{
const struct B a = baz (bar (0, 0));
struct C b;
struct B c[2];
struct A d = { 0, 1 };
c[0].b1.a1 = 0;
c[0].b1.a2 = 2;
c[1].b1.a1 = 4;
c[1].b1.a2 = 8;
return foo (0, 2, -1, d, 3, c[0], c[1], a);
}
__attribute__((noipa)) void
corge (struct C *x)
{
char buf[1024];
__builtin_memset (buf, 0xaa, sizeof (buf));
asm volatile ("" : : "r" (buf));
__builtin_memset (x, 0x55, sizeof (struct C));
asm volatile ("" : : "r" (x));
}
int
main ()
{
struct C x;
corge (&x);
x = qux ();
if (x.c6 || x.c9 != 7)
__builtin_abort ();
}
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #10 from Richard Earnshaw ---
Almost certainly this is related to the need for a copyreloc and presumably the
linker has not created one for some reason. So I suspect this is most likely a
binutils issue rather than a compiler one. The code generated for the simple
test is just
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr3, #:lower16:stderr
movtr3, #:upper16:stderr
push{r4, lr}
movwr0, #:lower16:.LC0
movtr0, #:upper16:.LC0
ldr r1, [r3]
bl printf
mov r0, #0
pop {r4, pc}
And the references to stderr will require the definition to be moved from the
shared library to the static image during linking.
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Jonathan Wakely changed: What|Removed |Added CC||msebor at gcc dot gnu.org Summary|std::sort of empty range|[11/12/13 Regression] |yield "warning: 'this' |std::sort of empty range |pointer is null"|yield "warning: 'this' ||pointer is null" Known to fail||11.1.0 Known to work||10.4.0 --- Comment #5 from Jonathan Wakely --- The warning started with r11-1697: Underline argument in -Wnonnull and in C++ extend warning to the this pointer [PR c++/86568]. Resolves: PR c++/86568 - -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #11 from Richard Biener ---
(In reply to Richard Earnshaw from comment #10)
> Almost certainly this is related to the need for a copyreloc and presumably
> the linker has not created one for some reason. So I suspect this is most
> likely a binutils issue rather than a compiler one. The code generated for
> the simple test is just
>
> main:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> movwr3, #:lower16:stderr
> movtr3, #:upper16:stderr
> push{r4, lr}
> movwr0, #:lower16:.LC0
> movtr0, #:upper16:.LC0
> ldr r1, [r3]
> bl printf
> mov r0, #0
> pop {r4, pc}
>
> And the references to stderr will require the definition to be moved from
> the shared library to the static image during linking.
So eventually linking with -Wl,-z,nocopyreloc will fail?
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Richard Biener changed: What|Removed |Added Blocks||95507 Target Milestone|--- |11.4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug fortran/108512] [13 Regression][OpenMP] ICE for valid loop data-sharing clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Version|unknown |13.0
[Bug target/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-24 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed: Trying 16 -> 6: 16: r86:QI#0=zero_extract(r87:HI,0x8,0x8) REG_DEAD r87:HI 6: r84:SI=zero_extend(r86:QI) REG_DEAD r86:QI Failed to match this instruction: (set (reg:SI 84 [ s.e2 ]) (zero_extract:SI (reg:HI 87) (const_int 8 [0x8]) (const_int 8 [0x8])))
[Bug target/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug rtl-optimization/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Andrew Pinski changed: What|Removed |Added Component|target |rtl-optimization --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Confirmed: > > Trying 16 -> 6: >16: r86:QI#0=zero_extract(r87:HI,0x8,0x8) > REG_DEAD r87:HI > 6: r84:SI=zero_extend(r86:QI) > REG_DEAD r86:QI > Failed to match this instruction: > (set (reg:SI 84 [ s.e2 ]) > (zero_extract:SI (reg:HI 87) > (const_int 8 [0x8]) > (const_int 8 [0x8]))) Hmm, is this even valid RTL that combine is producing ... If there was a subreg to SI mode there from the HI mode reg, it would match correctly.
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 --- Comment #4 from Martin Liška --- ~/Programming/gcc2/configure --enable-languages=c --prefix=/home/marxin/bin/gcc --disable-bootstrap --disable-multilib --disable-libsanitizer --target=powerpc-freebsd13
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 --- Comment #5 from Martin Liška --- Created attachment 54334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54334&action=edit Configure and build log
[Bug sanitizer/108510] ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-01-24 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please report a test-case that does not contain the following violation: pr108510.c:9:7: warning: assignment to ‘short int *’ from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Andrew Pinski --- checking for as... no checking for powerpc-freebsd13-as... no So the answer to my question of did you compile binutils first is no and you are not doing a combined build either: checking where to find the target as... pre-installed So this is not a bug that needs to be fixed really.
[Bug ipa/108509] [13 Regression] ICE in add, at hash-set.h:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2023-01-24 --- Comment #1 from Martin Liška --- Pretty much the same as PR108330, let me fix it.
[Bug sanitizer/108510] ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510
--- Comment #2 from Li Shaohua ---
Sure: (compiler explorer: https://godbolt.org/z/3qEavnan5)
% cat a.c
int a;
char b;
int *c = &a, *d;
long e;
int main() {
long *f = &e;
{
int g=0;
d = &g;
}
*d << (b = ((*f)--, c || *d));
}
%
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 Segher Boessenkool changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #7 from Segher Boessenkool --- It is not a bug even. However, our documentation could be clearer that you need a working assembler and linker etc., and the hint that putting binutils in the same prefix (before doing GCC) makes everything automatically work could be helpful?
[Bug ipa/108509] [13 Regression] ICE in add, at hash-set.h:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509 --- Comment #2 from Martin Liška --- I'm testing a patch.
[Bug sanitizer/108510] ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Martin Liška ---
(In reply to Li Shaohua from comment #2)
> Sure: (compiler explorer: https://godbolt.org/z/3qEavnan5)
>
> % cat a.c
> int a;
> char b;
> int *c = &a, *d;
> long e;
> int main() {
> long *f = &e;
> {
> int g=0;
> d = &g;
> }
So if c is non-zero, then we don't need to load *d here. Plus, the result of
the expression is unused, so the leftmost *d does not play any role.
> *d << (b = ((*f)--, c || *d));
> }
> %
If you change it to:
*d <<= (b = ((*f)--, c || *d));
you will hit the ASAN error.
[Bug target/108491] cross compiler does not work: cc1: error: ‘-msecure-plt’ not supported by your assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #8 from Alexander Monakov --- Isn't this what --with-gnu-as --with-gnu-ld options are for?
[Bug sanitizer/108497] UBsan at -O1 failed to report an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108497 --- Comment #2 from Martin Liška --- @Jakub: Can you please take a look?
[Bug c/108518] New: Format-overflow warning using `*.s` directive with null but zero-length string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108518
Bug ID: 108518
Summary: Format-overflow warning using `*.s` directive with
null but zero-length string
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron at aarongraham dot com
Target Milestone: ---
https://godbolt.org/z/YGra91Woa
#include
int main() {
// This causes a format-overflow warning, but it
// should not warn if size() is 0
printf("%.*s\n", 0, (char*)0);
}
The warning is:
: In function 'int main()':
:6:13: warning: '%.*s' directive argument is null [-Wformat-overflow=]
6 | printf("%.*s\n", 0, (char*)0);
| ^~~~
I see this commonly when using std::string_view with printf. In cases where it
knows that you're passing a default-constructed string_view it produces this
warning.
It should not produce this warning if the length being printed is 0.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #12 from Richard Biener --- Reverting the linker patch gets past the failure point.
[Bug sanitizer/108497] UBsan at -O1 failed to report an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108497 --- Comment #3 from Jakub Jelinek --- Not now nor in the near future. After all, it isn't a regression, so couldn't be fixed during stage4 anyway.
[Bug c/107994] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107994 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:45cff68d063b689bd6a9f30827b1fdd3f5ea2cb4 commit r12-9063-g45cff68d063b689bd6a9f30827b1fdd3f5ea2cb4 Author: Richard Biener Date: Wed Dec 21 12:27:58 2022 +0100 middle-end/107994 - ICE after error with comparison gimplification The following avoids passing down error_mark_node to fold_convert. PR middle-end/107994 * gimplify.cc (gimplify_expr): Catch errorneous comparison operand. (cherry picked from commit 845b514e8a150447ba041294586af76a6ac05158)
[Bug tree-optimization/108076] [10/11/12 Regression] GCC with -O3 produces code which fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108076 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a3dfcaac560f5589028fdd967bfaa60d84c265ac commit r12-9064-ga3dfcaac560f5589028fdd967bfaa60d84c265ac Author: Richard Biener Date: Mon Dec 12 17:52:46 2022 +0100 tree-optimization/108076 - if-conversion and forced labels When doing if-conversion we simply throw away labels without checking whether they are possibly targets of non-local gotos or have their address taken. The following rectifies this and refuses to if-convert such loops. PR tree-optimization/108076 * tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks with non-local or forced labels that we later remove labels from. * gcc.dg/torture/pr108076.c: New testcase. (cherry picked from commit b4fddbe9592e9feb37ce567d90af822b75995531)
[Bug c/107994] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107994 Richard Biener changed: What|Removed |Added Known to work||12.2.1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||12.2.0 --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/107554] [10/11/12 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ca8b8191983d1a211a718b39ca07e35b8c626416 commit r12-9062-gca8b8191983d1a211a718b39ca07e35b8c626416 Author: Richard Biener Date: Fri Nov 11 14:28:52 2022 +0100 tree-optimization/107554 - fix ICE in stlen optimization The following fixes a wrongly typed variable causing an ICE. PR tree-optimization/107554 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Use unsigned HOST_WIDE_INT type for the strlen. * gcc.dg/pr107554.c: New testcase. Co-Authored-By: Nikita Voronov (cherry picked from commit 81de4037454275f8ed6d858fbc129e832c6147ef)
[Bug tree-optimization/108164] [12 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu since r12-5267-g540d92ae9b629eb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Status|ASSIGNED|RESOLVED Known to work||12.2.1 Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/108164] [12 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu since r12-5267-g540d92ae9b629eb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:50ef4fc8c848929ee79af97ac445a45baab7d575 commit r12-9065-g50ef4fc8c848929ee79af97ac445a45baab7d575 Author: Richard Biener Date: Mon Dec 19 14:55:45 2022 +0100 tree-optimization/108164 - undefined overflow with IV vectorization vect_update_ivs_after_vectorizer can end up emitting a signed IV update when the loop body performed an unsigned computation. The following makes sure to perform that update in the type of the loop update type to avoid undefined behavior on overflow. PR tree-optimization/108164 * tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer): Perform vect_step_op_add update in the appropriate type. * gcc.dg/pr108164.c: New testcase. (cherry picked from commit ec459469f8a75d96a9b26694554efcc900d411de)
[Bug tree-optimization/108500] [11/12/13 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f31fa9ea35ebcf221a2abaacba5511225f5d036e commit r13-5325-gf31fa9ea35ebcf221a2abaacba5511225f5d036e Author: Richard Biener Date: Tue Jan 24 10:49:18 2023 +0100 tree-optimization/108500 - avoid useless fast-query compute in CFG cleanup CFG cleanup computes dominators before the loop over blocks looking for merging opportunities. That computes also the fast-query DFS numbers but that's a bit pointless since any CFG cleanup will invalidate them immediately (they are re-computed before fixing up loops). The following avoids this and fixes the SIGSEGV due to the deep recursion in assign_dfs_numbers after inlining very many small functions. PR tree-optimization/108500 * dominance.h (calculate_dominance_info): Add parameter to indicate fast-query compute, defaulted to true. * dominance.cc (calculate_dominance_info): Honor fast-query compute parameter. * tree-cfgcleanup.cc (cleanup_tree_cfg_noloop): Do not compute the dominator fast-query DFS numbers.
[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 Richard Biener changed: What|Removed |Added Summary|[11/12/13 Regression] -O|[11/12 Regression] -O |-finline-small-functions|-finline-small-functions |results in "internal|results in "internal |compiler error: |compiler error: |Segmentation fault" on a|Segmentation fault" on a |very large program (700k|very large program (700k |function calls) |function calls) Known to fail||12.2.1 Known to work||13.0 --- Comment #9 from Richard Biener --- The testcase now works on trunk by means of avoiding the recursion before CFG cleanup.
[Bug other/108519] New: [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519 Bug ID: 108519 Summary: [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd Product: gcc Version: 13.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: --- g:733a1b777f16cd397b43a242d9c31761f66d3da8, r13-5154-g733a1b777f16cd This test is failing on some powerpc64 LE systems. make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr105586.c" FAIL: gcc.target/powerpc/pr105586.c (test for excess errors) # of unexpected failures1 /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c -fdiagnostics-plain-output -mdejagnu-tune=power4 -O2 -fcompare-debug -fno-if-conversion -fno-guess-branch-probability -S -o pr105586.s^M xgcc: error: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c: '-fcompare-debug' failure (length)^M compiler exited with status 1 FAIL: gcc.target/powerpc/pr105586.c (test for excess errors) Excess errors: xgcc: error: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr105586.c: '-fcompare-debug' failure (length) commit 733a1b777f16cd397b43a242d9c31761f66d3da8 (HEAD, refs/bisect/bad) Author: Alexander Monakov Date: Fri Jan 13 21:04:02 2023 +0300 sched-deps: do not schedule pseudos across calls [PR108117]
[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519 Richard Biener changed: What|Removed |Added Keywords||compare-debug-failure, ||testsuite-fail Component|other |rtl-optimization Target Milestone|--- |13.0 Priority|P3 |P1
[Bug tree-optimization/107212] [11 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107212 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2461fa40fc24a403dc8149338f44b0e4aef4f173 commit r11-10480-g2461fa40fc24a403dc8149338f44b0e4aef4f173 Author: Richard Biener Date: Tue Oct 11 11:34:55 2022 +0200 tree-optimization/107212 - SLP reduction of reduction paths The following fixes an issue with how we handle epilogue generation for SLP reductions of reduction paths where the actual live lanes are not "canonical". We need to make sure to identify all live lanes as reductions and thus have to iterate over all participating SLP lanes when walking the reduction SSA use-def chain. Also the previous attempt likely to mitigate such issue in vectorizable_live_operation is misguided and has to be removed. PR tree-optimization/107212 * tree-vect-loop.c (vectorizable_reduction): Make sure to set STMT_VINFO_REDUC_DEF for all live lanes in a SLP reduction. (vectorizable_live_operation): Do not pun to the SLP node representative for reduction epilogue generation. * gcc.dg/vect/pr107212-1.c: New testcase. * gcc.dg/vect/pr107212-2.c: Likewise. (cherry picked from commit ee467644c53ee2f7d633a8e1f53603feafab4351)
[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (Fortran) since r11-1501-gda2b7c7f0a136b4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107254 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:fb335c938bbd54e83af2d281f0ccf79df1c342b3 commit r11-10481-gfb335c938bbd54e83af2d281f0ccf79df1c342b3 Author: Richard Biener Date: Fri Oct 14 11:14:59 2022 +0200 tree-optimization/107254 - check and support live lanes from permutes The following fixes an omission from adding SLP permute nodes which is live lanes originating from those. We have to check that we can extract the lane and have to actually code generate them. PR tree-optimization/107254 * tree-vect-slp.c (vect_slp_analyze_node_operations_1): For permutes also analyze live lanes. (vect_schedule_slp_node): For permutes also code generate live lane extracts. * gfortran.dg/vect/pr107254.f90: New testcase. (cherry picked from commit 9ed4a849afb5b18b462bea311e7eee454c2c9f68)
[Bug tree-optimization/107323] [10/11 Regression] Loop distribute issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:28fe903730d2c6e424732184ab2d8b1e7d46db6c commit r11-10482-g28fe903730d2c6e424732184ab2d8b1e7d46db6c Author: Richard Biener Date: Fri Oct 21 09:45:44 2022 +0200 tree-optimization/107323 - loop distribution partition ordering issue The following reverts part of the PR94125 fix which causes us to use a bogus partition ordering after applying versioning for alias to the testcase in PR107323. Instead PR94125 is fixed by appropriately considering to be merged SCCs when skipping edges we want to ignore because of the alias versioning. PR tree-optimization/107323 * tree-loop-distribution.c (pg_unmark_merged_alias_ddrs): New function. (loop_distribution::break_alias_scc_partitions): Revert postorder save/restore from the PR94125 fix. Instead make sure to not ignore edges from SCCs we are going to merge. * gcc.dg/tree-ssa/pr107323.c: New testcase. (cherry picked from commit 09f9814dc02c161ed78604c6df70b19b596f7524)
[Bug tree-optimization/107554] [10/11 Regression] Segmentation fault during GIMPLE pass: strlen (tree-ssa-strlen.cc:4772)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107554 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:23a9270c999a24cdc0b716e832e5f16bb13db891 commit r11-10483-g23a9270c999a24cdc0b716e832e5f16bb13db891 Author: Richard Biener Date: Fri Nov 11 14:28:52 2022 +0100 tree-optimization/107554 - fix ICE in stlen optimization The following fixes a wrongly typed variable causing an ICE. PR tree-optimization/107554 * tree-ssa-strlen.c (strlen_pass::count_nonzero_bytes): Use unsigned HOST_WIDE_INT type for the strlen. * gcc.dg/pr107554.c: New testcase. Co-Authored-By: Nikita Voronov (cherry picked from commit 81de4037454275f8ed6d858fbc129e832c6147ef)
[Bug tree-optimization/107212] [11 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107212 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|11.5|11.4 Known to work||11.3.1 Known to fail||11.3.0 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/107254] [11 Regression] Wrong vectorizer code (Fortran) since r11-1501-gda2b7c7f0a136b4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107254 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.3.1 Status|ASSIGNED|RESOLVED --- Comment #13 from Richard Biener --- Fixed.
[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #10 from Qing Zhao ---
> --- Comment #9 from Richard Biener ---
>
> GCC handles for example
>
> struct A { char data[1]; };
> struct B { int n; struct A a; };
>
> as if the a.data[] array is a flex-array.
Okay. Then the maximum size of __builtin_object_size for it should be -1,
right?
> It also handles
>
> struct C { int n; struct A a; int x; };
>
> as if a.data[] can be up to 4 elements large (we allow an array to extend
> flexibly to padding - but only if it is trailing).
A little confused here:
when the structure with a trailing flexible-array member is a middle
field of
an outer structure, GCC extension will treat it as a flexible-array
too? But the
maximum size of this flexible-array will be bounded by the size of the
padding
of that field?
Is the above understanding correct?
> I see that's not
> consistently handled though.
>
> I think the [] syntax should follow the C standard as what testcases are
> accepted/rejected by the frontend and any extensions there should be
> documented
Agreed, usually where these extension should be documented?
> (those are separate from what the former array_at_struct_end_p
> allowed semantically
So, your mean to leave such extension out of “array_at_struct_end_p” (the
current “array_ref_flexible_size_p”)?
Handle them separately instead?
[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #19 from Jakub Jelinek ---
So, the problem is the separate string_concatenate mode introduced in that
r11-1810-ge362a897655e3b92949b65a2b53e00fb3ab8ded0 commit.
This mode is turned on whenever at least one of the stores is using a
STRING_CST and is successfully merged with the other stores.
Now, this mode assumes that the start of the store is on a byte boundary and
that the store ends on a byte boundary too, it simply creates a character array
with try_size / BITS_PER_UNIT and ignores any masking.
It is true that merged_store_group::can_be_merged_into does various checks, if
string_concatenation mode is on, it will reject merging with MEM_REF, etc.,
plus
/* STRING_CST is compatible with INTEGER_CST if no BIT_INSERT_EXPR. */
if (info->rhs_code == STRING_CST
&& stores[0]->rhs_code == INTEGER_CST
&& stores[0]->bitsize == CHAR_BIT)
return !bit_insertion;
if (stores[0]->rhs_code == STRING_CST
&& info->rhs_code == INTEGER_CST
&& info->bitsize == CHAR_BIT)
return !bit_insertion;
and also merged_store_group::do_merge turns this mode off if:
/* But we cannot use it if we don't have consecutive stores. */
if (!consecutive)
string_concatenation = false;
and on if:
/* We want to use concatenation if there is any string. */
if (info->rhs_code == STRING_CST)
{
string_concatenation = true;
gcc_assert (!bit_insertion);
}
Now, if the goal is to only do the string_concatenation mode if it is some set
single character stores and at least one or more STRING_CST stores, the above
doesn't achieve that by far.
The first cited hunk above from can_be_merged_into allows it if the first store
is char sized integral store and some later is STRING_CST. It doesn't check if
that
first store is byte aligned, and doesn't check all the other stores in between.
All do_merge then does is if the stores aren't consecutive the
string_concatenation mode is turned off. So e.g. we reject merging if there is
2 byte INTEGER_CST store followed by consecutive STRING_CST, but allow 1, 2 and
4 byte INTEGER_CST stores followed by STRING_CST (all consecutive), or say 1
byte, then 3 bits, then STRING_CST etc.
The second one is more strict, when the first store is STRING_CST, we punt on
any following INTEGER_CST store even when it is consecutive, if it isn't 1 byte
store.
Consider e.g. on x86_64-linux with -O2:
struct U { char c[16]; };
struct V { char c[16]; };
struct S { unsigned int a : 3, b : 8, c : 21; struct U d; unsigned int e;
struct V f; unsigned int g : 5, h : 27; };
struct T { unsigned int a : 16, b : 8, c : 8; struct U d; unsigned int e;
struct V f; unsigned int g : 5, h : 27; };
__attribute__((noipa)) void
foo (struct S *p)
{
p->b = 231;
p->c = 42;
p->d = (struct U) { "abcdefghijklmno" };
p->e = 0xdeadbeef;
p->f = (struct V) { "ABCDEFGHIJKLMNO" };
}
__attribute__((noipa)) void
bar (struct S *p)
{
p->b = 231;
p->c = 42;
p->d = (struct U) { "abcdefghijklmno" };
p->e = 0xdeadbeef;
p->f = (struct V) { "ABCDEFGHIJKLMNO" };
p->g = 12;
}
__attribute__((noipa)) void
baz (struct T *p)
{
p->c = 42;
p->d = (struct U) { "abcdefghijklmno" };
p->e = 0xdeadbeef;
p->f = (struct V) { "ABCDEFGHIJKLMNO" };
p->g = 12;
}
int
main ()
{
struct S s = {};
struct T t = {};
foo (&s);
if (s.a != 0 || s.b != 231 || s.c != 42
|| __builtin_memcmp (&s.d.c, "abcdefghijklmno", 16) || s.e != 0xdeadbeef
|| __builtin_memcmp (&s.f.c, "ABCDEFGHIJKLMNO", 16) || s.g != 0 || s.h !=
0)
__builtin_abort ();
__builtin_memset (&s, 0, sizeof (s));
s.a = 7;
s.g = 31;
s.h = (1U << 27) - 1;
foo (&s);
if (s.a != 7 || s.b != 231 || s.c != 42
|| __builtin_memcmp (&s.d.c, "abcdefghijklmno", 16) || s.e != 0xdeadbeef
|| __builtin_memcmp (&s.f.c, "ABCDEFGHIJKLMNO", 16) || s.g != 31 || s.h
!= (1U << 27) - 1)
__builtin_abort ();
__builtin_memset (&s, 0, sizeof (s));
bar (&s);
if (s.a != 0 || s.b != 231 || s.c != 42
|| __builtin_memcmp (&s.d.c, "abcdefghijklmno", 16) || s.e != 0xdeadbeef
|| __builtin_memcmp (&s.f.c, "ABCDEFGHIJKLMNO", 16) || s.g != 12 || s.h
!= 0)
__builtin_abort ();
__builtin_memset (&s, 0, sizeof (s));
s.a = 7;
s.g = 31;
s.h = (1U << 27) - 1;
bar (&s);
if (s.a != 7 || s.b != 231 || s.c != 42
|| __builtin_memcmp (&s.d.c, "abcdefghijklmno", 16) || s.e != 0xdeadbeef
|| __builtin_memcmp (&s.f.c, "ABCDEFGHIJKLMNO", 16) || s.g != 12 || s.h
!= (1U << 27) - 1)
__builtin_abort ();
baz (&t);
if (t.a != 0 || t.b != 0 || t.c != 42
|| __builtin_memcmp (&t.d.c, "abcdefghijklmno", 16) || t.e != 0xdeadbeef
|| __builtin_memcmp (&t.f.c, "ABCDEFGHIJKLMNO", 16) || t.g != 12 || t.h
[Bug c/108520] New: [C2x] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520
Bug ID: 108520
Summary: [C2x] ICE in nonnull_arg_p, at tree.cc:14372 with -O1
and above (gnu::assume)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
Consider the following testcase. The important aspects are i) optimized, ii)
array of structures containing multiple elements, iii) assume.
Using 13.0.1 20230124 (experimental).
# cat assume.c
static
void f0() { }
[[ gnu::nonnull(1) ]]
void f1(void *)
{
const struct { void (*f)(); } af[] = {
{ f0 } , { f0 } , { f0 }
};
for (__typeof__(af[0]) * it = af, * const end = af + sizeof(af) /
sizeof(af[0]); it != end; ++it)
{
[[ gnu::assume (it->f) ]];
it->f();
}
}
# gcc -c -std=gnu2x -Wall -Wextra -O1 assume.c
during GIMPLE pass: ethread
assume.c: In function 'f1':
assume.c:16:3: internal compiler error: in nonnull_arg_p, at tree.cc:14372
---
(gdb) bt
#0 in fancy_abort(char const*, int, char const*) ()
#1 in nonnull_arg_p(tree_node const*) [clone .cold] ()
#2 in get_range_global (r=..., name=)
at <...>/src/gcc/gcc/value-query.cc:330
#3 in global_range_query::range_of_expr (this=,
r=..., expr=,
stmt=) at <...>/src/gcc/gcc/value-query.cc:406
#4 in gimple_infer_range::check_assume_func (this=,
call=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:87
#5 in gimple_infer_range::gimple_infer_range (this=,
s=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:166
#6 in infer_range_manager::register_all_uses (this=,
name=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:374
#7 in infer_range_manager::has_range_p (this=,
name=,
bb=) at <...>/src/gcc/gcc/gimple-range-infer.cc:273
#8 in infer_range_manager::maybe_adjust_range (this=,
r=..., name=,
bb=) at <...>/src/gcc/gcc/gimple-range-infer.cc:290
#9 in path_range_query::adjust_for_non_null_uses (this=, bb=)
at <...>/src/gcc/gcc/gimple-range-path.cc:502
#10 in path_range_query::compute_ranges (this=,
dependencies=)
at <...>/src/gcc/gcc/gimple-range-path.cc:623
#11 in back_threader::find_taken_edge_cond (this=,
path=..., cond=)
at <...>/src/gcc/gcc/bitmap.h:955
#12 in back_threader::maybe_register_path (this=,
profit=...)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:248
#13 in back_threader::find_paths_to_names (this=,
bb=,
interesting=, overall_paths=,
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:371
#14 in back_threader::find_paths_to_names (this=,
bb=,
interesting=, overall_paths=,
at <...>/src/gcc/gcc/bitmap.h:955
#15 in back_threader::maybe_thread_block (this=,
bb=)
at <...>/src/gcc/gcc/bitmap.h:955
#16 in back_threader::thread_blocks (this=)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:975
#17 in pass_thread_jumps_full::execute (this=,
fun=)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:1105
#18 in execute_one_pass (pass=)
at <...>/src/gcc/gcc/passes.cc:2644
#19 in execute_pass_list_1 (pass=)
at <...>/src/gcc/gcc/passes.cc:2753
#20 in execute_pass_list_1 (pass=)
at <...>/src/gcc/gcc/passes.cc:2754
#21 in execute_pass_list (fn=, pass=)
at <...>/src/gcc/gcc/passes.cc:2764
#22 in cgraph_node::expand (this=)
at <...>/src/gcc/gcc/context.h:48
#23 in symbol_table::compile (this=)
at <...>/src/gcc/gcc/cgraphunit.cc:2015
#24 in symbol_table::finalize_compilation_unit (this=)
at <...>/src/gcc/gcc/cgraphunit.cc:2302
#25 in compile_file () at <...>/src/gcc/gcc/toplev.cc:471
#26 in toplev::main(int, char**) ()
#27 in main (argc=<...>, argv=<...>) at <...>/src/gcc/gcc/main.cc:39
[Bug middle-end/108520] [13 Regression] [C2x] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520 Marek Polacek changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2023-01-24 Summary|[C2x] ICE in nonnull_arg_p, |[13 Regression] [C2x] ICE |at tree.cc:14372 with -O1 |in nonnull_arg_p, at |and above (gnu::assume) |tree.cc:14372 with -O1 and ||above (gnu::assume) Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 CC||mpolacek at gcc dot gnu.org Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #20 from Jakub Jelinek --- Created attachment 54335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54335&action=edit gcc13-pr108498.patch Untested fix (well, checked on both testcases on x86_64-linux -m32/-m64 and on the first one for powerpc64-linux -m64).
[Bug tree-optimization/108520] [13 Regression] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume and gnu::nonnull)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Summary|[13 Regression] [C2x] ICE |[13 Regression] ICE in
|in nonnull_arg_p, at|nonnull_arg_p, at
|tree.cc:14372 with -O1 and |tree.cc:14372 with -O1 and
|above (gnu::assume) |above (gnu::assume and
||gnu::nonnull)
--- Comment #2 from Andrew Pinski ---
Confirmed, simplified C/C++ testcase:
```
static void f0() { }
typedef void (*ft)();
struct st { ft f; };
#define array_s 3
[[ gnu::nonnull(1) ]]
void f1(void *)
{
struct st af[array_s] = {
{ f0 } , { f0 } , { f0 }
};
for (struct st *i = af, *e = af+array_s; i != e; i++)
{
[[ gnu::assume (i->f) ]];
i->f();
}
}
```
get_range_global is assuming (bad pun) that it can call nonnull_arg_p even for
non-current function parm_decls.
[Bug target/108515] Fails to link fixincl with unresolvable R_ARM_MOVW_ABS_NC reloca tion against symbol `stderr@@GLIBC_2.4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515 Richard Earnshaw changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #13 from Richard Earnshaw --- (In reply to Richard Biener from comment #11) > So eventually linking with -Wl,-z,nocopyreloc will fail? If you want to avoid copyrelocs you'll need to compile with -fpie.
[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503 Jason Merrill changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- Broken by r13-4461-gf13305518558f20ef2d460a74eb29dad5fce1350
[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug target/108521] New: doc/invoke.texi contains remnants of Cygwin options removed in 2010-10-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108521 Bug ID: 108521 Summary: doc/invoke.texi contains remnants of Cygwin options removed in 2010-10-07 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: Brian.Inglis at SystematicSw dot ab.ca Target Milestone: --- We are still getting questions about the `--no-/cygwin` options removed on *2010-10-07* because a remnant still appears under the *x86 Windows options* summary in gcc/doc/invoke.texi line 1476 in master. Attached patch removes the remnant to kill this for good; also submitted to gcc-patches from home email.
[Bug target/108521] doc/invoke.texi contains remnants of Cygwin options removed in 2010-10-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108521 Brian W. Inglis changed: What|Removed |Added CC||Brian.Inglis at SystematicSw dot a ||b.ca --- Comment #1 from Brian W. Inglis --- Created attachment 54336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54336&action=edit gcc/doc/invoke.texi: remove Cygwin options remnants from x86 Windows options summary
[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498 --- Comment #21 from Eric Botcazou --- > That said, I think especially for backports to 11/12 and perhaps even for 13 > the easiest will be the second option, clear string_merging on non-aligned > start/width. > > Eric, your thoughts on this? Yes, nonaligned strings do not make much sense. Where do they come from in your first testcase? Is it fold-const synthesizing STRING_CST from INTEGER_CST?
