[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out with trailing return type based on decltype of argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116317 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #10 from Nathaniel Shead --- Should be fixed for GCC 15.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 116317, which changed state. Bug 116317 Summary: [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out with trailing return type based on decltype of argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116317 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out with trailing return type based on decltype of argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116317 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |15.0
[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out with trailing return type based on decltype of argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116317 --- Comment #9 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:4a99443c5dd9a235022652ba0fb143c6370ea99d commit r15-4861-g4a99443c5dd9a235022652ba0fb143c6370ea99d Author: Nathaniel Shead Date: Thu Oct 31 20:54:29 2024 +1100 c++/modules: Fix recursive dependencies [PR116317] In cases like the linked PR we sometimes get mutually recursive dependencies that both rely on the other to have been streamed as part of their merge key information. In the linked PR, this causes an ICE. The root cause is that 'sort_cluster' is not correctly ordering the dependencies; both the element_t specialisation and the reverse_adaptor::first function decl depend on each other, but by streaming element_t first it ends up trying to stream itself recursively as part of calculating its own merge key, which apart from the checking ICE will also cause issues on stream-in, as the merge key will not properly stream. There is a comment already in 'sort_cluster' describing this issue, but it says: Finding the single cluster entry dep is very tricky and expensive. Let's just not do that. It's harmless in this case anyway. However in this case it was not harmless: it's just somewhat luck that the sorting happened to work for the existing cases in the testsuite. This patch solves the issue by noting any declarations that rely on deps first seen within their own merge key. This declaration gets marked as an "entry" dep; any of these deps that end up recursively referring back to that entry dep as part of their own merge key do not. Then within sort_cluster we can ensure that the entry dep is written to be streamed first of its cluster; this will ensure that any other deps are just emitted as back-references, and the mergeable dep itself will structurally decompose. PR c++/116317 gcc/cp/ChangeLog: * module.cc (depset::DB_MAYBE_RECURSIVE_BIT): New flag. (depset::DB_ENTRY_BIT): New flag. (depset::is_maybe_recursive): New accessor. (depset::is_entry): New accessor. (depset::hash::writing_merge_key): New field. (trees_out::decl_value): Inform dep_hash while we're writing the merge key information for a decl. (depset::hash::add_dependency): Find recursive deps and mark the entry point. (sort_cluster): Ensure that the entry dep is streamed first. gcc/testsuite/ChangeLog: * g++.dg/modules/late-ret-4_a.H: New test. * g++.dg/modules/late-ret-4_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/113814] [modules] canonical types ICE with imported partial specialization matching existing template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113814 --- Comment #4 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:815e48e3d42231b675bae1dec5fa26890f048ef1 commit r15-4862-g815e48e3d42231b675bae1dec5fa26890f048ef1 Author: Nathaniel Shead Date: Thu Oct 31 20:05:16 2024 +1100 c++/modules: Propagate TYPE_CANONICAL for partial specialisations [PR113814] In some cases, when we go to import a partial specialisation there might already be an incomplete implicit instantiation in the specialisation table. This causes ICEs described in the linked PR as we now have two separate matching specialisations for this same arguments with different TYPE_CANONICAL. We already support multiple specialisations with the same args however, as they may be differently constrained. So we can solve this by simply ensuring that the TYPE_CANONICAL of the new partial specialisation matches the existing specialisation. PR c++/113814 gcc/cp/ChangeLog: * pt.cc (add_mergeable_specialization): Propagate TYPE_CANONICAL. gcc/testsuite/ChangeLog: * g++.dg/modules/partial-6.h: New test. * g++.dg/modules/partial-6_a.H: New test. * g++.dg/modules/partial-6_b.H: New test. * g++.dg/modules/partial-6_c.C: New test. Signed-off-by: Nathaniel Shead Co-authored-by: Jason Merrill
[Bug c++/117231] [15 regression] Incorrect code generation for std::generator since r15-3840-g650e9156656187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231 Sam James changed: What|Removed |Added Last reconfirmed||2024-11-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[15 regression] Incorrect |[15 regression] Incorrect |code generation for |code generation for |std::generator |std::generator since ||r15-3840-g650e9156656187
[Bug rtl-optimization/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117095 Sam James changed: What|Removed |Added Last reconfirmed||2024-11-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/56513] Wrong code generation with -O3 on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #7 from Sam James --- I'm not sure what to suggest for this if it's an ancient wrong-code bug which seems to have been legitimate but was latent as of 2013. Could easily have been fixed properly since. Needs proper analysis before that commit, I guess.
[Bug rtl-optimization/99221] copyprop_hardreg_forward_1 deletes insn by mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99221 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #2 from Sam James --- r11-7775-ga28cc94a27529b
[Bug middle-end/106408] PRE with infinite loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106408 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-02
[Bug tree-optimization/117398] [12/13/14/15 Regression] ICE: in invert, at value-range.cc:2165 at -O3 with "-fno-thread-jumps"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117398 Sam James changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #2 from Sam James --- * With just -O1, 11 works and >=12 fails, bisected to r12-2591-g2e96b5f14e4025. * With -O2 -fno-thread-jumps, 12 works and >=13 fails. Needs bisection I guess.
[Bug target/116799] [14/15 Regression] Miscompiled code (vim testsuite fails) on s390x at -O2 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 Sam James changed: What|Removed |Added Summary|[14/15 Regression] |[14/15 Regression] |Miscompiled code on s390x |Miscompiled code (vim |at -O2 since|testsuite fails) on s390x |r14-2675-gef28aadad6e |at -O2 since ||r14-2675-gef28aadad6e Ever confirmed|0 |1 Last reconfirmed||2024-11-02 Status|UNCONFIRMED |NEW
[Bug middle-end/92419] const variable aliases lead to folding non-const initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92419 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-11-02 CC||sjames at gcc dot gnu.org
[Bug tree-optimization/117417] New: ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117417 Bug ID: 117417 Summary: ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 59520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59520&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Ofast testcase.c testcase.c: In function 'foo': testcase.c:17:1: error: non-top-level 'bit_field_ref' 17 | foo () | ^~~ # VUSE <.MEM_11> _4 = REALPART_EXPR >; during GIMPLE pass: forwprop testcase.c:17:1: internal compiler error: verify_gimple failed 0x2c9c5fe internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:518 0x1620e5d verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5682 0x1486ed4 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2102 0x148744e execute_todo /repo/gcc-trunk/gcc/passes.cc:2156 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20241102 (experimental) (GCC)
[Bug target/117418] New: ICE: in plus_constant, at explow.cc:102 with -mx32 -maddress-mode=long and __builtin_ia32_encodekey256_u32()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117418 Bug ID: 117418 Summary: ICE: in plus_constant, at explow.cc:102 with -mx32 -maddress-mode=long and __builtin_ia32_encodekey256_u32() Product: gcc Version: 15.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: x86_64-pc-linux-gnux32 Created attachment 59521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59521&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -maddress-mode=long -mwidekl -mx32 testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:7:3: internal compiler error: in plus_constant, at explow.cc:102 7 | __builtin_ia32_encodekey256_u32(0, a, a, &a); | ^~~~ 0x2c9c5fe internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:518 0xe8453b fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:1696 0x78eec7 plus_constant(machine_mode, rtx_def*, poly_int<1u, long>, bool) /repo/gcc-trunk/gcc/explow.cc:102 0x1b04f81 ix86_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:14171 0x1177039 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:12402 0x1035e37 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.h:323 0x1035e37 expand_call_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:2897 0x1035e37 expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.cc:3964 0x1035e37 expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:4106 0x103c25e expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.cc:6162 0x103df47 execute /repo/gcc-trunk/gcc/cfgexpand.cc:6901 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20241102 (experimental) (GCC)
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 uecker at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from uecker at gcc dot gnu.org --- Fixed on trunk (I filed a new bug PR117419 for the test failures)
[Bug testsuite/117419] test failures for enum-alias-{1,2,30 on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419 uecker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot gnu.org Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115157 Last reconfirmed||2024-11-02 Status|UNCONFIRMED |NEW --- Comment #1 from uecker at gcc dot gnu.org --- .
[Bug c/117391] wrong composite for unspecified sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117391 --- Comment #2 from uecker at gcc dot gnu.org --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667285.html
[Bug gcov-profile/117415] Bogus execution count for assignment to *func()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117415 --- Comment #3 from Jørgen Kvalsvik --- >From a quick look it seems like the problem is fundamentally the difference in how gcc counts executions (on the basic block) and how that is mapped to lines. I don't know if there a complete fix if the expectation is lines [1], other than maybe applying some heuristics to not count multiple basic blocks in a straight line that map to the same line. [1] For example, you can remove all newlines from the source and it would most likely still be a valid C program. How would you count "lines executed"?
[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108080 --- Comment #12 from Nathaniel Shead --- This was fixed for GCC 14. The remaining issues with Aarch64 SVE are tracked by PR108080.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 111224, which changed state. Bug 111224 Summary: modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug debug/15736] [4.0 Regression] internal compiler error: in force_decl_die, at dwarf2out.c:12441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15736 --- Comment #10 from Andrew Pinski --- (In reply to Carlo Wood from comment #9) > Just curious... what caused the 20 years of delay? Sam has been auditing the testsuite to find issues like a missnamed testcase (like in this case). So the testcase was not running before but is now since he renamed it. He put the PR # in the changelog so it got into bugzilla to record a related change.
[Bug tree-optimization/102705] [12/13/14/15 Regression] Dead Code Elimination Regression at -O3 since r12-2637-g145bc41dae7c7bfa093d61e77346f98e6a595a0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #8 from Andrew Pinski ---
Actually we should be able to convert:
# RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
_2 = 1 >> b.1_1;
Into:
`b.1_1 == 0`
as b.1_1 since the only value that gives out 1 that is defined is 0.
That might solve it too.
Since if we had that, then:
_t = b.1_1 == 0;
_2 = (int)_t;
iftmp.0_9 = (char) _2;
_3 = (unsigned int) _2;
b = _3;
_4 = iftmp.0_9 ^ 1;
_22 = (short int) _4;
_5 = (short int) _2;
if (_5 == _22)
and then:
_t1 = b.1_1 != 0;
_4 = (char) _t1;
_22 = (short int)_t1;
_2 = (short int)_t;
And then _t1 == _t1 which gives false.
So maybe:
/* `1 >> x` can be "simplified" into `(convert)x == 0`. */
(simplify
(rshift integer_onep @2)
(if (INTEGRAL_TYPE_P (type))
(convert (eq:boolean_type_node @2 { build_zero_cst (type); }
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #417 from John Paul Adrian Glaubitz --- I haven't been able to find any regressions. Thus, my suggestion would be to clean the patches up now and get them merged if that's okay. This would expose the patches to a larger audience and help them get tested more thoroughly. Also, Jeff Law could pick them up for his GCC weekly(?) tests.
[Bug fortran/117381] -fmax-identifier-length= is completely ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381 Jerry DeLisle changed: What|Removed |Added Severity|normal |enhancement Status|WAITING |NEW --- Comment #19 from Jerry DeLisle --- I am reminded of when the first IBM PC was expandable to 640K of memory and comments at the time, who would ever need that much memory. Therefore, I recommend that we leave the default limit per standards and allow users to set -fmax-identifier-length= up to 127. Give a warning if 63 is exceeded regardless of -std= and an error with -pedantic. Error regardless if <6 or greater than 127. Cleanup our documentation as noted in others comments. We should also make it clear this is not a defect in gfortran but it is a request for a reasonable enhancement. My time is limited so if anyone else would like to take this on, please do. If I can get to it, I will. Steve has shown most, if not all, of the needed patch.
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 --- Comment #9 from Sam James --- Thanks!
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #7 from Sam James --- Thanks!
[Bug c/117391] wrong composite for unspecified sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117391 Sam James changed: What|Removed |Added Status|NEW |ASSIGNED CC||sjames at gcc dot gnu.org Keywords||patch
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 Sam James changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-11-02 Target Milestone|--- |15.0 --- Comment #7 from Sam James --- ping (going over wrong-code UNCO bugs), looks like the test patch didn't land yet? (also just tidying up assignee given the original thing was fixed)
[Bug target/111593] wrong code for 128-bit multiplication on MIPS64R6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111593 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-11-02 Status|UNCONFIRMED |ASSIGNED
[Bug target/113243] mips: Wrong code for pr91323.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113243 Sam James changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-11-02
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug testsuite/117419] New: test failures for enum-alias-{1,2,30 on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419
Bug ID: 117419
Summary: test failures for enum-alias-{1,2,30 on arm-eabi
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: uecker at gcc dot gnu.org
Target Milestone: ---
Test case failure from PR115157.
New tests that FAIL (6 tests):
arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-1.c (test for excess errors)
arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-2.c execution test
arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-3.c execution test
[Bug tree-optimization/117414] missing predicated VN due to combining if statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117414 --- Comment #2 from Andrew Pinski --- https://inbox.sourceware.org/gcc-patches/20241102150921.3319089-1-quic_apin...@quicinc.com/T/#t Though I wonder if some of this could be done using the ranger, maybe for another time.
[Bug tree-optimization/117420] New: wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117420
Bug ID: 117420
Summary: wrong code at -O1 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/7nKzWzohb
[674] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241102 (experimental) (GCC)
[675] %
[675] % gcctk -O1 small.c
[676] % ./a.out
Aborted
[677] % cat small.c
int a, b;
int main() {
b = -(1 | -(a < 1));
a = (~b & 2) / 2;
if (b != 1)
__builtin_abort();
return 0;
}
[Bug middle-end/55369] expmed.c is miscompiled in stage1 bootstrap at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55369 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from John David Anglin --- Fixed. Don't know when.
[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1fb467dbcc2cdd3bb89fa860a1f86b7e334e0ce3 commit r15-4863-g1fb467dbcc2cdd3bb89fa860a1f86b7e334e0ce3 Author: Jakub Jelinek Date: Sat Nov 2 18:47:27 2024 +0100 gimplify: Fix up RAW_DATA_CST related ICE [PR117384] Apparently tree_output_constant_def doesn't strictly guarantee that the returned VAR_DECL will have the same or uselessly convertible type as the type of the constant passed to it, compare_constants says: /* For arrays, check that mode, size and storage order match. */ /* For record and union constructors, require exact type equality. */ The older use of tree_output_constant_def in gimplify.cc was already handling this right: ctor = tree_output_constant_def (ctor); if (!useless_type_conversion_p (type, TREE_TYPE (ctor))) ctor = build1 (VIEW_CONVERT_EXPR, type, ctor); but the spot I've added for RAW_DATA_CST missed this. So, the following patch adds that. 2024-11-02 Jakub Jelinek PR middle-end/117384 * gimplify.cc (gimplify_init_ctor_eval): Add VIEW_CONVERT_EXPR around rctor if it doesn't have expected type. * c-c++-common/init-7.c: New test.
[Bug libstdc++/117406] std::ilogb should return INT_MAX when argument is infinite also for 16-bit floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug libstdc++/117406] std::ilogb should return INT_MAX when argument is infinite also for 16-bit floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:36a9e2b22596711455e702ea5a5a3f26e145321c
commit r15-4864-g36a9e2b22596711455e702ea5a5a3f26e145321c
Author: Jakub Jelinek
Date: Sat Nov 2 18:48:54 2024 +0100
libstdc++: Fix up std::{,b}float16_t std::{ilogb,l{,l}r{ound,int}}
[PR117406]
These overloads incorrectly cast the result of the float __builtin_*
to _Float or __gnu_cxx::__bfloat16_t. For std::ilogb that changes
behavior for the INT_MAX return because that isn't representable in
either of the floating point formats, for the others it is I think
just a very inefficient hop from int/long/long long to std::{,b}float16_t
and back. I mean for the round/rint cases, either the argument is small
and then the return value should be representable in the floating point
format too, or it is too large that the argument is already integral
and then it should just return the argument with the round trips.
Too large value is unspecified unlike ilogb.
2024-11-02 Jakub Jelinek
PR libstdc++/117406
* include/c_global/cmath (std::ilogb(_Float16),
std::llrint(_Float16),
std::llround(_Float16), std::lrint(_Float16),
std::lround(_Float16)):
Don't cast __builtin_* return to _Float16.
(std::ilogb(__gnu_cxx::__bfloat16_t),
std::llrint(__gnu_cxx::__bfloat16_t),
std::llround(__gnu_cxx::__bfloat16_t),
std::lrint(__gnu_cxx::__bfloat16_t),
std::lround(__gnu_cxx::__bfloat16_t)): Don't cast __builtin_*
return to
__gnu_cxx::__bfloat16_t.
* testsuite/26_numerics/headers/cmath/117406.cc: New test.
[Bug target/117416] New: [15 Regression] ICE: in gen_prefetch, at config/i386/i386.md:28541 with __builtin_ia32_prefetch()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117416
Bug ID: 117416
Summary: [15 Regression] ICE: in gen_prefetch, at
config/i386/i386.md:28541 with
__builtin_ia32_prefetch()
Product: gcc
Version: 15.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: x86_64-pc-linux-gnu
Compiler output:
$ cat testcase.c
void foo() { __builtin_ia32_prefetch(0, 5, 0, 0); }
$ x86_64-pc-linux-gnu-gcc testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:1:14: internal compiler error: in gen_prefetch, at
config/i386/i386.md:28541
1 | void foo() { __builtin_ia32_prefetch(0, 5, 0, 0); }
| ^~~
0x2c9c5fe internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0xe8453b fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1696
0x9da865 gen_prefetch(rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/i386/i386.md:28541
0x1b068b0 ix86_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:14233
0x1177039 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:12402
0x1035e37 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/repo/gcc-trunk/gcc/expr.h:323
0x1035e37 expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:2897
0x1035e37 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3964
0x1035e37 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4106
0x103c25e expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6162
0x103df47 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6901
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r15-4860-20241101203111-g6a2e8913df6-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241102 (experimental) (GCC)
[Bug c++/117422] New: Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422
Bug ID: 117422
Summary: Error: template parameter was not declared in this
scope
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/rz5eGzqf6
```
template
void f();
struct S {
template
friend void f() {
T x;
}
};
int main() {
f();
}
```
: In function 'void f()':
:7:17: error: 'T' was not declared in this scope [-Wtemplate-body]
7 | T x;
| ^
Compiler returned: 1
[Bug middle-end/117423] union not written to with particular layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 --- Comment #1 from Andrew Pinski --- Created attachment 59525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59525&action=edit Cleanuped testcase
[Bug tree-optimization/117423] [12/13/14/15 Regression] union not written to with particular layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 --- Comment #3 from Andrew Pinski --- Obvbious workaround `-fno-tree-sra` .
[Bug tree-optimization/117423] [12/13/14/15 Regression] union not written to with particular layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Ever confirmed|0 |1 Target Milestone|--- |12.5 Status|UNCONFIRMED |NEW Summary|union not written to with |[12/13/14/15 Regression] |particular layout |union not written to with ||particular layout Last reconfirmed||2024-11-03 Component|middle-end |tree-optimization --- Comment #2 from Andrew Pinski --- Confirmed. Before esra: rv.DATA.var_0._1 = 2; var7 = f2 (arg0_5(D)); rv.DATA.var_0._0 = var7; D.2927 = rv; After: rv$DATA$var_0$_1_17 = 2; var7 = f2 (arg0_5(D)); rv.DATA.var_0._0 = var7; MEM [(struct s2 *)&D.2927] = rv$DATA$var_0$_1_17; MEM [(struct s2 *)&D.2927 + 8B] = rv$DATA$var_1$_1_18(D); Notice var7 is not copied correctly.
[Bug c++/100037] lookup doesn't find class template parameter in default member initializer of forward declared nested class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99 --- Comment #5 from Andrew Pinski --- Note this is related to PR 99 and most likely the same underlying issue as bug 117422 where we use the wrong template arugment sometimes.
[Bug tree-optimization/117423] [12/13/14/15 Regression] union not written to with particular layout since r10-6321-g636e80eea24b78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 --- Comment #4 from Sam James --- r10-6321-g636e80eea24b78
[Bug c/117289] gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-03 Ever confirmed|0 |1
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422 --- Comment #4 from eczbek.void at gmail dot com --- Wow, very strange. Thanks for the workaround.
[Bug target/117304] ICE: in emit_move_insn, at expr.cc:4633 with -mavx10.1 and __builtin_ia32_cvtudq2ps512_mask()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117304 --- Comment #2 from Zdenek Sojka --- Created attachment 59523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59523&action=edit testcase using __builtin_ia32_cvttpd2udq512_mask() $ x86_64-pc-linux-gnu-gcc -mavx10.1 testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:8:8: internal compiler error: in emit_move_insn, at expr.cc:4633 8 | v ^= __builtin_ia32_cvttpd2udq512_mask(d, v, 0, 4); |^ 0x2c9c5fe internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:518 0xe8453b fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:1696 0x797434 emit_move_insn(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/expr.cc:4633 0x114ebf1 copy_to_reg(rtx_def*) /repo/gcc-trunk/gcc/explow.cc:630 0x1ad9587 ix86_expand_round_builtin /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:12945 ...
[Bug target/117416] [15 Regression] ICE: in gen_prefetch, at config/i386/i386.md:28541 with __builtin_ia32_prefetch() by r15-4833-ge9ab41b79933d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117416 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||lin1.hu at intel dot com Last reconfirmed||2024-11-02 Summary|[15 Regression] ICE: in |[15 Regression] ICE: in |gen_prefetch, at|gen_prefetch, at |config/i386/i386.md:28541 |config/i386/i386.md:28541 |with|with |__builtin_ia32_prefetch() |__builtin_ia32_prefetch() ||by r15-4833-ge9ab41b79933d4
[Bug target/117421] [RISCV] Use byte comparison instead of word comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
--- Comment #1 from Andrew Pinski ---
Note riscv is sometimes does not support unaligned accesses which might be part
of the issue here.
Reduced to just:
```
int ext_is_gzip(char * ext) {
return __builtin_memcmp(ext, "gzip", 4) == 0;
}
```
I should note that -mno-strict-align still does not do it but that is because
it might be slow still to do unaligned access.
using -mtune=thead-c906 "works".
I am suspect this is expected behavior.
[Bug rtl-optimization/117423] New: union not written to with particular layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423
Bug ID: 117423
Summary: union not written to with particular layout
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tpg+gcc at mutabah dot net
Target Milestone: ---
Created attachment 59524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59524&action=edit
Preprocessed output of reproduction (2-20241102-TimeCodegenError.i) from
12.3.0-1ubuntu1~22.04
Found on ubuntu using 11.4.0-1ubuntu1~22.04, reproduced using
12.3.0-1ubuntu1~22.04, and then checked using godbolt to be present from 10.0
up to (latest) 14.2, but NOT on 9.5
Seen while debugging auto-generated code. When optimisations are enabled, a
particular union field isn't assigned - leading to use of uninitialised memory.
For the below code snippet (full source attached) the write of `var7` to
`rv.DATA.var_0._0` is not present in the final executable (as demonstrated by
the disassembly - and a runtime assertion failure).
>From my testing, the intermediate variable `var7` needs to exist, it needs to
be in a conditional branch, and the layout of the output union needs to have a
specific pattern.
```
#include
#include
struct s_ZRG2cE18time0_3_29_H4d4date4Date0g {
// /*@0*/struct s_ZRG3cE9core0_0_03num7nonzero10NonZeroI320g _0; //
::"core-0_0_0"::num::nonzero::NonZeroI32/*S*/
/*@0*/int32_t _0; // i32
} ;
struct
s_ZRG2cE9core0_0_06resultG9ResultErr2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
{
/*@0*/uint8_t _4; // bool
/*@8*/int64_t _1; // i64
} ;
struct
e_ZRG2cE9core0_0_06result6Result2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
{
union {
struct
s_ZRG2cE9core0_0_06resultG8ResultOk2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
{
/*@0*/uint8_t _1; // u8
/*@4*/struct s_ZRG2cE18time0_3_29_H4d4date4Date0g
_0; // Required!
} var_0;
struct
s_ZRG2cE9core0_0_06resultG9ResultErr2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
var_1;
} DATA;
};
__attribute__ ((noinline)) int
ZRIG2cI17deranged0_3_8_H8110ranged_i329RangedI320v2gV4_0989e2ffV4_2cfe51003new0g_OP(int32_t
arg0);
//{ return arg0 > 12345; }
struct s_ZRG2cE18time0_3_29_H4d4date4Date0g
ZRIG2cE18time0_3_29_H4d4date4Date0g25from_julian_day_unchecked0g(int32_t
arg0);
//{ struct s_ZRG2cE18time0_3_29_H4d4date4Date0g rv = { arg0 }; return rv; }
// <::"time-0_3_29_H4d"::date::Date/*S*/ /*- */>::from_julian_day
struct
e_ZRG2cE9core0_0_06result6Result2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
ZRIG2cE18time0_3_29_H4d4date4Date0g15from_julian_day0g(
int32_t arg0 // i32
) // ->
::"core-0_0_0"::result::Result<::"time-0_3_29_H4d"::date::Date/*S*/,::"time-0_3_29_H4d"::error::component_range::ComponentRange/*S*/,>/*E*/
{
struct
e_ZRG2cE9core0_0_06result6Result2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
rv;
struct
s_ZRG2cE9core0_0_06resultG9ResultErr2gG2cE18time0_3_29_H4d4date4Date0gG3c_D5error15component_range14ComponentRange0g
var6 = {0};
struct s_ZRG2cE18time0_3_29_H4d4date4Date0g var7;
if(
ZRIG2cI17deranged0_3_8_H8110ranged_i329RangedI320v2gV4_0989e2ffV4_2cfe51003new0g_OP(arg0)
) {
rv.DATA.var_1 = var6;
return rv;
}
else {
rv.DATA.var_0._1 = 2;
// Intermetdiate variable needed.
var7 =
ZRIG2cE18time0_3_29_H4d4date4Date0g25from_julian_day_unchecked0g( arg0 );
rv.DATA.var_0._0 = var7;
return rv;
}
}
```
```
115e :
115e: f3 0f 1e fa endbr64
1162: 53 push %rbx
1163: 89 fb mov%edi,%ebx
1165: e8 df ff ff ff call 1149
116a: ba 00 00 00 00 mov$0x0,%edx
116f: 84 c0 test %al,%al
1171: 74 0e je 1181
1173: b8 00 00 00 00 mov$0x0,%eax
1178: 88 d0 mov%dl,%al
117a: ba 00 00 00 00 mov$0x0,%edx
117f: 5b pop%rbx
1180: c3 ret
1181: 89 df mov%ebx,%edi
1183: e8 cf ff ff ff call 1157
1188: ba 02 00 00 00 mov$0x2,%edx
118d: eb e4 jmp1173
```
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-11-03 Known to fail||3.4.6 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- Confirmed. Note obvious workaround is to name the original template argument in the template definition of f to be T. Like so: ``` template void f(); ``` I think this might be a dup too since this is an old old bug.
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422 --- Comment #3 from Andrew Pinski --- Looks very similar to the issue of PR 100037 too.
[Bug c/117289] gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289 --- Comment #2 from Indu Bhagat --- Regarding handling of duplicate types in CTF, the bulk of expectation lies on the link-time de-duplication. On the compiler side, we simply try to not emit duplicate CTF types to avoid bloating up the object files (and well, to reduce the work at link time): this is achieved by DWARF DIE references as the key in the ctfc_types hash_table (see ctf_type_exists ()). In this testcase, when -std=gnu23 is added to the command line, I do see that there are two distinct DWARF DIEs with tag DW_TAG_subroutine_type: one for the structure member and another for the typedef. (As a consequence, we see the two CTF types are added in the CTF container). <2><3c>: Abbrev Number: 2 (DW_TAG_member) <3d> DW_AT_name: (indirect string, offset: 0x6f7): func <41> DW_AT_decl_file : 1 <41> DW_AT_decl_line : 14 <42> DW_AT_decl_column : 16 <43> DW_AT_type: <0x59> <47> DW_AT_data_member_location: 8 <2><48>: Abbrev Number: 0 <1><49>: Abbrev Number: 1 (DW_TAG_pointer_type) <4a> DW_AT_byte_size : 8 <4a> DW_AT_type: <0x22> <1><4e>: Abbrev Number: 3 (DW_TAG_subroutine_type) <4f> DW_AT_prototyped : 1 <4f> DW_AT_sibling : <0x59> <2><53>: Abbrev Number: 4 (DW_TAG_formal_parameter) <54> DW_AT_type: <0x49> <2><58>: Abbrev Number: 0 <1><59>: Abbrev Number: 1 (DW_TAG_pointer_type) <5a> DW_AT_byte_size : 8 <5a> DW_AT_type: <0x4e> ... <1><74>: Abbrev Number: 8 (DW_TAG_typedef) <75> DW_AT_name: (indirect string, offset: 0x227c): rcu_callback_t <79> DW_AT_decl_file : 1 <7a> DW_AT_decl_line : 20 <7b> DW_AT_decl_column : 16 <7c> DW_AT_type: <0x80> <1><80>: Abbrev Number: 1 (DW_TAG_pointer_type) <81> DW_AT_byte_size : 8 <81> DW_AT_type: <0x85> <1><85>: Abbrev Number: 3 (DW_TAG_subroutine_type) <86> DW_AT_prototyped : 1 <86> DW_AT_sibling : <0x90> <2><8a>: Abbrev Number: 4 (DW_TAG_formal_parameter) <8b> DW_AT_type: <0x49> <2><8f>: Abbrev Number: 0 <1><90>: Abbrev Number: 9 (DW_TAG_variable) <91> DW_AT_name: rcb <95> DW_AT_decl_file : 1 <96> DW_AT_decl_line : 22 <97> DW_AT_decl_column : 16 <98> DW_AT_type: <0x74> <9c> DW_AT_external: 1 <9c> DW_AT_location: 9 byte block: 3 10 0 0 0 0 0 0 0 (DW_OP_addr: 10)
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I think this might be a dup too since this is an old old bug.
At least it is related to PR 99 which shows that sometimes we mention the
template argument from the old one.
Note also you can make this accepts invalid too:
```
template
void f();
struct S {
template
friend void f() {
Q x;
}
};
int main() {
f();
}
```
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422 --- Comment #5 from Andrew Pinski --- (In reply to eczbek.void from comment #4) > Wow, very strange. Thanks for the workaround. Most likely what is happening is the 2 decls are merged early and then the template argument from the other decl is used instead of the new one which was just declared. This is why comment #2 is happening :).
[Bug tree-optimization/112090] ``(1 >> X) != 0` pattern should be extended to support other constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112090 --- Comment #1 from Andrew Pinski --- Also for `1 >> x` it should just be turned into `x == 0` instead but that is PR 102705 .
[Bug tree-optimization/117424] [12/13/14/15 regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 --- Comment #3 from Sam James --- -O3 -fno-unswitch-loops works.
[Bug c/117424] New: Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
Bug ID: 117424
Summary: Miscompile with different optimization flags
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
When I compiled this case by -O3, it terminated with signal: SIGSEGV. When
compiled with -O0/O1/O2, its output is 0:
```c
int printf(const char *, ...);
int a;
unsigned char c;
int e(int f) {
int d = f * 10;
return d;
}
int g(int f, int *l) {
int h = 0;
for (int j = 0; j < 10; j++)
for (int k = 0; k < f; k++)
if (l[k])
h++;
return h;
}
int m(int f) {
int b = 0, n = g(f, &b);
return n;
}
int main() {
int i = 0;
for (; e(c + 77) + c - 836 + i < 2; i++)
for (; m(c - 5);)
;
printf("%d\n", a);
}
```
The version of gcc is 12.1. Details can be found here:
https://godbolt.org/z/1Kd4s4K7x.
I've checked the code with -Wall and -Wextra, no warning has appeared.
[Bug c/117424] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- It crashes but not in Valgrind.
[Bug tree-optimization/117424] [12/13/14/15 regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |12.5
[Bug c/117424] [12/13/14/15 regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 Sam James changed: What|Removed |Added Known to work||11.5.0 Known to fail||12.4.1, 13.3.1, 14.2.1, ||15.0 Keywords||wrong-code Summary|Miscompile with different |[12/13/14/15 regression] |optimization flags |Miscompile with different ||optimization flags --- Comment #2 from Sam James --- I'm not confident about the evaluation order in m.
[Bug tree-optimization/117424] [12/13/14/15 regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-03 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #2) > I'm not confident about the evaluation order in m. Change it to be: int b = 0; int n = g(f, &b); and it still fails. But I think the issue is around: for (; e(c + 77) + c - 836 + i < 2; i++) for (; m(c - 5);) But even the call to m. -fwrapv seems to fixes the issue. So does `-fno-tree-vrp` (and -fdisable-tree-evrp -fdisable-tree-vrp1). So does `-fno-tree-vectorize`. Note with -fno-tree-vrp the vectorized IR looks the same except for the side storage of the loop bounds which might be the issue ...
[Bug tree-optimization/117398] [12/13/14/15 Regression] ICE: in invert, at value-range.cc:2165 at -O3 with "-fno-thread-jumps"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117398 Sam James changed: What|Removed |Added Keywords|needs-bisection | --- Comment #4 from Sam James --- Thank you Andrew!
[Bug tree-optimization/117424] [12/13/14/15 regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 --- Comment #5 from Sam James --- -fno-aggressive-loop-optimizations or -fno-strict-overflow as well
[Bug c/117425] New: Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425
Bug ID: 117425
Summary: Miscompile with different optimization flags
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
When I compiled this code with -O1/2/3, its output would be 8. However, with
-O0, its output is 7:
```c
int printf(const char *, ...);
int a;
long b = 1;
long *c = &b, *d = &b;
int e() {
for (; *d + a <= 7; a++)
;
return 0;
}
int main() {
e() | ((*c = 0, 0) || 0);
printf("%d\n", a);
return 0;
}
```
The version is gcc 4.7.3. I've checked the code with -Wall and -Wextra. The
unused warning seems to have no influence on this miscompilation. When I assign
a varibale to e() | ((*c = 0, 0) || 0) and print the value, it's always 0 and
the value of a is still different.
The details can be found here: https://godbolt.org/z/eWPTW5E7c
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 --- Comment #2 from Yunbo Ni --- (In reply to Sam James from comment #1) > (In reply to Yunbo Ni from comment #0) > > The version is gcc 4.7.3. > > When you say this, do you mean that is the first version you saw it on? Sorry for the misunderstanding I caused. I mean when I used earlier version of gcc, I didn't see the bug appear.
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- (In reply to Yunbo Ni from comment #0) > The version is gcc 4.7.3. When you say this, do you mean that is the first version you saw it on?
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- This is unspecified on the order of evaluating e() vs ((*c = 0, 0) || 0). Even though there is a sequence point between *c = 0 and 0 (and || 0) there is no sequence point for the original `|` so e() could be executed first or `*c = 0;`
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 --- Comment #4 from Andrew Pinski --- That is: ``` e() ; ((*c = 0, 0) || 0); ``` vs: ``` ((*c = 0, 0) || 0); e() ; ``` GCC has a warning for sequence points (-Wsequence-point) but this one is hard to figure out since e() depends on the assigned of *c which is not exactly locally known. There is a paper to change C to make this well defined rather unspecified. But as of right now it is not.
[Bug tree-optimization/110361] [13/14/15 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110361 Sam James changed: What|Removed |Added Keywords|needs-bisection | --- Comment #7 from Sam James --- Fixed by r13-8594-g40ddc0b05a47f9.
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 --- Comment #6 from Yunbo Ni --- (In reply to Andrew Pinski from comment #5) > A good resource for sequence points is https://c-faq.com/expr/seqpoints.html > . Thanks for your detailed explanation! I'll check it out.
[Bug c/117425] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117425 --- Comment #5 from Andrew Pinski --- A good resource for sequence points is https://c-faq.com/expr/seqpoints.html .
[Bug tree-optimization/117423] [12/13/14/15 Regression] union not written to with particular layout since r10-6321-g636e80eea24b78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 --- Comment #5 from John Hodge --- (In reply to Andrew Pinski from comment #3) > Obvbious workaround `-fno-tree-sra` . Thanks for pointing out the flag to avoid this issue, that's allowed me to progress with my other testing. And thanks very much for the prompt replies :)
[Bug testsuite/117419] test failures for enum-alias-{1,2,30 on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419 --- Comment #3 from uecker at gcc dot gnu.org --- I sent a patch before but there is still something wrong: PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655473.html Discussion: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656106.html https://patchwork.sourceware.org/project/gcc/patch/0f6bc7aacf6407b4fcdcb10c9d99f10292461a19.ca...@tugraz.at/
[Bug tree-optimization/117420] [15 regression] wrong code at -O1 on x86_64-linux-gnu since r15-4601-ge2e798b8607401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117420 Sam James changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Summary|[15 regression] wrong code |[15 regression] wrong code |at -O1 on x86_64-linux-gnu |at -O1 on x86_64-linux-gnu ||since ||r15-4601-ge2e798b8607401 --- Comment #3 from Sam James --- r15-4601-ge2e798b8607401
[Bug testsuite/117419] test failures for enum-alias-{1,2,30 on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419 Sam James changed: What|Removed |Added Keywords||testsuite-fail Status|NEW |ASSIGNED
[Bug tree-optimization/117417] [15 Regression] ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117417 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Last reconfirmed||2024-11-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|ICE: verify_gimple failed: |[15 Regression] ICE: |non-top-level |verify_gimple failed: |'bit_field_ref' with -Ofast |non-top-level ||'bit_field_ref' with -Ofast --- Comment #1 from Andrew Pinski --- Confirmed. It looks like it was exposed by a change to DSE.
[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to GCC Commits from comment #13) > The master branch has been updated by Paul Thomas : > > https://gcc.gnu.org/g:7f93910a8b5d606ad742a3594750f0c2b20d8bda > > commit r15-4835-g7f93910a8b5d606ad742a3594750f0c2b20d8bda > Author: Paul Thomas > Date: Fri Nov 1 07:45:00 2024 + > > Fortran: Fix problems with substring selectors in ASSOCIATE [PR115700] > > 2024-11-01 Paul Thomas > > gcc/fortran > PR fortran/115700 > * resolve.cc (resolve_assoc_var): Extract a substring reference > with missing as well as non-constant start or end. > > gcc/testsuite/ > PR fortran/115700 > * gfortran.dg/associate_69.f90: Activate commented out tests. > * gfortran.dg/associate_70.f90: Test correct functioning of > references in associate_69.f90 tests. Paul, the addition to testcase gfortran.dg/associate_69.f90 fails on 32-bit targets (or using -m32), which can be seen by comparing the dumps: for -m32 the final "stop 6" gets optimized away already at -Og, but not at -m64. So the pattern needs to be reconsidered. Can you have a look?
[Bug tree-optimization/117420] wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117420 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Last reconfirmed||2024-11-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Before fre: # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _3 = (intD.6) _2; _4 = -_3; ... # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _8 = -_3; The value assigned to _8 is wrong I think. Before forwprop2: # RANGE [irange] int [-INF, +INF] MASK 0xfffe VALUE 0x0 _12 = _3 * -2; # RANGE [irange] int [0, 0][2, 2] MASK 0x2 VALUE 0x0 _7 = _12 & 2; # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _8 = _7 / 2; After: # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _8 = -_3; Comes from: Matching expression match.pd:197, gimple-match-6.cc:22 Matching expression match.pd:2311, gimple-match-5.cc:64 Matching expression match.pd:197, gimple-match-6.cc:22 Matching expression match.pd:2878, gimple-match-8.cc:90 Matching expression match.pd:2883, gimple-match-4.cc:94 Matching expression match.pd:2311, gimple-match-5.cc:64 Applying pattern match.pd:5607, gimple-match-9.cc:17041 Applying pattern match.pd:990, gimple-match-1.cc:4265 Applying pattern match.pd:5508, gimple-match-10.cc:14607 gimple_simplified to _8 = -_3; /* Simplify (t * u) / v -> t * (u / v) if u is multiple of v. */ /* X / (1 << C) -> X /[ex] (1 << C) if the low C bits of X are clear. */ I think the issue is how with_possible_nonzero_bits2 is defined or its use in the pattern added by r15-4601-ge2e798b8607401 . It is causing to remove the &2.
[Bug tree-optimization/110361] [13/14/15 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-2020-g16b013c9d9b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110361 --- Comment #6 from Sam James --- (In reply to Sam James from comment #5) > (In reply to Andrew Pinski from comment #4) > > Looks like this was fixed sometime after r13-2020-g16b013c9d9b but before > > the release of GCC 13. > > I'll bisect when I'm done with another. Nevermind, I won't, it's too much of a pain in that range w/ float changes. Someone needs to do it w/ older glibc or musl instead.
[Bug tree-optimization/117417] [12/13/14/15 Regression] ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117417 Andrew Pinski changed: What|Removed |Added Summary|[15 Regression] ICE:|[12/13/14/15 Regression] |verify_gimple failed: |ICE: verify_gimple failed: |non-top-level |non-top-level |'bit_field_ref' with -Ofast |'bit_field_ref' with -Ofast Known to work||9.5.0 Target Milestone|15.0|12.5 Known to fail||10.1.0 --- Comment #3 from Andrew Pinski --- With my new reduced testcase, the test started to fail in GCC 10.1.0
[Bug tree-optimization/117417] [15 Regression] ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117417 --- Comment #2 from Andrew Pinski --- Created attachment 59522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59522&action=edit New reduced testcase This one fails even in GCC 14.
[Bug testsuite/117419] test failures for enum-alias-{1,2,30 on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117419 Andrew Pinski changed: What|Removed |Added Target||arm --- Comment #2 from Andrew Pinski --- Most likely due to -fshort-enum being the default on arm.
[Bug target/117421] New: [RISCV] Use byte comparison instead of word comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
Bug ID: 117421
Summary: [RISCV] Use byte comparison instead of word comparison
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojciech_mula at poczta dot onet.pl
Target Milestone: ---
Consider this simple function:
---
#include
bool ext_is_gzip(std::string_view ext) {
return ext == "gzip";
}
---
For the x86 target, GCC nicely inlines compile-time constant, and produces the
code like that (it's from GCC 15, with `-O3 -march=icelake-server`):
---
ext_is_gzip(std::basic_string_view >):
xorl%eax, %eax
cmpq$4, %rdi
je .L5
ret
.L5:
cmpl$1885960807, (%rsi)
sete%al
ret
---
However, for the RISC-V target, GCC emits plain byte-by-byte comparison
(riscv64-unknown-linux-gnu-g++ (crosstool-NG UNKNOWN) 15.0.0 20241031
(experimental), with `-O3 -march=rv64gcv`):
---
ext_is_gzip(std::basic_string_view >):
addisp,sp,-16
sd a0,0(sp)
sd a1,8(sp)
li a5,4
beq a0,a5,.L9
li a0,0
addisp,sp,16
jr ra
.L9:
lbu a4,0(a1)
li a5,103
beq a4,a5,.L10
.L3:
li a0,1
.L4:
xoria0,a0,1
addisp,sp,16
jr ra
.L10:
lbu a4,1(a1)
li a5,122
bne a4,a5,.L3
lbu a4,2(a1)
li a5,105
bne a4,a5,.L3
lbu a4,3(a1)
li a5,112
li a0,0
beq a4,a5,.L4
li a0,1
j .L4
---
My wild guess is that we have by default a high cost of placing huge
compile-time values in RISC-V. However, when I checked what is emitted for
"gzip" & "pizg" given as u32, then we have:
---
0: 677a7537lui a0,0x677a7
4: 9705051baddiw a0,a0,-1680 # 677a6970
8: 70698537lui a0,0x70698
c: a675051baddiw a0,a0,-1433 # 70697a67
---
A godbolt link for convenience: https://godbolt.org/z/e16bP369n.
[Bug c/117426] New: Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117426
Bug ID: 117426
Summary: Miscompile with different optimization flags
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
When I compiled this code with -O0/1/2, its output is 1. While with -O3, its
output is 0:
```c
int printf(const char *, ...);
int a[6];
int b, d, i, j, l, m, n;
char *c;
int f[8][8][4];
int *g = &d;
char p[11];
int main() {
short q[6];
int k = 0;
for (; k < 2; k++) {
{
char o[3];
int e = 53;
char *h = o;
c = p;
while (e)
*c++ = e /= 10;
while (c != p)
*h++ = *--c;
*h++ = '\0';
n = h - o;
}
q[n - 2] = 1;
}
*g = q[1];
printf("%d\n", d);
l = 0;
for (; l < 10; l++)
if (m)
printf("index = \n");
i = 0;
for (; i < 7; i++) {
j = 0;
for (; j < 7; j++)
b = a[b];
}
j = 0;
for (; j < 8; j++) {
l = 0;
for (; l < 4; l++)
b = a[b ^ f[i][j][l]];
}
}
```
This bug can be reproduced by 14.1 and later versions. I've checked the code
with -Wall and -Wextra.
The details can be found here: https://godbolt.org/z/1a9EbfoP6
[Bug target/109780] [12/13/14/15 Regression] csmith: runtime crash with -O2 -march=znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780 --- Comment #28 from Sam James --- trunk works for me, but 14 doesn't. (Needed -fno-stack-protector -fno-stack-clash-protection to override some defaults.) I don't think https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780#c23 was committed though.
[Bug middle-end/111843] [meta-bug] wrong-code due to -fstack-reuse=/clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111843 --- Comment #2 from Sam James --- (In reply to Eric Gallager from comment #1) > Don't meta-bugs usually put all their other bugs in the "Depends on" field, > rather than "Blocks"? yes, fixed
[Bug tree-optimization/113662] [13/14/15 Regression] Wrong code for std::sort with fancy pointer since r13-6945-g429a7a88438cc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 --- Comment #7 from Sam James --- > I'd be glad to perform other tests if needed. We could really do with the Boost dependency being dropped if you could try spend time on that. Also, please attach preprocessed source for the original testcase.
[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117426 --- Comment #3 from Andrew Pinski --- And yes my current patch for scope conflicts fixes the issue. Though I have to rewrite it.
[Bug c/115023] __builtin_assoc_barrier does not talk about contracting even though it prevents it too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115023 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Novembe ||r/667318.html --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667318.html
[Bug tree-optimization/117424] [12/13/14/15 regression] Miscompile with different optimization flags since r12-4871-g502ffb1f389011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424 Sam James changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com Summary|[12/13/14/15 regression]|[12/13/14/15 regression] |Miscompile with different |Miscompile with different |optimization flags |optimization flags since ||r12-4871-g502ffb1f389011 --- Comment #6 from Sam James --- Started with r12-4871-g502ffb1f389011. I could bisect with the param back a bit more but experience says that doesn't tend to get us far.
[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117426 Andrew Pinski changed: What|Removed |Added Summary|Miscompile with different |[14/15 Regression] |optimization flags |Miscompile with different ||optimization flags Component|c |middle-end Target Milestone|--- |14.3 --- Comment #1 from Andrew Pinski --- -fstack-reuse=none fixes it ...
[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117426
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Last reconfirmed||2024-11-03
Keywords||wrong-code
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Partition 0: size 12 align 2
q o
That is definitely wrong.
_391 = _389 - _390;
h_392 = (char *) _391;
h_393 = h_392 + 1;
...
o ={v} {CLOBBER(eos)};
_399 = _396 + -2;
q[_399] = 1;
c = &p;
*h_392 = 0;
o ={v} {CLOBBER(eos)};
_10 = q[1];
It does not realize h_392 could point to inside o due to complexity of the
definition.
Anyways this should be fixed with my patch to fix scope conflicts.
[Bug debug/15736] [4.0 Regression] internal compiler error: in force_decl_die, at dwarf2out.c:12441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15736 --- Comment #9 from Carlo Wood --- Just curious... what caused the 20 years of delay?
[Bug target/115931] mips: vec_pack_usat_m's pattern is wrong at gcc/config/mips/loongson-mmi.md:167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115931 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Hmm... If I read the manual correctly Loongson MMI doesn't even have "packuswh" (vec_pack_usat_v2si). It only has packushb (vec_pack_usat_v4hi).
[Bug tree-optimization/117398] [12/13/14/15 Regression] ICE: in invert, at value-range.cc:2165 at -O3 with "-fno-thread-jumps"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117398
--- Comment #3 from Andrew Macleod ---
(In reply to Sam James from comment #2)
> * With just -O1, 11 works and >=12 fails, bisected to
> r12-2591-g2e96b5f14e4025.
> * With -O2 -fno-thread-jumps, 12 works and >=13 fails. Needs bisection I
> guess.
dont worry about bisecting. We aren't handling the case where all cases go to
one lable, resulting in VARYING. we try to invert handled cases to remove them
from the defalut case, but VARYING can't be inverted.. (neither VARYING nor
UNDEFINED can be inverted as UNDEFINED has no type, so we cant call
invert().invert() and get the original value back) so we trap
I'll run this through testing,
diff --git a/gcc/gimple-range-edge.cc b/gcc/gimple-range-edge.cc
index e3a197a2293..31db631b349 100644
--- a/gcc/gimple-range-edge.cc
+++ b/gcc/gimple-range-edge.cc
@@ -159,8 +159,14 @@ gimple_outgoing_range::calc_switch_ranges (gswitch *sw)
// Remove the case range from the default case.
int_range_max def_range (type, low, high);
range_cast (def_range, type);
- def_range.invert ();
- default_range.intersect (def_range);
+ // if all possible values are taken, set default_range to UNDEFINED.
+ if (def_range.varying_p ())
+ default_range.set_undefined ();
+ else
+ {
+ def_range.invert ();
+ default_range.intersect (def_range);
+ }
// Create/union this case with anything on else on the edge.
int_range_max case_range (type, low, high);
[Bug c++/64346] gcc generates incorrect debug info for ctor/dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64346 --- Comment #6 from Jason Merrill --- (In reply to dehao from comment #3) > For AutoFDO, we actually needs symbols from the symbol table because > indirect call promotion needs the symbol name to find the right callee. I don't understand why the -O0 output is relevant for autofdo; surely you want to do data collection on an optimized build and then use it on another optimized build? We could change debug output so that you see the C1 as an intermediate inline function, but it's not clear to me why that would be beneficial. Also, there's no indirect call here, constructors are always called directly.
