[Bug tree-optimization/120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > One reason is that this is one of the few users of rhs_to_tree, aka we go > back to GENERIC and its folding. Yes I noticed that when I disabled forward_propagate_into_gimple_cond and got a failure dealing with `&a->b != c`. I am thinking I need to write out to a file when forward_propagate_into_gimple_cond/forward_propagate_into_comparison gets back something that is folded to find more rather than just disabling it and finding testsuite failures. Because there could some that the testsuite is not testing for.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #9 from Robert Dubner --- Whether or not this will fix any other problems, I don't know. I do know that valgrind was reporting uninitialized data, and now it is not.
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 Sam James changed: What|Removed |Added Target Milestone|--- |12.5 Summary|Segmentation fault with |[12/13/14/15 regression] |specific optimizations |Segmentation fault with ||specific optimizations ||since ||r10-3311-gff6686d2e5f797 Keywords|needs-bisection,| |needs-reduction | Component|middle-end |ipa CC||jamborm at gcc dot gnu.org
[Bug target/120223] New: [16 Regression] ICE: in extract_insn, at recog.cc:2882 unrecognizable insn: (xor:DI (reg:DI 136) (const_int ...)) with -mcpu=thead-c906
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120223
Bug ID: 120223
Summary: [16 Regression] ICE: in extract_insn, at recog.cc:2882
unrecognizable insn: (xor:DI (reg:DI 136) (const_int
...)) with -mcpu=thead-c906
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 61404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61404&action=edit
-freport-bug output
Compiler output:
$ echo 'long foo(long x) { return x ^ 0x8000; }' |
riscv64-unknown-linux-gnu-gcc -mcpu=thead-c906 -xc -
: In function 'foo':
:1:43: error: unrecognizable insn:
(insn 7 6 10 2 (set (reg:DI 134 [ _2 ])
(xor:DI (reg:DI 136)
(const_int 2147483648 [0x8000]))) "":1:29 -1
(nil))
during RTL pass: vregs
:1:43: internal compiler error: in extract_insn, at recog.cc:2882
0x374f341 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0x113757d fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1815
0xbb6154 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0xbb61d1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0xba6fe2 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2882
0x14e31f3 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1612
0x14e31f3 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1995
0x14e31f3 execute
/repo/gcc-trunk/gcc/function.cc:2042
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.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20250511074635-r16-525-g004bf889e0b1b9-checking-yes-rtl-df-extra-nobootstrap-nographite-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/16.0.0/lto-wrapper
Target: riscv64-unknown-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 --without-cloog --without-ppl --without-isl
--with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--enable-libsanitizer --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20250511074635-r16-525-g004bf889e0b1b9-checking-yes-rtl-df-extra-nobootstrap-nographite-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250511 (experimental) (GCC)
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 90179, which changed state. Bug 90179 Summary: typo in diagnostic for unrecognized control register https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90179 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug translation/90179] typo in diagnostic for unrecognized control register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90179 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Andrew Pinski --- Fixed in GCC 10 by r10-4124-gf8cb8bcde13df2.
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 --- Comment #3 from Christophe Jaillet --- Created attachment 61405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61405&action=edit Reduced reproducer With the attached file, I manage to reproduce the behavior. The #define are the one from Linux, simplified by hand to ease the understanding.
[Bug target/120228] New: Need to call df_insn_rescan after emit_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120228 Bug ID: 120228 Summary: Need to call df_insn_rescan after emit_insn Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: liuhongt at gcc dot gnu.org Target Milestone: --- Target: x86-64 i386 backend has codes like set_insn = emit_insn_before (set, insn); df_insn_rescan (set_insn); df_insn_rescan isn't needed since df_insn_rescan has been called by emit_insn_before.
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Bug 85559 depends on bug 21231, which changed state. Bug 21231 Summary: cmov and cstore standard names not documented. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21231 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/120223] [16 Regression] ICE: in extract_insn, at recog.cc:2882 unrecognizable insn: (xor:DI (reg:DI 136) (const_int ...)) with -mcpu=thead-c906
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120223 --- Comment #1 from Zdenek Sojka --- Created attachment 61407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61407&action=edit probably related -freport-bug output, less reduced, with more flags; fails on ior
[Bug middle-end/21231] cmov and cstore standard names not documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21231 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120230 Target Milestone|--- |4.5.0 --- Comment #3 from Andrew Pinski --- cmov optab is unused (PR120230). Which means this is fixed for GCC 4.5.0. I am testing a patch to remove cmov optab right now too.
[Bug middle-end/101852] [meta-bug] some standard RTL names are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101852 Bug 101852 depends on bug 21231, which changed state. Bug 21231 Summary: cmov and cstore standard names not documented. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21231 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2025-03-21 00:00:00 |2025-5-12 --- Comment #10 from Iain Sandoe --- (In reply to Robert Dubner from comment #9) > Whether or not this will fix any other problems, I don't know. I do know > that valgrind was reporting uninitialized data, and now it is not. sadly, it does not fix the underlying issue: I built and tested r16-528-gd7d24f9cc55d5cf0a70a984d4e63e8a307710d9e There are still 90 FAILs on x86_64 darwin all of this same form. /src-local/gcc-master/gcc/testsuite/cobol.dg/group1/declarative_1.cob:51:22: sorry, unimplemented: SECTION segment was ignored (that's an empty string - which shows as two spaces)
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 Radek Barton changed: What|Removed |Added CC||radek.barton at microsoft dot com --- Comment #20 from Radek Barton --- If you'd like to try experimental native compiler, we can refer you to https://github.com/Windows-on-ARM-Experiments/msys2-woarm64-build for the instructions how to add it to a MSYS2 shell. We would be happy for any feedback if you do. Is there any other form of native compiler you'd prefer instead of MSYS2 packages?
[Bug target/120228] Need to call df_insn_rescan after emit_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120228 --- Comment #1 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:9506c28a557bcea34af13478f05d2d9fc3727072 commit r16-535-g9506c28a557bcea34af13478f05d2d9fc3727072 Author: H.J. Lu Date: Mon May 12 10:02:24 2025 +0800 x86: Remove df_insn_rescan after emit_insn_* Since df_insn_rescan has been called by emit_insn_*, there is no need to call it after calling emit_insn_*. Remove its unnecessary usages. PR target/120228 * config/i386/i386-features.cc (ix86_place_single_vector_set): Remove df_insn_rescan after emit_insn_*. (remove_partial_avx_dependency): Likewise. (replace_vector_const): Likewise. Signed-off-by: H.J. Lu
[Bug c/120227] New: Incorrect debug info generation with options -gcodeview -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120227
Bug ID: 120227
Summary: Incorrect debug info generation with options
-gcodeview -g
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bc-info at styx dot cabel.net
Target Milestone: ---
$ cat test.c
// gcc -c -gcodeview -g test.c
void f(void) {}
$ gcc -c -gcodeview -g test.c
cciogM22.s: Assembler messages:
cciogM22.s:174: Error: can't resolve .debug$T - .Ltext0
cciogM22.s:246: Error: can't resolve .debug$T - .Ltext0
But -g -gcodeview work correct :)
[Bug gcov-profile/120229] New: [GCOV] AutoFDO cannot distinguish privatized functions of different LTO partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120229
Bug ID: 120229
Summary: [GCOV] AutoFDO cannot distinguish privatized functions
of different LTO partitions
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: dhruvc at nvidia dot com
Target Milestone: ---
The GCOV file format as used by the AutoFDO tools does not track source file
information for functions. This means that when resolving functions by
stripping
the suffixes from the profile information, the auto-profile pass ends up
using only the first instance of a function for all `function_instance's with
the same base name.
Example:
=== a.cpp
__attribute__((noinline)) static void effect_1() {}
void global() { effect_1(); }
===
=== b.cpp
__attribute__((noinline)) static void effect_1() {}
extern void global();
int main() {
/* ... for-loop ... */
global();
effect_1();
/* } */
}
===
This example will create `effect_1.lto_priv.0' and `effect_1.lto_priv.1' if
both functions are assigned to the same LTO partition. If the indices in the
string table are 1 and 2, auto-profile will track these as: 1 -> `effect_1',
2 -> `effect_1' after stripping the suffixes. When annotating these functions,
it will end up picking 1 -> `effect_1' for both of them, using the incorrect
profile information for the second function.
The solution for this problem is to track the source-file name in GCOV, by
pairing each function-name entry with the name of the source file it came from.
TODO: The downside to this solution is that different directories having source
files with the same name containing static functions with the same name,
assigned to the same LTO partition will exhibit the old, broken behaviour.
We are currently working on a prototype patch that fixes this bug.
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 --- Comment #4 from Christophe Jaillet --- The naming I've used is really bad. function_ok() is where the code looks *NOT* optimal and function_ko() where the generated code looks better...
[Bug target/120223] [16 Regression] ICE: in extract_insn, at recog.cc:2882 unrecognizable insn: (xor:DI (reg:DI 136) (const_int ...)) with -mcpu=thead-c906
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120223 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Keywords||needs-bisection
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 --- Comment #5 from Christophe Jaillet --- Created attachment 61406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61406&action=edit generated asm file The generated output. The first fuction has a shrq. A shift is expected here. The 2nd function doesn't have the sihft, which is the expected behavior. How ever, the first function uses cmpq which looks uneeded here, while the other one only cmpl.
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #18 from mcccs at gmx dot com --- > this problem is first present in the output of the pass > "x.c.100t.fixup_cfg3.c" Sorry, there are non-tree dumps as well. the first wrong dump is (of course) the "inline" ipa dump
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #21 from Christoph Reiter --- > Try removing the -g switch from the command line (leaving -gcodeview) - the combination of the -gcodeview -g switches (and in that order!) leads to such errors. Well, only those who know what SHOULD happen with such a combination of switches can "fix" it :). Removing "-g" does not change anything here. Note that this only occurs with 32bit builds, 64bit works fine. > And it seems to me that it is worth opening a separate ticket about this > situation (it appears on any source) and is not directly related to codeview > generation errors. OK, thanks
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #19 from Tobias Burnus --- Note that C23 added Trigonometric functions: acospi, asinpi, atan2pi, atanpi, cospi, sinpi, tanpi. That's supported, e.g., in Glibc 2.41. IMHO, the proper way is to add the proper __builtin_ to GCC and use it in Fortran with a fallback in libgfortran (like we have for C99) and an mpfr implentation both in gcc/simplify.cc for constant expressions and in fold*.cc for expressions that only become constant after value propagation. Note that mpfr 4.2.0 added functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi, mpfr_atanpi and mpfr_atan2pi. This implies that we should use it by default, only falling back to a replacement if mpfr is too old.
[Bug c++/120224] New: ICE in cp_parser_expression_statement with ambiguous std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224
Bug ID: 120224
Summary: ICE in cp_parser_expression_statement with ambiguous
std::void_t overload resolution since 14.1 until trunk
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
GCC triggers an internal compiler error when resolving a templated function
```
#include
template using Void_t = void;
template
void my_template(std::void_t* val);
template
void my_template(Void_t*){
}
int main() {
my_template(nullptr);
}
```
```
: In function 'int main()':
:9:29: internal compiler error: in cp_parser_expression_statement, at
cp/parser.cc:13601
9 | my_template(nullptr);
| ^
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22989b6 internal_error(char const*, ...)
???:0
0x7d443e fancy_abort(char const*, int, char const*)
???:0
0x981ebd c_parse_file()
???:0
0xa8b739 c_common_parse_file()
???:0
```
Happens since 14.1 until trunk
https://gcc.godbolt.org/z/zfcrEvKqq
[Bug c++/120224] [14/15/16 Regression] ICE in cp_parser_expression_statement with ambiguous std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224 Andrew Pinski changed: What|Removed |Added Summary|ICE in |[14/15/16 Regression] ICE |cp_parser_expression_statem |in |ent with ambiguous |cp_parser_expression_statem |std::void_t overload|ent with ambiguous |resolution since 14.1 until |std::void_t overload |trunk |resolution since 14.1 until ||trunk Known to fail||14.1.0 Known to work||12.4.0, 13.3.0 Target Milestone|--- |14.3
[Bug fortran/120225] New: [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for decimal trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225 Bug ID: 120225 Summary: [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for decimal trigonometric functions Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- New in mpfr 4.2.0: "New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu, mpfr_atanu and mpfr_atan2u." Use it if the u variants if mpfr is new enough and the fallback otherwise: "Set rop to the cosine (resp. sine and tangent) of op multiplied by 2 Pi and divided by u. For example, if u equals 360, one gets the cosine (resp. sine and tangent) for op in degrees"
[Bug c++/120224] [14/15/16 Regression] ICE in cp_parser_expression_statement with std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-05-11
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Note this is not invalid for being ambious. Just the declaration and definition
names the same template function but add an extra constraint on them.
It is invalid due to `++int{}` would be invalid.
[Bug c++/120224] [14/15/16 Regression] ICE in cp_parser_expression_statement with std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224 --- Comment #2 from Andrew Pinski --- /* If we ran into a problem, make sure we complained. */ gcc_assert (seen_error ());
[Bug c++/120224] [14/15/16 Regression] ICE in cp_parser_expression_statement with std::void_t overload resolution since 14.1 until trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120224 --- Comment #3 from Andrew Pinski --- I am 99% sure this was exposed by r14-6343-g0c018a74eb1aff .
[Bug tree-optimization/120222] New: FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120222 Bug ID: 120222 Summary: FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1 Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Created attachment 61402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61402&action=edit Tree dump spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc -B/home/dave/gnu/gcc/o bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c -fdiagnostics-plain-output -O2 -fno-tree-loop-distribute-patterns -ftree-vectori ze -fdump-tree-vect-details -fvect-cost-model=dynamic -lm -o ./gen-vect-28.exe PASS: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o bjdir64/hppa64-hp-hpux11.11/./libatomic/.libs::/home/dave/gnu/gcc/objdir64/gcc:/ home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/ gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/sr c/.libs Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/tree-ssa/gen-vect-28.c execution test gcc.dg/tree-ssa/gen-vect-28.c: pattern found 2 times FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1 PASS: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Vectorizing an unaligned access" 0 gcc.dg/tree-ssa/gen-vect-28.c: pattern found 2 times FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 Sam James changed: What|Removed |Added CC||jklowden at gcc dot gnu.org, ||rdubner at gcc dot gnu.org --- Comment #5 from Sam James --- Ping on this please. It makes it hard to see if there's actual COBOL regressions.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #7 from Robert Dubner --- Never mind. I am seeing the valgrind error, thank you very much. Let me see if I can get rid of it, and we'll move on from there.
[Bug tree-optimization/120222] [16 Regression] FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120222 Andrew Pinski changed: What|Removed |Added Summary|FAIL: |[16 Regression] FAIL: |gcc.dg/tree-ssa/gen-vect-28 |gcc.dg/tree-ssa/gen-vect-28 |.c scan-tree-dump-times |.c scan-tree-dump-times |vect "vectorized 1 loops" 1 |vect "vectorized 1 loops" 1 Target Milestone|--- |16.0 Keywords||testsuite-fail
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug tree-optimization/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-11 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- Either the preprocessed source or include all of the defines, GENMASK and FIELD_PREP_CONST. And include the 2 functions which can compile fully rather than just the current code fragments.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #8 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:d7d24f9cc55d5cf0a70a984d4e63e8a307710d9e commit r16-528-gd7d24f9cc55d5cf0a70a984d4e63e8a307710d9e Author: Robert Dubner Date: Sun May 11 13:43:32 2025 -0400 cobol: Eliminate padding bytes from cbl_declarative_t. [PR119377] By changing the type of a variable in the cbl_declarative_t structure from "bool" to "uint32_t", three uninitialized padding bytes were turned into initialized bytes. This eliminates the valgrind error caused by those uninitialized values. This is an interim fix, which expediently eliminates the valgrind problem. The underlying design flaw, which involves turning a host-side C++ structure into a run-time data block, is slated for complete replacement in the next few weeks. libgcobol/ChangeLog: PR cobol/119377 * common-defs.h: (struct cbl_declaratives_t): Change "bool global" to "uint32_t global".
[Bug target/120209] [SH] Float constant 1.0 is loaded from constant pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120209
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
Last reconfirmed||2025-05-11
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Oleg Endo ---
(In reply to Paul Cercueil from comment #0)
> With the following code compiled at -Os:
>
> float sh4_floorf(float x) {
> float x2 = (float)(int)x;
>
> if (x < -1.0f)
> x2 += -1.0f;
>
> return x2;
> }
>
> GCC generates:
>
> _sh4_floorf:
> mova.L6,r0
> fmov.s @r0+,fr1
> ftrcfr5,fpul
> fcmp/gt fr5,fr1
> bf/s.L5
> float fpul,fr0
> fldi1 fr1
> fsubfr1,fr0
> .L5:
> rts
> nop
> .L6:
> .long -1082130432
>
> Notice how the 1.0f constant is loaded from .L6 using mova + fmov.s, while
> it could be loaded using fldi1 directly.
The test case is somewhat bogus. Changing the "-1.0f" to "1.0f" will generate
the "fldi1" instruction for the comparison as well.
Based on our previous discussion, I guess you'd expect this case to generate
the sequence "fldi1; fneg" to load the constant -1.0, which would be better in
this case.
> The compiler also does not seem to understand that fr1 contains -1.0f which
> it can add to fr0 directly, and instead it will load 1.0f with fldi1 this
> time and substract it to fr0.
That's because there are two constants in your case "-1" and "1".
If the test case is changed to
if (x < -2.0f)
x2 *= -2.0f;
... then we will see that constants are shared in registers.
[Bug target/120218] New: [16 Regression] 8% slowdown of 507.cactuBSSN_r on Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120218 Bug ID: 120218 Summary: [16 Regression] 8% slowdown of 507.cactuBSSN_r on Intel Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=793.437.0 there was an 8% exec time slowdown of the 507.cactuBSSN_r SPEC 2017 benchmark between commits r16-117-g2056d52d74070f r16-310-g3584aab37f54bc when run with -Ofast -march=generic on an Intel Ice Lake (3rd generation Xeon) machine. This is a regression against GCC 15. See the comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1095.437.0&plot.1=1210.437.0&plot.2=793.437.0&; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #15 from mcccs at gmx dot com --- There's indeed a miscompilation and I've confirmed it's still present in the current trunk. With -fno-dce -fno-ipa-cp -fno-tree-dce the issue was visible until r12-248 which made the issue latent. So I added -fno-tree-dse and then it was made latent by r12-1848. So I added: sed -i -e 's/mark_dead_statements (m_oparms\[i\]/(void)3;\/\//g' ./gcc/gcc/ipa-param-manipulation.cc which replaced "mark_dead_statements(blahblah)" with a no-op but then it was made latent by r15-5336 so I replaced in ipa-fnsummary.cc if (!gimple_plf (stmt, STMT_NECESSARY)) with if (!gimple_plf (stmt, STMT_NECESSARY) && 0) and the issue can be reproduced. **Summary for reproducing the issue from trunk:** Download the minimized testcase from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282#c14 -O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-dse -fno-tree-dse sed -i -e 's/mark_dead_statements (m_oparms\[i\]/(void)3;\/\//g' ./gcc/gcc/ipa-param-manipulation.cc in ipa-fnsummary.cc, add && 0 after the condition of "!gimple_plf (stmt, STMT_NECESSARY)"
[Bug target/120218] [16 Regression] 8% slowdown of 507.cactuBSSN_r on Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120218 Filip Kastl changed: What|Removed |Added Target Milestone|--- |16.0
[Bug target/120209] [SH] Float constant -1.0 is loaded from constant pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120209 --- Comment #2 from Paul Cercueil --- > The test case is somewhat bogus. Changing the "-1.0f" to "1.0f" will > generate the "fldi1" instruction for the comparison as well. Yes, I got confused while writing the bug report. The problem is loading the -1.0f constant. > Based on our previous discussion, I guess you'd expect this case to generate > the sequence "fldi1; fneg" to load the constant -1.0, which would be better > in this case. > > > > The compiler also does not seem to understand that fr1 contains -1.0f which > > it can add to fr0 directly, and instead it will load 1.0f with fldi1 this > > time and substract it to fr0. > > That's because there are two constants in your case "-1" and "1". > > If the test case is changed to > > if (x < -2.0f) > x2 *= -2.0f; > > ... then we will see that constants are shared in registers. Well, but I'm doing if (x < -1.0f) x2 += -1.0f; So that's only one constant, -1.0.
[Bug tree-optimization/120219] New: [16 Regression] ~11% slowdown of 548.exchange2_r on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219 Bug ID: 120219 Summary: [16 Regression] ~11% slowdown of 548.exchange2_r on AMD Zen Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org CC: pinskia at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu As seen for example here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=298.407.0 there was a 11% exec time slowdown of the 548.exchange2_r SPEC 2017 benchmark when run with -O2 -march=generic -flto on an AMD Zen2 machine. I bisected it to r16-448-g8335fd561fa823. Author: Andrew Pinski Date: Sun May 4 19:24:09 2025 + Loop-IM: Hoist (non-expensive) stmts to executed all loop when running before PRE While fixing up how rewrite_to_defined_overflow works, gcc.dg/Wrestrict-22.c started to fail. This is because `d p+ 2` would moved by LIM and then be rewritten not using pointer plus. The rewriting part is correct behavior. It only recently started to be moved out; due to r16-190-g6901d56fea2132. Which has the following comment: ``` When we run before PRE and PRE is active hoist all expressions since PRE would do so anyway and we can preserve range info but PRE cannot. ``` This is not true if hoisting past the always executed point; so, instead of hoisting these statements all the way out of the max loops, take into account the always executed loop too. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * tree-ssa-loop-im.cc (compute_invariantness): Hoist to the always executed point if ignorning the cost. Signed-off-by: Andrew Pinski gcc/tree-ssa-loop-im.cc | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) This slowdown also happened on Zen3 and Zen4: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=470.407.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=957.407.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1103.407.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #19 from Christoph Reiter --- After doing some more testing, the 32bit build now fails with these patches: [1/301] Compiling C++ object operations/external/exr-save.dll.p/exr-save.cc.obj FAILED: operations/external/exr-save.dll.p/exr-save.cc.obj "ccache" "c++" "-Ioperations/external/exr-save.dll.p" "-Ioperations/external" "-I../operations/external" "-I." "-I.." "-Igegl" "-I../gegl" "-Igegl/buffer" "-I../gegl/buffer" "-Igegl/graph" "-I../gegl/graph" "-Igegl/module" "-I../gegl/module" "-Igegl/opencl" "-I../gegl/opencl" "-Igegl/operation" "-I../gegl/operation" "-Igegl/process" "-I../gegl/process" "-Igegl/property-types" "-I../gegl/property-types" "-IC:/msys64/mingw32/include/babl-0.1" "-IC:/msys64/mingw32/include/glib-2.0" "-IC:/msys64/mingw32/lib/glib-2.0/include" "-IC:/msys64/mingw32/include/gio-win32-2.0" "-IC:/msys64/mingw32/include/OpenEXR" "-IC:/msys64/mingw32/include/Imath" "-fdiagnostics-color=always" "-D_GLIBCXX_ASSERTIONS=1" "-Wall" "-Winvalid-pch" "-std=gnu++14" "-O2" "-g" "-DHAVE_CONFIG_H" "-DGEGL_ENABLE_DEBUG" "-Winit-self" "-Wmissing-declarations" "-Wpointer-arith" "-Wno-unused-parameter" "-Wno-cast-function-type" "-D_FILE_OFFSET_BITS=64" "-gcodeview" "-ftree-vectorize" "-pthread" "-DLIBDEFLATE_DLL" -MD -MQ operations/external/exr-save.dll.p/exr-save.cc.obj -MF "operations/external/exr-save.dll.p/exr-save.cc.obj.d" -o operations/external/exr-save.dll.p/exr-save.cc.obj "-c" ../operations/external/exr-save.cc C:\msys64\tmp\ccR9hXob.s: Assembler messages: C:\msys64\tmp\ccR9hXob.s:19098: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19100: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19102: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19104: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19106: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19108: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19110: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19112: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19114: Error: can't resolve .text - Lcvline612 ...
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 --- Comment #7 from Jonathan Wakely --- Try `e == 42` with your edit. Obviously that should work, but you've completely broken the comparison operator. That's not a fix.
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 --- Comment #6 from Jonathan Wakely --- No, __t is not an expected, you cannot access it with *__t
[Bug fortran/120220] New: Lack of testing for -fc-prototypes and -fc-prototypes-external
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120220 Bug ID: 120220 Summary: Lack of testing for -fc-prototypes and -fc-prototypes-external Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- There is currently no way of testing the output of -fc-prototypes and -fc-prototypes-external, which makes it much easier for regressions such as PR120107 and PR120139 to creep in. See also https://gcc.gnu.org/pipermail/fortran/2025-May/062134.html .
[Bug target/119919] 7% exchange2 regression between g:6390fc86995fbd5239497cb9e1797a3af51d3936 and g:f72a2d221539cede358f2487b94bc370c6fc44b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919 Filip Kastl changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120219 --- Comment #9 from Filip Kastl --- Reported the new slowdown as pr120219.
[Bug ipa/113197] [12/13/14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119 since r12-5177-g494bdadf28d0fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197 --- Comment #15 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0902cdb6069c12a027a1d0cfd1b7a0daa1a21b5c commit r14-11758-g0902cdb6069c12a027a1d0cfd1b7a0daa1a21b5c Author: Richard Biener Date: Mon Sep 30 09:07:36 2024 +0200 tree-optimization/113197 - bougs assert in PTA PTA asserts that EAF_NO_DIRECT_READ is not set when flags are set consistently which doesn't make sense. The following removes the assert. PR tree-optimization/113197 * tree-ssa-structalias.cc (handle_call_arg): Remove bougs assert. * gcc.dg/lto/pr113197_0.c: New testcase. * gcc.dg/lto/pr113197_1.c: Likewise. (cherry picked from commit 02f4efe3c12cf7ef54e5a71b11044c15be5c7fab)
[Bug ipa/113197] [12/13/14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119 since r12-5177-g494bdadf28d0fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197 --- Comment #16 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:aef1a618e200158e5f83331ae618492d1ef3573d commit r14-11759-gaef1a618e200158e5f83331ae618492d1ef3573d Author: Dimitar Dimitrov Date: Thu Oct 24 19:59:42 2024 +0300 testsuite: Require effective target pie for pr113197 The test for PR113197 explicitly enables PIE. But targets without PIE emit warnings when -fpie is passed (e.g. pru and avr), which causes the test to fail. Fix by adding an effective target requirement for PIE. With this patch, the test now is marked as unsupported for pru-unknown-elf. Testing for x86_64-pc-linux-gnu passes with current mainline, and fails if the fix from r15-4018-g02f4efe3c12cf7 is reverted. PR ipa/113197 gcc/testsuite/ChangeLog: * gcc.dg/lto/pr113197_0.c: Require effective target pie. Signed-off-by: Dimitar Dimitrov (cherry picked from commit bcd56224d74cdd8dc3c77097de51e97bc7b6d181)
[Bug target/119519] [14 Regression] RISC-V, autovectorization, internal compiler error when "V" RISC-V extension used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119519 Richard Biener changed: What|Removed |Added Known to work||14.2.1 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- This was now backported, thus fixed.
[Bug libstdc++/120198] [14/15/16 Regression] std::scoped_lock disabled for non-gthread environments (such as arm-none-eabi)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120198 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/120209] [SH] Float constant -1.0 is loaded from constant pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120209 --- Comment #3 from Oleg Endo --- (In reply to Paul Cercueil from comment #2) > > Well, but I'm doing > > if (x < -1.0f) > x2 += -1.0f; > > So that's only one constant, -1.0. Yes, that's what you wrote in the code. But the "+ -1" operation gets canonicalized to "- +1" and the constant is changed, which is a valid transformation. This results in two constants being used. This could be fixed with some SH specific RTL pass to look out for +1 and -1 fp constant uses. Not sure if there's a simpler way.
[Bug target/120200] [16 Regression] profiledbootstrap broken on x86_64-linux with -Wstringop-overflow in i386-expand.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120200 Richard Biener changed: What|Removed |Added Keywords||build, diagnostic Target||x86_64-*-* Target Milestone|--- |16.0
[Bug tree-optimization/120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206 --- Comment #2 from Richard Biener --- One reason is that this is one of the few users of rhs_to_tree, aka we go back to GENERIC and its folding.
[Bug tree-optimization/120211] [15/16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|16.0|15.2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Summary|[16 regression] ICE on |[15/16 regression] ICE on |valid code at -O3 with |valid code at -O3 with |"-fno-tree-copy-prop|"-fno-tree-copy-prop |-fno-tree-dominator-opts|-fno-tree-dominator-opts |-fno-tree-loop-ivcanon |-fno-tree-loop-ivcanon |-fno-tree-pre |-fno-tree-pre |-fno-code-hoisting" on |-fno-code-hoisting" on |x86_64-linux-gnu: in|x86_64-linux-gnu: in |gimple_phi_arg_def_from_edg |gimple_phi_arg_def_from_edg |e, at gimple.h:4759 |e, at gimple.h:4759 Version|unknown |16.0 Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- I've just backported that rev :/
[Bug tree-optimization/120210] [12/13/14/15 Regression] std::array like class gives an maybe-uninitialized warning on size() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120210 Richard Biener changed: What|Removed |Added Blocks||24639 Target Milestone|--- |12.5 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug target/120218] [16 Regression] 8% slowdown of 507.cactuBSSN_r on Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120218 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I'd guess one of the costing changes.
[Bug target/120215] [16 Regression] FAIL: gcc.target/i386/pr78794.c scan-assembler pandn by r16-517-g993aa0bd28722c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120215 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ||testsuite-fail Target Milestone|--- |16.0
[Bug tree-optimization/120219] [16 Regression] ~11% slowdown of 548.exchange2_r on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120219 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |16.0 --- Comment #1 from Richard Biener --- There was a similar jump before, so maybe we're just hitting that very thing again? Has that been filed/bisected?
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #20 from Iouri Kharon --- (In reply to Christoph Reiter from comment #19) > After doing some more testing, the 32bit build now fails with these patches: > > [1/301] Compiling C++ object > operations/external/exr-save.dll.p/exr-save.cc.obj > FAILED: operations/external/exr-save.dll.p/exr-save.cc.obj > "ccache" "c++" "-Ioperations/external/exr-save.dll.p" > "-Ioperations/external" "-I../operations/external" "-I." "-I.." "-Igegl" > "-I../gegl" "-Igegl/buffer" "-I../gegl/buffer" "-Igegl/graph" > "-I../gegl/graph" "-Igegl/module" "-I../gegl/module" "-Igegl/opencl" > "-I../gegl/opencl" "-Igegl/operation" "-I../gegl/operation" "-Igegl/process" > "-I../gegl/process" "-Igegl/property-types" "-I../gegl/property-types" > "-IC:/msys64/mingw32/include/babl-0.1" > "-IC:/msys64/mingw32/include/glib-2.0" > "-IC:/msys64/mingw32/lib/glib-2.0/include" > "-IC:/msys64/mingw32/include/gio-win32-2.0" > "-IC:/msys64/mingw32/include/OpenEXR" "-IC:/msys64/mingw32/include/Imath" > "-fdiagnostics-color=always" "-D_GLIBCXX_ASSERTIONS=1" "-Wall" > "-Winvalid-pch" "-std=gnu++14" "-O2" "-g" "-DHAVE_CONFIG_H" > "-DGEGL_ENABLE_DEBUG" "-Winit-self" "-Wmissing-declarations" > "-Wpointer-arith" "-Wno-unused-parameter" "-Wno-cast-function-type" > "-D_FILE_OFFSET_BITS=64" "-gcodeview" "-ftree-vectorize" "-pthread" > "-DLIBDEFLATE_DLL" -MD -MQ > operations/external/exr-save.dll.p/exr-save.cc.obj -MF > "operations/external/exr-save.dll.p/exr-save.cc.obj.d" -o > operations/external/exr-save.dll.p/exr-save.cc.obj "-c" > ../operations/external/exr-save.cc > C:\msys64\tmp\ccR9hXob.s: Assembler messages: > C:\msys64\tmp\ccR9hXob.s:19098: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19100: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19102: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19104: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19106: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19108: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19110: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19112: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19114: Error: can't resolve .text - Lcvline612 > ... Try removing the -g switch from the command line (leaving -gcodeview) - the combination of the -gcodeview -g switches (and in that order!) leads to such errors. Well, only those who know what SHOULD happen with such a combination of switches can "fix" it :). And it seems to me that it is worth opening a separate ticket about this situation (it appears on any source) and is not directly related to codeview generation errors.
[Bug middle-end/117498] [13/14 regression] Miscompile with -O3 since r13-1268-g8c99e307b20c502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117498 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||13.3.0, 14.2.0 Known to work||13.3.1, 14.2.1 --- Comment #11 from Richard Biener --- The fix was backported, I'll backport the testcase. Fixed.
[Bug middle-end/117498] [13/14 regression] Miscompile with -O3 since r13-1268-g8c99e307b20c502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117498 --- Comment #12 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:02e9aa56a469ea6c3021a4d3052cb229cdda4e04 commit r13-9648-g02e9aa56a469ea6c3021a4d3052cb229cdda4e04 Author: Jakub Jelinek Date: Fri Jan 31 12:39:34 2025 +0100 testsuite: Add testcase for already fixed PR [PR117498] This wrong-code issue has been fixed with r15-7249. We still emit warnings which are questionable and perhaps we'd get better generated code if niters determined the loop has only a single iteration without UB and we'd punt on vectorizing it (or unrolling). 2025-01-31 Jakub Jelinek PR middle-end/117498 * gcc.c-torture/execute/pr117498.c: New test. (cherry picked from commit 9fc0683082067801e3790f7cfffedbf5441e0f82)
[Bug middle-end/117498] [13/14 regression] Miscompile with -O3 since r13-1268-g8c99e307b20c502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117498 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Biener : https://gcc.gnu.org/g:cc589c2a4be9bf7242d7f17d44629fb87309a4a9 commit r14-11757-gcc589c2a4be9bf7242d7f17d44629fb87309a4a9 Author: Jakub Jelinek Date: Fri Jan 31 12:39:34 2025 +0100 testsuite: Add testcase for already fixed PR [PR117498] This wrong-code issue has been fixed with r15-7249. We still emit warnings which are questionable and perhaps we'd get better generated code if niters determined the loop has only a single iteration without UB and we'd punt on vectorizing it (or unrolling). 2025-01-31 Jakub Jelinek PR middle-end/117498 * gcc.c-torture/execute/pr117498.c: New test. (cherry picked from commit 9fc0683082067801e3790f7cfffedbf5441e0f82)
[Bug tree-optimization/116855] [14 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 --- Comment #13 from Richard Biener --- Too late for backporting to 14.3 IMO, also not sure how important it is - we did not have an actual case where this caused problems AFAIK. early-break vectorization is quite restricted on the 14 branch.
[Bug middle-end/117811] [12/13/14 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811 --- Comment #25 from Richard Biener --- This looks good to backport?
[Bug c++/118245] [14 Regression] ICE: in convert_nontype_argument, Passing a lambda as a template argument and base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118245 --- Comment #11 from Richard Biener --- (In reply to Nathaniel Shead from comment #10) > This is fixed for GCC 15. Unfortunately this patch isn't appropriate for > backporting as it will cause ABI changes without also backporting the fix > for PR107741 (r15-7147-g685c458fb4775c). > > Instead I'll probably end up reverting the changes to parser.cc in > r14-9232-g3685fae23bb008 since the modules testcases are less important, > unless I can find a way to fix it while keeping the existing ABI behaviour. Did you get to this?
[Bug c++/117501] [14 Regression] Consteval constructor does not initialize the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117501 --- Comment #9 from Richard Biener --- Safe enough to backport?
[Bug c++/118775] [12/13/14 Regression] ICE in tree_to_uhwi with unique_ptr and addresss of var converted to an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775 --- Comment #8 from Richard Biener --- (In reply to Marek Polacek from comment #6) > Fixed on trunk so far. I think I'll backport at least to 14. So?
[Bug c++/119303] [12/13/14 Regression] ICE: error reporting routines re-entered. in warning_at (diagnostic-global-context.cc:185)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119303 --- Comment #7 from Richard Biener --- Looks easy to backport?
[Bug c++/118590] [14 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #14 from Richard Biener --- Looks trivial enough to backport?
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #23 from Richard Biener --- This looks safe enough for backporting?
[Bug c++/115645] [12/13/14 Regression] new S[1][1]() requires non-explicit default ctor since r11-3092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115645 --- Comment #9 from Richard Biener --- This looks safe enough to backport?
[Bug c++/117887] [12/13/14 regression] ICE when building qtwebengine-6.8.1 (add_extra_args, at cp/pt.cc:13682) since r11-3261-gb28b621ac67bee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117887 --- Comment #17 from Richard Biener --- r15-3530-gdfb63765e994be is listed as dependent, but is it? Can this be backported?
[Bug tree-optimization/116855] [14 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 --- Comment #14 from Tamar Christina --- (In reply to Richard Biener from comment #13) > Too late for backporting to 14.3 IMO, also not sure how important it is - we > did not have an actual case where this caused problems AFAIK. early-break > vectorization is quite restricted on the 14 branch. Yeah I've been working on the backport, but it's a lot of changes to backport as it requires all the changes to vectorizable_load etc, and would require changes to the backend (for the cases where we make it safe by forcing partial masking). As you said GCC 14's early break was quite conservative. I could easily reject the case where the requested vector alignment is not the natural alignment of the type, which covers this misalignment. So I'm not sure what to do for a backport here.
[Bug c++/116379] [12/13/14 Regression] Type deduction error on decltype(auto) of parenthesized non-static data member since r12-5778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116379 --- Comment #5 from Richard Biener --- This looks safe enough to backport?
[Bug c++/117778] [14 Regression] ICE maybe_add_lambda_conv_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117778 --- Comment #6 from Richard Biener --- Safe enough to backport?
[Bug target/119919] 7% exchange2 regression between g:6390fc86995fbd5239497cb9e1797a3af51d3936 and g:f72a2d221539cede358f2487b94bc370c6fc44b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919 Filip Kastl changed: What|Removed |Added CC||pheeck at gcc dot gnu.org --- Comment #8 from Filip Kastl --- There is another slowdown -- new peak in the graphs. I'm currently bisecting it and will create a new PR once I'm done. Is it possible Honza's change was somehow reverted? I don't see a revert commit though.
[Bug tree-optimization/120211] [16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211
Yunbo Ni changed:
What|Removed |Added
CC||yunboni at smail dot nju.edu.cn
--- Comment #2 from Yunbo Ni ---
There is a similar case that crashes at -O2:
```c
int a, b, d;
void e() {
do {
int f = 0;
while (1) {
int c = a;
for (; (c & 1) == 0; c = 1)
for (; c & 1;)
;
if (a)
break;
f++;
}
b = f & 5;
if (b)
break;
} while (d++);
}
void main() {}
```
Bisected to
https://github.com/gcc-mirror/gcc/commit/9def392a1b63a198d15d972f73b4afc888389d7c
[Bug ipa/120146] [15 Regression] ICE: SIGSEGV in all_refs_explicit_p (cgraph.h:3201) with -O -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120146 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:47e830211d39b5efb14144bbdaf8f2d83ba8375e commit r15-9654-g47e830211d39b5efb14144bbdaf8f2d83ba8375e Author: Richard Biener Date: Wed May 7 10:20:55 2025 +0200 ipa/120146 - deal with vanished varpool nodes in IPA PTA I don't understand why they vanish when still refered to, but lets deal with that in a conservative way. PR ipa/120146 * tree-ssa-structalias.cc (create_variable_info_for): If the symtab cannot tell us whether all refs to a variable are explicit assume they are not. * g++.dg/ipa/pr120146.C: New testcase. (cherry picked from commit b38e3a7196d25bc8bcb1fe55da7663745cea9470)
[Bug tree-optimization/120143] [15 Regression] ICE with -fwhole-program on undefined extern var in verify_ssa since r15-7886-g2427793af1e545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120143 --- Comment #8 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:94d10c0ef2dca46f1c043c81bcda67ee7e2efc67 commit r15-9653-g94d10c0ef2dca46f1c043c81bcda67ee7e2efc67 Author: Richard Biener Date: Wed May 7 09:43:54 2025 +0200 tree-optimization/120143 - ICE with failed early break store move The early break vectorization store moving was incorrectly trying to move the pattern stmt instead of the original one which failed to register and then confused virtual SSA form due to the update triggered by a degenerate virtual PHI. PR tree-optimization/120143 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Move/update the original stmts, not the pattern stmts which lack virtual operands and are not in the IL. * gcc.dg/vect/vect-early-break_135-pr120143.c: New testcase. (cherry picked from commit da377e7ebf84a05943fb768eaeb7d682dee865fa)
[Bug tree-optimization/120143] [15 Regression] ICE with -fwhole-program on undefined extern var in verify_ssa since r15-7886-g2427793af1e545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120143 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||15.1.1 --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/120043] [15 Regression] wrong code at -O{s,2,3} with -fallow-store-data-races on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120043 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||15.1.1 --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/120089] [15 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120089 --- Comment #28 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:4017b37de2b39f4bbd7bb9524101558002a258e8 commit r15-9652-g4017b37de2b39f4bbd7bb9524101558002a258e8 Author: Richard Biener Date: Mon May 5 14:29:34 2025 +0200 tree-optimization/120089 - force all PHIs live for early-break vect The following makes sure to even mark unsupported PHIs live when doing early-break vectorization since otherwise we fail to validate we can vectorize those and generate wrong code based on the scalar PHIs which would only work with a vectorization factor of one. PR tree-optimization/120089 * tree-vect-stmts.cc (vect_stmt_relevant_p): Mark all PHIs live when not already so and doing early-break vectorization. (vect_mark_stmts_to_be_vectorized): Skip virtual PHIs. * tree-vect-slp.cc (vect_analyze_slp): Robustify handling of early-break forced IVs. * gcc.dg/vect/vect-early-break_134-pr120089.c: New testcase. (cherry picked from commit 9def392a1b63a198d15d972f73b4afc888389d7c)
[Bug tree-optimization/120043] [15 Regression] wrong code at -O{s,2,3} with -fallow-store-data-races on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120043 --- Comment #6 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:856c493db1d5e2fa9377f4a0c438afbcaf6c7e01 commit r15-9651-g856c493db1d5e2fa9377f4a0c438afbcaf6c7e01 Author: Richard Biener Date: Thu May 8 10:05:42 2025 +0200 tree-optimization/120043 - bogus conditional store elimination The following fixes conditional store elimination to properly check for conditional stores to readonly memory which we can obviously not store to unconditionally. The tree_could_trap_p predicate used is only considering rvalues and the chosen approach mimics that of loop store motion. PR tree-optimization/120043 * tree-ssa-phiopt.cc (cond_store_replacement): Check whether the store is to readonly memory. * gcc.dg/torture/pr120043.c: New testcase. (cherry picked from commit 93586e5d51188bf71f4f8fae4ee94ff631740f24)
[Bug ipa/120146] [15 Regression] ICE: SIGSEGV in all_refs_explicit_p (cgraph.h:3201) with -O -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120146 Richard Biener changed: What|Removed |Added Known to work||15.1.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/120089] [15 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120089 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||15.1.1 Resolution|--- |FIXED --- Comment #29 from Richard Biener --- Fixed.
[Bug fortran/120107] [15/16 regression] -fc-prototypes for ISO_FORTRAN_ENV generates duplicate typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Thomas Koenig --- Hm, I think they should not be dumped at all...
[Bug fortran/120139] [15/16 Regression] -fc-prototypes emits incorrect type for arrays with variable extents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Target Milestone|--- |15.2 Ever confirmed|0 |1 Summary|-fc-prototypes emits|[15/16 Regression] |incorrect type for arrays |-fc-prototypes emits |with variable extents |incorrect type for arrays ||with variable extents Last reconfirmed||2025-05-11 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/120211] [15/16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/120211] [15/16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:833db92d69cf371af3ade32e2a2b154c22e7ef15 commit r16-526-g833db92d69cf371af3ade32e2a2b154c22e7ef15 Author: Richard Biener Date: Sun May 11 14:03:12 2025 +0200 tree-optimization/120211 - constrain LOOP_VINFO_EARLY_BREAKS_LIVE_IVS more The PR120089 fix added more PHIs to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS but not checking that we only add PHIs with a latch argument. The following adds this missing check. PR tree-optimization/120211 * tree-vect-stmts.cc (vect_stmt_relevant_p): Only add PHIs from the loop header to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS. * gcc.dg/vect/vect-early-break_135-pr120211.c: New testcase. * gcc.dg/torture/pr120211-1.c: Likewise.
[Bug tree-optimization/120211] [15/16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:44cd55a1df897e3160cffeb10f96171bafc06400 commit r15-9655-g44cd55a1df897e3160cffeb10f96171bafc06400 Author: Richard Biener Date: Sun May 11 14:03:12 2025 +0200 tree-optimization/120211 - constrain LOOP_VINFO_EARLY_BREAKS_LIVE_IVS more The PR120089 fix added more PHIs to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS but not checking that we only add PHIs with a latch argument. The following adds this missing check. PR tree-optimization/120211 * tree-vect-stmts.cc (vect_stmt_relevant_p): Only add PHIs from the loop header to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS. * gcc.dg/vect/vect-early-break_135-pr120211.c: New testcase. * gcc.dg/torture/pr120211-1.c: Likewise.
[Bug c/120221] New: Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221
Bug ID: 120221
Summary: Missed optimization related to switch handling
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.jaillet at wanadoo dot fr
Target Milestone: ---
Hi,
while looking at generate code around the GENMASK, FIELD_PREP and co macro in
Linux, I compared the generated code from cht_wc_extcon_get_id() in
drivers/extcon/extcon-intel-cht-wc.c
I use default linux flags, so this should be compiled at -O2.
The code looks like:
#define CHT_WC_PWRSRC_USBID_MASKGENMASK(4, 3)
#define CHT_WC_PWRSRC_USBID_SHIFT 3
#define CHT_WC_PWRSRC_RID_ACA 0
#define CHT_WC_PWRSRC_RID_GND 1
#define CHT_WC_PWRSRC_RID_FLOAT 2
static int cht_wc_extcon_get_id(struct cht_wc_extcon_data *ext, int pwrsrc_sts)
{
switch ((pwrsrc_sts & CHT_WC_PWRSRC_USBID_MASK) >>
CHT_WC_PWRSRC_USBID_SHIFT) {
case CHT_WC_PWRSRC_RID_GND:
return INTEL_USB_ID_GND;
case CHT_WC_PWRSRC_RID_FLOAT:
return INTEL_USB_ID_FLOAT;
case CHT_WC_PWRSRC_RID_ACA:
return INTEL_USB_RID_A;
default:
return INTEL_USB_ID_FLOAT;
}
}
The generated code, on x86_64 looks like:
testl %eax, %eax
jne .L142
movslq 8(%rsp), %rax
shrq$3, %rax
andl$3, %eax
je .L106
cmpq$1, %rax
jne .L107
In order to get rid of the >>, I tried to make a better use of FIELD_PREP_CONST
and I changed the code into:
#define CHT_WC_PWRSRC_USBID_MASKGENMASK(4, 3)
#define CHT_WC_PWRSRC_RID_ACA
FIELD_PREP_CONST(CHT_WC_PWRSRC_USBID_MASK, 0)
#define CHT_WC_PWRSRC_RID_GND
FIELD_PREP_CONST(CHT_WC_PWRSRC_USBID_MASK, 1)
#define CHT_WC_PWRSRC_RID_FLOAT
FIELD_PREP_CONST(CHT_WC_PWRSRC_USBID_MASK, 2)
static int cht_wc_extcon_get_id(struct cht_wc_extcon_data *ext, int pwrsrc_sts)
{
switch (pwrsrc_sts & CHT_WC_PWRSRC_USBID_MASK) {
case CHT_WC_PWRSRC_RID_GND:
return INTEL_USB_ID_GND;
case CHT_WC_PWRSRC_RID_FLOAT:
return INTEL_USB_ID_FLOAT;
case CHT_WC_PWRSRC_RID_ACA:
return INTEL_USB_RID_A;
default:
return INTEL_USB_ID_FLOAT;
}
}
The generated code now looks like:
testl %eax, %eax
jne .L142
movl8(%rsp), %eax
andl$24, %eax
je .L106
cmpl$8, %eax
jne .L107
The shrq is correctly removed, and we compare against 8 in place of 1 which
looks correct.
However, I wonder why the initial version used movslq and cmpq, while the other
version only andl and cmpl.
Using the 'q' version looks useless to me and not-optimal.
Should gcc manage by itself to see that 'q' version are not needed in both
cases?
[Bug c/120221] Missed optimization related to switch handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221 --- Comment #1 from Sam James --- Can you give a preprocessed testcase please?
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #16 from mcccs at gmx dot com --- Created attachment 61401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61401&action=edit innocent gimple code failing with trunk with -O3 -fno-dce -fno-tree-dce -fno-dse -fno-tree-dse or with -O0 no patches needed, this well-formed gimple file fails with trunk "-O3 -fno-dce -fno-tree-dce -fno-dse -fno-tree-dse" or "-O0"
[Bug ipa/120098] [16 regression] g++.dg/lto/devirt-23 FAILs since r16-372-g064cac730f88dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120098 John David Anglin changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-11 CC||danglin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from John David Anglin --- Also see this on hppa64-hp-hpux11.11.
[Bug tree-optimization/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 Kael Franco changed: What|Removed |Added Attachment #61399|0 |1 is obsolete|| --- Comment #6 from Kael Franco --- Created attachment 61403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61403&action=edit Reduce C code again
[Bug ipa/110282] [12/13/14/15 regression] Segmentation fault with specific optimizations since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282
--- Comment #17 from mcccs at gmx dot com ---
Actually my test file in comment 16 is invalid. This means the failure happens
before the optimized pass and it needs the DCE-disabled GCC I described in
comment 15 to reproduce the faulty optimized dump (which is then propagated in
later passes in any GCC).
The problem is that the parameter pointer is not set to the argument so
dereferencing it causes a segfault. Dumping all the passes, this problem is
first present in the output of the pass "x.c.100t.fixup_cfg3.c" as compiled
with the modified GCC with -O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-dse
-fno-tree-dse
The previous dump, "x.058t.local-fnsummary2", is sane and looks like this:
int * __GIMPLE (ssa,guessed_local(1073741824))
n (int * o)
{
...
_3 = __MEM (o_17(D));
...
main ()
{
__BB(2):
n (&a);
whereas x.c.100t.fixup_cfg3.c looks like this:
int __GIMPLE (ssa)
main ()
{
int * o;
...(no assignment to o)...
_6 = __MEM (o_5(D));
__attribute__((noclone)) to the function fixes the segmentation fault,
__attribute__((noinline)) doesn't.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #6 from Robert Dubner --- Declarative and Exception processing have been changed significantly in recent days. Is the declarative_1 problem still showing up?
[Bug middle-end/120230] cmov_optab is not used for expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120230 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine.
