[Bug tree-optimization/108783] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-14 --- Comment #1 from Richard Biener --- reassoc1 does [local count: 966367643]: # a_4(ab) = PHI + _14 = a_4(ab) != 0; foo (x_9(D), y_12(D)); goto ; [99.96%] @@ -36,8 +59,7 @@ [local count: 1073312329]: _1 = y_12(D) != 0; _2 = a_4(ab) != 0; - _3 = _1 & _2; - _10 = _2 & _3; + _10 = _14 & _1; _15 = (int) _10; return _15; Confirmed. It also inserts a new use of a_4(ab) which we try to generally avoid (but in this specific case it shouldn't be a problem). Not sure why reassoc expands _2 and re-emits the _14 definition here.
[Bug tree-optimization/108782] [13 Regression] ICE in add_phi_arg, at tree-phinodes.cc:359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108782 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-02-14 --- Comment #1 from Richard Biener --- I will have a look.
[Bug rtl-optimization/108774] [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug debug/108784] New: '-fcompare-debug' failure (length) w/ -O1 -fharden-conditional-branches -funroll-all-loops --param ira-simple-lra-insn-threshold=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108784
Bug ID: 108784
Summary: '-fcompare-debug' failure (length) w/ -O1
-fharden-conditional-branches -funroll-all-loops
--param ira-simple-lra-insn-threshold=1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
Created attachment 54457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54457=edit
gkd diff
gcc 13.0.1 20230212 snapshot (g:06ca0c9abb260266b688e2c2154c72214bb47076) fails
-fcompare-debug check when compiling the following testcase w/ -O1
-fharden-conditional-branches -funroll-all-loops --param
ira-simple-lra-insn-threshold=1:
int m;
void
foo (int x)
{
int i;
if (m)
m += m;
for (i = 0; i < 7; ++i)
{
__int128 a = 2;
m += x * m && m / a;
}
while (x < 1)
while (x < 1)
++x;
}
% aarch64-linux-gnu-gcc-13 -O1 -fcompare-debug -fharden-conditional-branches
-funroll-all-loops --param ira-simple-lra-insn-threshold=1 -c cdyfgse4.c
aarch64-linux-gnu-gcc-13: error: cdyfgse4.c: '-fcompare-debug' failure (length)
gkd diff attached.
W/ gcc 13.0.1 20230212 snapshot I get massive -fcompare-debug failures w/ all
kinds of test cases I have, either generated or real-world programs, when
compiling for aarch64-linux-gnu w/ ira-simple-lra-insn-threshold parameter
values ranging 1 to 3. I believe it has nothing to do w/
-fharden-conditional-branches, as there are many testcases that fail w/ that
omitted.
[Bug c++/108781] Underlying variables of structured bindings should not be treated as having external or module linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108781 --- Comment #1 from Jiang An --- Oh, the variable doesn't seem strictly unnamed ([dcl.struct.bind]/1): > First, a variable with a unique name e is introduced. But it seems that `e` should be unique in the whole program...
[Bug tree-optimization/108783] New: [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108783
Bug ID: 108783
Summary: [13 Regression] ICE: verify_flow_info failed (error:
returns_twice call is not first in basic block 3)
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.1 20230212 snapshot (g:06ca0c9abb260266b688e2c2154c72214bb47076) ICEs
when compiling the following testcase w/ -O1:
int
bar (int x)
{
return x;
}
__attribute__((returns_twice)) int
foo (int x, int y)
{
int a;
a = bar (x);
(void) foo (x, y);
return y && a && a;
}
% gcc-13 -O1 -c ibxb9fcz.c
ibxb9fcz.c: In function 'foo':
ibxb9fcz.c:8:1: error: returns_twice call is not first in basic block 3
8 | foo (int x, int y)
| ^~~
foo (x_9(D), y_12(D));
during GIMPLE pass: reassoc
ibxb9fcz.c:8:1: internal compiler error: verify_flow_info failed
0xa06a6d verify_flow_info()
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/cfghooks.cc:285
0xe0b153 execute_function_todo
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/passes.cc:2103
0xe0b69e execute_todo
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/passes.cc:2145
[Bug tree-optimization/108782] New: [13 Regression] ICE in add_phi_arg, at tree-phinodes.cc:359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108782
Bug ID: 108782
Summary: [13 Regression] ICE in add_phi_arg, at
tree-phinodes.cc:359
Product: gcc
Version: 13.0
Status: UNCONFIRMED
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.1 20230212 snapshot (g:06ca0c9abb260266b688e2c2154c72214bb47076) ICEs
when compiling the following testcase w/ -O1 -fno-tree-copy-prop:
int m;
__attribute__ ((simd)) int
foo (void)
{
int a, b = 0;
m = a = 1;
while (a != 0)
{
b = m;
m = 2;
++a;
}
return b;
}
% gcc-13 -O1 -fno-tree-copy-prop -w -c nkivh61j.c
during GIMPLE pass: vect
nkivh61j.c: In function 'foo.simdclone.0':
nkivh61j.c:4:1: internal compiler error: in add_phi_arg, at
tree-phinodes.cc:359
4 | foo (void)
| ^~~
0x764623 add_phi_arg(gphi*, tree_node*, edge_def*, unsigned int)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-phinodes.cc:359
0x118e3a6 vectorizable_recurr(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, vec*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vect-loop.cc:8489
0x1f73bf8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vect-stmts.cc:11467
0x119fff3 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vect-loop.cc:10890
0x11dfde0 vect_transform_loops
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1007
0x11e041e try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1153
0x11e041e try_vectorize_loop
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1183
0x11e07d4 execute
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230212/work/gcc-13-20230212/gcc/tree-vectorizer.cc:1299
[Bug target/80175] rs6000 target should have a strlensi pattern that works for recent powerpc processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80175 Peter Bergner changed: What|Removed |Added Assignee|acsawdey at gcc dot gnu.org|unassigned at gcc dot gnu.org CC||bergner at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #1 from Peter Bergner --- Aaron isn't working on GCC anymore, so unassigning him.
[Bug c++/108781] New: Underlying variables of structured bindings should not be treated as having external or module linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108781
Bug ID: 108781
Summary: Underlying variables of structured bindings should not
be treated as having external or module linkage
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: link-failure, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
For the following example with two translation units:
```C++
// main.cpp
using Arr = int[2];
auto [bx, by] = Arr{};
int main(){}
```
```C++
// a.cpp
using Arr = int[2];
auto [bx, by] = Arr{};
```
Currently a linker error is emitted (Godbolt link:
https://godbolt.org/z/e43s4ErKs):
> /opt/compiler-explorer/gcc-trunk-20230213/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
> CMakeFiles/test.dir/main.cpp.o:(.bss+0x0): multiple definition of
> `_ZDC2bx2byE'; CMakeFiles/test.dir/a.cpp.o:(.bss+0x0): first defined here
The linker succeeds if `[bx, by]` is changed to `[bx, bz]` in either TU (but
not both).
Presumably, _ZDC2bx2byE is the mangled name of the unnamed variable created in
the structured binding declaration. Per current standard wording ([basic.link],
see also discussion in https://github.com/cplusplus/CWG/issues/240), structured
bindings have no linkage, and so do the unname variables because they don't
even have names.
So linker should be successful for this example, and both TUs have its own
distinct unnamed variable.
[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 --- Comment #15 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:4f5a1198065dc078f8099db628da7b06a2666f34 commit r13-5978-g4f5a1198065dc078f8099db628da7b06a2666f34 Author: Kewen Lin Date: Mon Feb 13 20:03:26 2023 -0600 rs6000/test: Adjust some test cases on partial vector [PR96373] As Richard pointed out in [1] and the testing on Power10, the proposed fix for PR96373 requires some updates on a few rs6000 test cases which adopt partial vector. This patch is to fix all of them with one extra option "-fno-trapping-math" as Richard suggested. Besides, the original test case also failed on Power10 without Richard's proposed fix, this patch adds it together for a bit better testing coverage. [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610728.html PR target/96373 gcc/testsuite/ChangeLog: * gcc.target/powerpc/p9-vec-length-epil-1.c: Add -fno-trapping-math. * gcc.target/powerpc/p9-vec-length-epil-2.c: Likewise. * gcc.target/powerpc/p9-vec-length-epil-3.c: Likewise. * gcc.target/powerpc/p9-vec-length-epil-4.c: Likewise. * gcc.target/powerpc/p9-vec-length-epil-5.c: Likewise. * gcc.target/powerpc/p9-vec-length-epil-6.c: Likewise. * gcc.target/powerpc/p9-vec-length-epil-8.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-1.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-2.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-3.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-4.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-5.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-6.c: Likewise. * gcc.target/powerpc/p9-vec-length-full-8.c: Likewise. * gcc.target/powerpc/pr96373.c: New test.
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Thomas Rodgers : https://gcc.gnu.org/g:2e558da77adade314d4373397c93a700717d50cd commit r11-10524-g2e558da77adade314d4373397c93a700717d50cd Author: Thomas W Rodgers Date: Fri Feb 10 09:35:11 2023 -0800 libstdc++: Add missing free functions for atomic_flag [PR103934] This patch adds - atomic_flag_test atomic_flag_test_explicit Which were missed when commit 491ba6 introduced C++20 atomic flag test. libstdc++-v3/ChangeLog: PR libstdc++/103934 * include/std/atomic (atomic_flag_test): Add. (atomic_flag_test_explicit): Add. * testsuite/29_atomics/atomic_flag/test/explicit.cc: Add test case to cover missing atomic_flag free functions. * testsuite/29_atomics/atomic_flag/test/implicit.cc: Likewise. (cherry picked from commit a8d769045b43e8509490362865a85cb31a855ccf)
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Thomas Rodgers : https://gcc.gnu.org/g:dec869c95562c0b1255f770e68e7ea72e7e92681 commit r12-9172-gdec869c95562c0b1255f770e68e7ea72e7e92681 Author: Thomas W Rodgers Date: Fri Feb 10 09:35:11 2023 -0800 libstdc++: Add missing free functions for atomic_flag [PR103934] This patch adds - atomic_flag_test atomic_flag_test_explicit Which were missed when commit 491ba6 introduced C++20 atomic flag test. libstdc++-v3/ChangeLog: PR libstdc++/103934 * include/std/atomic (atomic_flag_test): Add. (atomic_flag_test_explicit): Add. * testsuite/29_atomics/atomic_flag/test/explicit.cc: Add test case to cover missing atomic_flag free functions. * testsuite/29_atomics/atomic_flag/test/implicit.cc: Likewise. (cherry picked from commit a8d769045b43e8509490362865a85cb31a855ccf)
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 --- Comment #3 from CVS Commits --- The master branch has been updated by Thomas Rodgers : https://gcc.gnu.org/g:56cf9372c0596c4df4003c72dc4665a306fbfe31 commit r13-5977-g56cf9372c0596c4df4003c72dc4665a306fbfe31 Author: Thomas W Rodgers Date: Fri Feb 10 10:09:06 2023 -0800 libstdc++: Add missing free functions for atomic_flag [PR103934] This patch adds - atomic_flag_wait atomic_flag_wait_explicit atomic_flag_notify atomic_flag_notify_explicit Which were missed when commit 83a1be introduced C++20 atomic wait. libstdc++-v3/ChangeLog: PR libstdc++/103934 * include/std/atomic (atomic_flag_wait): Add. (atomic_flag_wait_explicit): Add. (atomic_flag_notify): Add. (atomic_flag_notify_explicit): Add. * testsuite/29_atomics/atomic_flag/wait_notify/1.cc: Add test case to cover missing atomic_flag free functions.
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Rodgers : https://gcc.gnu.org/g:a8d769045b43e8509490362865a85cb31a855ccf commit r13-5976-ga8d769045b43e8509490362865a85cb31a855ccf Author: Thomas W Rodgers Date: Fri Feb 10 09:35:11 2023 -0800 libstdc++: Add missing free functions for atomic_flag [PR103934] This patch adds - atomic_flag_test atomic_flag_test_explicit Which were missed when commit 491ba6 introduced C++20 atomic flag test. libstdc++-v3/ChangeLog: PR libstdc++/103934 * include/std/atomic (atomic_flag_test): Add. (atomic_flag_test_explicit): Add. * testsuite/29_atomics/atomic_flag/test/explicit.cc: Add test case to cover missing atomic_flag free functions. * testsuite/29_atomics/atomic_flag/test/implicit.cc: Likewise.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 108780, which changed state. Bug 108780 Summary: Spurious warning with -ftrivial-auto-var-init=zero https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108780 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 Andrew Pinski changed: What|Removed |Added CC||trprince at synopsys dot com --- Comment #5 from Andrew Pinski --- *** Bug 108780 has been marked as a duplicate of this bug. ***
[Bug middle-end/108780] Spurious warning with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108780 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 107411. *** This bug has been marked as a duplicate of bug 107411 ***
[Bug c++/108780] New: Spurious warning with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108780
Bug ID: 108780
Summary: Spurious warning with -ftrivial-auto-var-init=zero
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trprince at synopsys dot com
Target Milestone: ---
I encountered the following spurious (or at least, confusing/misleading--note
the variable name) warning on some code after enabling
`-ftrivial-auto-var-init=zero` on one of our codebases. It appears that there
have been similar issues with spurious warnings and
`-ftrivial-auto-var-init=zero` in the past but I was able to reproduce this
with trunk on godbolt:
https://godbolt.org/z/zre74sWq1
$ cat bad.cpp
struct a {
int b();
};
void c() {
a d;
const auto (d.b());
}
$ g++ --version
g++ (GCC) 12.1.0
Copyright (C) 2022 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.
$ g++ -ftrivial-auto-var-init=zero -Wuninitialized -c bad.cpp
bad.cpp: In function ‘void c()’:
bad.cpp:6:22: warning: ‘D.2414’ is used uninitialized [-Wuninitialized]
6 | const auto (d.b());
| ^
$
I'd be happy to provide any additional context if I'm missing anything.
[Bug d/107469] Build of GDC on FreeBSD 14 fails due to outdated value of __FreeBSD_version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107469 --- Comment #2 from CVS Commits --- The master branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:daeb6c94bbdfdf909bae23b6dbe31eee8957af9d commit r13-5974-gdaeb6c94bbdfdf909bae23b6dbe31eee8957af9d Author: Lorenzo Salvadore Date: Tue Feb 14 00:28:11 2023 +0100 d: Update __FreeBSD_version values [PR107469] Update __FreeBSD_version values for the latest supported FreeBSD versions. In particular, add __FreeBSD_version for FreeBSD 14, which is necessary to compile libphobos successfully on FreeBSD 14. libphobos/ChangeLog: PR d/107469 * libdruntime/core/sys/freebsd/config.d: Update __FreeBSD_version.
[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #23 from Piotr Kubaj --- (In reply to Segher Boessenkool from comment #22) > (In reply to Piotr Kubaj from comment #21) > > I'm not sure whether it will help, but the issue only affects building > > 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc > > for powerpc works just fine. > > I can reproduce it with a simple testcase always. It needs a > powerpc64-freebsd > compiler, built with all default options. With -m32 it still uses the 64-bit > processor, so equivalent to -mcpu=power4. If you manually use -mcpu=7450 all > works fine. Wouldn't it be possible to just set -mcpu=7450 in the Makefile for multilib?
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #3) > Patch attached. The patch fixes comment#0, but not e.g. this slight variation: if ( len([character(n+1) :: '']) /= 0 ) stop valgrind produces long output ... :-(
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 --- Comment #5 from Jakub Jelinek --- It is a similar tweak like many other asan tweaks which use params rather than switches.
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #4 from Florian Weimer --- Shouldn't this be an -f switch if it's an official compiler feature?
[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/108681] [13 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3cac06d84f334705ed0bce12fbc3a4cec4a8fd3b commit r13-5972-g3cac06d84f334705ed0bce12fbc3a4cec4a8fd3b Author: Richard Sandiford Date: Mon Feb 13 21:13:59 2023 + lra: Replace subregs in bare uses & clobbers [PR108681] In this PR we had a write to one vector of a 4-vector tuple. The vector had mode V1DI, and the target doesn't provide V1DI moves, so this was converted into: (clobber (subreg:V1DI (reg/v:V4x1DI 92 [ b ]) 24)) followed by a DImode move. (The clobber isn't really necessary or helpful for a single word, but would be for wider moves.) The subreg in the clobber survived until after RA: (clobber (subreg:V1DI (reg/v:V4x1DI 34 v2 [orig:92 b ] [92]) 24)) IMO this isn't well-formed. If a subreg of a hard register simplifies to a hard register, it should be replaced by the hard register. If the subreg doesn't simplify, then target-independent code can't be sure which parts of the register are affected and which aren't. A clobber of such a subreg isn't useful and (again IMO) should just be removed. Conversely, a use of such a subreg is effectively a use of the whole inner register. LRA has code to simplify subregs of hard registers, but it didn't handle bare uses and clobbers. The patch extends it to do that. One question was whether the final_p argument to alter_subregs should be true or false. True is IMO dangerous, since it forces replacements that might not be valid from a dataflow perspective, and uses and clobbers only exist for dataflow. As said above, I think the correct way of handling a failed simplification would be to delete clobbers and replace uses of subregs with uses of the inner register. But I didn't want to write untested code to do that. In the PR, the clobber caused an infinite loop in DCE, because of a disagreement about what effect the clobber had. But for the reasons above, I think that was GIGO rather than a bug in DF or DCE. gcc/ PR rtl-optimization/108681 * lra-spills.cc (lra_final_code_change): Extend subreg replacement code to handle bare uses and clobbers. gcc/testsuite/ PR rtl-optimization/108681 * gcc.target/aarch64/pr108681.c: New test.
[Bug fortran/103475] ICE in gfc_expr_attr, at fortran/primary.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103475 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline.
[Bug rtl-optimization/108774] [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774 --- Comment #2 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:a33e3dcbd15e73603796e30b5eeec11a0c8bacec commit r13-5971-ga33e3dcbd15e73603796e30b5eeec11a0c8bacec Author: Vladimir N. Makarov Date: Mon Feb 13 16:05:04 2023 -0500 RA: Clear reg equiv caller_save_p flag when clearing defined_p flag IRA can invalidate initially setup equivalence in setup_reg_equiv. Flag caller_saved was not cleared during invalidation although init_insns were cleared. It resulted in segmentation fault in get_equiv. Clearing the flag solves the problem. For more precaution I added clearing the flag in other places too although it might be not necessary. PR rtl-optimization/108774 gcc/ChangeLog: * ira.cc (ira_update_equiv_info_by_shuffle_insn): Clear equiv caller_save_p flag when clearing defined_p flag. (setup_reg_equiv): Ditto. * lra-constraints.cc (lra_constraints): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr108774.c: New.
[Bug fortran/103475] ICE in gfc_expr_attr, at fortran/primary.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103475 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a commit r13-5970-g2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a Author: Harald Anlauf Date: Mon Feb 13 22:02:44 2023 +0100 Fortran: error recovery after invalid use of CLASS variable [PR103475] gcc/fortran/ChangeLog: PR fortran/103475 * primary.cc (gfc_expr_attr): Avoid NULL pointer dereference for invalid use of CLASS variable. gcc/testsuite/ChangeLog: PR fortran/103475 * gfortran.dg/pr103475.f90: New test.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #19 from Andrew Pinski --- Note in the loop case we know it does not wrap because there is a check already: [local count: 118111600]: if (rows_8(D) > 3) goto ; [89.00%] else goto ; [11.00%] [local count: 105119324]: _13 = rows_8(D) + 18446744073709551612; _15 = _13 / 4; doloop.6_5 = _15 + 1;
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 Andrew Pinski changed: What|Removed |Added Target|powerpc64le-linux |powerpc64le-linux, ||aarch64-*-* --- Comment #18 from Andrew Pinski --- Note this shows up on aarch64 too with my reduced testcase.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #17 from Andrew Pinski ---
_13 = rows_8(D) + 18446744073709551612;
_15 = _13 >> 2;
doloop.8_5 = _15 + 1;
This is what IV-OPTS produces.
Reduced testcase:
typedef __SIZE_TYPE__ size_t;
void convert(size_t rows, float*src, float *result)
{
for(size_t i = 0; i + 4 <= rows; i+=4) {
float t = src[i];
result[i] = t;
}
}
[Bug rtl-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #16 from Chip Kerchner ---
Dang copy and paste issue... This is what I meant.
unsigned long int
foo (unsigned long int a)
{
return (a + (N*M)) / N - M;
}
[Bug rtl-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #15 from Chip Kerchner ---
How about this (from Peter's testcase)? Does it still have issues? It
produces the same assembly.
#define N 32
#define M 2
unsigned long int
foo (unsigned long int a)
{
return (a - (N*M)) / N + M;
}
[Bug rtl-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37451 Component|tree-optimization |rtl-optimization --- Comment #14 from Andrew Pinski --- Oh yes pr 37451 . There are a few other related ones referenced now too. But basically it is doloop which is introducing this. The original example does not correspond to the example in given by the eigen folks either..
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757 --- Comment #13 from Andrew Pinski --- IIRC this is a doloop issue and has been reported before. Maybe even by myself while I was working at Sony. I think I tried to fix it too.
[Bug tree-optimization/108757] We do not simplify (a - (N*M)) / N + M -> a / N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #12 from Chip Kerchner ---
Here is an example of the original problem
#define EIGEN_ALWAYS_INLINE __attribute__((always_inline)) inline
typedef __vector float Packet4f;
typedef size_t Index;
EIGEN_ALWAYS_INLINE Packet4f ploadu(const float* from)
{
return vec_xl(0, const_cast(from));
}
EIGEN_ALWAYS_INLINE void pstoreu(float* to, const Packet4f )
{
vec_xst(from, 0, to);
}
void convert(Index rows, float*src, float *result)
{
for(Index i = 0; i + 4 <= rows; i+=4) {
Packet4f r32_0 = ploadu(src + i + 0);
pstoreu(result + i + 0, r32_0);
}
}
And the output (with notation on the lines in question)
cmpldi 0,3,3
blelr 0
addi 3,3,-4 <- i = rows - 4
li 9,0
srdi 3,3,2 <- i >>= 2
addi 8,3,1 <- i = i + 1
andi. 7,8,0x3
mr 10,8
beq 0,.L10
cmpdi 0,7,1
beq 0,.L14
cmpdi 0,7,2
beq 0,.L15
lxv 0,0(4)
mr 8,3
li 9,16
stxv 0,0(5)
.L15:
lxvx 0,4,9
addi 8,8,-1
stxvx 0,5,9
addi 9,9,16
.L14:
lxvx 0,4,9
cmpdi 0,8,1
stxvx 0,5,9
addi 9,9,16
beqlr 0
.L10:
srdi 10,10,2
mtctr 10
.L3:
lxvx 0,4,9
addi 10,9,16
addi 7,9,32
addi 8,9,48
stxvx 0,5,9
lxvx 0,4,10
addi 9,9,64
stxvx 0,5,10
lxvx 0,4,7
stxvx 0,5,7
lxvx 0,4,8
stxvx 0,5,8
bdnz .L3
blr
In this case the 3 lines notated can be replaced a simple `srdi 8,3,2`
[Bug fortran/103475] ICE in gfc_expr_attr, at fortran/primary.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103475 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|WAITING |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Can reproduce now. Taking.
[Bug target/108516] [11/12 Regression] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Summary|Useless movzx instruction |[11/12 Regression] Useless |emitted when loading 8 bits |movzx instruction emitted |from 24 bit struct |when loading 8 bits from 24 ||bit struct Severity|enhancement |normal Known to fail||12.2.0 Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #8 from Uroš Bizjak --- Fixed.
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 Andrew Pinski changed: What|Removed |Added Summary|No option to change |AARCH64 should add an |thread-pointer location on |option to change TLS |AArch64 |register location to ||support EL1/EL2/EL3 system ||registers Target||aarch64-*-linux-gnu ||aarch64-*-elf Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Windows aarch64 support will even use the system register
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 --- Comment #3 from Marco Elver --- (In reply to Jakub Jelinek from comment #2) > Marco, is this what you are looking for? Yes, looks good - the tests verify the behaviour I'd expect. Thanks!
[Bug target/108779] New: No option to change thread-pointer location on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 Bug ID: 108779 Summary: No option to change thread-pointer location on AArch64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zach-gcc at cs dot stanford.edu Target Milestone: --- On AArch64, GCC uses tpidr_el0 (user-mode accessible) to access the thread-pointer for loading thread-local variables by default. There is no option to change this to tpidr_el1 (or tpidr_el2/tpidr_el3), which is necessary for using thread-local variables in kernel code (or any code that runs at a higher privilege level). Clang has the `-mtp` option for AArch64 (https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mtp) that controls this, but it seems GCC does not. There is a GCC `-mtp` option for ARM, but not AArch64. See also the original gcc-help message I sent here: https://gcc.gnu.org/pipermail/gcc-help/2023-February/142212.html Thanks!
[Bug c++/108778] New: Missing optimization with direct register access instead of structure mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108778
Bug ID: 108778
Summary: Missing optimization with direct register access
instead of structure mapping
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
The following example uses two functional identical ways to save the SREG of a
AVR µC, in this case an avr128da32.
To access the SREG two different ways are used: one directly via the SREG macro
and one via a structure mapping (the Cpu_t structure is actually not included
in the avr headers,
so a definition of the Cpu_t structure is given here).
If the SREG macro way is used the optimization regarding the variable g is
missed (see assembler code below).
Using the structure mapping the load / store of g is correctly optimized out of
the loop.
In the SREG macro case unfortunately not!
#include
#include
#include
#include
#define ACCESS_ONCE(x) (*(volatile typeof(x)*)&(x))
typedef struct Cpu { // this is missing in avr headers
volatile uint8_t r0;
volatile uint8_t r1;
volatile uint8_t r2;
volatile uint8_t r3;
volatile uint8_t ccp;
volatile uint8_t r5;
volatile uint8_t r6;
volatile uint8_t r7;
volatile uint8_t r8;
volatile uint8_t r9;
volatile uint8_t ra;
volatile uint8_t rampz;
volatile uint8_t rc;
volatile uint16_t sp;
volatile uint8_t sreg;
} Cpu_t;
#define CPU (*(Cpu_t *) 0x0030)
static uint8_t flag;
static uint16_t counter;
static uint16_t g;
static inline uint16_t count() {
const uint8_t save = CPU.sreg;
//const uint8_t save = SREG; // suppresses optimization
asm volatile("cli" : : :);
const uint16_t t = ACCESS_ONCE(counter);
//SREG = save; // suppresses optimization
CPU.sreg = save;
return t;
}
static void func(void) {
for(uint8_t i = 0; i < 20; i++) {
g += count();
if (ACCESS_ONCE(flag)) {
ACCESS_ONCE(flag) = 1;
}
}
}
ISR(USART0_RXC_vect) {
_MemoryBarrier();
counter += 1;
if (counter >= 100) {
flag = 1;
}
}
int main() {
func();
}
the generated assembly should be:
main:
lds r24,g; g_lsm.16, g
lds r25,g+1 ; g_lsm.16, g
ldi r18,lo8(20) ; ivtmp_7,
ldi r19,lo8(1) ; tmp56,
.L5:
in r22,__SREG__ ; save, MEM[(struct Cpu_t *)48B].sreg
cli
lds r20,counter ; t, MEM[(volatile uint16_t *)]
lds r21,counter+1; t, MEM[(volatile uint16_t *)]
out __SREG__,r22 ; MEM[(struct Cpu_t *)48B].sreg, save
add r24,r20 ; g_lsm.16, t
adc r25,r21 ; g_lsm.16, t
lds r20,flag ; _6, MEM[(volatile uint8_t *)]
cpse r20,__zero_reg__; _6
sts flag,r19 ; MEM[(volatile uint8_t *)], tmp56
.L4:
subi r18,lo8(-(-1)) ; ivtmp_7,
cpse r18,__zero_reg__; ivtmp_7,
rjmp .L5 ;
sts g,r24; g, g_lsm.16
sts g+1,r25 ; g, g_lsm.16
ldi r24,0;
ldi r25,0;
ret
but using SREG it gets:
main:
ldi r24,lo8(20) ; ivtmp_12,
ldi r25,lo8(1) ; tmp59,
.L5:
in r18,__SREG__ ; save, MEM[(volatile uint8_t *)63B]
cli
lds r20,counter ; t, MEM[(volatile uint16_t *)]
lds r21,counter+1; t, MEM[(volatile uint16_t *)]
out __SREG__,r18 ; MEM[(struct Cpu_t *)48B].sreg, save
lds r18,g; g, g
lds r19,g+1 ; g, g
add r18,r20 ; tmp53, t
adc r19,r21 ; , t
sts g,r18; g, tmp53
sts g+1,r19 ; g, tmp53
lds r18,flag ; _6, MEM[(volatile uint8_t *)]
cpse r18,__zero_reg__; _6
sts flag,r25 ; MEM[(volatile uint8_t *)], tmp59
.L4:
subi r24,lo8(-(-1)) ; ivtmp_12,
cpse r24,__zero_reg__; ivtmp_12,
rjmp .L5 ;
ldi r24,0;
ldi r25,0;
ret
[Bug target/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 --- Comment #7 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:00b8a212ea2132fb68e42488317392346e169035 commit r13-5969-g00b8a212ea2132fb68e42488317392346e169035 Author: Uros Bizjak Date: Mon Feb 13 17:17:46 2023 +0100 i386: Relax extract location operand mode requirements [PR108516] Combine pass simplifies zero-extend of a zero-extract to: Trying 16 -> 6: 16: r86:QI#0=zero_extract(r87:HI,0x8,0x8) REG_DEAD r87:HI 6: r84:SI=zero_extend(r86:QI) REG_DEAD r86:QI Failed to match this instruction: (set (reg:SI 84 [ s.e2 ]) (zero_extract:SI (reg:HI 87) (const_int 8 [0x8]) (const_int 8 [0x8]))) which fails instruction recognision. The pattern is valid, since there is no requirement on the mode of the location operand. The patch relaxes location operand mode requirements of *extzv and *extv insn patterns to allow all supported integer modes. The patch also adds support for a related sign-extend from zero-extracted operand. 2023-02-13 Uroš Bizjak gcc/ChangeLog: PR target/108516 * config/i386/predicates.md (extr_register_operand): New special predicate. * config/i386/i386.md (*extv): Use extr_register_operand as operand 1 predicate. (*exzv): Ditto. (*extendqi_ext_1): New insn pattern. gcc/testsuite/ChangeLog: PR target/108516 * gcc.target/i386/pr108516-1.c: New test. * gcc.target/i386/pr108516-2.c: Ditto.
[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761 --- Comment #6 from Andrew Pinski --- (In reply to Paul Robinson from comment #5) > Modifying the syntax of the attribute won't help users who are importing > code from a third party, but still want to do dead-stripping/deduplication. And it might break code from third party with that option, that was my point.
[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761 --- Comment #5 from Paul Robinson --- Modifying the syntax of the attribute won't help users who are importing code from a third party, but still want to do dead-stripping/deduplication.
[Bug c++/108759] "mandatory copy elision" not implemented during constant evaluation redux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108759 Marek Polacek changed: What|Removed |Added Last reconfirmed||2023-02-13 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, we haven't elided the TARGET_EXPR: * = TARGET_EXPR == }>
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #11 from Jakub Jelinek ---
Even better don't make second initializer_list member __rebind:
namespace std {
struct __new_allocator {};
template using __allocator_base = __new_allocator;
struct allocator : __allocator_base {};
template struct initializer_list {
void *_M_array;
decltype(sizeof 0) _M_len;
};
template
struct basic_string {
basic_string(const T *, allocator = allocator());
~basic_string();
};
using string = basic_string;
template
struct array {
T _M_elems;
};
template
struct list {
list =(initializer_list);
};
}
struct RGWSyncTraceManager {
std::list> admin_commands;
void hook_to_admin_command();
};
void RGWSyncTraceManager::hook_to_admin_command() {
admin_commands = {{""}, {""}};
}
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #10 from Jakub Jelinek ---
Slightly better testcase where basic_string, array and list are at least
templates, again -std=c++20:
namespace std {
struct __new_allocator {};
template using __allocator_base = __new_allocator;
struct allocator : __allocator_base {};
template struct initializer_list {
void *_M_array;
decltype(sizeof 0) __rebind;
};
template
struct basic_string {
basic_string(const T *, allocator = allocator());
~basic_string();
};
using string = basic_string;
template
struct array {
T _M_elems;
};
template
struct list {
list =(initializer_list);
};
}
struct RGWSyncTraceManager {
std::list> admin_commands;
void hook_to_admin_command();
};
void RGWSyncTraceManager::hook_to_admin_command() {
admin_commands = {{""}, {""}};
}
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 Jakub Jelinek changed: What|Removed |Added CC||elver at google dot com --- Comment #2 from Jakub Jelinek --- Marco, is this what you are looking for?
[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-02-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 54456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54456=edit gcc13-pr108777.patch Untested implementation.
[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761 Paul Robinson changed: What|Removed |Added CC||paul_robinson at playstation dot s ||ony.com --- Comment #4 from Paul Robinson --- (In reply to Andrew Pinski from comment #1) > I think an option would be the wrong appoarch because many of the times, you > are marking a variable inside a section exactly because you want it to be > part of an "array". I think distinct options for -ffunction-sections and -fdata-sections would be the answer to that. I mean, we _already_ have separation options, so handling code and data independently makes sense. > I think rather section should have a secondary argument which mark as > needing to append the function name on it ... I believe the linker will not take an input with sections "foo.f" and "foo.g" and concatenate them into a single "foo" section in the linked object. That special behavior works only for standard sections like .text AFAIK. The Clang change proposes using section groups instead, so the final section has the name the user specified. I don't know whether this would work for non-ELF object formats. I suspect COFF would be okay, as it has no-deduplicate COMDAT.
[Bug sanitizer/108777] New: Add support for --param asan-kernel-mem-intrinsic-prefix=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777
Bug ID: 108777
Summary: Add support for --param
asan-kernel-mem-intrinsic-prefix=1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
As mentioned in the https://lkml.org/lkml/2023/2/9/1182 thread, Linux kernel
would like
to have --param asan-kernel-mem-intrinsic-prefix=1 support which would use
__asan_memcpy, __asan_memmove and __asan_memset with -fsanitize=kernel-address
and
__hwasan_memcpy, __hwasan_memmove and __hwasan_memset with
-fsanitize=kernel-hwaddress
instead of memcpy, memmove and memset calls in kasan instrumented functions,
such that
kernel memcpy/memmove/memset could remain uninstrumented for use in kernel
functions
with no_sanitize ("kernel-address").
[Bug testsuite/108776] New: new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108776 Bug ID: 108776 Summary: new test case c-c++-common/rotate-11.c from r12-9158-ga015ebe382cd6d fails Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a015ebe382cd6d0beab9db4ad33fbd252b7e2339, r12-9158-ga015ebe382cd6d make -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/rotate-11.c" FAIL: c-c++-common/rotate-11.c -Wc++-compat scan-tree-dump-times optimized " r<< " 5 FAIL: c-c++-common/rotate-11.c -std=gnu++98 scan-tree-dump-times optimized " r<< " 5 FAIL: c-c++-common/rotate-11.c -std=gnu++14 scan-tree-dump-times optimized " r<< " 5 FAIL: c-c++-common/rotate-11.c -std=gnu++17 scan-tree-dump-times optimized " r<< " 5 FAIL: c-c++-common/rotate-11.c -std=gnu++20 scan-tree-dump-times optimized " r<< " 5 # of expected passes2 # of expected passes8 # of unexpected failures1 # of unexpected failures4 commit a015ebe382cd6d0beab9db4ad33fbd252b7e2339 (HEAD, refs/bisect/bad) Author: Jakub Jelinek Date: Thu Jan 19 10:00:51 2023 +0100 forwprop: Further fixes for simplify_rotate [PR108440]
[Bug rtl-optimization/108774] [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774 --- Comment #1 from Vladimir Makarov --- Thank you for reporting this. I'll try to fix it as soon as possible, today or tomorrow.
[Bug c++/108775] Move construction clobbers data through [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108775 --- Comment #2 from Andrew Pinski --- I suspect this is similar to https://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2403 .
[Bug c++/82113] RVO isn't applied to base class constructor call in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82113 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 98995 ***
[Bug c++/98995] [10/11/12/13 Regression] Copy elision not applied to members declared with [[no_unique_address]] or a empty base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995 Andrew Pinski changed: What|Removed |Added CC||for.gcc.bugzilla at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 82113 has been marked as a duplicate of this bug. ***
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #9 from Jakub Jelinek ---
Well, the reduction isn't exactly valid though, given how it defines
std::list/array.
I guess I could retry reduce with
class RGWSyncTraceManager { std::list >
admin_commands; public: int hook_to_admin_command(); };
int RGWSyncTraceManager::hook_to_admin_command() { admin_commands = { {
"sync trace show name=search,type=CephString,req=false", "sync trace show
[filter_str]: show current multis
ite tracing information" }, { "sync trace history
name=search,type=CephString,req=false", "sync trace history [filter_str]: show
history of multisite tracing inf
ormation" }, { "sync trace active
name=search,type=CephString,req=false", "show active multisite sync entities
information" }, { "sync trace
active_short name=search,type=CephString,req=false", "show active multisite
sync entities entries" } }; return 0; }
as forced last few lines.
[Bug c++/108775] Move construction clobbers data through [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108775 --- Comment #1 from danakj at orodu dot net --- This occurs on 12.2.0 Linux, as well as GCC trunk on Godbolt in C++20 mode.
[Bug c++/108775] New: Move construction clobbers data through [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108775
Bug ID: 108775
Summary: Move construction clobbers data through
[[no_unique_address]]
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: danakj at orodu dot net
Target Milestone: ---
Clang also clobbers data in the same way:
https://github.com/llvm/llvm-project/issues/60711
(MSVC does not)
```
#include
#include
#include
#include
struct S2 {
uint64_t a;
};
struct S : public S2 {
S(uint8_t b, uint64_t a) : S2(a), b(b) {}
uint8_t b;
// 3 bytes padding.
};
static_assert(sizeof(S) == 16);
union U {
U() {}
[[no_unique_address]] S s;
};
static_assert(sizeof(U) == 16);
struct D {
D(uint8_t i) : i(i) {}
[[no_unique_address]] U u;
uint8_t i;
};
static_assert(sizeof(D) == 16);
int main() {
D d(1u);
std::cout << (int)d.i << "\n";
// Regular construction into `D::u` doesn't touch `D::i`. Good.
new () S(2, 3);
std::cout << (int)d.i << "\n";
S s(4, 5);
// Move construction into `D::u` overwrites `D::i`. Bad.
new () S(std::move(s));
std::cout << (int)d.i << "\n";
return d.i;
}
```
Godbolt: https://godbolt.org/z/YzrM59E5a
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 --- Comment #8 from Martin Liška --- Wow, you reduced that really fast Jakub!
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #7 from Jakub Jelinek ---
Reduced testcase:
struct __new_allocator {};
template using __allocator_base = __new_allocator;
struct allocator : __allocator_base {};
template struct initializer_list {
void *_M_array;
decltype(sizeof 0) __rebind;
};
struct basic_string {
basic_string(const char *, allocator = allocator());
~basic_string();
};
struct array {
basic_string _M_elems;
};
struct list {
void operator=(initializer_list);
};
}
struct RGWSyncTraceManager {
std::list admin_commands;
void hook_to_admin_command();
};
void RGWSyncTraceManager::hook_to_admin_command() {
admin_commands = {{""}, {""}};
}
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 --- Comment #16 from Stefan Schulze Frielinghaus --- Fixed in mainline. Fine for me to close this now.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 --- Comment #3 from Richard Biener --- (In reply to Martin Liška from comment #2) > (In reply to Jakub Jelinek from comment #1) > > Does firefox really use -fimplicit-constexpr and -g1? > > Yes. Note the former option is used since gcc12: > https://bugzilla.mozilla.org/show_bug.cgi?id=1754752 Note 'decl' is for me. For dwarf2 we return comp_unit_die () for this, but for -g1 we run into case NAMESPACE_DECL: case IMPORTED_DECL: if (debug_info_level <= DINFO_LEVEL_TERSE) return; so maybe for force_decl_die we want to do the same or alternatively for get_context_die () allow force_decl_die to "fail" and force one for the next up context up to comp_unit_die ()? OTOH, we run into this for a limbo entry that in the end likely will not get any DIE at -g1 anyway, so "forcing" a context via get_context_die is possibly excessive as well. So I think the actual bug is that we created a DIE for __tag when -g1 doesn't want a DIE for its ultimate context. Alternative make force_decl_die honor the dwarf2out_decl reality like with diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc index 1f39df3b1e2..bd2c9444ff3 100644 --- a/gcc/dwarf2out.cc +++ b/gcc/dwarf2out.cc @@ -26742,7 +26742,8 @@ force_decl_die (tree decl) break; case NAMESPACE_DECL: - if (dwarf_version >= 3 || !dwarf_strict) + if (debug_info_level > DINFO_LEVEL_TERSE + && (dwarf_version >= 3 || !dwarf_strict)) dwarf2out_decl (decl); else /* DWARF2 has neither DW_TAG_module, nor DW_TAG_namespace. */ in which case we'll put the function decl context in the CU DIE rather than in a namespace DIE?
[Bug rtl-optimization/108774] [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Priority|P3 |P1
[Bug rtl-optimization/108774] New: [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108774 Bug ID: 108774 Summary: [13 Regression] ICE: in get_equiv, at lra-constraints.cc:534 with -Os -ftrapv -mcmodel=large Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 54455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54455=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Os -ftrapv -mcmodel=large testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in get_equiv, at lra-constraints.cc:534 7 | } | ^ 0x7405ab get_equiv /repo/gcc-trunk/gcc/lra-constraints.cc:534 0x1206c92 lra_constraints(bool) /repo/gcc-trunk/gcc/lra-constraints.cc:5052 0x11f12c4 lra(_IO_FILE*) /repo/gcc-trunk/gcc/lra.cc:2375 0x11a1459 do_reload /repo/gcc-trunk/gcc/ira.cc:5960 0x11a1459 execute /repo/gcc-trunk/gcc/ira.cc:6146 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-5964-20230213153338-g452db716d8d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-5964-20230213153338-g452db716d8d-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230213 (experimental) (GCC)
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug middle-end/28614] gcc.c-torture/compile/20001226-1.c times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28614 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1 commit r13-5966-g72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1 Author: Richard Biener Date: Mon Feb 13 14:41:24 2023 +0100 tree-optimization/28614 - high FRE time for gcc.c-torture/compile/20001226-1.c I noticed that for gcc.c-torture/compile/20001226-1.c even -O1 has around 50% of the compile-time accounted to FRE. That's because we have blocks with a high incoming edge count and can_track_predicate_on_edge visits all of them even though it could stop after the second. The function is also called repeatedly for the same edge. The following fixes this and reduces the FRE time to 1% on the testcase. PR tree-optimization/28614 * tree-ssa-sccvn.cc (can_track_predicate_on_edge): Avoid walking all edges in most cases. (vn_nary_op_insert_pieces_predicated): Avoid repeated calls to can_track_predicate_on_edge unless checking is enabled. (process_bb): Instead call it once here for each edge we register possibly multiple predicates on.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6436add49ed9ecf74f1f01b4fe18961df4f3e83d commit r13-5965-g6436add49ed9ecf74f1f01b4fe18961df4f3e83d Author: Richard Biener Date: Mon Feb 13 10:41:51 2023 +0100 tree-optimization/108691 - indirect calls to setjmp DCE now chokes on indirect setjmp calls becoming direct because that exposes them too late to be subject to abnormal edge creation. The following patch honors gimple_call_ctrl_altering for those and _not_ treat formerly indirect calls to setjmp as calls to setjmp in notice_special_calls. Unfortunately there's no way to have an indirect call to setjmp properly annotated (the returns_twice attribute is ignored on types). RTL expansion late discovers returns-twice for the purpose of adding REG_SETJMP notes and also sets ->calls_setjmp (instead of asserting it is set). There's no good way to transfer proper knowledge around here so I'm using ->calls_setjmp as a flag to indicate whether gimple_call_ctrl_altering_p was set. PR tree-optimization/108691 * tree-cfg.cc (notice_special_calls): When the CFG is built honor gimple_call_ctrl_altering_p. * cfgexpand.cc (expand_call_stmt): Clear cfun->calls_setjmp temporarily if the call is not control-altering. * calls.cc (emit_call_1): Do not add REG_SETJMP if cfun->calls_setjmp is not set. Do not alter cfun->calls_setjmp. * gcc.dg/pr108691.c: New testcase.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #150 from Richard Biener --- For _num.i at -O2+ it's PRE / postreload GCSE via compute_transp that takes all compile-time. The reason is all the sbitmaps used and using them "inverted" aka one bitmap per BB instead of one bitmap per expr. Sorting the expressions after bitmap index before processing doesn't help here. Samples: 116K of event 'cycles', Event count (approx.): 132865298352 Overhead Samples Command Shared Object Symbol 7.64% 8910 cc1 cc1 [.] find_base_term # 6.45% 7521 cc1 cc1 [.] get_ref_base_and_extent# 6.35% 7406 cc1 cc1 [.] compute_transp # 2.85% 3308 cc1 cc1 [.] bitmap_bit_p # 2.84% 3314 cc1 cc1 [.] rtx_equal_for_memref_p # 2.68% 3124 cc1 cc1 [.] find_base_term it's also mostly alias analysis cost, so maybe the bitmaps are not the actual problem but that we compute transparency for each block and each expression even for blocks that will in the end not require it because the expr isn't antic through it.
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 --- Comment #6 from Jakub Jelinek --- Trying to cvise reduce now (from hand reduced testcase from 15M to 5M).
[Bug middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #15 from CVS Commits ---
The master branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d
commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d
Author: Stefan Schulze Frielinghaus
Date: Mon Feb 13 15:33:38 2023 +0100
IBM zSystems: Do not propagate scheduler state across basic blocks
[PR108102]
So far we propagate scheduler state across basic blocks within EBBs and
reset the state otherwise. In certain circumstances the entry block of
an EBB might be empty, i.e., no_real_insns_p is true. In those cases
scheduler state is not reset and subsequently wrong state is propagated
to following blocks of the same EBB.
Since the performance benefit of tracking state across basic blocks is
questionable on modern hardware, simply reset the state for each basic
block.
Fix also resetting f{p,x}d_longrunning.
gcc/ChangeLog:
PR target/108102
* config/s390/s390.cc (s390_bb_fallthru_entry_likely): Remove.
(struct s390_sched_state): Initialise to zero.
(s390_sched_variable_issue): For better debuggability also emit
the current side.
(s390_sched_init): Unconditionally reset scheduler state.
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #5 from Jakub Jelinek ---
It is on
admin_commands = { { "sync trace show name=search,type=CephString,req=false",
"sync trace show [filter_str]: show current multisite tracing information" },
{ "sync trace history
name=search,type=CephString,req=false", "sync trace history [filter_str]: show
history of multisite tracing information" },
{ "sync trace active
name=search,type=CephString,req=false", "show active multisite sync entities
information" },
{ "sync trace active_short
name=search,type=CephString,req=false", "show active multisite sync entities
entries" } };
in int RGWSyncTraceManager::hook_to_admin_command(), where admin_commands is:
std::list > admin_commands;
Though, -std=c++20:
#include
#include
#include
#include
struct S
{
std::list > admin_commands;
void foo ();
};
void
S::foo ()
{
admin_commands = { { "sync trace show name=search,type=CephString,req=false",
"sync trace show [filter_str]: show current multisite tracing information" },
{ "sync trace history
name=search,type=CephString,req=false", "sync trace history [filter_str]: show
history of multisite tracing information" },
{ "sync trace active
name=search,type=CephString,req=false", "show active multisite sync entities
information" },
{ "sync trace active_short
name=search,type=CephString,req=false", "show active multisite sync entities
entries" } };
}
is rejected with
/tmp/1.C: In member function ‘void S::foo()’:
/tmp/1.C:18:137: error: no match for ‘operator=’ (operand types are
‘std::__cxx11::list, 3> >’ and
‘’)
18 | { "sync trace active_short
name=search,type=CephString,req=false", "show active multisite sync entities
entries" } };
|
^
In file included from
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/list:66,
from /tmp/1.C:1:
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/list.tcc:267:5:
note: candidate: ‘std::__cxx11::list<_Tp, _Alloc>& std::__cxx11::list<_Tp,
_Alloc>::operator=(const std::__cxx11::list<_Tp, _Alloc>&) [with _Tp =
std::array, 3>; _Alloc =
std::allocator, 3> >]’
267 | list<_Tp, _Alloc>::
| ^
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/list.tcc:268:27:
note: no known conversion for argument 1 from ‘’ to ‘const
std::__cxx11::list, 3> >&’
268 | operator=(const list& __x)
| ^~~
In file included from
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/list:65:
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/stl_list.h:929:7:
note: candidate: ‘std::__cxx11::list<_Tp, _Alloc>& std::__cxx11::list<_Tp,
_Alloc>::operator=(std::__cxx11::list<_Tp, _Alloc>&&) [with _Tp =
std::array, 3>; _Alloc =
std::allocator, 3> >]’
929 | operator=(list&& __x)
| ^~~~
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/stl_list.h:929:24:
note: no known conversion for argument 1 from ‘’ to ‘std::__cxx11::list, 3>
>&&’
929 | operator=(list&& __x)
| ~~~^~~
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/stl_list.h:947:7:
note: candidate: ‘std::__cxx11::list<_Tp, _Alloc>& std::__cxx11::list<_Tp,
_Alloc>::operator=(std::initializer_list<_Tp>) [with _Tp =
std::array, 3>; _Alloc =
std::allocator, 3> >]’
947 | operator=(initializer_list __l)
| ^~~~
/home/jakub/src/gcc/obj18i/usr/local/include/c++/13.0.1/bits/stl_list.h:947:46:
note: no known conversion for argument 1 from ‘’ to ‘std::initializer_list,
3> >’
947 | operator=(initializer_list __l)
| ~^~~
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Does firefox really use -fimplicit-constexpr and -g1? Yes. Note the former option is used since gcc12: https://bugzilla.mozilla.org/show_bug.cgi?id=1754752
[Bug c/108375] [10/11/12/13 Regression] Some variably modified types not detected as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
--- Comment #5 from Martin Uecker ---
Recursing into arrays is simple and does not seem to cause any problems,
but this not enough for GNU C, we can also have VLA or variably modified
types as member of structs. At least the later is sometimes useful.
void bar(int a)
{
struct foo { char (*p)[a]; };
goto x;
struct foo B;
x: ;
}
Unfortunately, recursing into structs is too expensive. We could use
walk_tree_without_duplicates but this still seems expensive.
I think we should simply add a bit which is set by the C FE for such
structs. The question is whether this is also needed by Ada or other
languages?
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |13.0 Priority|P3 |P1
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 Martin Liška changed: What|Removed |Added Keywords||needs-reduction --- Comment #4 from Martin Liška --- I'm not sure I'll be able to reduce it, btw. it crashes here: #0 fancy_abort (file=file@entry=0x22c7288 "/home/marxin/Programming/gcc/gcc/gimplify.cc", line=line@entry=3058, function=function@entry=0x22c6bab "gimplify_var_or_parm_decl") at /home/marxin/Programming/gcc/gcc/diagnostic.cc:2219 #1 0x007c1226 in gimplify_var_or_parm_decl (expr_p=0x7fffcfd6e338) at /home/marxin/Programming/gcc/gcc/gimplify.cc:3058 #2 0x00ebcb6b in gimplify_expr (expr_p=0x7fffcfd6e338, pre_p=0x7fffbbb0, post_p=0x7fffb0f8, gimple_test_f=0xeab4c0 , fallback=3) at /home/marxin/Programming/gcc/gcc/gimplify.cc:16822 #3 0x00ec36d6 in gimplify_addr_expr (expr_p=0x7fffba8c6940, pre_p=0x7fffbbb0, post_p=0x7fffb0f8) at /home/marxin/Programming/gcc/gcc/gimplify.cc:6561 #4 0x00ebce24 in gimplify_expr (expr_p=0x7fffba8c6940, pre_p=0x7fffbbb0, post_p=0x7fffb0f8, gimple_test_f=0xe6fb70 , fallback=1) at /home/marxin/Programming/gcc/gcc/gimplify.cc:16408 #5 0x00ec8822 in gimplify_expr (post_p=0x0, allow_ssa=true, fallback=, gimple_test_f=, pre_p=0x7fffbbb0, expr_p=0x7fffba8c6940) at /home/marxin/Programming/gcc/gcc/gimplify.cc:17425 #6 gimplify_arg (arg_p=0x7fffba8c6940, pre_p=0x7fffbbb0, call_location=1422861833, allow_ssa=) at /home/marxin/Programming/gcc/gcc/gimplify.cc:3504 #7 0x00ecbf1c in gimplify_call_expr (expr_p=0x7fffcb66aad8, pre_p=0x7fffbbb0, want_value=) at /home/marxin/Programming/gcc/gcc/gimplify.cc:3789 #8 0x00ebd0ec in gimplify_expr (expr_p=0x7fffcb66aad8, pre_p=0x7fffbbb0, post_p=0x7fffb308, gimple_test_f=0xeafb80 , fallback=0) at /home/marxin/Programming/gcc/gcc/gimplify.cc:16333 #9 0x00ebf4e7 in gimplify_stmt (stmt_p=, seq_p=0x7fffbbb0) at /home/marxin/Programming/gcc/gcc/gimplify.cc:7219 ... (gdb) p debug_tree(decl) unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76fe43f0 fields ignored decl_6 BLK /home/marxin/Programming/testcases/ceph.ii:10806:11 size unit-size align:8 warn_if_not_align:0 offset_align 8 decl_not_flexarray: 0 offset bit-offset context chain > context full-name "class std::allocator" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=3 interface-only pointer_to_this reference_to_this chain > addressable used ignored read BLK /home/marxin/Programming/testcases/ceph.ii:322049:24 size unit-size align:8 warn_if_not_align:0 context >
[Bug c++/108773] [13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph since r13-4563-g1e1847612d7f169f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 Martin Liška changed: What|Removed |Added Summary|internal compiler error: in |[13 Regression] ICE in |gimplify_var_or_parm_decl, |gimplify_var_or_parm_decl, |at gimplify.cc:3058 |at gimplify.cc:3058 |compiling ceph |compiling ceph since ||r13-4563-g1e1847612d7f169f --- Comment #3 from Martin Liška --- Started with r13-4563-g1e1847612d7f169f
[Bug c++/108773] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-13 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I can reproduce that I'm reducing that right now..
[Bug c++/108773] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 --- Comment #1 from kkeithle at redhat dot com --- see https://bugzilla.redhat.com/show_bug.cgi?id=2169364 see https://bugzilla-attachments.redhat.com/attachment.cgi?id=1943849 for preprocessed source file (too big to attach here)
[Bug c++/108773] New: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773 Bug ID: 108773 Summary: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3058 compiling ceph Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kkeithle at redhat dot com Target Milestone: --- Description of problem: see https://koji.fedoraproject.org/koji/taskinfo?taskID=97426819 gcc throws compiler error during compilation of ...ceph/src/rgw/driver/rados/rgw_sync_trace.cc in ceph snapshot from https://1.chacra.ceph.com/r/ceph/main/9754cafc029e1da83f5ddd4332b69066fe6b3ffb/centos/8/flavors/default/SRPMS/ceph-18.0.0-2148.g9754cafc.el8.src.rpm Version-Release number of selected component (if applicable): 13.0.1-0.2.fc38 How reproducible: See preprocessed output in the attachment
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 --- Comment #1 from Jakub Jelinek --- Does firefox really use -fimplicit-constexpr and -g1? Anyway, I'm afraid I have no idea what the problem is here, the ICE is when trying to force a DIE for std::_Sp_make_shared_tag::_S_ti()::__tag late, but there is no debug info for _S_ti() beucase it was implicitly marked constexpr and with -g1 probably not really used.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-02-13 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 Ever confirmed|0 |1 Component|c++ |debug
[Bug c++/108772] New: [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
Bug ID: 108772
Summary: [13 Regression] ICE in force_decl_die, at
dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Noticed that in Firefox package:
$ cat ice.ii
namespace std {
struct _Sp_counted_base {
virtual void *_M_get_deleter(const int &);
};
bool _S_eq(int);
struct _Sp_make_shared_tag {
static const int &_S_ti() {
static constexpr char __tag{};
return reinterpret_cast(__tag);
}
};
struct _Impl {
_Impl(int);
};
int _Sp_counted_ptr_inplace___a;
struct _Sp_counted_ptr_inplace : _Sp_counted_base {
_Sp_counted_ptr_inplace() : _M_impl(_Sp_counted_ptr_inplace___a) {}
void *_M_get_deleter(const int &__ti) {
auto __ptr(_M_ptr());
&__ti == &_Sp_make_shared_tag::_S_ti() || _S_eq(__ti);
return __ptr;
}
int *_M_ptr();
_Impl _M_impl;
};
struct __shared_count {
__shared_count(int, int) { _Sp_counted_ptr_inplace(); }
};
int _M_ptr;
struct __shared_ptr {
template
__shared_ptr(_Alloc __tag) : _M_refcount(_M_ptr, __tag) {}
__shared_count _M_refcount;
};
int shared_ptr___tag;
struct shared_ptr : __shared_ptr {
shared_ptr() : __shared_ptr(shared_ptr___tag) {}
};
void ArgEq() { shared_ptr(); }
} // namespace std
$ g++ ice.ii -flto -fPIC -shared -O1 -fimplicit-constexpr -g1
lto1: internal compiler error: in force_decl_die, at dwarf2out.cc:26770
0x672f7a force_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:26770
0x970f8f force_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:4940
0x970f8f get_context_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:26701
0x970f8f force_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:26717
0x984b2d force_decl_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:26715
0x984b2d get_context_die
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:26701
0x984b2d flush_limbo_die_list
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:32079
0x988ca8 dwarf2out_finish
/home/marxin/Programming/gcc/gcc/dwarf2out.cc:32155
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/105651] [12 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Jonny Grant changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #24 from Jonny Grant ---
Hi, Glad it is fixed in trunk. I saw this fail in 12.2 - test case below.
#include
typedef struct a_bc
{
std::string a;
std::string b;
} a_t;
void f()
{
a_t c;
c.a = " sdfsdf fsdfsdf fdfsfdsdf "; // seems to need this long string to
reproduce, down to 8 bytes it didn't
c.b = "E";
}
[Bug libstdc++/108771] New: Incorrect noexcept for merging in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108771 Bug ID: 108771 Summary: Incorrect noexcept for merging in Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Target Milestone: --- _M_merge_unique and _M_merge_equal in _Rb_tree have noexcept. This is problematic because the call to _M_insert_node is potentially throwing, by the call to the comparison object. The subclause [associative.reqmts.general] also suggest it can throw: a.merge(a2) Throws: Nothing unless the comparison object throws. There is no such issue in _Hashtable.
[Bug c/108770] Spurious -Warray-bounds at -O2 (gcc >= 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108770
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-13
Blocks||56456
Status|UNCONFIRMED |NEW
Keywords||diagnostic
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We've "optimized" the loop to
while (1)
{
if (i == 2) { put (2); if (arr[2] == 0) break; put (2); }
else { if (arr[i] == 0) break; }
i++;
}
and diagnose the appearing out-of-bounds accesses. It's like some other
bugs where jump threading isolates a path that's not reachable at runtime
but we fail to prove that and thus fail to eliminate the isolated path.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c/108770] New: Spurious -Warray-bounds at -O2 (gcc >= 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108770
Bug ID: 108770
Summary: Spurious -Warray-bounds at -O2 (gcc >= 12)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.jones at vector dot com
Target Milestone: ---
I think this might be a duplicate of some other cases, but this also seems
"simpler" and more surprising about the -Warray-bounds:
```
extern void put(int i);
int check_idx(int i) {
if (i > 1)
put(i);
return i;
}
const char *arr[] = {"A", 0};
void init() {
int i = 0;
while (arr[check_idx(i)] != 0) {
if (arr[check_idx(i)]) {}
i++;
}
}
```
On Godbolt, and with `-Warray-bounds -Werror`, we get:
* GCC 11.3, -O2: compiles
* GCC 11.3, -O3: compiles
* GCC 12.1, -O2: does not compile
* GCC 12.1, -O3: does not compile
* GCC "trunk" (22ba8570e6343e10e4a82e837166e181a1abb21b-binutils-2.38),
-O2: does not compile
* GCC "trunk" (22ba8570e6343e10e4a82e837166e181a1abb21b-binutils-2.38),
-O3: does not compile
The error looks like:
```
: In function 'init':
:9:13: error: array subscript 2 is above array bounds of 'const char
*[2]' [-Werror=array-bounds=]
9 | while (arr[check_idx(i)] != 0) {
| ~~~^~
:6:13: note: while referencing 'arr'
6 | const char *arr[] = {"A", 0};
| ^~~
cc1: all warnings being treated as errors
Compiler returned: 1
```
As far as I can tell, this program is "well formed": the first iteration of the
loop (`i=0`), then `arr[i] != 0`; on the second iteration of the loop (`i=1`),
`arr[i] == 0`, so we terminate.
Basically, "by inspection", it is unclear to me how GCC decides on the array
index being possible at 2.
Interestingly, if you change:
```
if (i > 1)
```
in `check_idx` to be anything *other* than the `length of arr - 1`, then the
warning goes away.
Equally, if you add an extra element to `arr` (e.g., `arr[] = {"A", "A", 0}`),
then you now need `i > 2` to trigger the warning.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | --- Comment #8 from Richard Biener --- Thanks. I'm thinking what to most sensibly do given that we do not support annotating an indirect call as returns_twice (that's something easy to add though, but won't help legacy code)
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691
--- Comment #7 from David Spickett ---
> That still leaves us with missing abnormal edges - David, was this reduced
> from an actual program?
No, it's a simplified version of the C used to generate an LLVM IR test case:
extern int setjmp(ptr);
extern void notsetjmp(void);
void bbb(void) {
setjmp(0);
int (*fnptr)(ptr) = setjmp;
fnptr(0);
notsetjmp();
}
The test is checking that llvm follows each call to a returns twice function
with a branch target identifier instruction. In case the function returns using
a jump instead of the normal ret. That's probably beside the point for this bug
though.
The "real code" that motivated the feature was not doing indirect calls. I just
tested that because there's no reason it shouldn't also work.
I don't know of a use case for code like this. Like you said, if the compiler
doesn't know what the indirect call target is, it won't know it's return twice.
If it does know what you're calling, you could probably just call it directly.
So I was just shuffling statements around to test clang and compare against gcc
and found the ICE that way.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691
--- Comment #6 from Richard Biener ---
The reason is that gimple_call_flags returns a different answer from the
indirect function call vs. the direct function call after propagating of
the constant. First of all 'returns_twice' is an attribute that
cannot be set on a function type:
int __attribute__((returns_twice)) (*foo) (void);
> gcc-12 -S t.c -Wall
t.c:1:1: warning: 'returns_twice' attribute ignored [-Wattributes]
1 | int __attribute__((returns_twice)) (*foo) (void);
| ^~~
so one cannot have an indirect call annotated. But even then we for
example treat indirect missing 'noreturn' conservatively, not requiring
it to end a BB and only enforce that in the fixup-CFG pass.
Now, for return_twice we could similarly check gimple_call_ctrl_altering.
That still leaves us with missing abnormal edges - David, was this reduced
from an actual program?
When fixing up DCE to not set cfun->calls_setjmp it will eventually be
set late in emit_call_1 via
if (ecf_flags & ECF_RETURNS_TWICE)
{
add_reg_note (call_insn, REG_SETJMP, const0_rtx);
cfun->calls_setjmp = 1;
}
a "fix" here would be to _check_ for cfun->calls_setjmp instead of setting it
(or assert it is set). The control-altering flag has no representation
on GENERIC, and we're still expanding calls via intermediate GENERIC ...
[Bug c++/108769] [C++20] __is_trivial returns true even if a default constructor's constraints are unsatisfied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108769 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58074, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106085 Keywords||accepts-invalid Last reconfirmed||2023-02-13 Ever confirmed|0 |1
[Bug c++/108769] New: [C++20] __is_trivial returns true even if a default constructor's constrains are unsatisfied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108769
Bug ID: 108769
Summary: [C++20] __is_trivial returns true even if a default
constructor's constrains are unsatisfied
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roi.jacobson1 at gmail dot com
Target Milestone: ---
GCC accepts this code:
template
struct S {
S() requires false = default;
};
static_assert(__is_trivial(S));
There are some related DRs that GCC doesn't implement (like DR1363), but I
don't think this falls under any of them.
[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 108768, which changed state. Bug 108768 Summary: bogus -Warray-bounds warnings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108768 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/108768] bogus -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108768
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener ---
Well, the function is inlined from
if ((p & 0x03) != extract (b, 64, 2)) {
and 64/8 + 1 == 9, so the warning is correct.
[Bug libcc1/67590] libcc1 cannot find objdump when cross build native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67590
Christer Solskogen changed:
What|Removed |Added
CC||christer.solskogen at gmail
dot co
||m
--- Comment #3 from Christer Solskogen ---
One workaround is adding gcc_cv_objdump=${TARGET}-objdump to the make command.
[Bug lto/97637] Compiling with LTO causes a bigger binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97637 Christer Solskogen changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED
[Bug rtl-optimization/108516] Useless movzx instruction emitted when loading 8 bits from 24 bit struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #6 from Uroš Bizjak --- Created attachment 54454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54454=edit patch to relax extract modes This patch relaxes extract and insert operand modes to no longer match op mode.
[Bug analyzer/108403] -Wanalyzer-null-dereference false negative with *q == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108403
Geoffrey changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Comment #1 from Geoffrey ---
Hi, David.I think this case may be a duplicate of Bug 107733
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733), because I can reduce it
to the following case_1. But, I tried to modify this case to the following
case_2 (https://godbolt.org/z/qTze3Mh6T). It seems that GCC adds two
contradictory conditions (q == 0 and *q == 0) to equivlent classes. I do not
think this still counts a duplicate of case_1. But I am not very sure. Could
you spare some time to help me understand this case? Maybe I can help to
contribute to GCC Static Analyzer. Thanks a lot!
case_1
```c
#include "stdio.h"
int *f(int *q)
{
if (q == 0)
{
*q == 0;
}
}
```
case_2
```c
#include "stdint.h"
#include "stdio.h"
#include
#include
extern void __analyzer_describe ();
extern void __analyzer_eval ();
extern void __analyzer_dump ();
extern void __analyzer_dump_state (const char *name, ...);
extern void __analyzer_dump_region_model ();
extern void __analyzer_dump_exploded_nodes ();
int *f(int *q)
{
if (q == 0 && *q == 0)
{
__analyzer_dump ();
__analyzer_eval (q == 0);
__analyzer_eval (*q == 0);
}
}
```
output of case_2:
```
rmodel:
stack depth: 1
frame (index 0): frame: 'f'@1
clusters within root region
cluster for: (*INIT_VAL(q_8(D)))
ESCAPED
m_called_unknown_fn: FALSE
constraint_manager:
equiv classes:
ec0: {(int)0 == INIT_VAL((*INIT_VAL(q_8(D == [m_constant]'0'}
ec1: {(void *)0B == INIT_VAL(q_8(D)) == [m_constant]'0B'}
constraints:
: In function 'f':
:19:9: warning: TRUE
19 | __analyzer_eval (q == 0);
| ^~~~
:20:9: warning: TRUE
20 | __analyzer_eval (*q == 0);
| ^
Compiler returned: 0
```
