[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
--- Comment #4 from Arseny Vakhrushev ---
Thanks a lot, Andrew! Totally my bad. Well, comparison seems to work too:
extern char _src[], _dst[], _end[]; // Defined by the linker
int main(void) {
char *src = &_src[0];
char *dst = &_dst[0];
char *end = &_end[0];
while (src < end) *dst++ = *src++;
return 0;
}
Are the asm("" : "+r" (p)) statements strictly needed?
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #3 from Andrew Pinski ---
#include
extern char _src[], _dst[]; // Defined by the linker
int main(void) {
char *l_src = src;
char *l_dst = dst;
asm ("" : "+r" (l_src));
asm ("" : "+r" (l_dst));
memcpy(l_src, l_dst + 1024, );
return 0;
}
--- CUT ---
Well this works too because you are not comparing the start and ends:
#include
extern char _src[], _dst[]; // Defined by the linker
int main(void) {
memcpy(&_dst[0], &_src[0] + 1024, );
return 0;
}
- CUT ---
Basically this is a C question really as _src/_dst is only size of 1 in the
original code you provided while in the above two cases it is an unknown size.
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939 --- Comment #2 from Arseny Vakhrushev --- Thanks for the quick reply! I've read the aforementioned comments, but can't get to see any similarities. May I ask you to recap what needs to be done in plain and simple words or direct me to the corresponding manual page?
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 Andrew Pinski changed: What|Removed |Added CC||neoxic at icloud dot com --- Comment #19 from Andrew Pinski --- *** Bug 106939 has been marked as a duplicate of this bug. ***
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- See bug 77964 comment #6 (and 7) on how to do this correctly. *** This bug has been marked as a duplicate of bug 77964 ***
[Bug c/106939] New: Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
Bug ID: 106939
Summary: Linker-defined symbols are stained due to 'array
subscript is partly outside array bounds' warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: neoxic at icloud dot com
Target Milestone: ---
Working with embedded applications, one often deals with manipulating memory
regions via symbols defined in a linker script. Please consider the following
snippet:
-
#include
extern char _src, _dst; // Defined by the linker
int main(void) {
memcpy(&_dst, &_src + 1024, );
return 0;
}
-
Compilation with GCC 12.2.0 yields lots of warnings:
-
$ cc -O2 -Wall -Wextra -fno-strict-aliasing -fwrapv a.c
a.c: In function ‘main’:
a.c:6:29: warning: array subscript 1024 is outside array bounds of ‘char[1]’
[-Warray-bounds]
6 | memcpy(&_dst, &_src + 1024, );
| ~~^~
a.c:3:13: note: at offset 1024 into object ‘_src’ of size 1
3 | extern char _src, _dst; // Defined by the linker
| ^~~~
a.c:6:9: warning: ‘memcpy’ forming offset [1, 1110] is out of the bounds [0, 1]
of object ‘_dst’ with type ‘char’ [-Warray-bounds]
6 | memcpy(&_dst, &_src + 1024, );
| ^
a.c:3:19: note: ‘_dst’ declared here
3 | extern char _src, _dst; // Defined by the linker
| ^~~~
-
These symbols are used as mere address anchors, they don't contain anything.
But no matter what I do like changing their type, casting their addresses, etc,
I can't get rid of the pesky sticky warnings now. Is there a clean way to work
around these warning without turning off Warray-bounds?
[Bug tree-optimization/106938] New: [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106938
Bug ID: 106938
Summary: [13 Regression] ICE in
predicate::init_from_control_deps
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) ICEs
when compiling the following testcase w/ -O1 -fno-ipa-pure-const -fno-tree-ccp
-Wuninitialized:
int n;
void
undefined (void);
__attribute__ ((returns_twice)) int
zero (void)
{
return 0;
}
void
bar (int)
{
int i;
for (i = 0; i < -1; ++i)
n = 0;
}
__attribute__ ((simd)) void
foo (void)
{
int uninitialized;
undefined ();
while (uninitialized < 1)
{
bar (zero ());
++uninitialized;
}
}
% gcc-13.0.0 -O1 -fno-ipa-pure-const -fno-tree-ccp -Wuninitialized -w -c
r1v5kswd.c
during GIMPLE pass: uninit
r1v5kswd.c: In function 'foo.simdclone.0':
r1v5kswd.c:22:1: internal compiler error: Segmentation fault
22 | foo (void)
| ^~~
0xeebbdf crash_signal
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/toplev.cc:314
0x1d2a191 gimple_code
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple.h:1807
0x1d2a191 predicate::init_from_control_deps(vec
const*, unsigned int, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple-predicate-analysis.cc:1776
0x1d2cc00 predicate::init_from_control_deps(vec
const*, unsigned int, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple-predicate-analysis.cc:1722
0x1d2cc00 uninit_analysis::init_from_phi_def(gphi*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple-predicate-analysis.cc:2116
0x1d2e9ab uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple-predicate-analysis.cc:2172
0x1d2ef59 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/gimple-predicate-analysis.cc:2195
0x1140e01 find_uninit_use
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-uninit.cc:1238
0x1141756 warn_uninitialized_phi
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-uninit.cc:1308
0x1141756 execute_late_warn_uninitialized
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-uninit.cc:1429
0x1141756 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-uninit.cc:1446
[Bug target/96072] ICE: Segmentation fault (in add_reg_note)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072 --- Comment #4 from Arseny Solokha --- They still ICE for me. % powerpc-e300c3-linux-gnu-gcc-13.0.0 -v Using built-in specs. COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-13.0.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/13.0.0/lto-wrapper Target: powerpc-e300c3-linux-gnu Configured with: /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220911/work/gcc-13-20220911/configure --host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/13.0.0 --includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13.0.0/include --datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0 --mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/man --infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13.0.0/include/g++-v13 --with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/13.0.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=yes --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20220911 (experimental) (GCC) % powerpc-e300c3-linux-gnu-gcc-13.0.0 -Q --help=target The following options are target specific: -G8 -m32 [enabled] -m64 [disabled] -mabi=altivec [disabled] -mabi=d32 [enabled] -mabi=d64 [disabled] -mabi=elfv1 [disabled] -mabi=elfv2 [disabled] -mabi=ibmlongdouble [enabled] -mabi=ieeelongdouble [disabled] -mabi=no-altivec [enabled] -mabi=vec-default [enabled] -mabi=vec-extabi [disabled] -mads [disabled] -maix-struct-return [enabled] -malign- natural -malign-branch-targets -mallow-movmisalign [disabled] -maltivec [disabled] -malways-hint -mavoid-indexed-addresses [disabled] -mbig [enabled] -mbig-endian [enabled] -mbionic [disabled] -mbit-align [disabled] -mbit-word[disabled] -mblock-compare-inline-limit= 63 -mblock-compare-inline-loop-limit=-1 -mblock-move-inline-limit=32 -mblock-ops-unaligned-vsx [disabled] -mblock-ops-vector-pair [disabled] -mbss-plt [disabled] -mcall-ABIlinux -mcmodel= small -mcmpb[disabled] -mcompat-align-parm [disabled] -mcpu=[default] -mcrypto [disabled] -mdebug= -mdirect-move [disabled] -mdlmzb [disabled] -meabi[disabled] -mefficient-unaligned-vsx [disabled] -memb [disabled] -mfloat128[disabled] -mfloat128-convert[disabled] -mfloat128-hardware [disabled] -mfp-in-toc [enabled] -mfprnd [disabled] -mfriz -mfull-toc[disabled] -mfused-madd -ffp-contract=fast -mgen-cell-microcode [ignored] -mglibc [enabled] -mgnu-attribute [enabled] -mhard-dfp[disabled] -mhard-float [enabled] -mhtm [disabled] -mieee128-constant[enabled] -minsert-sched-nops= -misel[disabled] -mlittle
[Bug middle-end/106928] 500.perlbench_r fail(VE) since r13-1933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928 --- Comment #3 from Jiu Fu Guo --- (In reply to Martin Liška from comment #2) > I think you missed -fno-finite-math-only option as documented here: > https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html#portability Thanks! It pass with -fno-finite-math-only.
[Bug target/100645] ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645 Kewen Lin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-09-14 --- Comment #1 from Kewen Lin --- I'll have a look.
[Bug target/97361] power10 unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alan Modra --- The bug report is nearly two years old, against gcc-11.0. I'd forgotten about it. Retesting just now shows current mainline does not hit the ICE, nor does current tip of gcc-11 branch.
[Bug target/97361] power10 unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||guihaoc at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #1 from Peter Bergner --- CCing some IBMers. I seem to recall some patches that went in recently from someone regarding condition code changes. Is this some fallout from that or something new?
[Bug target/101322] ICE in copy_to_mode_reg, at explow.c:651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101322 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Peter Bergner --- Fixed everywhere.
[Bug target/101322] ICE in copy_to_mode_reg, at explow.c:651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101322 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:8301b8e84d833467b435b33592e0aa599d2db582 commit r10-10983-g8301b8e84d833467b435b33592e0aa599d2db582 Author: Peter Bergner Date: Wed Aug 31 21:14:36 2022 -0500 rs6000: Don't ICE when we disassemble an MMA variable [PR101322] When we expand an MMA disassemble built-in with C++ using a pointer that is cast to a valid MMA type, the type isn't passed down to the expand machinery and we end up using the base type of the pointer which leads to an ICE. This patch enforces we always use the correct MMA type regardless of the pointer type being used. 2022-08-31 Peter Bergner gcc/ PR target/101322 * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Enforce the use of a valid MMA pointer type. gcc/testsuite/ PR target/101322 * g++.target/powerpc/pr101322.C: New test. (cherry picked from commit 2985049049f12b0aa3366ca244d387820385b9e8)
[Bug target/96072] ICE: Segmentation fault (in add_reg_note)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-09-13 --- Comment #3 from Segher Boessenkool --- None of these ICE, not at any optimisation level, for no Linux ABI. Is this fixed, are any special options needed?
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 --- Comment #6 from Tom Allen --- (In reply to Jonathan Wakely from comment #5) > (In reply to Tom Allen from comment #4) > > If this is the case, then when I have subdirectories which I explicitly do > > not want to copy, but files at the same level in the source directory which > > I do want to overwrite in their destinations, there is no way to perform the > > operation unless I manually iterate and check file types, then call > > copy_file(). > > I don't think that's quite true. You can still use filesystem::copy, you > just need to use copy_options specific to the file type. So iterate over the > directory contents and for directories, call filesystem::copy with no > arguments, and for files, call filesystem::copy with update_existing / > overwrite_existing. > > > That seems like a strange asymmetry compared to the recursive > > call. > > For a recursive call, passing copy_options that only make sense for files is > useful, because there could be files somewhere in a sub-dir that you want to > copy. Passing those when copying just a directory, without recursing, isn't > useful. > > For a shallow, non-recursive copy, I think it makes sense that you would > have to call copy for each file individually, and if you're already doing > that, it's not such a stretch to use arguments specific to the file type. > > In any case, that's what the standard says, so it's not a GCC bug. > > If you think this is a defect in the standard then report it to the > committee instead: > https://cplusplus.github.io/LWG/lwg-active.html#submit_issue In this case, would it be possible to add a warning to the compiler for this usage? Even with -Wall -Wextra it's silent, and since it functions as a no-op, it's somewhat confusing to track down.
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely --- (In reply to Tom Allen from comment #4) > If this is the case, then when I have subdirectories which I explicitly do > not want to copy, but files at the same level in the source directory which > I do want to overwrite in their destinations, there is no way to perform the > operation unless I manually iterate and check file types, then call > copy_file(). I don't think that's quite true. You can still use filesystem::copy, you just need to use copy_options specific to the file type. So iterate over the directory contents and for directories, call filesystem::copy with no arguments, and for files, call filesystem::copy with update_existing / overwrite_existing. > That seems like a strange asymmetry compared to the recursive > call. For a recursive call, passing copy_options that only make sense for files is useful, because there could be files somewhere in a sub-dir that you want to copy. Passing those when copying just a directory, without recursing, isn't useful. For a shallow, non-recursive copy, I think it makes sense that you would have to call copy for each file individually, and if you're already doing that, it's not such a stretch to use arguments specific to the file type. In any case, that's what the standard says, so it's not a GCC bug. If you think this is a defect in the standard then report it to the committee instead: https://cplusplus.github.io/LWG/lwg-active.html#submit_issue
[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936
--- Comment #2 from Aldy Hernandez ---
This assert was put here to make sure that the legacy get_value_range() wasn't
being called on stuff that legacy couldn't handle (floats, etc), because the
result would ultimately be copied into a value_range_equiv.
In this case, simplify_casted_cond() is calling it on an offset_type which
isn't either an integer nor a pointer, so the assert is failing. However,
range_of_expr happily punted on it because it couldn't handle it, so we're just
returning VARYING. As value_range_equiv can store VARYING types of anything
(including types it can't handle), this is fine.
I think the easiest thing to do is remove the assert. If someone from the non
legacy world tries to get a non integer/pointer range here, it's going to blow
up anyhow because the temporary in get_value_range is int_range_max.
Anywho. This should do the trick. I'm in transit to Cauldron. Could someone
test and push this? I'd hate to leave what looks like an ICE on valid code
open.
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 06ad5fe9708..0bdd670982b 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -167,7 +167,6 @@ range_query::free_value_range_equiv (value_range_equiv *v)
const class value_range_equiv *
range_query::get_value_range (const_tree expr, gimple *stmt)
{
- gcc_checking_assert (value_range_equiv::supports_p (TREE_TYPE (expr)));
int_range_max r;
if (range_of_expr (r, const_cast (expr), stmt))
return new (equiv_alloc->allocate ()) value_range_equiv (r);
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932
--- Comment #4 from Tom Allen ---
(In reply to Jonathan Wakely from comment #2)
> I think this is the correct behaviour according to the standard.
>
> Where f is status("source") and t is status("dest").
>
> Effects are then as follows:
>
> - If f.type() or t.type() is an implementation-defined file type ...
>
> [they're not]
>
> - Otherwise, an error is reported as specified in 31.12.5 if:
>
> [list of conditions that are not true]
>
> - Otherwise, if is_symlink(f), then:
>
> [it's not]
>
> - Otherwise, if is_regular_file(f), then:
>
> [it's not]
>
> - Otherwise, if
> is_directory(f) &&
> (options & copy_options::create_symlinks) != copy_options::none
>
> [create_symlinks is not set in the options]
>
> - Otherwise, if
> is_directory(f) &&
> ((options & copy_options::recursive) != copy_options::none ||
> options == copy_options::none)
>
> [this is the case we want to hit, but the condition is false because
> recursive is not set and options != none]
>
> - Otherwise, for the signature with argument ec, ec.clear().
>
> [You didn't pass an erroc_code]
>
> - Otherwise, no effects.
>
> [Bingo]
>
> So you need to use copy_options::recursive to get the effects you want.
If this is the case, then when I have subdirectories which I explicitly do not
want to copy, but files at the same level in the source directory which I do
want to overwrite in their destinations, there is no way to perform the
operation unless I manually iterate and check file types, then call
copy_file(). That seems like a strange asymmetry compared to the recursive
call.
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 --- Comment #7 from Ville Voutilainen --- Since this is a 13 regression, we can close this, right? There's no backports needed.
[Bug go/106747] [12 Regression] Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 Ian Lance Taylor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ian Lance Taylor --- Fixed on GCC 12 branch.
[Bug c++/106903] Incorrectly accepts call to function template when deduced type doesn't match adjusted type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106903 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=10 --- Comment #1 from Patrick Palka --- PR10 looks similar/related
[Bug fortran/106934] [10/11/12/13 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Keywords|needs-bisection | Ever confirmed|0 |1 Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE: verify_gimple failed |ICE: verify_gimple failed ||since ||r9-5682-gef310a95a934d0f3 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-13 --- Comment #1 from Martin Liška --- Started with the added verifier in r9-5682-gef310a95a934d0f3, likely a FE issue.
[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-13 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |get_value_range, at |get_value_range, at |value-query.cc:170 |value-query.cc:170 since ||r13-1815-g8b8103dcd2624936 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords|needs-bisection | --- Comment #1 from Martin Liška --- Started with r13-1815-g8b8103dcd2624936.
[Bug go/106747] [12 Regression] Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:23605c6a4eef5ca8ecb64d7006b60aeed241c29c commit r12-8763-g23605c6a4eef5ca8ecb64d7006b60aeed241c29c Author: Ian Lance Taylor Date: Tue Sep 13 13:11:17 2022 -0700 libgo: make runtime.Version return a meaningful string For golang/go#51850 Fixes PR go/106747 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/414734
[Bug c++/106937] [10/11/12/13 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606 since r10-1214-g1bf32c1141e23074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106937 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-13 Ever confirmed|0 |1 Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE tree check: expected|ICE tree check: expected |identifier_node, have |identifier_node, have |tree_list in|tree_list in |pp_tree_identifier, at |pp_tree_identifier, at |tree-pretty-print.cc:4606 |tree-pretty-print.cc:4606 ||since ||r10-1214-g1bf32c1141e23074 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Martin Liška --- Likely started with r10-1214-g1bf32c1141e23074.
[Bug ipa/106935] [10/11/12/13 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505 since r10-5098-g9b14fc3326e08797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||fxue at gcc dot gnu.org Summary|[12/13 Regression] ICE in |[10/11/12/13 Regression] |redirect_call_stmt_to_calle |ICE in |e, at cgraph.cc:1505|redirect_call_stmt_to_calle ||e, at cgraph.cc:1505 since ||r10-5098-g9b14fc3326e08797 Last reconfirmed||2022-09-13 --- Comment #1 from Martin Liška --- With -m32 -mandroid --param ipa-cp-eval-threshold=200 -Ofast -fno-semantic-interposition it started since r10-5098-g9b14fc3326e08797.
[Bug tree-optimization/106931] [12/13 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931 Martin Sebor changed: What|Removed |Added Summary|[12/13 Regression] |[12/13 Regression] |-Wstringop-overflow false |-Wstringop-overflow false |positive -O3 |positive -O3 |-fno-tree-vectorize since |-fno-tree-vectorize with |r12-3300-gece28da924ddda8b |loop unrolling since ||r12-3300-gece28da924ddda8b --- Comment #2 from Martin Sebor --- The false positive is issued for the store to A[i_90] in BB 10 by the strlen pass, where i_90's range is [8, 8]. [local count: 712060]: _35 = (sizetype) i_90; _36 = B.1_83 + _35; _37 = *_36; A[i_90] = _37;<< -Wstringop-overflow _20 = _93 + 9; i_39 = (int) _20; goto ; [100.00%] Changing i's type to unsigned avoids the warning. The IL looks very close but i_90's range in BB 10 is VR_UNDEFINED instead. The following is debug_ranger() output for BBs 9 and 10 in the original test case. === BB 9 Imports: _93 Exports: _8 i_90 _93 _8 : _93(I) _86 : i_82(I) _87 : i_82(I) B.1_83(I) _86 i_90 : _8 _93(I) i_82[irange] int [7, 7] NONZERO 0x7 _93 [irange] unsigned int [0, 0] NONZERO 0x0 Relational : (_8 > _93) [local count: 801058]: _86 = (sizetype) i_82; _87 = B.1_83 + _86; _88 = *_87; A[i_82] = _88; _8 = _93 + 8; i_90 = (int) _8; if (i_90 != 8) goto ; [88.89%] else goto ; [11.11%] _8 : [irange] unsigned int [8, 8] NONZERO 0x8 _86 : [irange] sizetype [7, 7] NONZERO 0x7 _87 : [irange] char * [1, +INF] i_90 : [irange] int [8, 8] NONZERO 0x8 9->10 (T) _8 : [irange] UNDEFINED 9->10 (T) i_90 : [irange] UNDEFINED 9->10 (T) _93 :[irange] UNDEFINED 9->12 (F) _8 : [irange] unsigned int [8, 8] NONZERO 0x8 9->12 (F) i_90 : [irange] int [8, 8] NONZERO 0x8 9->12 (F) _93 :[irange] unsigned int [0, 0] NONZERO 0x0 === BB 10 _93 [irange] UNDEFINED [local count: 712060]: _35 = (sizetype) i_90; _36 = B.1_83 + _35; _37 = *_36; A[i_90] = _37; _20 = _93 + 9; i_39 = (int) _20; goto ; [100.00%] whereas for the unsigned case: === BB 10 _85 [irange] UNDEFINED i_90[irange] UNDEFINED
[Bug fortran/106934] [10/11/12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Keywords||needs-bisection
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 --- Comment #3 from Jonathan Wakely --- (In reply to Tom Allen from comment #0) > This appears to be contrary to bullet 4.7.4 in Section 29.11.14.3 of the > C++20 spec, where for regular files in a source directory, the effect should > be equivalent to passing any options through to a copy_file() call on each > file. No, because f is not a regular file, it's the directory "source".
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932
--- Comment #2 from Jonathan Wakely ---
I think this is the correct behaviour according to the standard.
Where f is status("source") and t is status("dest").
Effects are then as follows:
- If f.type() or t.type() is an implementation-defined file type ...
[they're not]
- Otherwise, an error is reported as specified in 31.12.5 if:
[list of conditions that are not true]
- Otherwise, if is_symlink(f), then:
[it's not]
- Otherwise, if is_regular_file(f), then:
[it's not]
- Otherwise, if
is_directory(f) &&
(options & copy_options::create_symlinks) != copy_options::none
[create_symlinks is not set in the options]
- Otherwise, if
is_directory(f) &&
((options & copy_options::recursive) != copy_options::none ||
options == copy_options::none)
[this is the case we want to hit, but the condition is false because recursive
is not set and options != none]
- Otherwise, for the signature with argument ec, ec.clear().
[You didn't pass an erroc_code]
- Otherwise, no effects.
[Bingo]
So you need to use copy_options::recursive to get the effects you want.
[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||needs-bisection Component|c++ |tree-optimization
[Bug ipa/106935] [12/13 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |12.3 Component|c++ |ipa Keywords||needs-bisection
[Bug c++/106937] New: [10/11/12/13 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106937
Bug ID: 106937
Summary: [10/11/12/13 Regression] ICE tree check: expected
identifier_node, have tree_list in pp_tree_identifier,
at tree-pretty-print.cc:4606
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r10 around 20190623, file reduced from
llvm-project-llvmorg-14.0.6/clang/test/Sema/attr-nocf_check.cpp :
(gcc configured with --enable-checking=yes)
$ cat z1.cc
[[gnu::nocf_check]] typedef void (*FuncPointerWithNoCfCheck)(void);
typedef void (*FuncPointer)(void);
[[gnu::nocf_check]] void testNoCfCheck();
void testNoCfCheck(){};
int [[gnu::nocf_check]] i;
void testNoCfCheckImpl(double i [[gnu::nocf_check]]) {}
void testNoCfCheckMismatch(FuncPointer f) {
FuncPointerWithNoCfCheck fNoCfCheck = f;
(*fNoCfCheck)();
}
$ g++-13-20220911 -c z1.cc -fcf-protection
z1.cc:5:5: warning: attribute ignored [-Wattributes]
5 | int [[gnu::nocf_check]] i;
| ^
z1.cc:5:5: note: an attribute that appertains to a type-specifier is ignored
z1.cc:6:51: warning: 'nocf_check' attribute only applies to function types
[-Wattributes]
6 | void testNoCfCheckImpl(double i [[gnu::nocf_check]]) {}
| ^
In function 'void testNoCfCheckMismatch(FuncPointer)':
tree check: expected identifier_node, have tree_list in pp_tree_identifier, at
tree-pretty-print.cc:4606
8 | FuncPointerWithNoCfCheck fNoCfCheck = f;
| ^
0x6fc2fc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8827
0x12b5d03 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3520
0x12b5d03 pp_tree_identifier(pretty_printer*, tree_node*)
../../gcc/tree-pretty-print.cc:4606
0xbcd38a pp_c_attributes_display(c_pretty_printer*, tree_node*)
../../gcc/c-family/c-pretty-print.cc:909
0x91332e dump_type_prefix
../../gcc/cp/error.cc:904
0x913c83 dump_type
../../gcc/cp/error.cc:664
0x91ff6f type_to_string
../../gcc/cp/error.cc:3411
0x923847 cxx_format_postprocessor::handle(pretty_printer*)
../../gcc/cp/error.cc:4348
0x21da278 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1496
0x21b9f10 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1548
0x21ba65a diagnostic_impl
../../gcc/diagnostic.cc:1712
0x21bcdea permerror(rich_location*, char const*, ...)
../../gcc/diagnostic.cc:1994
0x80f736 convert_like_internal
../../gcc/cp/call.cc:7950
0x80ac97 convert_like
../../gcc/cp/call.cc:8501
0x80ac97 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:12791
0xb40d82 convert_for_assignment
../../gcc/cp/typeck.cc:10050
0xb414b2 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.cc:10141
0xb4bf1a digest_init_r
../../gcc/cp/typeck2.cc:1358
0xb4f100 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/typeck2.cc:1371
0xb4f100 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.cc:842
[Bug c++/106936] New: [13 Regression] ICE in get_value_range, at value-query.cc:170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936
Bug ID: 106936
Summary: [13 Regression] ICE in get_value_range, at
value-query.cc:170
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220717 and 20220724, at -O2+, reduced from
llvm-project-llvmorg-14.0.6/clang/test/Analysis/pointer-to-member.cpp :
(gcc configured with --enable-checking=yes)
$ cat z1.cc
namespace testPointerToMemberMiscCasts2 {
struct B {
int f;
};
struct L : public B { };
struct R : public B { };
struct D : public L, R { };
int B::* pb = ::f;
int R::* pr = pb;
int D::* pdr = pr;
}
$ g++-13-20220911 -c z1.cc -O2 -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre
during GIMPLE pass: vrp
z1.cc: In function '(static initializers for z1.cc)':
z1.cc:11:1: internal compiler error: in get_value_range, at value-query.cc:170
11 | }
| ^
0x153dd5b range_query::get_value_range(tree_node const*, gimple*)
../../gcc/value-query.cc:170
0x15a0aee simplify_using_ranges::simplify_casted_cond(gcond*)
../../gcc/vr-values.cc:3720
0x15a3f27 simplify_using_ranges::simplify(gimple_stmt_iterator*)
../../gcc/vr-values.cc:4420
0x14ff342 rvrp_folder::fold_stmt(gimple_stmt_iterator*)
../../gcc/tree-vrp.cc:4321
0x13d34a6 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-propagate.cc:870
0x1f34077 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.cc:311
0x13d2525 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc/tree-ssa-propagate.cc:987
0x14f38dd execute_ranger_vrp(function*, bool)
../../gcc/tree-vrp.cc:4349
[Bug c++/106935] New: [12/13 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 Bug ID: 106935 Summary: [12/13 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 2024 and 20211121, at -Ofast, with file g++.dg/ipa/pr71146.C : (gcc configured with --enable-checking=yes) $ g++-13-20220911 -c pr71146.C -m32 -mandroid --param ipa-cp-eval-threshold=200 -O3 $ $ g++-13-20220911 -c pr71146.C -m32 -mandroid --param ipa-cp-eval-threshold=200 -Ofast during IPA pass: inline pr71146.C: In member function 'void C::fn2()': pr71146.C:20:11: internal compiler error: in redirect_call_stmt_to_callee, at cgraph.cc:1505 20 | foo->fn (0, 0, 0); | ^ 0xc9e883 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*) ../../gcc/cgraph.cc:1505 0x1260f1f redirect_all_calls(copy_body_data*, basic_block_def*) ../../gcc/tree-inline.cc:3002 0x12645d3 copy_cfg_body ../../gcc/tree-inline.cc:3157 0x12645d3 copy_body ../../gcc/tree-inline.cc:3338 0x1267898 expand_call_inline ../../gcc/tree-inline.cc:5123 0x1269919 gimple_expand_calls_inline ../../gcc/tree-inline.cc:5318 0x1269919 optimize_inline_calls(tree_node*) ../../gcc/tree-inline.cc:5490 0xf2bc6b inline_transform(cgraph_node*) ../../gcc/ipa-inline-transform.cc:790 0x10c2e50 execute_one_ipa_transform_pass ../../gcc/passes.cc:2336 0x10c2e50 execute_all_ipa_transforms(bool) ../../gcc/passes.cc:2399 0xca5875 cgraph_node::expand() ../../gcc/cgraphunit.cc:1827 0xca7216 expand_all_functions ../../gcc/cgraphunit.cc:1998 0xca7216 symbol_table::compile() ../../gcc/cgraphunit.cc:2348 0xcaa8ef symbol_table::compile() ../../gcc/cgraphunit.cc:2532 0xcaa8ef symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2529
[Bug fortran/106934] New: [10/11/12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 Bug ID: 106934 Summary: [10/11/12/13 Regression] ICE: verify_gimple failed Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9 : (gcc configured with --enable-checking=yes) $ cat z1.f90 subroutine s logical(1) :: a = .true. logical(2) :: b a = transfer(b, a) end $ gfortran-13-20220911 -c z1.f90 -O2 z1.f90:5:3: 5 | end | ^ Error: 'bit_field_ref' of non-mode-precision operand _12 = BIT_FIELD_REF ; during GIMPLE pass: ccp z1.f90:5:3: internal compiler error: verify_gimple failed 0xf92e24 verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.cc:5569 0xe391ee execute_function_todo ../../gcc/passes.cc:2091 0xe39c72 execute_todo ../../gcc/passes.cc:2145
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #14 from Segher Boessenkool --- What is the exact command line (and relevant configuration!) required to reproduce this?
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||sayle at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |extract_insn, at|extract_insn, at |recog.cc:2791 (error: |recog.cc:2791 (error: |unrecognizable insn)|unrecognizable insn) since ||r13-2049-g6f94923dea21bd92 Last reconfirmed||2022-09-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started since r13-2049-g6f94923dea21bd92.
[Bug tree-optimization/106931] [12/13 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-13 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Keywords|needs-bisection | Status|UNCONFIRMED |NEW Summary|[12/13 Regression] |[12/13 Regression] |-Wstringop-overflow false |-Wstringop-overflow false |positive -O3 |positive -O3 |-fno-tree-vectorize |-fno-tree-vectorize since ||r12-3300-gece28da924ddda8b --- Comment #1 from Martin Liška --- Started with r12-3300-gece28da924ddda8b.
[Bug target/105587] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-210-gfcda0efccad41eba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105587 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Yes.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 105587, which changed state. Bug 105587 Summary: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-210-gfcda0efccad41eba https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105587 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/105587] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-210-gfcda0efccad41eba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105587 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #6 from Arseny Solokha --- Should this PR be closed now?
[Bug target/106877] [12/13 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877 --- Comment #4 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:ff85f0afc7d5684378944f88a9bc9b931034788b commit r13-2653-gff85f0afc7d5684378944f88a9bc9b931034788b Author: Roger Sayle Date: Tue Sep 13 19:49:20 2022 +0100 PR target/106877: Robustify reg-stack to malformed asm. This patch resolves PR target/106877 an ICE-on-invalid inline-asm regression. An innocent upstream change means that the test case from PR inline-asm/84683 now hits a different assert in reg-stack.cc's move_for_stack_reg. Fixed by duplicating Jakub's solution to PR 84683 https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495193.html at this second (similar) gcc_assert. 2022-09-13 Roger Sayle gcc/ChangeLog PR target/106877 * reg-stack.cc (move_for_stack_reg): Check for any_malformed_asm in gcc_assert. gcc/testsuite/ChangeLog PR target/106877 * g++.dg/ext/pr106877.C: New test case.
[Bug inline-asm/84683] [7 Regression] internal compiler error: in move_for_stack_reg, at reg-stack.c:1173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84683 --- Comment #7 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:ff85f0afc7d5684378944f88a9bc9b931034788b commit r13-2653-gff85f0afc7d5684378944f88a9bc9b931034788b Author: Roger Sayle Date: Tue Sep 13 19:49:20 2022 +0100 PR target/106877: Robustify reg-stack to malformed asm. This patch resolves PR target/106877 an ICE-on-invalid inline-asm regression. An innocent upstream change means that the test case from PR inline-asm/84683 now hits a different assert in reg-stack.cc's move_for_stack_reg. Fixed by duplicating Jakub's solution to PR 84683 https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495193.html at this second (similar) gcc_assert. 2022-09-13 Roger Sayle gcc/ChangeLog PR target/106877 * reg-stack.cc (move_for_stack_reg): Check for any_malformed_asm in gcc_assert. gcc/testsuite/ChangeLog PR target/106877 * g++.dg/ext/pr106877.C: New test case.
[Bug target/106933] New: [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Bug ID: 106933
Summary: [13 Regression] ICE in extract_insn, at recog.cc:2791
(error: unrecognizable insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) ICEs
when compiling the following testcase w/ -O2:
short int
bar (void);
__int128
empty (void)
{
}
__attribute__ ((simd)) int
foo (__int128 *p)
{
int a = 0x8000;
*p = empty ();
return *p == (a < bar ());
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -O2 -c ylbcgrld.c
ylbcgrld.c: In function 'foo.simdclone.2':
ylbcgrld.c:17:1: error: unrecognizable insn:
17 | }
| ^
(insn 73 72 74 3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:V1TI 20 xmm0 [orig:82 D.2028 ] [82])
(const_int 1 [0x1]))) "ylbcgrld.c":16:13 -1
(expr_list:REG_DEAD (reg:V1TI 20 xmm0 [orig:82 D.2028 ] [82])
(nil)))
during RTL pass: cprop_hardreg
ylbcgrld.c:17:1: internal compiler error: in extract_insn, at recog.cc:2791
0x730822 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:108
0x73083e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:116
0x72edc3 extract_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.cc:2791
0xe4dc0b extract_constrain_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.cc:2690
0xe58de6 copyprop_hardreg_forward_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/regcprop.cc:826
0xe59fbf execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/regcprop.cc:1408
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 --- Comment #1 from Tom Allen --- Created attachment 53573 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53573=edit Preprocessor output for minimal testcase reproducing this issue.
[Bug libstdc++/106932] New: Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932
Bug ID: 106932
Summary: Incorrect behavior of std::filesystem::copy() with
overwrite_existing or update_existing options
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.allen at intel dot com
Target Milestone: ---
When using std::filesystem::copy_options::overwrite_existing or
std::filesystem::copy_options::update_existing as part of a call to
std::filesystem::copy(), no destination directory is created, and the source
directory is not copied. In addition, no exception is thrown. If neither of
these options are specified, the behavior is as expected, creating the
destination directory and copying all regular files into it.
This appears to be contrary to bullet 4.7.4 in Section 29.11.14.3 of the C++20
spec, where for regular files in a source directory, the effect should be
equivalent to passing any options through to a copy_file() call on each file.
This bug occurs on SUSE Linux Enterprise Server 12 SP5, running on an Intel
Xeon Gold 6136 CPU.
Additionally, testing with GCC 10.2.0 and 12.2.0 shows the same issue.
The build configuration options used with GCC 11.3.0 specifically were:
/nfs/orto/proj/tapeout/cit_rep/ImagingToolsSupport/v2/bootstrap/build/sles12/gcc920/gcc/11.3.0/default/extract/gcc-11.3.0/configure
--prefix=/nfs/orto/proj/tapeout/cit_rep/ImagingToolsSupport/v2/bootstrap/install/sles12/gcc920/gcc/11.3.0/default
--with-specs='%{!static:%x{-rpath=/nfs/orto/proj/tapeout/cit_rep/ImagingToolsSupport/v2/bootstrap/install/sles12/gcc920/gcc/11.3.0/default/lib64:/nfs/orto/proj/tapeout/cit_rep/ImagingToolsSupport/v2/bootstrap/install/sles12/gcc920/gcc/11.3.0/default/lib}}'
--enable-lto
The command line which triggers this bug is:
g++ -std=c++20 -Wall -o dir_copy_test dir_copy_test.cpp
No errors or warnings are emitted by the compiler, and the source directory for
the test case is identical in structure to the one shown in the Notes section
at https://en.cppreference.com/w/cpp/filesystem/copy, i.e.
copy_test/
`-- source
|-- file1
|-- file3
`-- subdir
`-- file2
To produce the issue:
cd copy_test
dir_copy_test source dest
The preprocessor output for the test code is attached.
[Bug tree-optimization/106931] [12/13 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, needs-bisection Summary|-Wstringop-overflow false |[12/13 Regression] |positive|-Wstringop-overflow false ||positive -O3 ||-fno-tree-vectorize Target Milestone|--- |12.3
[Bug tree-optimization/106931] New: -Wstringop-overflow false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931 Bug ID: 106931 Summary: -Wstringop-overflow false positive Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kasper93 at gmail dot com Target Milestone: --- Created attachment 53572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53572=edit minimal test case Hello, I noticed increased amount of -Wstringop-overflow warnings on FFmpeg build with gcc 12.2.0, doesn't happen with gcc 11.3.0. At first glance most of them are bogus and happen only when specific set of compiler flags are used. I minimized one case, see attachment, it is pretty simple. I think gcc should handle this properly. Happens with this specific command gcc -O3 -fno-tree-vectorize -Wstringop-overflow -c test.c Attached case is minimized cbs_av1.c. For more cases which looks like gcc12 regression you can compile FFmpeg ./configure --enable-lto make Note that lto has to be enabled, without lto it doesn't produce those warnings. I can minimize more cases, but frankly I don't want to spend time minimizing it only to see the same pattern at the end. So maybe let's work on this first. Tested with FFmpeg 60d8c2019f Thanks, Kacper
[Bug libgomp/106906] libgomp/env.c: 3 * boolean value assigned to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106906 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Tweaked (not saying fixed because there is no bug to fix).
[Bug libgomp/106906] libgomp/env.c: 3 * boolean value assigned to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106906 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e11babbfac21163118b69dd25b468ade80dbe8de commit r13-2652-ge11babbfac21163118b69dd25b468ade80dbe8de Author: Jakub Jelinek Date: Tue Sep 13 19:00:02 2022 +0200 libgomp: Appease some static analyzers [PR106906] While icv_addr[1] = false; assignments where icv_addr has void * element type is correct and matches how it is used (in those cases the void * pointer is then cast to bool and used that way), there is no reason not to add explicit (void *) casts there which are there already for (void *) true. And, there is in fact even no point in actually doing those stores at all because we set that pointer to NULL a few lines earlier. So, this patch adds the explicit casts and then comments those out to show intent. 2022-09-13 Jakub Jelinek PR libgomp/106906 * env.c (get_icv_member_addr): Cast false to void * before assigning it to icv_addr[1], and comment the whole assignment out.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 106920, which changed state. Bug 106920 Summary: -Warray-bound false positive regression with -O2 or -Os and constant address https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- This is a deliberate change, dup of bug 105762. If the address is a valid address, you can also pass --param=min-pagesize=0 to say that all addresses are valid (see PR 99578). *** This bug has been marked as a duplicate of bug 105762 ***
[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762 Andrew Pinski changed: What|Removed |Added CC||npfhrotynz-ptnqh.myvf@noclu ||e.notk.org --- Comment #5 from Andrew Pinski --- *** Bug 106920 has been marked as a duplicate of this bug. ***
[Bug target/106536] P9: gcc does not detect setb pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106536 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-09-13 Status|UNCONFIRMED |NEW CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- Confirmed. GCC uses conditional branches here in expand already. It is hard to optimise this over that. Using -mcpu=power10 we don't get conditional branches: cmpld 7,3,4 # 8[c=4 l=4] *cmpdi_unsigned li 9,1 # 43 [c=4 l=4] *movsi_internal1/8 cmpld 0,3,4 # 45 [c=4 l=4] *cmpdi_unsigned setnbc 10,28 # 44 [c=4 l=4] *setnbc_unsigned_si isel 3,9,10,1# 46 [c=4 l=4] isel_unsigned_si/1 extsw 3,3# 24 [c=4 l=4] extendsidi2/1 blr # 51 [c=4 l=4] simple_return but this of course isn't ideal yet either. The branches aren't fully optimised away until ce2, which is *after* combine. ce1 didn't catch this, perhaps because the two conditional assignments are a bit intertwined there?
[Bug rtl-optimization/106751] internal compiler error: in purge_dead_edges with inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #7 from Segher Boessenkool ---
For me (powerpc64-linux) it fails with
===
106751.c:10:1: error: flow control insn inside a basic block
(jump_insn 6 3 13 2 (parallel [
(asm_operands/v ("") ("") 0 []
[]
[
(label_ref:DI 9)
] 106751.c:5)
(clobber (reg:SI 98 ca))
]) "106751.c":5:3 -1
(expr_list:REG_UNUSED (reg:SI 98 ca)
(nil))
-> 9)
during RTL pass: loop2_invariant
===
That pass did
===
Set in insn 13 is invariant (0), cost 4, depends on
Decided to move invariant 0 -- gain 4
Invariant 0 moved without introducing a new temporary register
changing bb of uid 13
from 3 to 2
===
It moved the insn after a jump_insn, not a good idea:
===
(jump_insn 6 3 13 2 (parallel [
(asm_operands/v ("") ("") 0 []
[]
[
(label_ref:DI 9)
] 106751.c:5)
(clobber (reg:SI 98 ca))
]) "106751.c":5:3 -1
(expr_list:REG_UNUSED (reg:SI 98 ca)
(nil))
-> 9)
(insn 13 6 9 2 (set (reg:SI 119)
(const_int 0 [0])) "106751.c":9:28 562 {*movsi_internal1}
(nil))
;; succ: 3 [always] count:10631108 (estimated locally)
===
Maybe it does not see this is an unconditional jump insn?
[Bug target/106895] powerpc64 strange extended inline asm behaviour with register pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Segher Boessenkool ---
wQ is a memory constraint, not a register constraint.
We have no way to express even/odd in register constraints. You can force
it some other way?
It's a lot easier if you use __atomic_* instead of inline asm? Like:
void f(unsigned __int128 *addr, unsigned __int128 val)
{
__atomic_store_n(addr, val, __ATOMIC_RELAXED);
}
Please reopen if you want something in particular to be changed. Thanks!
[Bug tree-optimization/106904] [12/13 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Summary|Incorrect |[12/13 Regression] |-Wstringop-overflow with|Incorrect |partial memcpy() into a |-Wstringop-overflow with |nested structure|partial memcpy() into a ||nested structure --- Comment #4 from Andrew Pinski --- (In reply to Zebediah Figura from comment #3) > From the warning, it seems like it thinks I wrote > > memcpy(>wp.hwnd, , sizeof(wp)); > > but that's not what I wrote. Oh I read the code wrong sorry about that.
[Bug c++/106926] string_view construction from literal string containing null/zero should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Blocks||87403 Last reconfirmed||2022-09-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- Is this a real problem you've seen in the wild? The same argument applies to std::string, doesn't it? To generalise it, I think we would probably want a new attribute telling the compiler that a character pointer argument will be passed to strlen, and only that many bytes used (i.e. it's treated as a "null-terminated byte string" in ISO C++ terminology). Then the compiler can warn if an argument to that function has unreachable characters. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/106929] declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- -std=c89 doesn't mean there aren't any extensions accepted, if you want the compiler to be pedantic, -pedantic or -pedantic-errors are the options to use as documented (the former just warns, the latter errors).
[Bug c/106929] declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929 --- Comment #4 from Michael Zimmermann --- Interesting, but IMO it should still fail if you specify an older C standard e.g. using `-std=c89`, but currently it doesn't.
[Bug c/106929] declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- It's also the documented behaviour: https://gcc.gnu.org/onlinedocs/gcc-11.3.0/gcc/Mixed-Labels-and-Declarations.html and in the release notes: https://gcc.gnu.org/gcc-11/changes.html#c So not a bug.
[Bug c/106929] declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929 --- Comment #2 from Jonathan Wakely --- For C17 (and previous standards), if you use -pedantic you'll get a warning, and -pedantic-errors will make it an error.
[Bug c/106929] declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929 --- Comment #1 from Jonathan Wakely --- This changed with r11-4813 and is intentional: C Parser: Implement mixing of labels and code. Implement mixing of labels and code as adopted for C2X and process some std-attributes on labels.
[Bug preprocessor/106930] New: No __ILP32__ preprocessor macro defined on ARM (32bit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106930 Bug ID: 106930 Summary: No __ILP32__ preprocessor macro defined on ARM (32bit) Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: stefan.bru...@rwth-aachen.de Target Milestone: --- For generic code, it is useful to have macros like __LP64__ and __ILP32__ everywhere. On ix86 (32bit), __ILP32__ is defined, while on ARM (e.g. ARMv7) it is not. IMHO __ILP32__ should be defined on *all* matching archs.
[Bug c/106929] New: declaration in switch-case doesn't fail since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106929
Bug ID: 106929
Summary: declaration in switch-case doesn't fail since GCC 11
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sigmaepsilon92 at gmail dot com
Target Milestone: ---
this code should fail because declarations inside switch-cases aren't allowed
without {}:
void fn(int a) {
switch (a) {
case 0:
int c = 5;
break;
}
}
Starting with gcc 11 this doesn't fail to compile anymore though.
The expected error message would look like this:
: In function 'fn':
:4:13: error: a label can only be part of a statement and a declaration
is not a statement
4 | int c = 5;
| ^~~
Compiler returned: 1
[Bug middle-end/106928] 500.perlbench_r fail(VE) since r13-1933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I think you missed -fno-finite-math-only option as documented here: https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html#portability
[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
Martin Liška changed:
What|Removed |Added
Summary|internal compiler error:|[12/13 Regression] ICE in
|Segmentation fault |maybe_splice_retval_cleanup
||at gcc/cp/except.cc:1330
||since
||r12-8066-g4822108e61ab8790
Target Milestone|--- |12.3
Last reconfirmed||2022-09-13
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Since r12-8066-g4822108e61ab8790, reduced test-case:
$ cat pr106925.ii
struct Foo;
template struct __array_traits { typedef Foo _Type[_Nm]; };
template struct array {
typename __array_traits<_Nm>::_Type _M_elems;
};
template struct MyVector { array data{}; };
struct Foo {
float a{0};
};
void foo(MyVector<1> = MyVector<1>());
[Bug middle-end/106928] 500.perlbench_r fail(VE) since r13-1933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928 --- Comment #1 from Jiu Fu Guo --- The out.mis file: 3258: # of abstol errors: 0 Minimum abstol: nan ^ 3259: Maximum reltol: 0.0e+00 # of abstol errors: 0 ^ 3260: # of reltol errors: 0 Maximum reltol: 0.0e+00 ^ 3261: # of obiwan errors: 0 Minimum reltol: nan ^ 3262: # of skiptol errors: 0 # of reltol errors: 0 ^ 3263: specdiff run completed # of obiwan errors: 0 ^ 3264: (0, 1): spec_diff(--lines, 10, --quiet, --calctol, --histogram, -m, --cw, one002, two003) # of skiptol errors: 0 ^ 3265: Absolute differences: specdiff run completed ^ 3266:* (0, 1): spec_diff(--lines, 10, --quiet, --calctol, --histogram, -m, --cw, one002, two003) ^ 3267:* Absolute differences: ^
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #13 from Yuri Gribov --- Posted to gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601041.html
[Bug middle-end/106928] New: 500.perlbench_r fail(VE) since r13-1933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106928 Bug ID: 106928 Summary: 500.perlbench_r fail(VE) since r13-1933 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: guojiufu at gcc dot gnu.org Target Milestone: --- With the latest trunk, the 500.perlbench_r (-Ofast) from spec2017 encounter VE on power9 and power10 on no matter with or without -fno-unsafe-math-optimizations. With bisect, the commit may be r13-1933 (Implement basic range operators to enable floating point VRP). One compiling command: gcc -std=c99 -m64 -c -o reentr.o -DSPEC -DNDEBUG -DPERL_CORE -I. -Idist/IO -Icpan/Time-HiRes -Icpan/HTML-Parser -Iext/re -Ispecrand -DDOUBLE_SLASHES_SPECIAL=0 -DSPEC_AUTO_SUPPRESS_OPENMP -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ofast -fno-unsafe-math-optimizations-DSPEC_LINUX_PPC_LE -fno-strict-aliasing -fgnu89-inline -DSPEC_LP64 reentr.c In configure, I use: default=base: # flags for all base OPTIMIZE= -Ofast -fno-unsafe-math-optimizations FOPTIMIZE = -std=legacy intrate,intspeed=base: # flags for integer base EXTRA_COPTIMIZE = -fno-strict-aliasing -fgnu89-inline Log message: *** Miscompare of diffmail.4.800.10.17.19.300.out; for details see benchspec/CPU/500.perlbench_r/run/run_base_refrate_base_64./diffmail.4.800.10.17.19.300.out.mis Error: 1x500.perlbench_r
[Bug tree-optimization/106927] false-positive -Werror=restrict warnings for memmove (calling memcpy) within string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106927
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||diagnostic
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
Last reconfirmed||2022-09-13
Component|c |tree-optimization
Summary|false-positive |false-positive
|-Werror=restrict warnings |-Werror=restrict warnings
|for memmove (calling|for memmove (calling
|memcpy) within array|memcpy) within string
||literal
--- Comment #2 from Richard Biener ---
We issue the diagnostic for
__builtin_memcpy ("abcdefghijklmnopqrstuvwxyz012345", [(void
*)"abcdefghijklmnopqrstuvwxyz012345" + 1B], 31);
but we'd better issue a -Wwrite-strings diagnostic.
The actually emitted diagnostic is indeed somewhat misleading but the
reason is we simplify the memmove call to memcpy as seen above because
we have
if (code == BUILT_IN_MEMMOVE)
{
/* Both DEST and SRC must be pointer types.
??? This is what old code did. Is the testing for pointer types
really mandatory?
If either SRC is readonly or length is 1, we can use memcpy. */
if (!dest_align || !src_align)
return false;
if (readonly_data_expr (src)
|| (tree_fits_uhwi_p (len)
&& (MIN (src_align, dest_align) / BITS_PER_UNIT
>= tree_to_uhwi (len
{
tree fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
...
that should probably suppress -Wrestrict on the call?
[Bug c/106927] false-positive -Werror=restrict warnings for memmove (calling memcpy) within array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106927
--- Comment #1 from Boris Faure ---
The code is indeed incorrect.
It should be:
#include
int main (void)
{
char s[] = "abcdefghijklmnopqrstuvwxyz012345";
size_t d = strlen(s);
__builtin_memmove(s, s + 1, d - 1);
return 0;
}
However, the error message is not helping.
[Bug modula2/93575] the modula2 frontend fails to build with a profiled bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93575 --- Comment #2 from Gaius Mulley --- seeking confirmation that this is fixed and can be closed?
[Bug c++/106651] [C++23] P1169 - static operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106651 Jakub Jelinek changed: What|Removed |Added Attachment #53565|0 |1 is obsolete|| Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-09-13 --- Comment #2 from Jakub Jelinek --- Created attachment 53571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53571=edit gcc13-pr106651.patch Full untested patch.
[Bug c/106927] New: false-positive -Werror=restrict warnings for memmove (calling memcpy) within array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106927
Bug ID: 106927
Summary: false-positive -Werror=restrict warnings for memmove
(calling memcpy) within array
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at boris dot fau.re
Target Milestone: ---
When compiling the following code with -Werror=restrict, gcc complains:
$cat foo.c
#include
int main (void)
{
char *s = "abcdefghijklmnopqrstuvwxyz012345";
size_t d = strlen(s);
__builtin_memmove(s, s + 1, d - 1);
return 0;
}
$ gcc -c -O2 -Werror=restrict -o foo.o foo.c
foo.c: In function 'main':
foo.c:8:5: error: '__builtin_memcpy' accessing 31 bytes at offsets 0 and 1
overlaps 30 bytes at offset 1 [-Werror=restrict]
8 | __builtin_memmove(s, s + 1, d - 1);
| ^~
This was reproduced on gentoo with gcc-11.3.0, on RHEL9 with gcc-11.2.1, on
debian bullseye with gcc-12.2.0, on debian buster with gcc-9.5.0, RHEL8 with
gcc-8.5.0.
Please note that, on gcc-12.2.0, without -O2, the compilation succeeds.
[Bug tree-optimization/106923] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512 since r13-2518-ga262f969d6fd936f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Richard Biener --- It's a latent bug in function splitting. When we outline a part of a returns-twice function the outlined part retains the 'returns-twice' attribute and thus now techincally the function calls setjmp. DCE now correctly asserts that a setjmp cannot appear out of nowhere and if it were there cfun->calls_setjmp should better indicate that. The easiest fix appears to be to disallow splitting returns-twice functions or amend check_forbidden_calls and forcefully clear the flag from the split part. Honza?
[Bug c++/106926] New: string_view construction from literal string containing null/zero should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926 Bug ID: 106926 Summary: string_view construction from literal string containing null/zero should warn Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jzwinck at gmail dot com Target Milestone: --- This code compiles but does something the programmer almost certainly does not want: #include constexpr std::string_view sv = "four\0nine"; // 9 bytes of data static_assert(sv.size() == 4); // required by C++, but surprising GCC can't implement what the programmer intended, so it should warn if a string_view is constructed or assigned from a string literal which contains null bytes before the end. When this happens, the rest of the string literal data is still accessible but only if you know it's there by some other means. I expect such usage to be very rare, so warning about it even at -Wall seems reasonable. Even if the warning only comes with -Wextra that would be better than silence.
[Bug c++/106925] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
Bug ID: 106925
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
The following minimal example leads to a segfault of GCC on latest trunk:
#include
template
struct MyVector
{
std::array data{};
};
template
struct Foo final
{
T a{0};
};
constexpr std::size_t kSize = 1;
void foo(MyVector, kSize> input = MyVector, kSize>())
{
}
: In instantiation of 'constexpr MyVector, 1>::MyVector()':
:17:74: required from here
:6:25: internal compiler error: Segmentation fault
6 | std::array data{};
| ^~~~
0x23428ae internal_error(char const*, ...)
???:0
0xb9cae7 maybe_splice_retval_cleanup(tree_node*)
???:0
0xce4fc2 do_poplevel(tree_node*)
???:0
0xce7973 finish_for_stmt(tree_node*)
???:0
0xba5019 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int,
vec**)
???:0
0xd0ee2e expand_vec_init_expr(tree_node*, tree_node*, int, vec**)
???:0
0xd494d1 digest_nsdmi_init(tree_node*, tree_node*, int)
???:0
0xbaabe5 get_nsdmi(tree_node*, bool, int)
???:0
0xbd282d get_defaulted_eh_spec(tree_node*, int)
???:0
0xc9d42a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xc9d23a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xb85043 mark_used(tree_node*, int)
???:0
0xac7bfb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xac9027 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xba3b2c build_value_init(tree_node*, int)
???:0
0xd4a73a build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0xc743a7 c_parse_file()
???:0
0xdae9f9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/106923] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512 since r13-2518-ga262f969d6fd936f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923 Martin Liška changed: What|Removed |Added Summary|[13 Regression] ICE in |[13 Regression] ICE in |eliminate_unnecessary_stmts |eliminate_unnecessary_stmts |, at tree-ssa-dce.cc:1512 |, at tree-ssa-dce.cc:1512 ||since ||r13-2518-ga262f969d6fd936f CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 Last reconfirmed||2022-09-13 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started since r13-2518-ga262f969d6fd936f.
[Bug c++/106921] [11/12/13 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[11/12.1] -O1 and -fipa-icf |[11/12/13 Regression] -O1 | -fpartial-inlining causes |and -fipa-icf |wrong code |-fpartial-inlining causes ||wrong code since ||r11-4987-g602c6cfc79ce4ae6 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r11-4987-g602c6cfc79ce4ae6. Lemme take a look.
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-13 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Please attach a pre-processed source code.
[Bug modula2/106917] modula-2 fails to bootstrap with the modula-2 branch ,20220912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106917 --- Comment #1 from Gaius Mulley --- please can I have a copy of the configure and make command? I've tried: ../gcc-git-devel-modula2/configure --enable-languages=m2 --prefix=/home/gaius/opt --libexecdir=/home/gaius/opt/lib --enable-host-shared --enable-valgrind-annotations --enable-threads=posix --enable-clocale=gnu --enable-multilib --enable-checking --enable-long-longx --enable-bootstrap --with-build-config=bootstrap-lto-lean which built on bullseye amd64 (slowly)
[Bug target/104482] ICE: Segmentation fault (in rs6000_builtin_type_compatible), or ICE: tree check: expected class 'type', have 'reference' (attr_addr_expr) in cp_type_quals, at cp/typeck.cc:10955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482 --- Comment #5 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:38db48346cc045ed5656233c42d01d6d06bffc35 commit r13-2643-g38db48346cc045ed5656233c42d01d6d06bffc35 Author: Kewen Lin Date: Tue Sep 13 04:14:23 2022 -0500 rs6000: Fix the check of bif argument number [PR104482] As PR104482 shown, it's one regression about the handlings when the argument number is more than the one of built-in function prototype. The new bif support only catches the case that the argument number is less than the one of function prototype, but it misses the case that the argument number is more than the one of function prototype. Because it uses "n != expected_args", n is updated in for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs; fnargs = TREE_CHAIN (fnargs), n++) , it's restricted to be less than or equal to expected_args with the guard !VOID_TYPE_P (TREE_VALUE (fnargs)), so it's wrong. The fix is to use nargs instead, also move the checking hunk's location ahead to avoid useless further scanning when the counts mismatch. PR target/104482 gcc/ChangeLog: * config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin): Fix the equality check for argument number, and move this hunk ahead. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr104482.c: New test.
[Bug target/105485] ICE: Segmentation fault in pcrel-opt.md:get_insn_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105485 --- Comment #5 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:94504c9ae157db937a2e62d533a36d56598f3c09 commit r13-2642-g94504c9ae157db937a2e62d533a36d56598f3c09 Author: Kewen.Lin Date: Tue Sep 13 04:13:59 2022 -0500 rs6000: Handle unresolved overloaded builtin [PR105485] PR105485 exposes that new builtin function framework doesn't handle unresolved overloaded builtin function well. With new builtin function support, we don't have builtin info for any overloaded rs6000_gen_builtins enum, since they are expected to be resolved to one specific instance. So when function rs6000_gimple_fold_builtin faces one unresolved overloaded builtin, the access for builtin info becomes out of bound and gets ICE then. We should not try to fold one unresolved overloaded builtin there and as the previous support we should emit one error message during expansion phase like "unresolved overload for builtin ...". PR target/105485 gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Add the handling for unresolved overloaded builtin function. (rs6000_expand_builtin): Likewise. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr105485.C: New test.
[Bug tree-optimization/106794] [13 Regression] ICE in vect_transform_slp_perm_load_1 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug c++/106924] New: Nested class: virtual function returns wrong pointer of covariant type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106924
Bug ID: 106924
Summary: Nested class: virtual function returns wrong pointer
of covariant type
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aeiken at motortech dot de
Target Milestone: ---
Created attachment 53570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53570=edit
test.ii file generated with g++ -save-temps test.cpp
The following was found with gcc-arm-none-eabi-10.3-2021.07, tests with other
versions for linux (Ubuntu 20.04.3 LTS) did also not work (e.g. g++ 9.4.0 on
Ubuntu).
Take a look at the example code in test.cpp:
A class (ABFabNested) is nested inside a class (class DerivedAB with multiple
inheritances (class BaseA and BaseB)).
Because of the class layout, the adresses of DerivedAB and BaseB are different.
The nested class itself is derived from a Base class (FabForB) which has a
virtual function(getPtr), which return a pointer to class BaseA.
The nested class overrides this virtual function, but returns a pointer to
class DerivedAB. This is allowed, because DerivedAB and BaseB are covariants.
If you have an instance of a pointer to FabForB, which points to an instance of
ABFabNested, getPtr returns the address of DerivedAB, not BaseA.
If you implement the same class (here ABFab) outside of DerivedAB (not nested)
and repeat the step before, getPtr returns the address of BaseA, which is what
I expected.
test.cpp was compiled with the 9.4.0 version of the g++ without any parameters:
g++ a.out
Output of a.out:
TEST fab:addr e89f6030 base e89f6040
TEST addr e89f6040
TEST fab nested: addr e89f6010 base e89f6020
TEST nested addr e89f6010
g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The test was repeated with other g++ versions (also newer version) with the
same result.
test.cpp:
#include
class BaseA
{
public:
virtual BaseA* getPtr(){return this;}
virtual ~BaseA(){}
};
class BaseB
{
public:
int i = 0;
virtual int geti(){return i;};
virtual ~BaseB(){}
};
class FabForB
{
public:
virtual BaseA* getPtr()=0;
virtual ~FabForB(){}
};
class DerivedAB: public BaseB, public BaseA
{
public:
virtual DerivedAB* getPtr(){printf("TEST D this %x\n", this);return this;}
virtual int geti(){return 5;};
class ABFabNested: public FabForB
{
public:
virtual DerivedAB* getPtr()
{
static DerivedAB staticD;
BaseA* basePtr =
printf("TEST fab nested: addr %x base %x\n", , basePtr);
return
}
virtual int geti(){return 5;};
};
};
class ABFab: public FabForB
{
public:
virtual DerivedAB* getPtr()
{
static DerivedAB staticD;
BaseA* basePtr =
printf("TEST fab:addr %x base %x\n", , basePtr);
return
}
virtual int geti(){return 5;};
};
int main()
{
ABFab fab;
DerivedAB::ABFabNested fabNested;
FabForB* fabPtr =
FabForB* fabNestedPtr =
printf("TEST addr %x \n", fabPtr->getPtr());
printf("TEST nested addr %x \n", fabNestedPtr->getPtr());
return 0;
}
[Bug target/106877] [12/13 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #3 from Roger Sayle --- Patch proposed https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601526.html
[Bug tree-optimization/106923] New: [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923
Bug ID: 106923
Summary: [13 Regression] ICE in eliminate_unnecessary_stmts, at
tree-ssa-dce.cc:1512
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) ICEs
when compiling the following testcase w/ -O1 -finline-small-functions
-fpartial-inlining --param max-inline-insns-single=1 --param
uninlined-function-insns=1:
int n;
int
baz (void);
__attribute__ ((returns_twice)) int
bar (void)
{
if (baz ())
++n;
return 0;
}
int
foo (void)
{
return bar ();
}
% gcc-13.0.0 -O1 -finline-small-functions -fpartial-inlining --param
max-inline-insns-single=1 --param uninlined-function-insns=1 -c xe0blvxx.c
during GIMPLE pass: dce
xe0blvxx.c: In function 'bar':
xe0blvxx.c:7:1: internal compiler error: in eliminate_unnecessary_stmts, at
tree-ssa-dce.cc:1512
7 | bar (void)
| ^~~
0x771cd5 eliminate_unnecessary_stmts
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-dce.cc:1512
0x771cd5 perform_tree_ssa_dce
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-ssa-dce.cc:1945
[Bug c++/106921] [11/12.1] -O1 and -fipa-icf -fpartial-inlining causes wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921 Richard Biener changed: What|Removed |Added Known to fail||11.3.0 Keywords||needs-bisection, wrong-code Ever confirmed|0 |1 Last reconfirmed||2022-09-13 Known to work||10.4.0 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Last reconfirmed||2022-09-13
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |12.3
Blocks||24639
Ever confirmed|0 |1
Keywords||diagnostic,
||missed-optimization
Summary|[12 Regression] Bogus |[12/13 Regression] Bogus
|uninitialized warning on|uninitialized warning on
|boost::optional<>>|r>>
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
Confirmed also on trunk and also with -O1 and the usual suspects -fno-ivopts
-fno-thread-jumps.
The question is whether
external = internal;
is problematic. For example
struct MyStruct { };
std::vector getMyStructs();
void test()
{
Optional> external;
Optional> internal;
external = internal;
}
is diagnosed with -std=c++20 -O -Wuninitialized -fno-tree-fre
-fno-tree-dominator-opts
that's because we then no longer forward the uninit state of the Optionals
and thus diagnose the conditional (on initialized)
[local count: 118702158]:
_34 = MEM[(struct vector *) + 8B].D.88471._M_impl.D.87778._M_finish;
_35 = MEM[(struct vector *) + 8B].D.88471._M_impl.D.87778._M_start;
if (_34 != _35)
goto ; [89.00%]
...
the same happens with the unreduced testcase, there we have similar code
conditional on external.m_initialized where we are not able to forward
the m_initialized state.
It might be the bisected rev. causes a missed optimization here, I will have
to check. At least I don't see a good reason why we don't forward it here.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug rtl-optimization/106913] [13 Regression] ICE in dump_bb_info, at cfg.cc:796 since r13-2263-gf71abacfed170852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106913 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/106913] [13 Regression] ICE in dump_bb_info, at cfg.cc:796 since r13-2263-gf71abacfed170852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106913 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad08894ea02b6308c4ed4e8cd8e6a564c2f581e8 commit r13-2639-gad08894ea02b6308c4ed4e8cd8e6a564c2f581e8 Author: Richard Biener Date: Tue Sep 13 08:46:51 2022 +0200 tree-optimization/106913 - ICE with -da and -Wuninitialized The following avoids setting and not clearing an auto_bb_flag on EXIT_BLOCK which we don't verify for such stale flags but dump_bb_info still asserts on them. PR tree-optimization/106913 * tree-ssa-uninit.cc (warn_uninitialized_vars): Do not set ft_reachable on EXIT_BLOCK.
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block since r13-2541-g78ef801b7263606d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block since r13-2541-g78ef801b7263606d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2c867232df70d3de304714906b4198ecb262eb32 commit r13-2640-g2c867232df70d3de304714906b4198ecb262eb32 Author: Richard Biener Date: Tue Sep 13 08:59:41 2022 +0200 middle-end/106909 - CTRL altering flag after folding The following makes sure to clear the CTRL altering flag when folding emits a __builitin_unreachable in place of a virtual call which now might become a trap. PR middle-end/106909 * gimple-fold.cc (gimple_fold_call): Clear the ctrl-altering flag of a unreachable call.
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
static tree
handle_pure_attribute (tree *node, tree name, tree ARG_UNUSED (args),
int ARG_UNUSED (flags), bool *no_add_attrs)
{
if (TREE_CODE (*node) == FUNCTION_DECL)
{
tree type = TREE_TYPE (*node);
if (VOID_TYPE_P (TREE_TYPE (type)))
warning (OPT_Wattributes, "%qE attribute on function "
"returning %", name);
DECL_PURE_P (*node) = 1;
/* ??? TODO: Support types. */
}
else
{
warning (OPT_Wattributes, "%qE attribute ignored", name);
*no_add_attrs = true;
}
meh.
I also question that we clear const/pure after instrumenting. We don't
do that for other instrumenting and it's only done for functions with
definitions but not functions in other (profile instrumented) TUs.
Edge counters do not alias anyway so that leaves for example
__gcov_time_profiler_counter which is updated like
# VUSE <.MEM_14>
PROF_time_profile_8 = __gcov_time_profiler_counterD.2013;
PROF_time_profile_9 = PROF_time_profile_8 + 1;
# .MEM_15 = VDEF <.MEM_14>
__gcov7.fooD.2016[0] = PROF_time_profile_9;
# .MEM_16 = VDEF <.MEM_15>
__gcov_time_profiler_counterD.2013 = PROF_time_profile_9;
the counter is public, external and static (eh?). We do eventually IPA
inline profile instrumented functions, but at least the above seems to be
at function end only.
That said, the const clearing doesn't have any effect, only the pure one
has.
It's possible to "fixup" in the vectorizer here but that's a hack for the
general inconsistency. The vectorizer can also build a const qualified
function type variant for the call fntype which might be a better fit but
then the simd clones use the exact same counters as the original function
which might or might not be intended ...
Honza - any comments on the pure/const difference for profile instrumented
code here? Do we need to "fix" the const case or can we drop the
pure/const state changes? It depends on that what the correct fix in
the vectorizer is.
[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 --- Comment #7 from Jakub Jelinek --- Created attachment 53569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53569=edit gcc13-pr106878-4.patch So, I've tried to restrict the verifiers so that they allow pointer arguments only for BIT_AND_EXPR with constant second argument and not for BIT_IOR_EXPR nor BIT_XOR_EXPR. Ran into reassoc issue which was converting (ptr1 == 0 && ptr2 == 0) into (ptr1 | ptr2) == 0 with BIT_IOR_EXPR in pointer type. This untested patch changes that, will see tonight how far I get with this adjusted patch.
[Bug tree-optimization/106922] New: [12 Regression] Bogus uninitialized warning on boost::optional<>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 Bug ID: 106922 Summary: [12 Regression] Bogus uninitialized warning on boost::optional<>> Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.zizka at nokia dot com Target Milestone: --- Created attachment 53568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53568=edit Reproducer for maybe uninitialized warning with gcc 12 In our production code when upgrading to gcc 12 from gcc 11 we have faced bogus warning "may be used uninitialized" on bit complex use of boost::optional vector of strings used in a loop with unrelated string stream redirect. > In file included from <..>/include/c++/12.0.0/vector:67, > from reproduce.cpp:13: > In destructor ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = > std::__cxx11::basic_string; _Alloc = > std::allocator >]’, > inlined from ‘void > boost::optional_detail::optional_base::destroy_impl() [with T = > std::vector >]’ at > /usr/include/boost/optional/optional.hpp:771:50, > inlined from ‘void boost::optional_detail::optional_base::destroy() > [with T = std::vector >]’ at > /usr/include/boost/optional/optional.hpp:757:21, > inlined from ‘void boost::optional_detail::optional_base::assign(const > boost::optional_detail::optional_base&) [with T = > std::vector >]’ at > /usr/include/boost/optional/optional.hpp:264:21, > inlined from ‘boost::optional_detail::optional_base& > boost::optional_detail::optional_base::operator=(const > boost::optional_detail::optional_base&) [with T = > std::vector >]’ at > /usr/include/boost/optional/optional.hpp:241:19, > inlined from ‘boost::optional& boost::optional::operator=(const > boost::optional&) [with T = std::vector > >]’ at /usr/include/boost/optional/optional.hpp:1040:15, > inlined from ‘void test()’ at reproduce.cpp:55:13: > <..>/include/c++/12.0.0/bits/stl_vector.h:680:22: error: > ‘*(std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > >*)((char*) + > offsetof(boost::Optional std::char_traits, std::allocator >, > std::allocator, > std::allocator > > > > >,boost::optional std::char_traits, std::allocator >, > std::allocator, > std::allocator > > > > >::.boost::optional_detail::optional_base std::char_traits, std::allocator >, > std::allocator, > std::allocator > > > > >::m_storage.boost::optional_detail::aligned_storage std::char_traits, std::allocator >, > std::allocator, > std::allocator > > > > >::dummy_)).std::vector > >::.std::_Vector_base, > std::allocator > > >::_M_impl.std::_Vector_base, > std::allocator > > >::_Vector_impl::.std::_Vector_base, > std::allocator > > >::_Vector_impl_data::_M_finish’ may be used uninitialized > [-Werror=maybe-uninitialized] > 680 | std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish, > | ~^ > 681 | _M_get_Tp_allocator()); > | ~~ > reproduce.cpp: In function ‘void test()’: > reproduce.cpp:45:40: note: ‘external’ declared here >45 | Optional> external; > |^~~~ I have tested this with gcc 12 (12.1.1, 12.2.1 and release/gcc-12 commit https://gcc.gnu.org/git/?p=gcc.git=commit;h=4ce316ca54c863cf0fd4257ba0ab768ab83c62e5;) with boost 1.69.0, 1.75.0, 1.76.0 and 1.80.0. All fails. With any boost version and gcc 11 (11.3.1 and release/gcc-11 tip commit https://gcc.gnu.org/git/?p=gcc.git=commit;h=7e356c3083c79473c941bc92d61f755e923bc86c) the warning doesn't appear. To reproduce: > $ g++ -Werror -std=c++20 -O2 -Wall -o reproduce.o -c reproduce.cpp I was not able to bump the reproducer to simpliear case. In all modification where loop is removed the warning disappears. The problem doesn't occur when std::optional is used. Only workaround I found is to add following pragma at top of the module: > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" > #include > #pragma GCC diagnostic pop I have bisected the problem to start with https://gcc.gnu.org/git/?p=gcc.git=commit;h=5b8b1522e04adc20980f396571be1929a32d148a commit 5b8b1522e04adc20980f396571be1929a32d148a (HEAD, refs/bisect/bad) Author: Richard Biener Date: Mon Sep 27 12:01:38 2021 +0200 tree-optimization/100112 - VN last_vuse and redundant store elimination This avoids the last_vuse optimization hindering redundant store elimination by always also recording the original VUSE that was in effect on the load. In stage3 gcc/*.o we have 3182752 times recorded a single entry and 903409 times two entries (that's ~20% overhead). With just recording a
[Bug modula2/106443] Many 32-bit tests FAIL to link on Solaris/sparcv9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106443 --- Comment #4 from Gaius Mulley --- just querying whether this bug can be closed now?
