[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 --- Comment #11 from sandra at gcc dot gnu.org --- OK, I've been digging around in the code. do_poplevel() only fills in BIND_EXPR_BLOCK if stmts_are_full_exprs_p() is true. I haven't figured out the control flow that affects the latter predicate or how the vars in a BIND_EXPR end up associated with some other block, but I understand what a full-expression is in C++, so I think I can go off and come up with some test cases to exercise that and figure out what the right thing to do with the tree coming in to this restructuring is.
[Bug target/93006] Better code with a-- == 0 rather than --a == -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93006
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=96702
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-05
--- Comment #2 from Andrew Pinski ---
Confirmed, the problem is the single_use usage in:
/* For equality, this is also true with wrapping overflow. */
(for op (eq ne)
(simplify
(op:c (nop_convert?@3 (plus:c@2 @0 (convert1? @1))) (convert2? @1))
(if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
|| TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
&& (CONSTANT_CLASS_P (@0) || (single_use (@2) && single_use (@3)))
&& tree_nop_conversion_p (TREE_TYPE (@3), TREE_TYPE (@2))
&& tree_nop_conversion_p (TREE_TYPE (@3), TREE_TYPE (@1)))
(op @0 { build_zero_cst (TREE_TYPE (@0)); })))
Similar as for the minus case, see PR 96702 for that ...
[Bug tree-optimization/109638] unsigned > 1 ? 0 : n is not optimized to n == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109638 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- This got fixed by r14-3036-gb57bd27cb68fdb .
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #21 from Jerry DeLisle --- (In reply to john.harper from comment #20) > With the first test case all the EN outputs were 666. but the Fortran 2018 > standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but > Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 > unless my copy of F2018 is out of date. (I note that the F2023 standard > removed the ambiguity by including "with w > 0" in the offending line of > Table 13.2.) However F2018 is unambiguous and agrees with F2023 on > EN0.0E0, requiring 666.E+0 > > With the second test case, which used 66600, I think all Jerry's outputs > are correct. I did not touch the code that writes the Exponent parts yet. So will have a look.
[Bug analyzer/111289] New: Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
Bug ID: 111289
Summary: Unwarranted -Wanalyzer-va-arg-type-mismatch warning
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 55842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55842=edit
test case foo.c
On the attached program, gcc 13.2.0 with analyzer produces a warning:
$ gcc -fanalyzer -O2 -S foo.c
foo.c: In function ‘do_open’:
foo.c:13:10: warning: ‘va_arg’ expected ‘mode_t’ {aka ‘unsigned int’} but
received ‘int’ for variadic argument 1 of ‘arg’ [CWE-686]
[-Wanalyzer-va-arg-type-mismatch]
13 | mode_t mode = va_arg (arg, mode_t);
| ^~~~
‘main’: events 1-2
|
| 20 | main ()
| | ^~~~
| | |
| | (1) entry to ‘main’
| 21 | {
| 22 | do_open ("nonexist.ent/", 0600);
| | ~~~
| | |
| | (2) calling ‘do_open’ from ‘main’ with 1 variadic argument
|
+--> ‘do_open’: events 3-4
|
|8 | do_open (char const *name, ...)
| | ^~~
| | |
| | (3) entry to ‘do_open’
|..
| 13 | mode_t mode = va_arg (arg, mode_t);
| |
| | |
| | (4) ‘va_arg’ expected ‘mode_t’ {aka ‘unsigned
int’} but received ‘int’ for variadic argument 1 of ‘arg’
|
There is no reason to warn here, because
1) ISO C 99 § 7.15.1.1.(2) says "... the behavior is undefined, except for the
following cases:
— one type is a signed integer type, the other type is the corresponding
unsigned integer type, and the value is representable in both types;
— ..."
Likewise ISO C 23 § 7.16.1.1.(2).
2) The argument that gets passed is an 'int'. The other type, mode_t, is
'unsigned int'. The argument is a constant, and its value 0600 is representable
both as 'int' and as 'unsigned int'.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #20 from john.harper at vuw dot ac.nz --- With the first test case all the EN outputs were 666. but the Fortran 2018 standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 unless my copy of F2018 is out of date. (I note that the F2023 standard removed the ambiguity by including "with w > 0" in the offending line of Table 13.2.) However F2018 is unambiguous and agrees with F2023 on EN0.0E0, requiring 666.E+0 With the second test case, which used 66600, I think all Jerry's outputs are correct. On Mon, 4 Sep 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Mon, 4 Sep 2023 17:12:30 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Tue, 5 Sep 2023 05:12:45 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #18 from Jerry DeLisle --- > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent is > zero it is not shown at all. If I do specify an exponent width it shown. For > example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug other/111288] formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 --- Comment #4 from Bruno Haible --- My proposed patch is a correction to commit 2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b by Jakub Jelinek. > patches should be posted to gcc-patches@ after reading > https://gcc.gnu.org/contribute.html I do have a copyright assigment for GCC in place. But I don't have time to follow the entire procedure. Maybe someone else can take over, from this point?
[Bug other/111288] formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 --- Comment #3 from Andrew Pinski --- patches should be posted to gcc-patches@ after reading https://gcc.gnu.org/contribute.html
[Bug other/111288] formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 --- Comment #2 from Bruno Haible --- Created attachment 55841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55841=edit Rendering after applying the fix
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 --- Comment #2 from Christophe Lyon --- Oops sorry I pushed an unwanted patch, which I reverted with https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
[Bug other/111288] formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 --- Comment #1 from Bruno Haible --- Created attachment 55840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55840=edit Rendering before applying the fix
[Bug other/111288] New: formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 Bug ID: 111288 Summary: formatting mistake in HTML documentation Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 55839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55839=edit proposed fix In https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html the declarations of the last 6 functions are not well formatted: the highlighted token is "int" or "long", not the name of the built-in. The attached patch fixes it. I'm also attaching the rendering before and after the patch is applied.
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 --- Comment #1 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:56d0592db19b69e3cc217fabe5c2f8be3a75a8cf commit r14-3660-g56d0592db19b69e3cc217fabe5c2f8be3a75a8cf Author: Christophe Lyon Date: Thu Aug 31 13:50:16 2023 + libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds (PR111238) As discussed in PR104167 (comments #8 and below), and PR111238, using -Wl,-gc-sections in the libstdc++ testsuite for arm-eabi (cross-toolchain) avoids link failures for a few tests: 27_io/filesystem/path/108636.cc std/time/clock/gps/1.cc std/time/clock/gps/io.cc std/time/clock/tai/1.cc std/time/clock/tai/io.cc std/time/clock/utc/1.cc std/time/clock/utc/io.cc std/time/clock/utc/leap_second_info.cc std/time/exceptions.cc std/time/format.cc std/time/time_zone/get_info_local.cc std/time/time_zone/get_info_sys.cc std/time/tzdb/1.cc std/time/tzdb/leap_seconds.cc std/time/tzdb_list/1.cc std/time/zoned_time/1.cc std/time/zoned_time/custom.cc std/time/zoned_time/io.cc std/time/zoned_traits.cc This patch achieves this by calling GLIBCXX_CHECK_LINKER_FEATURES in cross-build cases, like we already do for native builds. We keep not doing so in Canadian-cross builds. However, this would hide the fact that libstdc++ somehow forces the user to use -Wl,-gc-sections to avoid undefined references to chdir, mkdir, chmod, pathconf, ... so maybe it's better to keep the status quo and not apply this patch? 2023-08-31 Christophe Lyon libstdc++-v3/ChangeLog: PR libstdc++/111238 * configure: Regenerate. * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross, non-Canadian builds.
[Bug other/111287] doc: "strict ISO mode" definition is not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-09-04 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Or just add ", etc." so it doesn't need to be updated again.
[Bug other/111287] New: doc: "strict ISO mode" definition is not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287 Bug ID: 111287 Summary: doc: "strict ISO mode" definition is not up-to-date Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html we read: "Outside strict ISO C mode (-ansi, -std=c90, -std=c99 or -std=c11) ..." Nowadays, the options -std=c17 and -std=c2x also put gcc in "strict ISO C mode", as can be seen from the __STRICT_ANSI__ preprocessor macro: $ : | gcc -std=c90 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c99 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c11 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c17 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c2x -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 Could this sentence in the manual be updated to include these new -std options?
[Bug c++/111286] [12/13/14 Regression] ICE on functional cast empty brace-init-list to const array reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.4 Known to fail||12.1.0 Keywords||ice-on-valid-code, ||needs-bisection Summary|ICE on functional cast |[12/13/14 Regression] ICE |empty brace-init-list to|on functional cast empty |const array reference |brace-init-list to const ||array reference Known to work||11.4.0 Ever confirmed|0 |1 Last reconfirmed||2023-09-04 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/111286] New: ICE on functional cast to const array reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Bug ID: 111286
Summary: ICE on functional cast to const array reference
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
With g++ 13.2.0
with flags: -std=c++20
The following code:
```
struct A {
A() noexcept {}
};
void foo() {
using T = const A (&)[1];
T{};
}
```
Produces the following compiler output:
: In function 'void foo()':
:7:7: internal compiler error: in cp_build_addr_expr_1, at
cp/typeck.cc:7147
7 | T{};
| ^
0x1ce7bde internal_error(char const*, ...)
???:0
0x7290fc fancy_abort(char const*, int, char const*)
???:0
0x74b040 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
???:0
0x8e9510 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x89fd5b c_parse_file()
???:0
0x98c5d9 c_common_parse_file()
???:0
https://godbolt.org/z/MaWTTv4Y7
[Bug testsuite/111071] [14 Regression] gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp has new failures since commit e7a36e4715c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111071 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:a338c5f6114f3b9f2ed067bc7738b405091a76ce commit r14-3658-ga338c5f6114f3b9f2ed067bc7738b405091a76ce Author: Thiago Jung Bauermann Date: Mon Sep 4 19:57:10 2023 +0100 testsuite: aarch64: Adjust SVE ACLE tests to new generated code Since commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify (-1-x) for vector." these tests fail on aarch64-linux: === g++ tests === Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_u8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu++98 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_u8_m === gcc tests === Running gcc:gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ... FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_s8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_s8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_FULL check-function-bodies subr_m1_u8_m FAIL: gcc.target/aarch64/sve/acle/asm/subr_u8.c -std=gnu90 -O2 -fno-schedule-insns -DCHECK_ASM --save-temps -DTEST_OVERLOADS check-function-bodies subr_m1_u8_m Andrew Pinski's analysis in PR testsuite/111071 is that the new code is better and the testcase should be updated. I also asked Prathamesh Kulkarni in private and he agreed. Here is the update. With this change, all tests in gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp pass on aarch64-linux. Suggested-by: Andrew Pinski gcc/testsuite/ PR testsuite/111071 * gcc.target/aarch64/sve/acle/asm/subr_s8.c: Adjust to new code. * gcc.target/aarch64/sve/acle/asm/subr_u8.c: Likewise.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #18) > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. Intel prints With (A,1X,EN0.0E0) 666.+0 which I think is slightly more in accordance with F2018 Table 13.2, which requires printing the exponent for the ...E0 version with the minimum number of digits, which is 1 for a zero exponent. See the "footnote (1)" there. Can you please check? Or am I missing something? > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent > is zero it is not shown at all. If I do specify an exponent width it shown. > For example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions?
[Bug tree-optimization/110009] Another missing ABS detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009 Andrew Pinski changed: What|Removed |Added Blocks||98907 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Vector testcases too: > > Which does work with the match pattern in comment #5. Except veclowering messes up ABSU, see PR 111285 for that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98907 [Bug 98907] Failure to optimize abs pattern
[Bug tree-optimization/110009] Another missing ABS detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009 --- Comment #7 from Andrew Pinski --- Created attachment 55838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55838=edit dg-testcase
[Bug tree-optimization/111285] New: vector ABSU is lowered incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285
Bug ID: 111285
Summary: vector ABSU is lowered incorrectly
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 110009
Target Milestone: ---
Take:
```
#define vector __attribute__((vector_size(1*sizeof(int
void unsigned_f1 (vector int *vp, vector unsigned *x)
{
vector int v = *vp;
vector unsigned int d_6;
vector int b_5;
vector unsigned int v1_2;
vector unsigned int _7;
vector int _9;
b_5 = v>>(sizeof(int)*8 - 1);
_9 = b_5 | 1;
d_6 = (vector unsigned int) _9;
v1_2 = (vector unsigned int) v;
_7 = v1_2 * d_6;
*x = _7;
}
```
and this match.pd pattern:
```
/* x * ((x>>N)|1) -> abs(x) */
(simplify
(mult:c @0 (nop_convert? (bit_ior:c (rshift @1 INTEGER_CST@2) integer_onep)))
(if (!TYPE_UNSIGNED (TREE_TYPE (@1))
&& wi::to_wide (@2) == element_precision (type) - 1
&& bitwise_equal_p (@0, @1))
(if (TYPE_UNSIGNED (type))
(absu @1)
(abs @1
```
With this we get right before vector lowering:
```
v_3 = *vp_2(D);
_7_4 = ABSU_EXPR ;
# .MEM_6 = VDEF <.MEM_1(D)>
*x_5(D) = _7_4;
```
Which is correct.
But then lowering comes along and gives:
```
v_3 = *vp_2(D);
_7 = VIEW_CONVERT_EXPR(v_3);
_7_4 = {_7};
# .MEM_6 = VDEF <.MEM_1(D)>
*x_5(D) = _7_4;
```
This is because we used the lhs type rather than the rhs type ...
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
[Bug 110009] Another missing ABS detection
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #18 from Jerry DeLisle --- With Johns test case from Comment #15 and the patch in Comment #17 I get the following: $ ./a.out real kinds 4 8 10 16 With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 ERROR STOP Scale factor out of range in format specifier 'E' or 'D' Notice that the width of exponents is also minimized and where the exponent is zero it is not shown at all. If I do specify an exponent width it shown. For example with exponent width of 4 and changing the value to 66600 I get: $ ./a.out real kinds 4 8 10 16 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 ERROR STOP Scale factor out of range in format specifier 'E' or 'D' This seems reasonable to me. Other opinions?
[Bug libstdc++/26142] global debug namespace clashes everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:affbb7b4322a01cecddaa4dfb70faee925a2348b commit r14-3654-gaffbb7b4322a01cecddaa4dfb70faee925a2348b Author: Jonathan Wakely Date: Mon Sep 4 12:12:35 2023 +0100 libstdc++: Fix filenames and comments in tests [PR26142] These tests have transposed digits in the filenames and comments. libstdc++-v3/ChangeLog: PR libstdc++/26142 * testsuite/23_containers/vector/26412-1.cc: Moved to... * testsuite/23_containers/vector/26142-1.cc: ...here. * testsuite/23_containers/vector/26412-2.cc: Moved to... * testsuite/23_containers/vector/26142-2.cc: ...here.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 --- Comment #3 from Thorsten Otto --- Created attachment 55837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55837=edit Avoid segmentation fault when calling assign_temp with a NULL type pointer Attached is a potential patch to fix that. The above mentioned commit was made for gcc 4.3, and all compiler versions after that are affected by it.
[Bug c/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #8 from philipp.tomsich at vrull dot eu ---
On Mon, 4 Sept 2023 at 13:38, manolis.tsamis at vrull dot eu <
gcc-bugzi...@gcc.gnu.org> wrote:
> My current match.pd pattern to do that is below; any feedback or
> improvements
> are welcome.
>
> (simplify
> (mult (convert@3 (plus @0 INTEGER_CST@1)) INTEGER_CST@2)
> (with { tree tt = TREE_TYPE(@3); }
>(if (INTEGRAL_TYPE_P (type)
> && !TYPE_SATURATING (type)
> && !TYPE_OVERFLOW_TRAPS (type)
> && !TYPE_OVERFLOW_SANITIZED (type)
> && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
> (plus (mult (convert:tt @0) @2) (mult (convert:tt @1) @2)
>
Please attach a current .patch to this ticket to make sure that there are
no surprises in reproducing.
[Bug other/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059 Thomas Schwinge changed: What|Removed |Added Component|middle-end |other Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Assignee|burnus at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #7 from Thomas Schwinge --- commit r14-3650-gfe0f9e09413047484441468b05288412760d8a09 "Add 'libgomp.c-c++-common/pr100059-1.c'"
[Bug c/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #7 from Manolis Tsamis ---
After some attempts to improve on this, my current solution is:
1) Do not change pointer_int_sum in c-common (otherwise codegen regressions
are observed)
2) Introduce a pattern that folds (unsigned type) (x + CONST_INT_1) *
CONST_INT_2 to (unsigned type) (x * CONST_INT_2) + (unsigned type) (CONST_INT_1
* CONST_INT_1) under the right circumstances.
This combination improves codegen (including the testcase provided) and also
doesn't cause any regressions on the GCC testsuite or benchmarks that I have
tried so far.
Given that a[(ulong) i +- C] in GIMPLE is quite common, I believe this change
helps with folding / canonicalization in many cases.
My current match.pd pattern to do that is below; any feedback or improvements
are welcome.
(simplify
(mult (convert@3 (plus @0 INTEGER_CST@1)) INTEGER_CST@2)
(with { tree tt = TREE_TYPE(@3); }
(if (INTEGRAL_TYPE_P (type)
&& !TYPE_SATURATING (type)
&& !TYPE_OVERFLOW_TRAPS (type)
&& !TYPE_OVERFLOW_SANITIZED (type)
&& !TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
(plus (mult (convert:tt @0) @2) (mult (convert:tt @1) @2)
[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111258 --- Comment #3 from Jiang An --- I've reduced the example and filed Bug 111284.
[Bug c++/111284] New: Some passing-by-value parameters are miscompiled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Bug ID: 111284
Summary: Some passing-by-value parameters are miscompiled since
GCC 9
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
GCC incorrectly rejects the following program since GCC 9
(https://godbolt.org/z/cGK1a1dqK):
```
class self_locator {
public:
self_locator() = default;
constexpr self_locator(const self_locator&) noexcept : this_{this} {}
constexpr self_locator& operator=(const self_locator&) noexcept { return
*this; }
constexpr bool valid() const noexcept { return this_ == this; }
private:
self_locator *this_ = this;
};
constexpr bool demonstrator(self_locator x) noexcept
{
return x.valid();
}
static_assert(demonstrator(self_locator{}), "");
static_assert([](self_locator x){ return x.valid(); }(self_locator{}), "");
```
The `valid` member function should always return true. But if `self_locator` is
passed by value, GCC can sometimes render the parameter in an inconsistent
state (perhaps due to incorrect bitwise copy).
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #6 from Matthias Klose --- last known successful profiled bootstrap with trunk 20230811
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #5 from Matthias Klose --- a normal bootstrap (at least on i686-linux-gnu) succeeds
[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- Due to P2448R2 (https://wg21.link/p2448r2), the posted example is totally valid since C++23.
[Bug middle-end/100059] [OpenMP] wrong code with 'declare target link' and a scalar variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org See Also||https://github.com/MentorEm ||bedded/nvptx-tools/pull/29 --- Comment #6 from Thomas Schwinge --- (In reply to Tobias Burnus from comment #4) > https://github.com/MentorEmbedded/nvptx-tools/pull/29 This is now finally incorporated, sorry for the (long...) delay. Are you going to push the GCC-level test case (submitted in this PR), or want me to? For nvptx offloading, it'll FAIL its execution test until nvptx-tools updated, but that's OK in my opinion.
[Bug tree-optimization/98907] Failure to optimize abs pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98907 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- Mine, bug 110009 comment #3 has the patch for this and that one.
[Bug tree-optimization/110009] Another missing ABS detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #6 from Andrew Pinski ---
Vector testcases too:
```
#define vector __attribute__((vector_size(4*sizeof(int
vector int
signed_f1(vector int v)
{
vector int b_5;
vector int _7;
vector int _9;
b_5 = v>>(sizeof(int)*8 - 1);
_9 = b_5 | 1;
_7 = v * _9;
return _7;
}
vector unsigned
unsigned_f1 (vector int v)
{
vector unsigned int d_6;
vector int b_5;
vector unsigned int v1_2;
vector unsigned int _7;
vector int _9;
b_5 = v>>(sizeof(int)*8 - 1);
_9 = b_5 | 1;
d_6 = (vector unsigned int) _9;
v1_2 = (vector unsigned int) v;
_7 = v1_2 * d_6;
return _7;
}
```
Which does work with the match pattern in comment #5.
[Bug tree-optimization/110009] Another missing ABS detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009 --- Comment #5 from Andrew Pinski --- With the nop_convert added and using bitwise_equal_p : (simplify (mult:c @0 (nop_convert? (bit_ior:c (rshift @1 INTEGER_CST@2) integer_onep))) (if (!TYPE_UNSIGNED (TREE_TYPE (@1)) && wi::to_wide (@2) == element_precision (type) - 1 && bitwise_equal_p (@0, @1)) (if (TYPE_UNSIGNED (type)) (absu @1) (abs @1
[Bug tree-optimization/110009] Another missing ABS detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #4 from Andrew Pinski ---
Mine.
Even the simple one:
```
int
signed_f1(int v)
{
int b_5;
int _7;
int _9;
b_5 = v>>(sizeof(v)*8 - 1);
_9 = b_5 | 1;
_7 = v * _9;
return _7;
}
```
is not detected.
First version without any nop_converts added:
(simplify
(mult:c @0 (bit_ior:c (rshift @0 INTEGER_CST@1) integer_onep))
(if (!TYPE_UNSIGNED (TREE_TYPE (@0))
&& wi::to_wide (@1) == element_precision (type) - 1)
(abs @0)))
[Bug tree-optimization/110010] (a>>N) != (b>>N) is not optimized to (a^b) >= (1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110010 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-04 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine.
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #4 from Andreas Schwab --- Doesn't fail here, but it uses release checking: https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc14/openSUSE_Tumbleweed/i586
[Bug tree-optimization/111148] Missing boolean optimizations due to comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48 --- Comment #1 from Andrew Pinski --- Note f was done in r14-3528 .
[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274 David Binderman changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from David Binderman --- (In reply to sandra from comment #9) > I'm not sure what a null BIND_EXPR_BLOCK actually means, or if it might be a > bug elsewhere that such a thing is being created? The comments on BIND_EXPR > in tree.def seem to imply that there is always an associated block. If it's > permissible, maybe the fix ought to pass through the superblock pointer in > the recursive call instead of the null block pointer. My best guess is to ask Richard. If he doesn't know, he is likely to know someone who will.
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 --- Comment #2 from Andrew Pinski --- Note `|` case already handled by r8-4395: /* a | ~(a ^ b) --> a | ~b */ (simplify (bit_ior:c @0 (bit_not:s (bit_xor:c @0 @1))) (bit_ior @0 (bit_not @1)))
[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Generalized for -O1 case:
> // (a & (b & ~a)) -> 0
> // (a & (b | ~a)) -> a & b
> // (a & (b ^ ~a)) -> a & b
> // (a & (b cmp !a)) -> a & (b cmp 0)
> (for op (tcc_comparison bit_and bit_xor bit_and)
> (simplify
> (bit_and:c zero_one_valued_p@0 (op:c @1 (convert? @2)))
> (with { bool wascmp; }
>(if (bitwise_inverted_equal_p (@0, @2, wascmp))
> (bit_and @0 (op @1 { build_zero_cst (TREE_TYPE (@1)); })
>
>
> Note I filed PR 111282 for `(a & (b ^ ~a))` also.
The corrected version is:
// (a & (b & ~a)) -> 0
// (a & (b | ~a)) -> a & b
// (a & (b ^ ~a)) -> a & b
// (a & (b cmp !a)) -> a & (b cmp 0)
(for op (tcc_comparison bit_and bit_xor bit_and)
(simplify
(bit_and:c zero_one_valued_p@0 (op:c @1 (convert? zero_one_valued_p@2)))
(with { bool wascmp; }
(if (bitwise_inverted_equal_p (@0, @2, wascmp))
(bit_and @0 (op @1 { build_zero_cst (TREE_TYPE (@1)); }))
[Bug target/110066] [13 Regression] [RISC-V] Segment fault if compiled with -static -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066 --- Comment #26 from rvalue --- (In reply to CVS Commits from comment #22) > The trunk branch has been updated by Andrew Pinski : > > https://gcc.gnu.org/g:bbc1a102735c72e3c5a4dede8ab382813d12b058 > > commit r14-2733-gbbc1a102735c72e3c5a4dede8ab382813d12b058 > Author: Andrew Pinski > Date: Sat Jul 22 08:52:42 2023 -0700 > > Fix PR 110066: crash with -pg -static on riscv > > The problem -fasynchronous-unwind-tables is on by default for riscv linux > We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ > point > to .eh_frame data from crtbeginT.o instead of the user-defined object > during static linking. > > This turns it off. > > OK? > > libgcc/ChangeLog: > > * config.host (riscv*-*-linux*): Add t-crtstuff to tmake_file. > (riscv*-*-freebsd*): Likewise. > * config/riscv/t-crtstuff: New file. Confirmed that the patch works for me.
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 Andrew Pinski changed: What|Removed |Added Summary|[14 Regression] gnat|[14 Regression] gnat |bootstrap broken on trunk |profilebootstrap broken on |20230902 on 32bit targets |trunk 20230902 on 32bit ||targets --- Comment #3 from Andrew Pinski --- Oh wait this is profile bootstrap: -fprofile-use
[Bug ipa/111283] [14 Regression] gnat bootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #2 from Andrew Pinski --- It works on x86_64. I wonder if those targets being ILP32 make it fail for some heurstics differences ...
[Bug ipa/111283] [14 Regression] gnat bootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 Andrew Pinski changed: What|Removed |Added Component|ada |ipa CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |14.0 Summary|gnat bootstrap broken on|[14 Regression] gnat |trunk 20230902 on 32bit |bootstrap broken on trunk |targets |20230902 on 32bit targets
[Bug ada/111283] gnat bootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #1 from Matthias Klose --- Configured with: -v --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a+fp --with-float=hard --with-mode=thumb --disable-werror --enable-checking=yes make profiledbootstrap-lean
[Bug ada/111283] New: gnat bootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 Bug ID: 111283 Summary: gnat bootstrap broken on trunk 20230902 on 32bit targets Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- seen with trunk 20230902 on at least arm-linux-gnueabihf, i686-linux-gnu and powerpc-linux-gnu: /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/arm-linux-gnueabihf/bin/ -B/usr/lib/gcc-snapshot/arm-linux-gnueabihf/bin/ -B/usr/lib/gcc-snapshot/arm-linux-gnueabihf/lib/ -isystem /usr/lib/gcc-snapshot/arm-linux-gnueabihf/include -isystem /usr/lib/gcc-snapshot/arm-linux-gnueabihf/sys-include-c -g -O2 -fprofile-use -fprofile-reproducible=parallel-runs -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/generated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat -Iada/gcc-interface -I../../src/gcc/ada/gcc-interface ../../src/gcc/ada/nlists.adb -o ada/nlists.o ../../src/gcc/ada/nlists.adb: In function 'Nlists.New_List': ../../src/gcc/ada/nlists.adb:787:4: error: probability of edge 15->16 not initialized during IPA pass: inline +===GNAT BUG DETECTED==+ | 14.0.0 20230902 (experimental) [master r14-3635-g4e2d53c9434] (arm-linux-gnueabihf) GCC error:| | verify_flow_info failed | | Error detected around ../../src/gcc/ada/nlists.adb:787:4 | | Compiling ../../src/gcc/ada/nlists.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). ../../src/gcc/ada/gcc-interface/system.ads ../../src/gcc/ada/nlists.adb ../../src/gcc/ada/nlists.ads ../../src/gcc/ada/types.ads ../../src/gcc/ada/libgnat/ada.ads ../../src/gcc/ada/libgnat/a-unccon.ads ../../src/gcc/ada/libgnat/a-uncdea.ads ../../src/gcc/ada/alloc.ads ../../src/gcc/ada/atree.ads ../../src/gcc/ada/sinfo.ads ../../src/gcc/ada/namet.ads ../../src/gcc/ada/hostparm.ads ../../src/gcc/ada/table.ads ../../src/gcc/ada/uintp.ads ../../src/gcc/ada/urealp.ads ada/sinfo-nodes.ads ada/seinfo.ads ../../src/gcc/ada/output.ads ../../src/gcc/ada/libgnat/s-os_lib.ads ../../src/gcc/ada/libgnat/s-string.ads ../../src/gcc/ada/einfo.ads ada/snames.ads ../../src/gcc/ada/stand.ads ada/einfo-entities.ads ../../src/gcc/ada/einfo-utils.ads ../../src/gcc/ada/debug.ads ../../src/gcc/ada/libgnat/s-exctab.ads ../../src/gcc/ada/libgnat/s-stalib.ads ../../src/gcc/ada/libgnat/s-unstyp.ads ../../src/gcc/ada/libgnat/s-conca2.ads ../../src/gcc/ada/libgnat/s-assert.ads ../../src/gcc/ada/libgnat/a-assert.ads ../../src/gcc/ada/table.adb ../../src/gcc/ada/opt.ads ../../src/gcc/ada/libgnat/s-wchcon.ads ../../src/gcc/ada/libgnat/s-memory.ads ../../src/gcc/ada/libgnat/a-except.ads ../../src/gcc/ada/libgnat/s-parame.ads ../../src/gcc/ada/libgnat/s-traent.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110919
--- Comment #7 from Andrew Pinski ---
Generalized for -O1 case:
// (a & (b & ~a)) -> 0
// (a & (b | ~a)) -> a & b
// (a & (b ^ ~a)) -> a & b
// (a & (b cmp !a)) -> a & (b cmp 0)
(for op (tcc_comparison bit_and bit_xor bit_and)
(simplify
(bit_and:c zero_one_valued_p@0 (op:c @1 (convert? @2)))
(with { bool wascmp; }
(if (bitwise_inverted_equal_p (@0, @2, wascmp))
(bit_and @0 (op @1 { build_zero_cst (TREE_TYPE (@1)); })
Note I filed PR 111282 for `(a & (b ^ ~a))` also.
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 --- Comment #1 from Andrew Pinski --- Note we will need to detect both `a & (b ^ ~a)` and `a & ~(a ^ b)` since a might be comparison too.
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-04 Ever confirmed|0 |1
[Bug tree-optimization/111282] New: `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282
Bug ID: 111282
Summary: `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a
& b` in gimple
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a, int b)
{
return a & (b ^ ~a);
}
``
This should be optimized to `a & b` which it is on the RTL.
