[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 --- Comment #9 from Jeffrey A. Law --- Yea, I think so -- which would be undefined because the sizes are different according to the docs you referenced. Which would also invalidate part of my responses in c#5 and c#7. It sounds like something ought to be checking the constraint that the input and output must have the same size.
[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #57 from Jeffrey A. Law ---
Below is a POC for improving the uninit analysis to handle this kind of case.
It's not complete. In particular it does not ensure that the we have the same
result on the RHS and LHS of the V_C_E. Basically I'm just showing where/how
we could look through a V_C_E to determine that the use is properly guarded.
+ /* If FLAG_DEF is a V_C_E, then we can look through it.
+The trick is to know when the V_C_E doesn't change the
+value, which isn't validated yet. */
+ if (is_gimple_assign (*flag_def)
+ && gimple_assign_rhs_code (*flag_def) == VIEW_CONVERT_EXPR)
+ {
+ tree rhs = gimple_assign_rhs1 (*flag_def);
+ rhs = TREE_OPERAND (rhs, 0);
+ if (TREE_CODE (rhs) == SSA_NAME)
+ {
+ if ((*flag_def = SSA_NAME_DEF_STMT (rhs)) == NULL)
+ continue;
+ }
+ }
[Bug middle-end/87489] [8/9/10/11 Regression] Spurious -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489 Jeffrey A. Law changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |law at gcc dot gnu.org Target Milestone|11.0|12.0 --- Comment #15 from Jeffrey A. Law --- I'm explicitly pushing this out of gcc-11. As I've mentioned in the thread for Martin's patch, reordering passes is generally not the right approach to solving most issues. I've got a proof-of-concept improvement to the jump threader that nearly catches this case that I'm attaching to this case so it doesn't get lost. The most important missing bit in that patch is when we have two statements in a block that must be considered, it gives up. While that was a reasonable limitation in the past, it's one we need to fix anyway and this BZ is a good motivator. While I'm confident that could be fixed and that we'd handle this issue, I'm not comfortable dropping in improvements like this into gcc-11 at this stage. Hence the explicit deferment to gcc-12.
[Bug tree-optimization/86010] [8 Regression] redundant memset with smaller size not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010 --- Comment #14 from Jeffrey A. Law --- I believe it's still an issue for gcc-8
[Bug tree-optimization/92539] [8/9/10/11 Regression] -Warray-bounds false positive with -O3 (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539 --- Comment #6 from Jeffrey A. Law --- I wonder if we're looking at this the wrong way. We have several blocks with this kind of structure: [local count: 30530247]: if (last_12 != [(void *)"aa" + 3B]) goto ; [54.59%] else goto ; [45.41%] The key point being that the RHS of the conditional is a bogus pointer. Nothing can ever be equal to that pointer. So we should be able to determine the result of the conditional in all those blocks. I suspect that alone is sufficient to make the false positive go away.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 --- Comment #6 from Jeffrey A. Law --- Duh. I should have seen the reinterpret_cast as a red flag on this one. And not surprising -fno-strict-aliasing makes the glm testsuite happy. Sorry for the noise.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #38 from Jeffrey A. Law --- sparc might be able to trip this.
[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- What about fixing the -g interaction? Much like how -g shouldn't affect code generation, it probably shouldn't be affecting warnings like this. There may be more we can/should do here, but that seems like a good place to start.
[Bug ipa/98594] New: [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
Bug ID: 98594
Summary: [11 Regression] IPA modref codegen bug
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: s390x
Created attachment 49917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49917=edit
Hacked up/reduced testcase
The "glm" package on s390x fails to build on s390x due to what appears to be a
bug in the IPA modref changes. Specifically:
commit 67a5c215940f4b21bac1aa489ce1f2fb3d52a53a
Author: Jan Hubicka
Date: Sat Sep 26 00:01:57 2020 +0200
Fix gimple_clobber handling in ipa-modref
2020-09-25 Jan Hubicka
* ipa-modref.c (analyze_stmt): Fix return value for
gimple_clobber.
But I suspect this is just exposing a bug elsewhere in the modref support.
Before early inlining we have:
int bitCount::test ()
{
int _1;
int _2;
int _3;
bool _4;
int _7;
int _8;
:
_1 = 1;
_2 = 1;
_7 = bitCount::bitCount_bitfield (_2);
_3 = _7;
_4 = _1 == _3;
_8 = (int) _4;
return _8;
}
Nothing really interesting there. THe called function looks like:
;; Function bitCount::bitCount_bitfield
(_ZN8bitCountL17bitCount_bitfieldIiEEiT_, funcdef_no=13, decl_uid=3087,
cgraph_uid=2, symbol_order=4)
Analyzing function body size: int bitCount::bitCount_bitfield(genType)
[with genType = int]/4
int bitCount::bitCount_bitfield (int x)
{
struct vec D.3185;
struct vec D.3199;
int _5;
:
glm::vec<1, int, glm::packed_highp>::vec (, x_2(D));
D.3199 = bitCount::bitCount_bitfield<1, int, glm::packed_highp>
(); [return slot optimization]
_5 = D.3199.D.3097.x;
D.3199 ={v} {CLOBBER};
D.3185 ={v} {CLOBBER};
return _5;
}
The most important thing to note here is that the local variable D.3185
and the parameter X get passed to the glm::vec constructor. D.3185 then
gets passed to an overload of bitCount::bitCount_bitfield.
The constructor looks like:
;; Function glm::vec<1, int, glm::packed_highp>::vec
(_ZN3glm3vecILi1EiLNS_9qualifierE0EEC1Ei, funcdef_no=16, decl_uid=3159,
cgraph_uid=5, symbol_order=7)
void glm::vec<1, int, glm::packed_highp>::vec (struct vec * const this,
int scalar)
{
:
*this_2(D) ={v} {CLOBBER};
this_2(D)->D.3097.x = scalar_4(D);
return;
}
So we take the 2nd argument and stuff it into a field within the first
argument. This all looks good. Now we look at the
bitCount::bitCount_bitfield overload (edited for brevity):
;; Function bitCount::bitCount_bitfield<1, int, glm::packed_highp>
(_ZN8bitCountL17bitCount_bitfieldILi1EiLN3glm9qualifierE0EEENS1_3vecIXT_EiXT1_EEERKNS3_IXT_ET0_XT1_EEE,
funcdef_no=17, decl_uid=3197, cgraph_uid=6, symbol_order=8)
struct vec bitCount::bitCount_bitfield<1, int, glm::packed_highp> (const
struct vec & v)
{
struct vec x;
:
x = MEM[(const struct vec &)v_2(D)];
x = bitCount::compute_bitfieldBitCountStep::call<1, unsigned
int, glm::packed_highp> (, 1431655765, 1);
x = bitCount::compute_bitfieldBitCountStep::call<1, unsigned
int, glm::packed_highp> (, 858993459, 2);
x = bitCount::compute_bitfieldBitCountStep::call<1, unsigned
int, glm::packed_highp> (, 252645135, 4);
glm::vec<1, int, glm::packed_highp>::vec (&, );
x ={v} {CLOBBER};
return ;
}
So note the first real statement. That's going to read the data that
was put into the vec node by the constructor. All good.
Now in the .einline dump things have gone to hell.
;; Function bitCount::test (_ZN8bitCount4testEv, funcdef_no=12,
decl_uid=3085, cgraph_uid=1, symbol_order=3)
Iterations: 1
Symbols to be put in SSA form
{ D.3471 D.3522 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 5
Number of blocks to update: 4 ( 80%)
Merging blocks 2 and 4
Merging blocks 2 and 3
int bitCount::test ()
{
struct vec D.3524;
struct vec D.3523;
int D.3522;
int _1;
int _2;
int _3;
bool _4;
int _6;
int _7;
int _8;
:
_1 = 1;
_2 = 1;
D.3524 = bitCount::bitCount_bitfield<1, int, glm::packed_highp>
(); [return slot optimization]
_6 = D.3524.D.3097.x;
D.3524 ={v} {CLOBBER};
D.3523 ={v} {CLOBBER};
_12 = _6;
_7 = _12;
_3 = _7;
_4 = _1 == _3;
_8 = (int) _4;
return _8;
}
Note we pass D.3523 to the bitCount_bitfield overload, but we've lost
the statement that initialized its data field. Naturally the overload
still loads that (now uninitialized) field and we get garbage data and
the testsuite fails miserably. FUrthermore, we get an uninitalized
warning (perhaps your subsequent uninit changes were papering over this
problem to some degree).
You should be able to see this with an s390x cross compiler with -O2.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #18 from Jeffrey A. Law --- Jon, there's no way for the optimizers to improve the to_derived_bad case as there's nothing in the IL after we leave the front-end that's useful. In the .original dump we have: ;; Function derived& to_derived_bad(base2*) (null) ;; enabled by -tree-original return = b != 0B ? (struct derived &) b + 18446744073709551612 : 0; There's just nothing the optimizers can do with that. The front-end would have to provide more information or remove the check itself (as is done for the to_derived_good case which has this .original dump): ;; Function derived& to_derived_good(base2*) (null) ;; enabled by -tree-original return = (struct derived &) NON_LVALUE_EXPR + 18446744073709551612;
[Bug target/98585] New: [11 Regression] target attribute resets cmodel on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98585
Bug ID: 98585
Summary: [11 Regression] target attribute resets cmodel on x86
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
CC: hjl.tools at gmail dot com, jakub at redhat dot com
Target Milestone: ---
Using the "target" attribute on x86 causes a reset of the cmodel from the
command line.
Compile this testcase with -mcmodel-large with gcc-10. You will see that we
use movabsq to load the address of "bar" into a register and use an indirect
jump. With gcc-11 we make a direct jump/call. This causes grub2 to FTBFS in
Fedora rawhide and RHEL 9.
This appears to be caused by ba948b37768c99cd8eb9f5b6fbd45fcf4bd15b78
void bar (void);
void
__attribute__ ((target ("bmi2")))
foo()
{
bar ();
}
[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Jeffrey A. Law --- I've been able to reproduce this. It's either the enabling jit or host shared libraries (which is required to enable jit). It's faulting in the escaped string tests which makes sense given John's bisection info. I'm debugging in the background as this isn't anywhere near the top of my todo list.
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #12 from Jeffrey A. Law --- On 12/30/20 10:30 AM, glaubitz at physik dot fu-berlin.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 > > --- Comment #11 from John Paul Adrian Glaubitz fu-berlin.de> --- > (In reply to Jeffrey A. Law from comment #10) >> So if that bisection is accurate, the only way this could be failing would >> be if something with a deprecated attribute is being used. >> >> Maybe some printfs in warn_deprecated_use? But again, I'm a bit surprised >> by the bisection results. > I have verified it. I checked out eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3, > reproduced the problem. Then reverted the change and it worked again. > > I honestly don't understand either how that commit could break the build. > >> http://3.14.90.209:8080/job/m68k-linux-gnu/ >> >> Has the most recent build results from my tester. As you can see everything >> built and regression tested on Dec 9. Dec 15 had a successful bootstrap, >> but glibc failed due to a relatively minor bug in glibc. > Is that a native bootstrap on qemu with "jit" enabled? native bootstrap with qemu. Don't offhand remember if jit is enabled. If not I can probably turn that on for the next one. jeff
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #10 from Jeffrey A. Law --- So if that bisection is accurate, the only way this could be failing would be if something with a deprecated attribute is being used. Maybe some printfs in warn_deprecated_use? But again, I'm a bit surprised by the bisection results. http://3.14.90.209:8080/job/m68k-linux-gnu/ Has the most recent build results from my tester. As you can see everything built and regression tested on Dec 9. Dec 15 had a successful bootstrap, but glibc failed due to a relatively minor bug in glibc.
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 --- Comment #7 from Jeffrey A. Law --- If you're V_C_E-ing to a narrower type, you just ignore the bits outside the target type, it's a lot like a narrowing subreg in the RTL world. I don't know what the semantics are for the widening case. ISTM that it's not really helpful there. At least that's my understanding after discussing pr80635 with Richi.
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 --- Comment #5 from Jeffrey A. Law --- The best way to think about V_C_E is that it's the same bits, just viewed in a different type whereas a cast can do things like sign/zero extension, truncation of floating point values to integers, etc).
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96708, which changed state. Bug 96708 Summary: Failure to optimize max pattern with comparison when using a temporary variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96708 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96708] Failure to optimize max pattern with comparison when using a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96708 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jeffrey A. Law --- Should be fixed with Eugene's patch on the trunk
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96679, which changed state. Bug 96679 Summary: Failure to optimize or+and+or pattern to and+or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96679] Failure to optimize or+and+or pattern to and+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jeffrey A. Law --- Should be fixed with Eugene's patch on the trunk.
[Bug target/97928] -fstack-clash-protection probe miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97928 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- I took a peek when Serge pointed me at the issue. I think there's a window where a signal handler could clash. It'd be hard to exploit, but we should fix it. It's on my TODO list.
[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #55 from Jeffrey A. Law --- So to summarize some thoughts from Richi from last year. Converting the V_C_E into a NOP_EXPR is undesirable as the truncation becomes sub-optimal because we end up with an additional masking operation. So the V_C_E is really the right thing. What that implies is that other passes need to get smarter about handling a V_C_E.
[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jeffrey A. Law --- Should be fixed on the trunk now.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 91318, which changed state. Bug 91318 Summary: [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug pch/86674] -W(no)-error=invalid-pch does not affect incorrect language warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86674 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Should be fixed on the trunk
[Bug middle-end/97804] ICE in output_constructor_register_field varasm.c:5407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97804 --- Comment #1 from Jeffrey A. Law --- Created attachment 49550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49550=edit Testcase
[Bug middle-end/97804] New: ICE in output_constructor_register_field varasm.c:5407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97804 Bug ID: 97804 Summary: ICE in output_constructor_register_field varasm.c:5407 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: law at redhat dot com Target Milestone: --- Trunk as of 5d46ec3db21d8c8926f15a634b2d6570536db5f1 faults compiling the attached code with -O2 -std=c++17 on x86_64: ./cc1plus -O2 -std=c++17 FreeLookCamera.cpp.ii -quiet -w /builddir/build/BUILD/dolphin-31524288e3b2450eaefff8202c6d26c4ba3f7333/Source/Core/VideoCommon/FreeLookCamera.cpp:305:1: internal compiler error: in output_constructor_regular_field, at varasm.c:5407 0x1bd1821 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5407 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bd1b62 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5446 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bd1b62 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5446 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bd1b62 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5446 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bd1b62 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5446 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bd1b62 output_constructor_regular_field /home/gcc/gcc/gcc/varasm.c:5446 0x1bd2742 output_constructor /home/gcc/gcc/gcc/varasm.c:5713 0x1bd0ed0 output_constant /home/gcc/gcc/gcc/varasm.c:5222 0x1bc6059 assemble_variable_contents /home/gcc/gcc/gcc/varasm.c:2128 0x1bc6afc assemble_variable(tree_node*, int, int, int) /home/gcc/gcc/gcc/varasm.c:2307 I haven't tried to reproduce or bisect. However, I would assume is likely a regression.
[Bug tree-optimization/97108] Wmaybe-uninitialized false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-06 --- Comment #1 from Jeffrey A. Law --- So the key to this testcase is the merge points. After some slight simplifications to the test we have the following key blocks: ;; basic block 2, loop depth 0, count 1073741823 (estimated locally), maybe hot ;;prev block 0, next block 3, flags: (NEW, VISITED) ;;pred: ENTRY [always] count:1073741823 (estimated locally) (FALLTHRU,EXECUTABLE) if (flags_8(D) == 0) goto ; [50.00%] else goto ; [50.00%] ;;succ: 5 [50.0% (guessed)] count:536870912 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;3 [50.0% (guessed)] count:536870912 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 3, loop depth 0, count 536870912 (estimated locally), maybe hot ;;prev block 2, next block 4, flags: (NEW, VISITED) ;;pred: 2 [50.0% (guessed)] count:536870912 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (flags_8(D) != -1) goto ; [32.00%] else goto ; [68.00%] ;;succ: 5 [32.0% (guessed)] count:171798688 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;4 [68.0% (guessed)] count:365072224 (estimated locally) (FALSE_VALUE,EXECUTABLE) [ ... ] ;; basic block 5, loop depth 0, count 708669600 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, VISITED) ;;pred: 2 [50.0% (guessed)] count:536870912 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;3 [32.0% (guessed)] count:171798688 (estimated locally) (TRUE_VALUE,EXECUTABLE) # orig_err_26 = PHI if (in_12(D) != 0) goto ; [33.00%] else goto ; [67.00%] ;;succ: 6 [33.0% (guessed)] count:233860967 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;7 [67.0% (guessed)] count:474808633 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 6, loop depth 0, count 233860966 (estimated locally), maybe hot ;;prev block 5, next block 7, flags: (NEW, VISITED) ;;pred: 5 [33.0% (guessed)] count:233860967 (estimated locally) (TRUE_VALUE,EXECUTABLE) _close (in_12(D)); ;;succ: 7 [always] count:233860966 (estimated locally) (FALLTHRU,EXECUTABLE) ;; basic block 7, loop depth 0, count 708669601 (estimated locally), maybe hot ;;prev block 6, next block 8, flags: (NEW, VISITED) ;;pred: 6 [always] count:233860966 (estimated locally) (FALLTHRU,EXECUTABLE) ;;5 [67.0% (guessed)] count:474808633 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (out_14(D) != 1) goto ; [48.88%] else goto ; [51.12%] ;;succ: 8 [48.9% (guessed)] count:346397699 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;9 [51.1% (guessed)] count:362271902 (estimated locally) (FALSE_VALUE,EXECUTABLE) Of particular note is that because BB2 and BB3 both reach BB5 we don't really have any useful information about FLAGS.The threader does know how to look through a join point like that, but it then runs into another at BB7 at which point it gives up. The backwards threader probably could be made to detect this case though. I'm pretty sure we're not raising queries for COND_EXPRs on the RHS of a statement, just for GIMPLE_COND statements. So this block: ;; basic block 9, loop depth 0, count 708669601 (estimated locally), maybe hot ;;prev block 8, next block 10, flags: (NEW, VISITED) ;;pred: 8 [always] count:346397698 (estimated locally) (FALLTHRU,EXECUTABLE) ;;7 [51.1% (guessed)] count:362271902 (estimated locally) (FALSE_VALUE,EXECUTABLE) _2 = orig_err_26 != 2; _1 = flags_8(D) == 0; _3 = _2 & _1; if (_3 != 0) goto ; [33.00%] else goto ; [67.00%] We don't raise a query for flags_8. The backwards threader also doesn't know how to imply a range from anything other than assignments. So the conditionals involving flags_8 aren't helpful. This is something we're going to want to tackle with ranger integration into the backwards threader. SO think we keep this as an open BZ until that's addressed.
[Bug libgcc/96948] _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jeffrey A. Law --- Should be fixed on trunk now.
[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- Should be fixed on trunk now
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96701, which changed state. Bug 96701 Summary: Failure to optimize self right-shift to 0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96701 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96701] Failure to optimize self right-shift to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96701 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jeffrey A. Law --- Fixed by Eugene's patch on the trunk.
[Bug target/96939] LTO vs. different arm arch options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #1 from Jeffrey A. Law --- I suspect this is the same thing we're seeing with the dozen or so armv7/NEON failures with LTO in Fedora. It was on my list to reduce, but hadn't gotten to it yet.
[Bug c/96407] LTO inlined functions don't inherit disabled warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2020-08-01 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com CC||law at redhat dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug middle-end/96397] New: GCC Fails to exploit ranges from overflow tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397
Bug ID: 96397
Summary: GCC Fails to exploit ranges from overflow tests
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Compile with -O2. We should be able to eliminate the x > p1 test if we were
smart about back propagating equivalences to generate a range from the
__builtin_add_overflow.
This was derived from a bogus warning in tpm2-pkcs11's testsuite.
#include
#include
extern void frob (void);
void
foo(size_t p1)
{
size_t x = p1 - 4;
size_t y;
if (__builtin_add_overflow (x, 8, ))
{
frob ();
}
else
{
if (x > p1)
abort ();
}
}
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #35 from Jeffrey A. Law --- That's a reasonable idea Eric -- the barriers are primarily there for the benefit of CFG building and manipulation and thus provide marginal, if any, benefit once we hit the reorg pass. I recall 81025 being particularly difficult to reproduce, but once understood it was pretty obvious what was going on. We could certainly look at your idea and see how it interacts with shrink-wrapping and the dwarf bits. I don't mind putting it on my todo list, but it's likely stage3 before I'd be able to reasonably look at it.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #33 from Jeffrey A. Law --- Have I mentioned before that I think __builtin_unreachable is fundamentally broken/wrong :-) I could argue that the BARRIER in the IL is wrong because it doesn't actually line up with the semantics of the instruction stream. But that's probably a losing battle with those who think that __builtin_unreachable's current behavior is sensible. One thought would be to turn a conditional jump followed by a barrier into an unconditional jump in jump.c. But I fear that just papers over the problem and that we'd see the same issue raise its head again in a slightly perturbed form that wasn't recognized by jump.c, but tripped the same code as we have now in reorg.c. Another thought would be to detect this in relax_delay_slots and twiddle the transformation to avoid the problematic behavior. I think we could detect just by seeing if there's a barrier after INSN in the same hunk of code that Eric quoted and changing the behavior slightly when that's detected. I hate special casing things like that and there's a reasonable chance other parts of GCC are affected by the same problem. That may argue for implementing both approaches. But I'd really just like to change how __builtin_unreachable works. Eric, thoughts? jeff
[Bug tree-optimization/94882] Failure to optimize and+or+sub into xor+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94882 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jeffrey A. Law --- This should be fixed on the trunk now.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #13 from Jeffrey A. Law --- Hmm, there's a control dependency though in bb13: [local count: 242478389]: # result_21 = PHI <1(5), sign_17(6)> switch (op_14(D)) [33.33%], case 0: [16.67%], case 1: [50.00%], case 3: [50.00%], case 5: [50.00%]> } So I'd hazard a guess that sign_17 either has the value 1 here or that result_21 is unused, otherwise you're right that cddce shouldn't remove the block.
[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #12 from Jeffrey A. Law --- The block in question goes away because it serves no purpose: [local count: 242478389]: _13 = *self_11(D); _16 = *other_12(D); sign_17 = _13 - _16; if (sign_17 == 0) goto ; [34.00%] else goto ; [66.00%] [local count: 160035736]: goto ; [100.00%] Note that bb6 just transfers control to bb13 with no other side effects. As a result bb5 is equivalent to: [local count: 242478389]: _13 = *self_11(D); _16 = *other_12(D); sign_17 = _13 - _16; if (sign_17 == 0) goto ; [34.00%] else goto ; [66.00%] With both arms of the conditional going to the same place and no other uses of sign_17 the whole block just turns into goto ; I see nothing wrong with what was done by DCE. The problem must be earlier in the optimizer pipeline.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #14 from Jeffrey A. Law --- The reason for turning the dereference into a trap is because we can clean up ancillary computations -- the address computation, the RHS of a store, and the like via standard dead code elimination algorithms.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 --- Comment #13 from Jeffrey A. Law --- Marc, Yes, absolutely. In fact, I think that falls out of the work Martin S is doing in this space. Conceptually we're looking to generalize that code so that we can route more cases where the compiler detects undefined behavior through the path isolation routines. Within those commonized routines we want to have a knob which selects different behavior from the compiler when undefined behavior is detected which could potentially include issuing the RTL equivalent of __builtin_unreachable vs trap vs warn, but leave the code alone, try to mitigate, etc. Where I think we've differed in the past is what to do with conditional branch upon which the undefined behavior is control dependent upon. As you may remember, the original submission of path isolation would turn that conditional into an unconditional branch to the valid path. That's not correct because there can be observable behavior that occurs on the path from the conditional, but before the undefined behavior triggers. Having a knob to twiddle *that* may or may not be a good idea.
[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- trap is much stronger than an unreachable. If you hit a gcc_unreachable location at runtime, execution just continues onward with no indication something terrible has happened. It's literally just a marker in our IL and results in no generated code. I think it's fundamentally broken from a security standpoint. __builtin_trap emits an actual trap into the instruction stream which halts the process immediately which is *much* better from a security standpoint
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #6 from Jeffrey A. Law --- That's an indication that something has tried to do an out of bounds read on a VEC object. The call chain points back to the initial quick_grow of an auto_vec from test_vector_cst_patterns -- which is wildly surprising. In fact if it were that broken I would fully expect other configurations, including x86_64 to be failing miserably. We're not seeing that. I would also expect that we could see the failure with a cross compiler, but that seems to be working fine as well. There's a nonzero chance this is actually a bug in the bootstrap compiler, particularly if it's happening in the stage1 build.
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 --- Comment #8 from Jeffrey A. Law --- I still don't understand why propagating one SSA_NAME for another is causing headaches later though. I don't see anything fundamentally wrong with your patch and it restores previous behavior since singleton_p would only be true for a constant, so consider it pre-approved.
[Bug tree-optimization/95649] [11 Regression] ICE during GIMPLE pass: cunroll since r11-1146-g1396fa5b91cfa0b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- What precisely is causing the problem? Are we doing something like mucking up the loop closed ssa form? Or do these passes have internal data that's invalidated by the PHI changes? Or something else? Hard to know what to recommend here without more info.
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law --- FWIW, I bootstrapped m68k within qemu on May30 with no testsuite regressions. Jun 6 also bootstrapped, but with some regressions with -fprofile-generate. So clearly you're builds are doing something different than mine. What Richi is asking for is a backtrace from the compiler itself. Without that or some way to reproduce the problem, then there's not much we can do.
[Bug middle-end/95309] New: [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309
Bug ID: 95309
Summary: [11 Regression] Many targets failing ssa-dom-cse-2.c
after vectorizer changes
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Various ports have regressed the tree-ssa/ssa-dom-cse-2.c after this change:
commit a4b48fc47c3406b6f41be093c4615879b7006710
Author: Richard Biener
Date: Mon May 18 16:05:00 2020 +0200
cost invariant nodes from vect_slp_analyze_node_operations SLP walk
2020-05-19 Richard Biener
* tree-vectorizer.h (_slp_tree::vectype): Add field.
(SLP_TREE_VECTYPE): New.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_VECTYPE.
(vect_create_new_slp_node): Likewise.
(vect_prologue_cost_for_slp): Move here from tree-vect-stmts.c
and simplify.
(vect_slp_analyze_node_operations): Walk nodes children for
invariant costing.
(vect_get_constant_vectors): Use local scope op variable.
* tree-vect-stmts.c (vect_prologue_cost_for_slp_op): Remove here.
(vect_model_simple_cost): Adjust.
(vect_model_store_cost): Likewise.
(vectorizable_store): Likewise.
You should be able to see this on the iq2000-elf port (and many others).
I believe the test is supposed to verify that we're able to determine the
return
value statically after unrolling the loop. It's unclear if the stores get in
the
way of cse-ing the assignment to _22 and _29 in the dump or if there's
something
else going on:
MEM[(int *)] = { 0 };
MEM[(int *) + 4B] = { 1 };
MEM[(int *) + 8B] = { 2 };
MEM[(int *) + 12B] = { 3 };
MEM[(int *) + 16B] = { 4 };
MEM[(int *) + 20B] = { 5 };
MEM[(int *) + 24B] = { 6 };
MEM[(int *) + 28B] = { 7 };
_22 = a[0];
_29 = a[1];
sum_30 = _22 + _29;
_36 = a[2];
sum_37 = sum_30 + _36;
_43 = a[3];
sum_44 = sum_37 + _43;
_50 = a[4];
sum_51 = sum_44 + _50;
_57 = a[5];
sum_58 = sum_51 + _57;
_64 = a[6];
sum_65 = sum_58 + _64;
_1 = a[7];
sum_16 = _1 + sum_65;
a ={v} {CLOBBER};
return sum_16;
[Bug target/95218] [11 Regression] FAIL: gcc.target/i386/fma_run_double_1.c execution test since r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #16 from Jeffrey A. Law ---
A "naked" use as an INSN should only occur inside the pattern of an insn (there
are exceptins that exist internally within reload and delay slot scheduling).
It's only supposed to be used to mark that a particular object is live and used
by the insn. I'll note the following:
...
This means that @code{use} can @emph{only} be used to describe
that the register is live. You should think twice before adding
@code{use} statements, more often you will want to use @code{unspec}
instead. The @code{use} RTX is most commonly useful to describe that
a fixed register is implicitly used in an insn. It is also safe to use
in patterns where the compiler knows for other reasons that the result
of the whole pattern is variable, such as @samp{cpymem@var{m}} or
@samp{call} patterns.
I think one could reasonably think that we should support (use (mem)) with the
same semantics -- it means that the value in memory is used which is helpful in
dependency tracking.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law --- I can't see how a REG_EQUAL note on an insn with multiple outputs can possibly work -- we wouldn't know what output the REG_EQUAL note refers to. And we have to consider an embedded side effect as having an output. Or to think of it another way, any embedded side effect can be implemented with a parallel at which point it's painfully obvious the insn has multiple outputs and a REG_EQUAL note would be inappropriate.
[Bug middle-end/91146] [9/10 Regression] -Werror=array-bounds if compile with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91146 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P2
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #6 from Jeffrey A. Law --- THe whole point of that change is to not require a dominating load if the object comes from the stack. We conditionally load from the same location, then have a PHI which selects that loaded value or "1" and we store the result. That's precisely what is supposed to be happening. The loop in question looks like: ;; basic block 3, loop depth 1 ;;pred: 2 ;;6 # ivtmp.13_9 = PHI <0(2), ivtmp.13_7(6)> _4 = MEM[base: in_21(D), index: ivtmp.13_9, step: 8, offset: 0B]; if (_4 == 0B) goto ; [5.50%] else goto ; [94.50%] ;;succ: 13 ;;4 ;; basic block 4, loop depth 1 ;;pred: 3 if (ivtmp.13_9 != 2) goto ; [28.10%] else goto ; [71.90%] ;;succ: 6 ;;5 ;; basic block 5, loop depth 1 ;;pred: 4 cstore_32 = MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B]; ;;succ: 6 ;; basic block 6, loop depth 1 ;;pred: 5 ;;4 # cstore_31 = PHI MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B] = cstore_31; _40 = (unsigned int) ivtmp.13_9; _38 = _40 + 1; _37 = (int) _38; ivtmp.13_7 = ivtmp.13_9 + 1; sum_a_27 = (int) ivtmp.13_7; if (n_16(D) > sum_a_27) goto ; [94.50%] else goto ; [5.50%] ;;succ: 3 ;;7 You can see the load from the same stock slot in bb5, the selecting PHI in bb6 and the store in bb6. THe test in bb4 looks weird and is the source of the problem I believe.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Looks like we're running past the end of the array with the stores in the loop.
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
--- Comment #7 from Jeffrey A. Law ---
So I first took a clean RHEL 8.1 system with kernel-4.18.0-147 and verified
that this simple stap script would fail:
stap -p4 -e 'probe module("nfsv3").function("nfs3_commit_done") {
println($task) }'
Which barfs with something like this output:
semantic error: failed to retrieve location attribute for 'task' [man
error::dwarf]: identifier '$task' at :1:62
dieoffset: 0x8068a from
/usr/lib/debug/lib/modules/4.18.0-105.el8.x86_64/kernel/fs/nfs/nfsv3.ko.debug
function: nfs3_commit_done at fs/nfs/nfs3proc.c:847:2 inlined by
nfs3_commit_done at fs/nfs/nfs3proc.c:840:12
source: probe module("nfsv3").function("nfs3_commit_done") {
println($task) }
I then rebuilt/reinstalled GCC with the patch in c#3, then rebuilt the kernel
with the updated GCC.
The simple stap script above is handled without error (generates a suitable .ko
file).
So it definitely helps. Richi, do you want to move forward with this?
[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- I'll see if if the proposed solution makes a difference for the case that was originally filed against stap.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 Jeffrey A. Law changed: What|Removed |Added CC||drahflow at gmx dot de --- Comment #13 from Jeffrey A. Law --- *** Bug 94655 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 94655, which changed state. Bug 94655 Summary: [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- Fundamentally if we're relying on the type of the MEM_REF, then we're going to run into problems. It simply does not map back to what the user originally wrote. That's the key issue Richi and Jakub are raising. pr94675 is another recently reported example. In that case as well FRE creates a MEM_REF from address arithmetic, but the type isn't useful and leads to a false positive out of bounds array warning. Forwprop can do this stuff as well, and I suspect if we were to dig elsewhere we'd find more examples. While I don't want to lose these warnings, they are proving problematical in the MEM_REF cases and I'm wondering if we need a distinct knob to disable them in the MEM_REF cases given the fundamental incompatibility between giving good diagnostics and the actions of various optimization passes. In the immediate term I'm going to mark this as a dup of 94675 (and any others I encounter in my BZ wanderings). *** This bug has been marked as a duplicate of bug 94675 ***
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Milestone|8.5 |11.0
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 Jeffrey A. Law changed: What|Removed |Added Target Milestone|8.5 |11.0 CC||law at redhat dot com
[Bug libstdc++/85145] [8/9/10 Regression] include_next broken icw/ --with-gxx-include-dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85145 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Milestone|10.0|11.0
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/69543] [8/9/10 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 Jeffrey A. Law changed: What|Removed |Added Target Milestone|8.5 |11.0
[Bug lto/94659] [8/9/10 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 Jeffrey A. Law changed: What|Removed |Added Priority|P2 |P3 --- Comment #4 from Jeffrey A. Law --- Whoops. Didn't mean to change the priority on this BZ.
[Bug lto/94659] [8/9/10 Regression] Missing symbol with LTO and target_clones since r8-1461-g871cc215f7507cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P2
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #12 from Jeffrey A. Law --- SO it's not terrible to get the key block cleaned up. but that's not sufficient to resolve this issue. We all missed an important tidbit. VRP is complaining about this: ps.D.2041.s = [(void *) + 7B]; Note the object we reference in the expression, "c". "c" is a byte: typedef unsigned char byte; byte c; One could argue the problem is FRE. Prior to fre3 we had: ;; basic block 9, loop depth 0 ;;pred: 7 _34 = ps.D.2041.s; _35 = _34 + 7; ps.D.2041.s = _35; fre3 turns that into: ps.D.2041.s = [(void *) + 7B]; And we're going to lose. One could also argue that the warning has to be tolerant of these actions from FRE. The question would be how to do that without totally compromising the warning.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #9 from Jeffrey A. Law --- Yea, unrolling and the array-bounds warning do have bad interactions. I suspect if we cleaned up this block that the backwards threader would likely kick in: # iftmp.2_18 = PHI <1(3), 1(4), 0(5)> _19 = (_Bool) iftmp.2_18; _2 = ~_19; _3 = (long int) _2; _4 = __builtin_expect (_3, 0); if (_4 == 0) goto ; [INV] else goto ; [INV] I'll play with that and see if there's something we can do cleanly early enough to matter.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- Backwards jump threading (where we'd like to handle this) doesn't handle the cast assignment (and assignments in general). I've hesitated adding this capability because it'll duplicate a lot of the work done by Ranger. So the threadable path is left in the IL when VRP1 runs, thus generating the false positive. I'd really like to see those warnings move out of VRP, or at least deferred until VRP2 where the dead paths have been cleaned up.
[Bug rtl-optimization/92430] [9 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- This was fixed in gcc-9 a few months back.
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466 Bug 19466 depends on bug 15826, which changed state. Bug 15826 Summary: don't use "if" to extract a single bit bit-field. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81601 Resolution|--- |FIXED --- Comment #19 from Jeffrey A. Law --- So the core issue here, using an if, conditional moves and the like to do single bit field extraction/testing is resolved. There is still an issue of canonicalizing the two representations which in turn opens up the possibility of finding more common subexpressions when both forms might be used. That is actually being tracked via pr81601.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 15826, which changed state. Bug 15826 Summary: don't use "if" to extract a single bit bit-field. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 15348, which changed state. Bug 15348 Summary: [tree-ssa] Convert (x < 0) || (y < 0) into (x | y) < 0. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15348 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/15348] [tree-ssa] Convert (x < 0) || (y < 0) into (x | y) < 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15348 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jeffrey A. Law --- Resolved at some point in the past. Not worth the trouble to bisect.
[Bug tree-optimization/92233] missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- Rather than jump threading what I think we want is the ability to note that the two object's values are related. In this specific example, in the THEN arm we know that at least one of them must be zero and thus the result of the multiplication must be zero. This kind of relational tracking is also helpful to jump threading and false positive elimination for the various middle end warnings. There's one or more other BZs which show that, but I don't know their #s offhand.
[Bug rtl-optimization/66087] Invalid narrowing of MEM with containing POST_INC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66087 --- Comment #5 from Jeffrey A. Law --- Interestingly enough it fails in a similar manner with LRA, but I agree that avoiding this earlier in the pipeline is preferable.
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-18 Ever confirmed|0 |1 CC||law at redhat dot com --- Comment #8 from Jeffrey A. Law --- I believe you can see the poor code generation when using the -m5200 option.
[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law --- So what configuration are you using, what options are you using to build your toolchain? I'd like to be able to verify a few things before trying to fix this. This isn't coming up at all in the bootstraps I'm doing for m68k-linux-gnu which are then used to build glibc. So I'm at a bit of a loss for how to reproduce the problem.
[Bug target/21530] libstdc++ not supported on h8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Jeffrey A. Law --- Fixed at some point long ago.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 92893, which changed state. Bug 92893 Summary: [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Jeffrey A. Law --- Ultimately a duplicate of 87296. Both are using the type of _REF which leads to the invalid diagnotics. *** This bug has been marked as a duplicate of bug 87296 ***
[Bug middle-end/87296] [8/9/10 Regression] -Wstringop-overflow false positive due to using MEM_REF type of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296 Jeffrey A. Law changed: What|Removed |Added CC||sbergman at redhat dot com --- Comment #8 from Jeffrey A. Law --- *** Bug 92893 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89550] [8/9/10 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Jeffrey A. Law --- Per c#7 and c#8.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 89550, which changed state. Bug 89550 Summary: [8/9/10 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law --- Yea, I think a NOTE_INSN_DELETED is valid in that location. So yea, using NEXT_INSN is probably wrong and we should be using something else like next_nonnote_insn. My only worry with next_nonnote_insn would be if it skipped something like a block note. What would be the implications for the scheduler if it walked through the various note insns?
[Bug tree-optimization/91384] [8/9/10 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6 from Jeffrey A. Law ---
Couldn't cmpelim realize insn6 sets the condition codes in a useful way in this
RTL:
(insn 29 3 6 2 (set (reg/v:SI 40 r12 [orig:82 ] [82])
(reg/v:SI 5 di [orig:83 a ] [83])) "j.c":9:9 67 {*movsi_internal}
(nil))
(insn 6 29 7 2 (parallel [
(set (reg/v:SI 40 r12 [orig:82 ] [82])
(neg:SI (reg/v:SI 40 r12 [orig:82 ] [82])))
(clobber (reg:CC 17 flags))
]) "j.c":9:9 525 {*negsi2_1}
(nil))
(insn 7 6 8 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 5 di [orig:83 a ] [83])
(const_int 0 [0]))) "j.c":9:6 7 {*cmpsi_ccno_1}
(nil))
(jump_insn 8 7 9 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 13)
(pc))) "j.c":9:6 736 {*jcc}
If we're just interested in CC_Z, then we could use the output of insn 7 rather
than needing a distinct test insn.
[Bug target/91912] [9/10 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91912 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- Fixed by Vlad's LRA work in March.
[Bug tree-optimization/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893 --- Comment #6 from Jeffrey A. Law --- Isn't this ultimately a case of relying on the type information from that MEM expression in a place where it's not valid?
[Bug tree-optimization/93674] [8/9/10 Regression] GCC eliminates conditions it should not, when strict-enums is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jeffrey A. Law --- Should be fixed by the commit referenced in c#15.
[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Should be fixed by the commit referenced in c#1.
[Bug target/94420] [8/9/10 Regression] ICE error: insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jeffrey A. Law --- Commit referenced by c#10 fixed this problem.
[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94440 Jeffrey A. Law changed: What|Removed |Added Target Milestone|8.5 |11.0 CC||law at redhat dot com
[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- per c#7.
[Bug debug/94439] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c: ‘-fcompare-debug’ failure since r10-3499-g0ce77f463d1d150e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk.
[Bug debug/94439] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c: ‘-fcompare-debug’ failure since r10-3499-g0ce77f463d1d150e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439 --- Comment #6 from Jeffrey A. Law --- And has likely been broken since the introduction of VTA if I'm reading the code correctly.
[Bug debug/94439] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c: ‘-fcompare-debug’ failure since r10-3499-g0ce77f463d1d150e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #5 from Jeffrey A. Law --- It looks like things go wrong when walking the regrename chains to find the best renaming possibility.
[Bug debug/94439] [10 Regression] gcc: error: gcc/testsuite/gcc.dg/torture/builtin-complex-1.c: ‘-fcompare-debug’ failure since r10-3499-g0ce77f463d1d150e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law --- I can probably take a stab. It's been a long time since I looked at the scheduler, but there was a time when I knew it reasonably well :-)
[Bug c/94106] [8/9/10 Regression] error on a function redeclaration with attribute transaction_safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P4
[Bug objc/94637] [10 Regression] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Priority|P3 |P4
[Bug driver/90392] Bogus value for %u in LINK_PLUGIN_SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |NEW Summary|[8/9/10 Regression] |Bogus value for %u in |Assertion failure in|LINK_PLUGIN_SPEC |ldlang.c:6868 when | |compiling with -flto| --- Comment #13 from Jeffrey A. Law --- Updating summary, dropping regression marker. Behavior seen as far back as gcc-6, probably started before then. Given the dl.res has been consistent, it's most likely not memory corruption -- if it were memory corruption I'd expect to see different results over time rather than the consistent "dl.res" output for %u.res.
