[Bug rtl-optimization/15792] missed subreg optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
Andrew Pinski changed:
What|Removed |Added
Known to fail||
--- Comment #12 from Andrew Pinski ---
(In reply to Gabriel Ravier from comment #11)
> Seems like the issue is present again, except it's test1 that gets the
> better asm now. Perhaps this should be re-opened ?
This bug was about 32bit x86 and the code looks good in GCC 9, 10, 11, and 12
and the trunk.
If you were testing on x86_64, you need to use __int128_t to see what the
original issue was about:
void gh();
void test(__int128_t x) {
long g = (long)x|((long)(x>>64));
if (g) gh();
}
void test1(__int128_t x) {
if (x) gh();
}
GCC 4.8+ produces:
test1:
.cfi_startproc
orq %rdi, %rsi
jne .L7
rep ret
For both. There was an extra mov in GCC 4.5.0-4.7.0 for test though. In GCC
4.4.0, test1 was two compare and jumps (ok). GCC 4.1.2 had the bad code
generation which was mentioned in comment #0.
[Bug target/46975] Replace 32 bit instructions with 16 bit instructions in thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46975 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |4.7.0 Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- The fix was committed as r0-109399-g527e82c2679a4b but since the commit log didn't have the bug # in it, it didn't reach here. The bug # is in the changelog though.
[Bug target/46127] Use 16bit add instead of 32bit in thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46127 Andrew Pinski changed: What|Removed |Added Severity|minor |enhancement Last reconfirmed|2010-10-27 16:18:15 |2023-5-14
[Bug target/45980] Use not in stead of add to generate new constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45980 --- Comment #2 from Andrew Pinski --- For the original testcase on the trunk we get: ldr r3, .L2 str r3, [r0] add r3, r3, #-2004318072 str r3, [r0, #4] add r3, r3, #-1459617792 sub r3, r3, #1228800 subwr3, r3, #3723 str r3, [r0, #8] sub r3, r3, #-2004318072 str r3, [r0, #12] ldr r3, .L2+4 str r3, [r0, #16] movsr3, #0 strdr3, r3, [r0, #20] bx lr .L3: .align 2 .L2: .word 1732584193 .word -1009589776
[Bug target/45252] unnecessary register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45252
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from Andrew Pinski ---
GCC 8+ does:
ts:
push{r0, r1, r2, r3, r4, lr}
mov r0, sp
movsr3, #0
str r3, [sp]
bl foo
add sp, sp, #20
ldr pc, [sp], #4
Which is exactly what you want.
[Bug target/36539] Poor register allocation from IRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Andrew Pinski --- GCC 4.8+ for -m32 -O2 -fno-pic -fomit-frame-pointer: get_cabac: pushl %ebp pushl %edi pushl %esi pushl %ebx movl20(%esp), %esi movl24(%esp), %ebp movl4(%esi), %ebx movl(%esi), %eax #APP # 16 "/app/example.cpp" 1 #%edi %ebx %ax 16(%esi) %ebp # 0 "" 2 #NO_APP movl%eax, (%esi) movl%edi, %eax movl%ebx, 4(%esi) andl$1, %eax popl%ebx popl%esi popl%edi popl%ebp ret Which most likely means it was fixed when LRA came in, aka r0-119686-g55a2c3226a3e90 so closing as fixed for GCC 4.8.
[Bug tree-optimization/39052] writing arrays twice not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39052
--- Comment #3 from Andrew Pinski ---
even for:
void foo(char *a, int n)
{
int i;
for (i=0; i
[Bug target/33716] gcc generates suboptimal code for long long shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33716 --- Comment #1 from Andrew Pinski --- 32bit x86 is not as important any more. With -msse2 these days, GCC produces: movq4(%esp), %xmm0 psrlq $4, %xmm0 movd%xmm0, %eax psrlq $32, %xmm0 movd%xmm0, %edx Which is faster anyways.
[Bug tree-optimization/51781] Missed optimization for ==/!= comparison type-sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51781 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- No longer working on this one.
[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109610 --- Comment #1 from Andrew Pinski --- Maybe once PR 109610 is fixed this also is fixed.
[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug rtl-optimization/109858] New: r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Bug ID: 109858 Summary: r14-172 caused some SPEC2017 bmk to degrade on Power Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org Target Milestone: --- On Power9, - at option -Ofast, 557.xz_r degraded -1.06%. - at option -Ofast, 511.povray_r degraded -1.24%. On Power10, - at option -O2, 520.omnetpp_r degraded -1.84%. I tried to run them in a few times, the gaps are stable. I've excluded those one in +-1% as noises. The full data is listed below: P9 O2: 500.perlbench_r 0.00% 502.gcc_r -0.20% 505.mcf_r 0.00% 520.omnetpp_r -0.30% 523.xalancbmk_r 0.00% 525.x264_r 0.00% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.00% 503.bwaves_r0.00% 507.cactuBSSN_r 0.00% 508.namd_r -0.32% 510.parest_r0.00% 511.povray_r0.32% 519.lbm_r -0.16% 521.wrf_r 0.00% 526.blender_r 0.27% 527.cam4_r 0.00% 538.imagick_r 0.00% 544.nab_r 0.00% 549.fotonik3d_r 0.00% 554.roms_r 0.00% P9 Ofast: 500.perlbench_r 0.00% 502.gcc_r 0.00% 505.mcf_r 0.00% 520.omnetpp_r 0.00% 523.xalancbmk_r 0.00% 525.x264_r 0.17% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 2.15% 557.xz_r-1.06% 503.bwaves_r2.21% 507.cactuBSSN_r -0.20% 508.namd_r -0.33% 510.parest_r0.00% 511.povray_r-1.24% 519.lbm_r 0.00% 521.wrf_r 0.19% 526.blender_r 0.00% 527.cam4_r 0.28% 538.imagick_r 0.32% 544.nab_r 0.00% 549.fotonik3d_r -0.83% 554.roms_r 1.33% Power10 O2: 500.perlbench_r 0.00% 502.gcc_r 0.33% 505.mcf_r 0.55% 520.omnetpp_r -1.84% 523.xalancbmk_r 0.00% 525.x264_r 0.36% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.31% 503.bwaves_r0.00% 507.cactuBSSN_r -0.31% 508.namd_r -0.22% 510.parest_r-0.64% 511.povray_r-0.86% 519.lbm_r -0.75% 521.wrf_r 0.20% 526.blender_r 0.20% 527.cam4_r 0.00% 538.imagick_r -0.15% 544.nab_r -0.18% 549.fotonik3d_r 0.00% 554.roms_r 0.00% Power10 Ofast: 502.gcc_r 0.16% 505.mcf_r 0.00% 520.omnetpp_r 0.00% 523.xalancbmk_r 0.22% 525.x264_r 0.30% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.31% 503.bwaves_r-0.18% 507.cactuBSSN_r 0.00% 508.namd_r 0.22% 510.parest_r-0.52% 511.povray_r0.00% 519.lbm_r 0.50% 521.wrf_r 0.00% 526.blender_r -0.80% 527.cam4_r 0.18% 538.imagick_r -0.11% 544.nab_r 0.17% 549.fotonik3d_r 0.63% 554.roms_r -0.63%
[Bug tree-optimization/64700] Sink common code through PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33315 --- Comment #7 from Andrew Pinski --- I should note store sinking is handled by the sinking pass by r11-408-g84935c9822183c .
[Bug target/40730] redundant memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c). The first redundant load was fixed by r11-408-g84935c9822183c. The extra store was fixed was fixed by r12-897-gde56f95afaaa22 . But it is still fixed fully.
[Bug target/40730] redundant memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33315 Known to fail||10.1.0, 11.1.0, 5.1.0 Known to work||12.1.0, 13.1.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Andrew Pinski --- Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c).
[Bug tree-optimization/89332] Missed detection of dead stores to array in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89332 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-02-18 00:00:00 |2023-5-14 Severity|normal |enhancement
[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68855 --- Comment #2 from Andrew Pinski --- Maybe: (simplify (paren (complex_expr @0 @1)) (complex_expr (paren @0) (paren @1)) (simplify (paren (real_expr @0)) (real_expr (paren @0)) (simplify (paren (imag_expr @0)) (real_expr (paren @0)) Is enough.
[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #3 from Andrew Pinski --- (for cmp (tcc_comparison) (simplify (cmp (pointer_diff @0 @1) integer_zero_p) (cmp @0 @1))) Maybe But we might also need handle the match patterns for too: A CMP B ? A - B : -(A - B) A CMP B ? A - B : B - A (which is also on my todo list anyways).
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:82502b5c3463bde98d4b7ffb9ecef9b123799ed1 commit r14-813-g82502b5c3463bde98d4b7ffb9ecef9b123799ed1 Author: Andrew Pinski Date: Sat May 13 22:25:21 2023 + MATCH: Add pattern for `signbit(x) ? x : -x` into abs (and swapped) This adds a simple pattern to match.pd for `signbit(x) ? x : -x` into abs. This can be done for all types even ones that honor signed zeros and NaNs because both signbit and - are considered only looking at/touching the sign bit of those types and does not trap either. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/109829 gcc/ChangeLog: * match.pd: Add pattern for `signbit(x) !=/== 0 ? x : -x`. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/abs-3.c: New test. * gcc.dg/tree-ssa/abs-4.c: New test.
[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #10 from Andrew Pinski --- *** Bug 105686 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/105686] [10/11/12/13/14 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Keywords|needs-bisection | --- Comment #6 from Andrew Pinski --- Nope it was fully fixed, via PR 90259. See bug 90259 comment #7 which makes this an exact duplicate of that bug so closing as such. *** This bug has been marked as a duplicate of bug 90259 ***
[Bug rtl-optimization/105686] [10/11/12/13/14 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686 Andrew Pinski changed: What|Removed |Added Known to fail|13.0| Keywords||needs-bisection --- Comment #5 from Andrew Pinski --- This seems like it has gone latent again in GCC 13. I noticed something in the pro_and_epilogue pass that merges the basic blocks at that point even.
[Bug ipa/97551] [11 Regression] ICE: verify_cgraph_node failed with "-O2 -fno-toplevel-reorder -fno-tree-dce -fno-tree-forwprop -fno-tree-fre -fipa-cp-clone"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97551 Andrew Pinski changed: What|Removed |Added Summary|ICE: verify_cgraph_node |[11 Regression] ICE: |failed with "-O2|verify_cgraph_node failed |-fno-toplevel-reorder |with "-O2 |-fno-tree-dce |-fno-toplevel-reorder |-fno-tree-forwprop |-fno-tree-dce |-fno-tree-fre |-fno-tree-forwprop |-fipa-cp-clone" |-fno-tree-fre ||-fipa-cp-clone" Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97576 Target Milestone|--- |11.0 --- Comment #3 from Andrew Pinski --- Been fixed for a few years now even in GCC 11. So closing as such. I suspect it was fixed by the same patch as PR 97576.
[Bug tree-optimization/94675] [10/11/12/13/14 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-04-21 00:00:00 |2023-5-14 --- Comment #25 from Andrew Pinski --- Hmm, At VRP, we have: _6 = + _2; We know after that statement, _2 should have a range of [0,1] because we know the size of _6 is 1 byte. If we use that information afterwards, VRP should be able to optimize the rest.
[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-05-14 Target Milestone|--- |13.2 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- This is the cause of the libstdc++ failures at https://builder.sourceware.org/buildbot/#/builders/215/builds/3026
[Bug libstdc++/109857] New: tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857
Bug ID: 109857
Summary: tzdata 2021a has bad data that cannot be parsed by
libstdc++
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
On debian stable the tzdata.zi file is from version 2021a of the IANA time zone
database and contains this line:
R K 2023 Max - O lastTh 24 0 -
This is invalid, because the fourth field should be "max" not "Max". This
causes libstdc++ to fail to parse the tzdata file and use a UTC-only fallback.
Maybe we should do:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -345,8 +345,9 @@ namespace std::chrono
friend istream& operator>>(istream& in, minmax_year&& y)
{
- if (ws(in).peek() == 'm') // keywords "minimum" or "maximum"
+ if (unsigned char c = ws(in).peek(); std::tolower(c) == 'm')
{
+ // keywords "minimum" or "maximum"
string s;
in >> s; // extract the rest of the word, but only look at s[1]
if (s[1] == 'a')
We should also consider ignoring the system tzdata files if the bundled copy
(currently 2023c) is newer. Or at least try using the bundled one if the
parsing the system file fails, as in this case.
[Bug middle-end/85614] Documentation: -fdump-tree should mention "original"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059297.html
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #29 from Jonathan Wakely --- (In reply to Janez Zemva from comment #27) > forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99 > compliance test is really strict, even openlibm fails the test (it fails to > define float_t and double_t, but this can be hacked around). It's precisely as strict as it needs to be: it checks that every name that will be subject to a using-declaration is present. Because otherwise compiling will give errors. But supporting openlibm would be nice, so I'll separate the checks for those typedefs.
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #15 from Uroš Bizjak --- *** Bug 109825 has been marked as a duplicate of this bug. ***
[Bug target/109825] [14 Regression] ICE in ix86_widen_mult_cost, at config/i386/i386.cc:20442 since r14-666-g608e7f3ab47fe7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825 Uroš Bizjak changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Uroš Bizjak --- Dup. *** This bug has been marked as a duplicate of bug 109807 ***
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #14 from Uroš Bizjak --- *** Bug 109838 has been marked as a duplicate of this bug. ***
[Bug middle-end/109838] [14 Regression] ICE on libaom-3.6.0: in ix86_widen_mult_cost, at config/i386/i386.cc:20444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838 --- Comment #2 from Uroš Bizjak --- *** This bug has been marked as a duplicate of bug 109807 ***
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #28 from Jonathan Wakely --- (In reply to Janez Zemva from comment #26) > I am a c++ user, so I don't like using c header files if at all possible. is a C++ header file, if you doubt that, you can check the path where it's included from. You'll see that libstdc++ installs its own in the same location as . If you prefer, include , you'll get the same contents. What I'm saying is to use ::trunc not std::trunc, because that is present whether or not libstdc++ adds the math functions to namespace std.
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #13 from Uroš Bizjak --- Fixed.
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 --- Comment #12 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:aed51e2051b24a6a2127c6626f451641557a571a commit r14-812-gaed51e2051b24a6a2127c6626f451641557a571a Author: Uros Bizjak Date: Sun May 14 21:53:17 2023 +0200 i386: Handle unsupported modes from ix86_widen_mult_cost [PR109807] Revert my previous change that faked handling of V4HI and V2SImodes in ix86_widen_mult_cost and rather return arbitrary high value for unsupported modes. This should prevent cost estimator from selecting non-existent vector widen multiply operation. gcc/ChangeLog: PR target/109807 * config/i386/i386.cc: Revert the 2023-05-11 change. (ix86_widen_mult_cost): Return high value instead of ICEing for unsupported modes. gcc/testsuite/ChangeLog: PR target/109807 * gcc.target/i386/pr109825.c: New test.
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 --- Comment #4 from Iain Sandoe --- Created attachment 55084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55084=edit Implement the use of fixed framework headers this was a proof-of-principle exercise while looking into issues caused by implementing __has_feature () [PR60512]. This does not have any of the mechanism to *create* or *install* the fixed headers (for my testing I just built a CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the problems found). So, still plenty to do ;)
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Looks like an extension of pr100218. Regtested ok. Taking.
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2023-05-14
Summary|[rejects valid] |Pointer-valued function
|Pointer-valued function |reference rejected as
|reference rejected as |actual argument
|actual argument |
--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative patch to fix the CLASS pointer case:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index d91722e6ac6..1955c8471a4 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -6256,7 +6265,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool
alloc_obj,
&& !(sym->attr.flavor == FL_PROCEDURE && sym == sym->result)
&& !(sym->attr.flavor == FL_PROCEDURE && sym->attr.proc_pointer)
&& !(sym->attr.flavor == FL_PROCEDURE
- && sym->attr.function && sym->attr.pointer))
+ && sym->attr.function && attr.pointer))
{
if (context)
gfc_error ("%qs in variable definition context (%s) at %L is not"
Regtesting now.
Another workaround is to not specify an INTENT for dummy argument plist, i.e.
type(parameter_list) :: plist
[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 --- Comment #2 from Andrew Pinski --- I cannot reproduce this with "../configure --with-build-config=bootstrap-O3" .
[Bug middle-end/109840] [14 Regression] internal compiler error: in expand_fn_using_insn, at internal-fn.cc:153 when building graphite2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Doh! The recent popcount(bswap(x)) optimizations shouldn't be changing the width of the popcount, i.e. the convert? extension needs to be re-inserted, it's only the bswap that gets eliminated. I'll investigate a fix.
[Bug middle-end/109856] New: -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856 Bug ID: 109856 Summary: -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12) Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 55083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55083=edit compile with 'gcc -O2 -Wnull-dereference' to reproduce the bug This is GCC 13.1.1 20230426 (Red Hat 13.1.1-1) on x86-64, and this is a regression from GCC (Ubuntu 12.2.0-17ubuntu1) 12.2.0. I ran into this problem when compiling GNU Emacs src/itree.c. This is a stripped-down version of the original problem (the code makes no sense by itself). Compile the attached program with: gcc -O2 -S -Wnull-dereference v2.i The output is: v2.i: In function ‘itree_remove_fix’: v2.i:28:16: warning: potential null pointer dereference [-Wnull-dereference] 28 | if (other->left) | ~^~ First, the diagnostic is confusing, because it highlights an entire expression, which cannot itself be a null pointer dereference. Second, there's no possible null pointer dereference here. The previous two lines are "if (!other)__builtin_unreachable ();" so OTHER itself cannot be null.
[Bug target/109855] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855 --- Comment #1 from Andrew Pinski --- Most likely caused by r14-473-g93c26deab98fc8 .
[Bug target/109855] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Host|x86_64-pc-linux-gnu |
[Bug tree-optimization/109848] [14 Regression] Recent change causing testsuite ICE on csky port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||testsuite-fail
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Thomas Koenig changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Chinoune changed: What|Removed |Added Resolution|INVALID |WONTFIX
[Bug target/109855] New: [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
Bug ID: 109855
Summary: [14 Regression] ICE: in curr_insn_transform, at
lra-constraints.cc:4231 unable to generate reloads for
{aarch64_mlav4hi_vec_concatz_le} at -O1
Product: gcc
Version: 14.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: aarch64-unknown-linux-gnu
Created attachment 55082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55082=edit
reduced testcase
Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:8:1: error: unable to generate reloads for:
8 | }
| ^
(insn 9 8 10 2 (set (reg:V8HI 102)
(vec_concat:V8HI (plus:V4HI (mult:V4HI (reg:V4HI 103)
(reg:V4HI 103))
(reg:V4HI 103))
(const_vector:V4HI [
(const_int 0 [0]) repeated x4
]))) "testcase.c":7:10 2022 {aarch64_mlav4hi_vec_concatz_le}
(expr_list:REG_DEAD (reg:V4HI 103)
(nil)))
during RTL pass: reload
testcase.c:8:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4231
0x8098df _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7c6f0a curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.cc:4231
0x101b67f lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5396
0x1002c44 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2375
0xfb22a9 do_reload
/repo/gcc-trunk/gcc/ira.cc:5967
0xfb22a9 execute
/repo/gcc-trunk/gcc/ira.cc:6153
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.
$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-810-20230514170325-g1871740c780-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-810-20230514170325-g1871740c780-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230514 (experimental) (GCC)
[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69388 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0
[Bug lto/109854] New: Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109854
Bug ID: 109854
Summary: Error: junk `(%rip)' after expression when using -flto
on files compiled with and without -masm=intel
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi.
With those two source files:
a.c:
#include
void a(void) {
puts("A");
}
main.c:
void a(void);
int main(void) {
a();
return 0;
}
and by running the following commands:
gcc -c -flto a.c # Note the absence of -masm=intel
gcc -masm=intel -O3 -flto a.o main.c -o main
I get the following error:
/tmp/cca9LQNs.s: Assembler messages:
/tmp/cca9LQNs.s:17: Error: junk `(%rip)' after expression
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Compiling the a.c file with -masm=intel solves the issue.
(Doing the opposite, that is compiling a.c with -masm=intel and main.c without
gives a different error: /usr/bin/ld: /tmp/ccMwJTwN.ltrans0.ltrans.o:
relocation R_X86_64_32S against undefined symbol `$8' can not be used when
making a PIE object; recompile with -fPIE
Please tell me if you want me to open a different issue for this case.)
Thanks to fix this issue.
[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Error with "-march=native -O3 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 Andrew Pinski changed: What|Removed |Added Component|libgcc |tree-optimization Last reconfirmed||2023-05-14 Keywords||build, diagnostic Status|UNCONFIRMED |WAITING Target||x86_64-linux-gnu Summary|Making of gcc13 stops at|Making of gcc13 errors out |libcpp/charset.cc with |compiling libcpp/charset.cc |Error |with Error with ||"-march=native -O3 " Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- You must have CXXFLAGS set to be "-march=native -O3 ". If so you should be using --disable-werror too. Can you attach the preprocessed source for charset.cc ? Also Please provide the output with -v while compiling charset.cc since -march=native will expand to something different depending on what machine you run gcc on.
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #27 from Janez Zemva --- forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99 compliance test is really strict, even openlibm fails the test (it fails to define float_t and double_t, but this can be hacked around).
[Bug rust/109853] New: WIN64 is a predefined constant on GCC MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109853
Bug ID: 109853
Summary: WIN64 is a predefined constant on GCC MinGW-w64
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: mehdi.chinoune at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
Target Milestone: ---
Building rust on MinGW-w64 fails because rust uses WIN64 as member of ABI enum
in gcc/rust/util/rust-abi.h
```
...
enum ABI
{
UNKNOWN,
RUST,
INTRINSIC,
C,
CDECL,
STDCALL,
FASTCALL,
WIN64,
SYSV64
};
...
```
WIN64 is a defined to 1 on MinGW-w64
```
$ echo | gcc -dM -E - | grep WIN64
#define _WIN64 1
#define __WIN64 1
#define __WIN64__ 1
#define WIN64 1
```
So, Please consider choosing a different name for Windows ABI.
[Bug ipa/108250] [12/13/14 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #13 from Arsen Arsenović ---
as an update, we've recently gotten valgrind working on a ppc32 machine, and we
get the following:
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq (tuple:1472)
==2738==by 0x17E55C: operator== (tuple:1504)
==2738==by 0x17E55C: operator!= (tuple:1553)
==2738==by 0x17E55C:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool)::{lambda(llvm::MVT,
llvm::MVT)#4}::operator()(llvm::MVT, llvm::MVT) const [clone .constprop.0]
(CodeGenDAGPatterns.cpp:556)
==2738==by 0x180E9F: __invoke_impl&, llvm::MVT&,
llvm::MVT&> (invoke.h:61)
==2738==by 0x180E9F:
__invoke&, llvm::MVT&,
llvm::MVT&> (invoke.h:96)
==2738==by 0x180E9F: __call (functional:495)
==2738==by 0x180E9F: operator() (functional:580)
==2738==by 0x180E9F: bool
berase_if, llvm::MVT)> >(llvm::MachineValueTypeSet&,
std::_Bind, llvm::MVT)>) (CodeGenDAGPatterns.cpp:59)
==2738==by 0x199113:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool) [clone .part.0] (CodeGenDAGPatterns.cpp:573)
==2738==by 0x1A4013: ApplyTypeConstraint (CodeGenDAGPatterns.cpp:1641)
==2738==by 0x1A4013: ApplyTypeConstraints (CodeGenDAGPatterns.h:1269)
==2738==by 0x1A4013:
llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool)
(CodeGenDAGPatterns.cpp:2564)
==2738==by 0x1A4DFB:
llvm::TreePattern::InferAllTypes(llvm::StringMap, llvm::MallocAllocator> const*) (CodeGenDAGPatterns.cpp:3094)
==2738==by 0x1AE02F: llvm::CodeGenDAGPatterns::ParsePatternFragments(bool)
(CodeGenDAGPatterns.cpp:3352)
==2738==by 0x1AE893:
llvm::CodeGenDAGPatterns::CodeGenDAGPatterns(llvm::RecordKeeper&,
std::function) (CodeGenDAGPatterns.cpp:3195)
==2738==by 0x2CF00B: GlobalISelEmitter (GlobalISelEmitter.cpp:3809)
==2738==by 0x2CF00B: llvm::EmitGlobalISel(llvm::RecordKeeper&,
llvm::raw_ostream&) (GlobalISelEmitter.cpp:6312)
==2738==by 0x352E1F: (anonymous
namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&)
(TableGen.cpp:251)
==2738==by 0x3E8447: llvm::TableGenMain(char const*, bool
(*)(llvm::raw_ostream&, llvm::RecordKeeper&)) (Main.cpp:122)
==2738==by 0x134BD7: main (TableGen.cpp:296)
==2738==
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq (tuple:1472)
==2738==by 0x17E55C: operator== (tuple:1504)
==2738==by 0x17E55C: operator!= (tuple:1553)
==2738==by 0x17E55C:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool)::{lambda(llvm::MVT,
llvm::MVT)#4}::operator()(llvm::MVT, llvm::MVT) const [clone .constprop.0]
(CodeGenDAGPatterns.cpp:556)
==2738==by 0x1810FF: __invoke_impl&, llvm::MVT&,
llvm::MVT&> (invoke.h:61)
==2738==by 0x1810FF:
__invoke&, llvm::MVT&,
llvm::MVT&> (invoke.h:96)
==2738==by 0x1810FF: __call (functional:495)
==2738==by 0x1810FF: operator() (functional:580)
==2738==by 0x1810FF: bool
berase_if)> >(llvm::MachineValueTypeSet&,
std::_Bind)>) (CodeGenDAGPatterns.cpp:59)
==2738==by 0x19919B:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool) [clone .part.0] (CodeGenDAGPatterns.cpp:580)
==2738==by 0x1A4013: ApplyTypeConstraint (CodeGenDAGPatterns.cpp:1641)
==2738==by 0x1A4013: ApplyTypeConstraints (CodeGenDAGPatterns.h:1269)
==2738==by 0x1A4013:
llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool)
(CodeGenDAGPatterns.cpp:2564)
==2738==by 0x1A4DFB:
llvm::TreePattern::InferAllTypes(llvm::StringMap, llvm::MallocAllocator> const*) (CodeGenDAGPatterns.cpp:3094)
==2738==by 0x1AE02F: llvm::CodeGenDAGPatterns::ParsePatternFragments(bool)
(CodeGenDAGPatterns.cpp:3352)
==2738==by 0x1AE893:
llvm::CodeGenDAGPatterns::CodeGenDAGPatterns(llvm::RecordKeeper&,
std::function) (CodeGenDAGPatterns.cpp:3195)
==2738==by 0x2CF00B: GlobalISelEmitter (GlobalISelEmitter.cpp:3809)
==2738==by 0x2CF00B: llvm::EmitGlobalISel(llvm::RecordKeeper&,
llvm::raw_ostream&) (GlobalISelEmitter.cpp:6312)
==2738==by 0x352E1F: (anonymous
namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&)
(TableGen.cpp:251)
==2738==by 0x3E8447: llvm::TableGenMain(char const*, bool
(*)(llvm::raw_ostream&, llvm::RecordKeeper&)) (Main.cpp:122)
==2738==by 0x134BD7: main (TableGen.cpp:296)
(and a few similar diagnostics)
these do not happen on x86 and there seems to be no conditional compilation.
I'll try to finish up a reduction soon, but I've been swamped as of late. I
have a reduction that deoptimized most code, leaving us with just a few
functions still being optimized, while still reproducing the bug, so that might
shed some light too.
presuming that some bit of GCC decided to remove a store that'd initialize
those values, any hint on how to see what?
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #26 from Martin Uecker --- I would be nice to have a way to avoid executable code while still being able to use this feature (which is useful!).
[Bug libgcc/109852] New: Making of gcc13 stops at libcpp/charset.cc with Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 Bug ID: 109852 Summary: Making of gcc13 stops at libcpp/charset.cc with Error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: ferdasi at opentrash dot com Target Milestone: --- After git pull make configure: configure --prefix=/home//software/gccinstall --disable-multilib Processor Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz uname -a Linux fedora 6.2.13-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 26 20:15:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux the production of gcc stoped after errors: ehome//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/xg++ -B/home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/ -B/home//software/gcccinstall/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home//software/gcc13/libstdc++-v3/libsupc++ -L/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -march=native -O3 -Wall -Wextra -g -O2 -fno-checking -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -march=native -O3 -Wall -Wextra-c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../.././libcpp/charset.cc In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 16 bytes into a region of size 6 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../.././libcpp/charset.cc:1747:9: note: at offset [3, 6] into destination object ‘buf’ of size 6 ../.././libcpp/charset.cc:1747:9: note: at offset 35 into destination object ‘buf’ of size 6 In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../.././libcpp/charset.cc:1747:9: note: at offset 36 into destination object ‘buf’ of size 6 1747 | uchar buf[6]; | ^~~ ../.././libcpp/charset.cc:1747:9: note: at offset [4, 6] into destination object ‘buf’ of size 6 ../.././libcpp/charset.cc:1747:9: note: at offset 36 into destination object ‘buf’ of size 6 In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter,
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #5 from Jan Hubicka --- > Actually why didn't we copy the loop header in the first place? Because it is considered to be do-while loop already (thanks to the in-loop conitional, do_while_loop_p is happy).
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #4 from Jan Hubicka --- > Rather, because store-motion out of a loop that might iterate zero times would > create a data race. Good point. If we did copy loop headers all the way to the store the problem will go away. Also I assume we can still add a flag which is set to true if loops iterates and then make store conditional...
