[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #12 from Aldy Hernandez 2013-03-01
19:17:32 UTC ---
> --- Comment #11 from Ian Lance Taylor 2013-03-01
> 14:52:53 UTC ---
> I suspect we can handle this case by observing that all the incoming values to
> the PHI node are constants.
Ian.
They're not all constants. In this particular case we have phis like this:
state_2 = PHI <0(6), state_3(12), 2(5)>
I suppose we could chase the SSA def chain and if all the phi arguments
are either constants, or known to point to an SSA that has been
previously analyzed as constant, then we can avoid generating an
overflow. But we'd have to keep track of states across calls to
vrp_visit_phi_node. Is this what you had in mind, or am I
misunderstanding something?
Obviously, Richi's idea is much simpler :). With his suggestion we
could probably do with:
@@ -8111,11 +8109,9 @@ vrp_visit_phi_node (gimple phi)
if (cmp_max < 0 || cmp_max > 0)
{
if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
- || !vrp_var_may_overflow (lhs, phi))
+ || !vrp_var_may_overflow (lhs, phi)
+ || supports_overflow_infinity (TREE_TYPE (vr_result.max)))
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
- vr_result.max =
- positive_overflow_infinity (TREE_TYPE (vr_result.max));
}
And similarly for MIN. In the above, supports_overflow_infinity is just
there to make sure we have a CONSTANT_CLASS_P. If that's not needed, we
could even do:
if (cmp_max < 0 || cmp_max > 0)
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
and be done with it.
Let me know. I am willing to entertain any approach y'all suggest.
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #14 from Aldy Hernandez 2013-03-01 19:33:47 UTC --- On 03/01/13 13:23, ian at airs dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 > > --- Comment #13 from Ian Lance Taylor 2013-03-01 > 19:23:00 UTC --- > How hard would it be to test whether the values are all constant or have the > same SSA_NAME_VAR as the value we are setting? That was actually my first idea, but it seemed too simple :). I will do so and report back. Thanks.
[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 --- Comment #7 from Aldy Hernandez 2012-02-22 20:20:34 UTC --- On 02/22/12 14:08, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 > > --- Comment #6 from Jakub Jelinek 2012-02-22 > 20:08:46 UTC --- > (In reply to comment #5) >> (In reply to comment #4) >>> That's (essentially) independent of the target, as it's a pure testsuite >>> issue. >>> Tests that require linking with -litm should go in libitm/testsuite instead. >> >> It shouldn't be linking with -litm. All the required dummy functions should >> be >> in gcc.dg/lto/trans-mem.h. > > But -fgnu-tm during linking now results in libitm.spec being sourced in, so it > needs either a hack version thereof somewhere where it can find it through -B > options, or some other approach. > This looks like a regression brought about by: +2012-02-13 Eric Botcazou + + * gcc.c (LINK_COMMAND_SPEC): Deal with -fgnu-tm. + (GTM_SELF_SPECS): Define if not already defined. + (driver_self_specs): Add GTM_SELF_SPECS. +* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -fgnu-tm. +(GTM_SELF_SPECS): Define. + * config/i386/cygwin.h (GTM_SELF_SPECS): Likewise. + * config/i386/mingw32.h (GTM_SELF_SPECS): Likewise.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #6 from Aldy Hernandez 2012-03-12 15:42:45 UTC --- On 03/12/12 10:32, rguenther at suse dot de wrote: es, but still cared about introducing write >> data races. This test case has both. I don't understand why we would allow >> introducing writes on paths that did not have it, but I will defer to you. > > Why should we avoid them if we know they cannot cause problems? This > will happen for every loop where we do not know if it iterates at least > once. Store-motion is a very important optimization. > > Richard. > They won't cause problems in a single threaded environment, but will cause problems in a multi threaded environment. Even if you're writing the value g_2 originally had, another thread may have written to g_2 right before. Just to get this straight, am I to assume that the default code generation for GCC is a single threaded environment? I just want to make sure I get these variants right in my head, and can properly separate what is and is not allowed in default GCC, and what only pertains to the C11 memory model (or transactional stuff). Thanks.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #10 from Aldy Hernandez 2012-03-12 15:56:30 UTC --- On 03/12/12 10:45, rguenther at suse dot de wrote: >> Just to get this straight, am I to assume that the default code >> generation for GCC is a single threaded environment? I just want to >> make sure I get these variants right in my head, and can properly >> separate what is and is not allowed in default GCC, and what only >> pertains to the C11 memory model (or transactional stuff). > > It certainly is, though we are getting more careful about this stuff > in recent years and generally only read data-races are ok. > > Richard. > Ah, ok. Now it's clear. I was confused because in a previous thread months ago you had mentioned that read data-races were ok, but write data-races were not, whereas here we are even allowing write data races. Understood. Thanks.
[Bug testsuite/59160] The test c-c++-common/cilk-plus/PS/reduction-3.c fails on x86_64-apple-darwin1(0|3)*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 --- Comment #1 from Aldy Hernandez --- > Is the line > > /* FIXME: This test has been xfailed until reductions are fixed. */ > > still relevant? I don't see any xfail in the source. > The FIXME is not relevant anymore. Can you post a patch to gcc-patches with your fix as well as removing the FIXME note? Thanks.
[Bug testsuite/59160] The test c-c++-common/cilk-plus/PS/reduction-3.c fails on x86_64-apple-darwin1(0|3)*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 --- Comment #3 from Aldy Hernandez --- On 11/18/13 09:02, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 > > --- Comment #2 from Dominique d'Humieres --- >> The FIXME is not relevant anymore. Can you post a patch to gcc-patches >> with your fix as well as removing the FIXME note? > > Is the use of stdlib.h OK for other targets? > You need to post it on gcc-patches because I am not a maintainer for this piece of code.
[Bug testsuite/59160] The test c-c++-common/cilk-plus/PS/reduction-3.c fails on x86_64-apple-darwin1(0|3)*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 --- Comment #5 from Aldy Hernandez --- On 11/18/13 09:45, dominiq at lps dot ens.fr wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 > > --- Comment #4 from Dominique d'Humieres --- >> You need to post it on gcc-patches because I am not a maintainer for >> this piece of code. > > Well, the test is yours. Who should I CC besides Iain Sandoe and Mike Stump? > Ideally a testsuite or global write maintainer should ok it. However, since it's such a small change... Your failure is on Darwin. If your change passes on, say...Linux, OK as obvious. Aldy
[Bug tree-optimization/56572] GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572 --- Comment #6 from Aldy Hernandez --- > walk the transaction tree and delete nested transactions. Hopefully > we could do this before actually creating the uninstrumented path. > > I think moving the creation of the uninstrumented path after ipa_inline > is probably a mistake. The inliner makes decisions e.g. based on the Ah I see. Yes, I agree that the creation of the uninstrumented path after ipa_inline is not a good idea, but then you are contradicting yourself. You want to delete nested transactions before creating the uninstrumented path (first quoted paragraph), but yet you don't want to move the uninstrumented path after ipa_inline (second quoted paragraph). Do you mean remove the nested transactions after ipa_inline (possibly tmmark), but then just suck it up and handle the multiple instrumented/uninstrumented code paths in the CFG? Or do you mean something else? Or do you mean make early inling smarter so it inlines transactions properly? Although perhaps something else could be added by ipa_inline, so we'd have the same problem.
[Bug other/51174] AIX unexpected error_mark node in new TM tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51174 --- Comment #9 from Aldy Hernandez 2011-11-17 19:04:43 UTC --- > I do not understand what you are asking. You can reproduce the failures or > you > cannot? My rs6000.c patch fixes some of the failures. The varasm.c patch is > necessary to fix the rest of the failures -- the ones in trans-mem.c. Oh sorry, I cannot reproduce the failures after your NULL handling patch went into mainline. Which failures are you still seeing, after your patch?
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 --- Comment #3 from Aldy Hernandez 2012-01-20 16:25:19 UTC --- > No luck!-(I get 'No symbol "fcode" in current context.' and if not ' optimized out>'). > The only things I have been to print stepping through > streamer_get_builtin_tree (ib=, data_in= out>) Try building the compiler without optimization (-O0).
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 --- Comment #5 from Aldy Hernandez 2012-01-20 20:03:09 UTC --- > I have never done that!-(I guess I have to pass something like CFLAGS and > CXXFLAGS in configure or make). What is the official way to do it? From the Debugging GCC wiki (http://gcc.gnu.org/wiki/DebuggingGCC): To build a debuggable compiler, configure the compiler normally and then make STAGE1_CFLAGS="-g -O0" all-stage1
[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #12 from Aldy Hernandez ---
The warning occurs in vrp1, not evrp, but for the record...
evrp dump:
tcp_chrono_set (struct tcp_sock * tp)
{
int type;
_1;
int _2;
unsigned char _3;
unsigned char _4;
:
_1 = tp_11(D)->chrono_type;
_2 = (int) _1;
if (_1 == 0)
goto ; [INV]
else
goto ; [INV]
:
_3 = BIT_FIELD_REF <*tp_11(D), 8, 96>;
_4 = _3 & 3;
if (_4 != 0)
goto ; [INV]
else
goto ; [INV]
:
tp_11(D)->chrono_stat[-1] = 1234;
:
return;
}
vrp1 dump with ASSERT_EXPRs:
[local count: 1073741825]:
_1 = tp_6(D)->chrono_type;
tp_8 = ASSERT_EXPR ;
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
_2 = BIT_FIELD_REF <*tp_8, 8, 96>;
_3 = _2 & 3;
if (_3 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 268435456]:
tp_8->chrono_stat[-1] = 1234;
vrp1 dump after ASSERT_EXPRs have been removed:
[local count: 1073741825]:
_1 = tp_6(D)->chrono_type;
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
_2 = BIT_FIELD_REF <*tp_6(D), 8, 96>;
_3 = _2 & 3;
if (_3 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 268435456]:
tp_6(D)->chrono_stat[-1] = 1234;
On Wed, Jan 17, 2018 at 2:19 PM, law at redhat dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
>
> --- Comment #11 from Jeffrey A. Law ---
> What do the dumps look like? In particular evrp & vrp1?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068 --- Comment #4 from Aldy Hernandez --- > Yes it's latent and the fix is trivial. Testing to see whether it affects > codequality. Thanks Wilco, I appreciate it. Errr, we all do :).
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #13 from Aldy Hernandez --- Do we care though? Does this bug pose a big enough problem on non MIPS16 that we would like addressed? Just curious On Sun, Feb 4, 2018 at 10:50 AM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 > > --- Comment #12 from Jeffrey A. Law --- > One more tidbit here. I noted that we got "reasonably" close to having enough > state in the combiner to attack this in c#7. The problem is there's a REG > object that we really need to be a CONST_INT. > > It turns out that we're failing to substitute the value from a REG_EQUAL note > as combine builds up that hunk of RTL. So if we were to substitute in the > REG_EQUAL, then we'd have a fighting chance to address this in the combiner. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug tree-optimization/87059] [9 Regression] internal compiler error: in set_value_range, at tree-vrp.c:289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059 --- Comment #8 from Aldy Hernandez --- On 08/23/2018 04:08 PM, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059 > > --- Comment #7 from Martin Sebor --- > The MIN_EXPR code predates my change -- r255898 just moved indentation. Based > on past experience I would assume MIN_EXPR to need the same types. The code > in > expand_builtin_strncmp mixes ssizetype and sizetype: > > len1 = c_strlen (arg1, 1); // returns ssizetype > len2 = c_strlen (arg2, 1); > > if (len1) >len1 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len1); > if (len2) >len2 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len2); > > len3 = fold_convert_loc (loc, sizetype, arg3); > ... > if (len != len3) >len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len, len3); > > So the fix is presumably to change len3 to > > len3 = fold_convert_loc (loc, ssizetype, arg3); > > Given the difference between sizetype and ssizetype is just one 's' it seems > like an easy mistake to make. If MIN_EXPR does, in fact, require arguments of > the same type then adding an assertion to fold_binary_loc() to verify it would > help expose these mistakes early. I'm not sure what the right predicate is to > use in the assertion. Just compare TYPE_MAIN_VARIANT of the two argument > types > for equality? > Thanks. Testing the following: gcc/ PR 87059/tree-optimization * builtins.c (expand_builtin_strncmp): Pass signed sizetype to fold_convert_loc. diff --git a/gcc/builtins.c b/gcc/builtins.c index b1a79f3f33f..7113d19aadf 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -4727,7 +4727,7 @@ expand_builtin_strncmp (tree exp, ATTRIBUTE_UNUSED rtx target, if (len2) len2 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len2); - tree len3 = fold_convert_loc (loc, sizetype, arg3); + tree len3 = fold_convert_loc (loc, ssizetype, arg3); /* If we don't have a constant length for the first, use the length of the second, if we know it. If neither string is constant length,
[Bug tree-optimization/87059] [9 Regression] internal compiler error: in set_value_range, at tree-vrp.c:289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059 --- Comment #16 from Aldy Hernandez --- On 08/24/2018 11:41 AM, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87059 > > --- Comment #15 from Segher Boessenkool --- > (In reply to Aldy Hernandez from comment #12) >> (It really irks me that the PPC backend has backend behavior that depends on >> what assembler (or cross assembler) is available at configure time. It >> makes it difficult to reproduce bugs with crosses.) > > This is so that it is possible to build GCC with a (slightly) older binutils. > You should never have problems with this if you always use a binutils for your > cross toolchains that is approximately as old as your GCC. Did you use an > ancient cross assembler? > I rarely use a cross assembler, since I only build cc1.
[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 --- Comment #7 from Aldy Hernandez --- Ok. Will do. On Feb 20, 2018 15:12, "law at redhat dot com" wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408 > > Jeffrey A. Law changed: > >What|Removed |Added > > > CC||law at redhat dot com > > --- Comment #6 from Jeffrey A. Law --- > ISTM that we ought to take the generated .s file and file a bug report > against > gas/binutils. There really isn't anything GCC can do here. > > Aldy, want to run with that? Obviously close this out once the > gas/binutils > report is filed... > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
--- Comment #10 from Aldy Hernandez ---
On 11/5/18 11:06 AM, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
>
> --- Comment #9 from Martin Sebor ---
> (In reply to Aldy Hernandez from comment #6)
>
> I agree, but it's just a small subset of such cases. There are many
> optimizing
> transformations that GCC does at -O0 that affect the IL later on: calls to
> library built-ins are folded into other library calls (strcpy to memcpy), or
> to
> MEM_REFs (memcpy), or even to constants (strlen). For example:
>
>int f (void)
>{
> return __builtin_strlen ("123");
>}
>
Yes, but in this -Og evrp case, the IL gets changed for *every* SSA name
with a range. That's rather significant IMO.
But alas, Jeff is working on this :).
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #10 from Aldy Hernandez 2012-12-18 16:48:40 UTC --- Ah yes, now I remember. Yes, there is a problem with libgcov.a. I wasn't seeing it because I was only building cc1. You are correct Teresa, that is the reason for the gymnastics in my original patch. houston:/build/trunkboot/gcc$ nm libgcov.a |grep popc U popcount_hwi I will let you and Richard sort it out :).
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 --- Comment #6 from Aldy Hernandez 2013-01-15 16:49:24 UTC --- > The third is for failures like "FAIL: gcc.c-torture/execute/builtins/memset.c > compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects" that fail to > link due to multiple definitions of memset or strlen; I see this for > arm-none-eabi (and I think some other EABI targets) but not for GNU/Linux > targets. The same tests fail for GCC 4.7 so it's not a regression. I'll file > a PR if there isn't one already. > Janis, please do. This way we can close this PR as the duplicate of 3 individual PRs. Thank you so much.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #14 from Aldy Hernandez 2013-01-18 17:14:56 UTC --- > You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception > call > is being used, it'll also give you the addresses so you can make sure that the > right one is being called as you step through. DYLD_PRINT_BINDINGS doesn't even list __cxa_allocate_exception for a simple program with a throw. dyld: bind: libgcc_s.1.dylib:0x100998000 = libSystem.B.dylib:dyld_stub_binder, *0x100998000 = 0x7FFF80F46F94 dyld: bind: libstdc++.6.dylib:0x1000AD0A0 = libSystem.B.dylib:__DefaultRuneLocale, *0x1000AD0A0 = 0x7FFF701FFBE0 dyld: bind: libstdc++.6.dylib:0x1000AD1C8 = libSystem.B.dylib:___mb_cur_max, *0x1000AD1C8 = 0x7FFF70200898 dyld: bind: libstdc++.6.dylib:0x1000AD020 = libSystem.B.dylib:___stderrp, *0x1000AD020 = 0x7FFF701FD2F8 dyld: bind: libstdc++.6.dylib:0x1000AD0B8 = libSystem.B.dylib:___stdinp, *0x1000AD0B8 = 0x7FFF701FD2E8 dyld: bind: libstdc++.6.dylib:0x1000AD0A8 = libSystem.B.dylib:___stdoutp, *0x1000AD0A8 = 0x7FFF701FD2F0 dyld: bind: libstdc++.6.dylib:0x1000AD000 = libSystem.B.dylib:dyld_stub_binder, *0x1000AD000 = 0x7FFF80F46F94 dyld: bind: libitm.1.dylib:0x100157020 = eh-1.exe:__ZdaPv, *0x100157020 = 0x10960 dyld: bind: libitm.1.dylib:0x100157018 = eh-1.exe:__ZdlPv, *0x100157018 = 0x10940 dyld: bind: libitm.1.dylib:0x100157028 = libSystem.B.dylib:__DefaultRuneLocale, *0x100157028 = 0x7FFF701FFBE0 dyld: bind: libitm.1.dylib:0x100157030 = libSystem.B.dylib:___stderrp, *0x100157030 = 0x7FFF701FD2F8 dyld: bind: libitm.1.dylib:0x100157010 = libSystem.B.dylib:_free, *0x100157010 = 0x7FFF80E45115 dyld: bind: libitm.1.dylib:0x100157000 = libSystem.B.dylib:dyld_stub_binder, *0x100157000 = 0x7FFF80F46F94 dyld: bind: eh-1.exe:0x11010 = libstdc++.6.dylib:__ZTIi, *0x11010 = 0x1000AE2C0 dyld: bind: eh-1.exe:0x11028 = libstdc++.6.dylib:___gxx_personality_v0, *0x11028 = 0x159D0 dyld: bind: eh-1.exe:0x11020 = libitm.1.dylib:__ITM_deregisterTMCloneTable, *0x11020 = 0x10013FED7 dyld: bind: eh-1.exe:0x11018 = libitm.1.dylib:__ITM_registerTMCloneTable, *0x11018 = 0x10013FE45 dyld: bind: eh-1.exe:0x11000 = libSystem.B.dylib:dyld_stub_binder, *0x11000 = 0x7FFF80F46F94 dyld: weak bind: libstdc++.6.dylib:0x1000AD010 = eh-1.exe:__ZdaPv, *0x1000AD010 = 0x10960 dyld: weak bind: libstdc++.6.dylib:0x1000AD458 = eh-1.exe:__ZdaPv, *0x1000AD458 = 0x10960 dyld: weak bind: libstdc++.6.dylib:0x1000AD460 = eh-1.exe:__ZdlPv, *0x1000AD460 = 0x10940 dyld: lazy bind: libstdc++.6.dylib:0x1000AD600 = libSystem.B.dylib:_pthread_key_create, *0x1000AD600 = 0x7FFF80E4221A dyld: lazy bind: libstdc++.6.dylib:0x1000AD488 = libSystem.B.dylib:___cxa_atexit, *0x1000AD488 = 0x7FFF80E44981 dyld: lazy bind: libitm.1.dylib:0x1001570F0 = libSystem.B.dylib:___cxa_atexit, *0x1001570F0 = 0x7FFF80E44981 dyld: lazy bind: eh-1.exe:0x11080 = libSystem.B.dylib:_dladdr, *0x11080 = 0x7FFF80E44D9A dyld: lazy bind: eh-1.exe:0x11090 = libSystem.B.dylib:_getsectdatafromheader_64, *0x11090 = 0x7FFF80E44BA6
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #9 from Aldy Hernandez 2013-01-22 00:23:03 UTC --- An image with parameters/instructions would be ideal. Heck...not ideal...great! Thanks so much. "mikpe at it dot uu.se" wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #8 from Mikael Pettersson 2013-01-21 23:18:34 UTC --- I'm using the ARAnym full-system m68040 emulator -- that's the only realistic option for testing gcc on Linux/m68k at the moment. I maintain my own small Fedora-based distro, so if you like I can supply a disk image with that, plus the scripts and ARAnym parameter files I use. Otherwise you can probably find HOWTOs and pointers to images on the Debian/m68k wiki.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #25 from Aldy Hernandez 2013-01-23 14:11:53 UTC --- > looks like (yet another) permutation of what works/doesn't with "ELF-style > weak > linking" I don't have darwin11 or 12 (yet) - but should do soon. > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0). Mac OS X 10.6.8.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939
--- Comment #16 from Aldy Hernandez 2013-01-29
19:47:24 UTC ---
>> double d, d2;
>> ...
>> if (d != d2) {
>> dumpd(d,d2);
>> return -1;
>> }
>>
>> By this point, "d" and "d2" are in fp2/fp3, and we compare them in
>> extended-precision real mode (fcmp.x) below:
> At this point alarm bells are already ringing... When I see EQ/NE
> comparisons of floating points, there's a good bet something is wrong.
For the record, only the EQ/NE above comes from GMP. The other one (in
dumpd()) I added myself in testing. But yes, that one "d != d2" is in
the original testcase.
I will try the various suggestions and report back.
Thanks everyone.
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 --- Comment #18 from Aldy Hernandez --- On 12/07/2016 11:38 AM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 > > --- Comment #17 from Jeffrey A. Law --- > It's just latent. We still need to fix it appropriately. > Ok. I see that compiling with -O3 -fno-tree-vrp shows a segfault at execution. I'll take a look. Hopefully it's still the same bug.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment #41 from Aldy Hernandez ---
Created attachment 40674
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40674&action=edit
miscompiled tree-ssa-structalias.ii on AIX
It looks like tree-ssa-structalias.c is being miscompiled, particularly
build_pred_graph. If I add __attribute__((optimize("-O0"))) to
build_pred_cgraph's definition and rebuild stage2's cc1 we have a
non-segfaulting cc1.
I wonder if we can now build a cross (with attachment 40673) to
--target=powerpc-ibm-aix7.2.0.0 and use the attached tree-ssa-structalias.ii to
compare before and after dumps.
[Bug lto/47889] [4.7/4.8/4.9 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 --- Comment #12 from Aldy Hernandez --- On 01/09/14 15:43, d.g.gorbachev at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 > > --- Comment #11 from Dmitry Gorbachev --- > GCC 4.7 still crashes on the testcase from attachment 25620: > > $ gcc -r -nostdlib -flto 1.c 2.c > In file included from 1.c:5:0, > from :0: > 2.c:5:17: warning: type of 's' does not match original declaration [enabled by > default] > In file included from :0:0: > 1.c:5:10: note: previously declared here > In file included from 1.c:5:0, > from :1: > 2.c: In function 'foo': > 2.c:10:5: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > Which version of 4.7? So in essence, 4.8 and 4.9 do not exhibit this behavior. I will remove the 4.8 and 4.9 tags.
[Bug lto/47889] [4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 --- Comment #14 from Aldy Hernandez --- On 01/09/14 16:01, d.g.gorbachev at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 > > --- Comment #13 from Dmitry Gorbachev --- > It was 4.7.4 20131207 (prerelease). > Can you try the actual release? 4.7.4, not the prerelease?
[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
--- Comment #21 from Aldy Hernandez ---
On 02/24/2015 12:39 AM, rguenther at suse dot de wrote:
> But yes, we have multiple such assignments to 'this' at the (possible
> assembler) location of a single statement which of course doesn't help.
>
> Thus we should DCE the debug stmt sequences between real stmts like
>
>>D.166591 ={v} {CLOBBER};
>># DEBUG this => &D.166589
>># DEBUG D#20 => &D.166589.D.71066
>># DEBUG this => D#20
>># DEBUG D#19 => &D#20->D.67748
>># DEBUG this => D#19
>>_1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> to the following at least ("DSE" actually, based on the actual
> name of the LHS a debugger might use to refer to the variable)
Let me see if I understood this correctly. We need a DSE/DCE pass right
before var-tracking that would eliminate the redundant `this' statements
right before a non debug statement. So, for something like this:
# DEBUG this => &cs
# DEBUG D#61 => &cs.D.73561
# DEBUG this => D#61
# DEBUG topol => 0
# DEBUG D#60 => &D#61->D.71953
# DEBUG this => D#60
# DEBUG D#59 => &D#60->rows
# DEBUG this => D#59
# DEBUG D#58 => &D#59->D.66859
# DEBUG this => D#58
# DEBUG D#57 => &D#58->_M_impl
# DEBUG this => D#57
# DEBUG this => D#57
# DEBUG this => D#57
MEM[(struct _Vector_impl *)&cs]._M_start = 0B;
:
# DEBUG this => &D.166575
# DEBUG D#21 => &D.166575.D.73843
# DEBUG this => D#21
# DEBUG D#19 => &D#21->D.67748
# DEBUG this => D#19
_1448 = &MEM[(struct Row *)&D.166575].D.66121;
Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448);
...we would delete all the "DEBUG this" in the first batch with the
exception of the last one (DEBUG this => D#57). All the intervening
"DEBUG D#[0-9][0-9]" statements would remain. For the second batch, we
would also delete all the "DEBUG this" statements except the last one
(DEBUG this => D#19)?
Is this what you have in mind?
>
>>D.166591 ={v} {CLOBBER};
>># DEBUG D#20 => &D.166589.D.71066
>># DEBUG D#19 => &D#20->D.67748
>># DEBUG this => D#19
>>_1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> As to "between stmts" that is because after each 'stepi' in the
> debugger you reach a new state computed by var-tracking. Intermediate
> state-transitions are not interesting as long as you preserve the
> "last" state before the next instruction.
>
> Thus in reality you'd want to perform this DCE/DSE right before
> var-tracking (or during the var-tracking insn scan phase)
>
>> Also, it may not be the DEBUG statements at fault, but the inefficiency
>> of the testcase itself (creating all these objects), in which case,
>> perhaps we could notice this behavior at var-tracking time, and bail?
>> Though this sounds like a kludge.
>
> Of course the issue is very large and repetitive functions. Thus
> another idea is to simply split up such functions. If just by
> making var-tracking work on SESE (or SEME) regions and dealing
> with the boundaries conservatively.
>
> Eventually this can be "hacked" by fake splitting/restoring the
> CFG around vt_initialize/vt_find_locations/vt_finalize. Maybe
> easier than to make them work on a CFG region.
The DCE/DSE pass sounds more straightforward IMO, but I just don't want
to deal with data flow equations ;-).
[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #23 from Aldy Hernandez --- On 02/24/2015 07:53 AM, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 > > --- Comment #22 from Jakub Jelinek --- > (In reply to Aldy Hernandez from comment #21) >> Let me see if I understood this correctly. We need a DSE/DCE pass right >> before var-tracking that would eliminate the redundant `this' statements >> right before a non debug statement. So, for something like this: > > First of all, these are GIMPLE statements, so doing anything on them can't be > right before var-tracking, which is one of the last RTL passes. Sorry, what I should've said was doing it right before expand, or at a place where gimple still exists. > That said, I very much doubt you can DCE much here, just use -fdump-tree-*-all > to see the uids of the this PARM_DECLs/VAR_DECLs, I bet most of them will be > different. Absolutely, _all_ of them are different for that matter. I think what Richi was saying was that we could do a DSE type pass but take intervening stores to a DEBUG statement that have the same LHS name a debugger would see, and remove them based on that. So it wouldn't matter that we have different `this': # DEBUG this (for type "class foo") => D.1234 # DEBUG this (for type "class bar") => D.5678 # DEBUG this (for type "class biz") => D.9012 The first two stores are useless because you wouldn't be able to access them from a debugger. Although perhaps I am misunderstanding something (??).
[Bug target/65278] [5 Regression] ICE (in output_718, at config/rs6000/rs6000.md:11592) on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65278 --- Comment #4 from Aldy Hernandez --- On 03/02/2015 08:30 AM, doko at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65278 > > --- Comment #2 from Matthias Klose --- > yes, 32bit powerpc, > > /usr/lib/gcc/powerpc-linux-gnu/5/cc1plus -fpreprocessed DistanceEstimation.ii > -msecure-plt -quiet -dumpbase DistanceEstimation.ii -auxbase > DistanceEstimation > -g -O2 -version -fPIC -fstack-protector-strong -Wformat -Wformat-security -o > /tmp/ccYUSH7u.s > Still can't reproduce, even with the un-preprocessed source.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #5 from Aldy Hernandez ---
I don't have access to a Darwin box. Could you provide a preprocessed file so I
can try to reproduce the defined but not used problem on a cross build?
Also, what triplet?
Thanks.
On Jun 7, 2015 4:09 AM, "iains at gcc dot gnu.org"
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
>
> --- Comment #1 from Iain Sandoe ---
> Created attachment 35710
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35710&action=edit
> declare "extern int __CFConstantStringClassReference" lazily
>
> There seem to be three issues triggered by 224161
>
> 1. Debug is not initialised when the built-ins are initialised, therefore
> any
> attempt to declare a variable at that time causes the segv. (hash table is
> not
> present).
>
> * at present, *darwin* declares "extern int
> __CFConstantStringClassReference[]" at the time that the CFString built-in is
> initialised.
>
> - on the basis that it's not clear *if* such early declarations are allowed,
> I've made a patch that makes the declaration lazily (when the fist use of the
> built-in occurs).
>
> This works around the reported crash (one could also use DECL_SOURCE_LOCATION
> != BUILTINS_LOCATION as an additional test at passes.c:338, if built-ins
> *are*
> supposed to be allowed to declare variables.
>
> … however ...
>
>
>
> 2. Once (1) is fixed, bootstrap then fails with:
>
> /GCC/gcc-trunk/gcc/ipa-pure-const.c:1640:1: error:
> ‘{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)’
> defined
> but not used [-Werror=unused-function]
> pass_ipa_pure_const::
>
> A --disable-werror boostrap completes, but there are a number of constructors
> and destructors that report "declared but not used". AFAICT, it's only
> constructors/destructors.
>
> This is occurring at stage #2, and I thought maybe that the stage#1 compiler
> could have been mis-compiled by the bootstrap; however, gcc-4.9, 5.1 and
> clang
> (xcode 5.1.1) bootstraps all give the same result.
>
> … additional info …
>
> =
>
> 3. During bootstrap (and in the test suite on the --disable-werror build)
> there
> are a large number of warnings from ld64 (of course, this might be a
> limitation
> of ld64, but for the record):
>
> warning: invalid DWARF generated by the compiler: DIE 0x02f7 has multiple
> AT_location attributes in
> '/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
>
> warning: invalid DWARF generated by the compiler: DIE 0x0317 has multiple
> AT_location attributes in
> '/GCC/ml/gcc-trunk-xtools/x86_64-apple-darwin12/libgcc/enable-execute-stack_s.o'.
>
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #10 from Aldy Hernandez ---
It's not supposed to. It's for issue three as stated.
On Jun 9, 2015 4:36 AM, "dominiq at lps dot ens.fr"
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
>
> --- Comment #9 from Dominique d'Humieres ---
> > Created attachment 35718
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35718&action=edit
> > Tentative patch for issue #3
>
> The patch does not fix the
>
> ../../work/gcc/ipa-pure-const.c:1636:1: error:
> '{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)'
> defined
> but not used [-Werror=unused-function]
>
> issue.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug debug/66597] [6 Regression] Bootstrap failure since debug-early merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597 --- Comment #4 from Aldy Hernandez --- On 06/19/2015 11:50 AM, krebbel at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597 > > --- Comment #2 from Andreas Krebbel --- > (In reply to Aldy Hernandez from comment #1) >> Is that the actual line number (18034) with current mainline? 18034 does >> not look like a place we could ICE in. >> >> Perhaps it's the ICE in 25535, because if it is, then it is a duplicate of >> PR66482. >> >> Could you please verify? > > I've just re-checked with r224673 (0bf0c7922570f90172ab21c8fa7782bff9e2fe60) > and it stays at 18034: My bad, I had an old tree. Could you attach a pre-processed testcase so I can reproduce on a cross build?
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 --- Comment #9 from Aldy Hernandez --- On 07/20/2015 03:14 PM, jason at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 > > --- Comment #8 from Jason Merrill --- > The problem seems to be that we inlined the function, but > DECL_POSSIBLY_INLINED > remains unset, so dwarf2out doesn't think it needs to call > dwarf2out_abstract_function. > > There also doesn't seem to be a cgraph edge for the inlined function call; I'm > guessing that the function was inlined in the initial compilation, and this > relationship is forgotten by the time we get to LTO. > > So, doesn't look like a dwarf2out bug. > Jason, thanks for looking into this. Sorry it wasn't dwarf2out related. Do you think perhaps we could diagnose this sort of problem earlier so it doesn't show up (confusingly) in dwarf2out land? Thanks.
[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124
--- Comment #5 from Aldy Hernandez 2011-03-15
12:42:36 UTC ---
> struct S
> {
>signed a : 26;
>signed b : 16;
>signed c : 10;
>volatile signed d : 14;
>int e;
> } s;
> I think you can't just modify s.e when writing s.d (I think it is fine to
> modify
> adjacent bitfields though, Aldy?).
No, you can't modify s.e when writing to s.d. However, you can modify
adjacent bitfields. All contiguous bitfields can be considered a single
memory location for the purpose of introducing data races. The only
exception is when bitfields are separated by a zero-length bitfield, or
when they happen to be contiguous but occur in different
structures/unions. Those conditions force alignments on those fields.
[Bug tree-optimization/96818] [11 Regression] ICE: in decompose, at wide-int.h:984 at -O since r11-2883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 --- Comment #11 from Aldy Hernandez --- Ah...it can be closed. On Wed, Oct 14, 2020, 17:58 jamborm at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818 > > --- Comment #10 from Martin Jambor --- > Is this bug still "WAITING" for something? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug. > >
[Bug tree-optimization/97609] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 --- Comment #8 from Aldy Hernandez --- Yes. On Thu, Oct 29, 2020, 09:47 marxin at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 > > Martin Liška changed: > >What|Removed |Added > > > CC||marxin at gcc dot gnu.org > > --- Comment #7 from Martin Liška --- > Can it be closed as fixed? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #10 from Aldy Hernandez ---
> > as well as here:
> >
> > if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> > {
> > /* We cannot compare overflowed values. */
> > if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> > return -2;
> >
> > return tree_int_cst_compare (val1, val2);
> > }
>
> VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
> on some TREE_OVERFLOW bits therein. This might be all long history
> but the above is probably because of that.
>
> Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
> of the IL for VRP purposes (as said, some passes are "confused" about
> existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
> internal processing - which, nowadays should use wide_int).
Ok, let's let sleeping dogs lie then. I'll drop the overflow will
building ranges.
Thanks for the explanation.
I'll commit the following if it passes tests.
Aldy
Drop overflow from constants while building ranges in ranger.
Sometimes overflow flag will leak into the IL. Drop them while
creating ranges.
gcc/ChangeLog:
PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97721.c: New test.
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index cf979845acf..6d351002830 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -165,6 +165,8 @@ get_tree_range (irange &r, tree expr)
switch (TREE_CODE (expr))
{
case INTEGER_CST:
+if (TREE_OVERFLOW_P (expr))
+ expr = drop_tree_overflow (expr);
r.set (expr, expr);
return true;
diff --git a/gcc/testsuite/gcc.dg/pr97721.c b/gcc/testsuite/gcc.dg/pr97721.c
new file mode 100644
index 000..c2a2848ba13
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97721.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O -fno-tree-dominator-opts" }
+
+int ot;
+
+void
+z6 (char *tw)
+{
+ while (ot >= 0)
+--ot;
+
+ __builtin_strcpy (&tw[ot], tw);
+}
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #20 from Aldy Hernandez --- On Wed, May 19, 2021 at 8:31 AM rguenth at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #17 from Richard Biener --- > (In reply to Andrew Macleod from comment #16) > > We could add an expression evaluator that can walk that expression, invoking > > range-ops on each expression, and calling a ranger instance to evaluate a > > range for any ssa_name it finds. > > > > It would bail if there are unknown tree-codes to range-ops. > > Yeah, it would be similar to the existing determine_value_range () function > which does exactly do this (but not using ranger). determine_value_range() has been calling range-ops under the covers for quite a while, so it's half-way there. It would require some minor tweaks: a) Use irange instead of value_range so as to not throw away the higher precision range-ops calculates. b) If we want context-aware ranges, pass it a gimple statement / edge / etc, and a range_query/ranger. Oh yeah, and return a proper range, not this value_range_kind + wide_int + wide_int business (determine_value_range_1 does this already).
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #26 from Aldy Hernandez --- On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de wrote: > It's probably too strict for multiple_of_p which is fine with > overflows that preserve modulo behavior. Could you provide an example?
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #30 from Aldy Hernandez --- On 5/26/21 3:23 PM, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #29 from rguenther at suse dot de --- > On Wed, 26 May 2021, amacleod at redhat dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >> >> --- Comment #28 from Andrew Macleod --- >> (In reply to rguent...@suse.de from comment #27) >>> On Wed, 26 May 2021, aldyh at redhat dot com wrote: >>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >>>> >>>> --- Comment #26 from Aldy Hernandez --- >>>> On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de >>>> wrote: >>>> >>>>> It's probably too strict for multiple_of_p which is fine with >>>>> overflows that preserve modulo behavior. >>>> >>>> Could you provide an example? >>> >>> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication >>> and the query whether it's a multiple of 8. Once you have no >>> range for 'D.1234' you will signal overflow (correctly) but >>> even then it's still a mutliple of 8. >> >> Determining whether an arbitrary expression is a multiple of some number is >> not >> really something we can figure out via ranges. Well, that's not quite true. >> If >> we fully fleshed out the operations you care about, things like multiply or >> shift you could get some results. presumably things like multiply by 2,4,8 >> and >> 16.. if we created correct multi-ranges for those, a cast of the high >> precision >> range back to the original precision would yield an identical non-varying >> range. and for non-multiples/unsupported values we'd get varying or something >> not the same as the original value?. This would only work if the original >> value doesn't come out varying.Although if its varying, maybe you dont >> care >> and a match is ok anyway?We could have may_overflow_p also return the >> higher precision range for inspection if its true... > > I guess optimally multiple_of_p would check for each individual > operation it looks at whether the op is transparent for the > modulo query and only if not checks whether there's possible overflow > (where ranges could help). My POC gimple_ranger_wider class can just be overloaded and in range_of_expr, you could just hijack the operations you care about (PLUS_EXPR, MULTIPLY_EXPR, etc) and treat them specially. Just a thought... Aldy
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #7 from Jakub Jelinek --- Perhaps if EVRP is folding debug stmts it could first fold non-debug stmts (and remember if there were any debug stmts) and only fold debug stmts afterwards, either just by using caches and not adding anything to them (if they survive to later passes), or just to make sure that the debug stmts don't affect non-debug folding. --- Comment #8 from Aldy Hernandez --- I'll work on it this weekend. If there's no patch by Monday morning, we can revert the patch while I find a solution. On Fri, May 28, 2021, 19:49 ro at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 > > Rainer Orth changed: > >What|Removed |Added > > > Target|i686|i686, sparc > CC||ro at gcc dot gnu.org > > --- Comment #6 from Rainer Orth --- > It also affects 32-bit sparc (sparc-sun-solaris2.11), maybe other 32-bit > targets, too? Unless a quick fix is coming forward, I suspect it would be > better > to revert the patch instead of keeping bootstrap broken for days. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > >
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 --- Comment #2 from Aldy Hernandez --- Huh. I wonder why this didn't show up in my regression tests. Are these tests not run by default? Either way, I'll take a look. On Thu, Aug 18, 2022, 23:29 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 > > Andrew Pinski changed: > >What|Removed |Added > > > Target|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | >Host|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | >Last reconfirmed||2022-08-18 > Build|powerpc64-linux-gnu,| >|powerpc64le-linux-gnu | > Ever confirmed|0 |1 > Status|UNCONFIRMED |NEW > > --- Comment #1 from Andrew Pinski --- > Looks like it also fails on x86_64-linux-gnu: > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599920.html > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment #3 from Aldy Hernandez ---
I'm going to need more specific instructions here.
Looking at the link provided, there's a target of arm-none-linux-gnueabihf
--with-arch=default --with-cpu=cortex-a9 --with-cpu=vfp -march=armv5t... that
has a a red "REGRESSED" column.
I tried to simulate that with a cross --target=arm-none-linux-gnueabihf:
diff --git a/gcc/testsuite/gcc.target/arm/ivopts-4.c
b/gcc/testsuite/gcc.target/arm/ivopts-4.c
index 2e866c01823..cb81d010bb5 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-4.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-4.c
@@ -1,5 +1,5 @@
/* { dg-do assemble } */
-/* { dg-options "-Os -fdump-tree-ivopts -save-temps" } */
+/* { dg-options "-Os -fdump-tree-ivopts -save-temps -S -mcpu=cortex-a9
-mfpu=vfp -march=armv5t" } */
extern unsigned int foo (int*) __attribute__((pure));
$ make check-gcc RUNTESTFLAGS=arm.exp=ivopts-4.c
=== gcc Summary ===
# of expected passes4
Can you provide specific flags to pass to cc1 on a cross to
arm-none-linux-gnueabihf in order to reproduce?
[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 --- Comment #18 from Defunct account. Do not use. --- > Yes. I guess it would be nice to have a CTOR or so for the case > where the path is really a single edge like in this case. Good idea. Will do.
[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103188
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at redhat dot com,
||amacleod at redhat dot com
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at
>
> #666394 0x015f2170 in should_duplicate_loop_header_p (
> header=, loop=0x766aa9f0,
> limit=0x7fffd97c, query=0x3fccb70)
> at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
> 83&& !entry_loop_condition_is_static (loop, query))
>
> likely ranger is confused by the intermediate IL (from other loops header
> copying), the IL is kept partly not in up-to-date SSA form (because running
> update_ssa is costly so we run it once after doing all header copying in
> a function).
Ughh, yeah. Ranger won't do well with in-flight SSA. I think we can do ok
with minimally changing IL like what evrp does with the substitute and fold
engine, but we expect things quite sane.
When working on this patch I saw the call to gimple_duplicate_sese_region would
increase the number of BBs, which caused problems in the cache and Andrew
fixed. I thought that was it for issues, obviously not.
>
> In this case we applied loop header copying to loop 4 containing loop 5
> which we are now processing.
>
> Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
> in a stmt are still old and _not_ replaced with their current definition.
> There's only so much you can do with such IL, in particular invoking SCEV
> isn't among that.
>
> You can actually check whether a SSA name may be affected by checking
> name_registered_for_update_p. SCEV doesn't do that.
Hmmm, useful.
>
> In the end that means that we'd have to do the ranger analysis before
> actually applying the header copying.
>
> Note that the current place of the
>
> /* Avoid loop header copying when optimizing for size unless we can
> determine that the loop condition is static in the first
> iteration. */
> if (optimize_loop_for_size_p (loop)
> && !loop->force_vectorize
> && !entry_loop_condition_is_static (loop, query))
> {
>
> is off in any case, since we iterate on blocks to copy, instead it should
> be done exactly once per loop. So we can do the "head", up until this
> and the very first should_duplicate_loop_header_p first for each loop,
> recording candidates in a vector and in a second loop process them all,
> not doing the already done entry_loop_condition_is_static.
>
> Let me cook up a patch to do that.
Thanks for fixing this!
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #16 from Aldy Hernandez --- On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > --- Comment #15 from David Edelsohn --- > I annotated execute_vrp_threader() to call getrusage() and print the size of > RSS around each call to threader.thread_jumps(). It consistently is growing, > but not in the threader itself. Was the former VPR Threader intentionally or > implicitly freeing some other data allocated by the compiler that the new > threader is not cleaning up? Huh. Very good insight. :-) diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 69a3ab0ea9d..c24c67f8874 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader () delete m_threader; delete m_state; delete m_ranger; + delete m_query; scev_finalize (); loop_optimizer_finalize ();
[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527 --- Comment #11 from Aldy Hernandez --- This looks mighty suspicious ;-) diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 69a3ab0ea9d..c24c67f8874 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader () delete m_threader; delete m_state; delete m_ranger; + delete m_query; scev_finalize (); loop_optimizer_finalize ();
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #20 from Aldy Hernandez --- Doesn't make a difference. If the blocks are stale, they need to be reconstructed anyhow. It's preexisting behavior in VRP anyhow. I heard you the first time ;-). On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > Bernhard Reutner-Fischer changed: > >What|Removed |Added > > CC||aldot at gcc dot gnu.org > > --- Comment #19 from Bernhard Reutner-Fischer --- > so as asked in > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what > about > dominance_info? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 --- Comment #21 from Aldy Hernandez --- However, if you care to test a patch, I'd be happy to review it. On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 > > Bernhard Reutner-Fischer changed: > >What|Removed |Added > > CC||aldot at gcc dot gnu.org > > --- Comment #19 from Bernhard Reutner-Fischer --- > so as asked in > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what > about > dominance_info? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 --- Comment #7 from Aldy Hernandez --- On Fri, Oct 1, 2021 at 1:46 PM rguenth at gcc dot gnu.org wrote: > > Could I inconvenience you to tweak this function with your insight? It's a > > tiny function, and it seems you're much more qualified to add the > > restriction code. If not, I'm sure I can stumble around it and send it for > > review. > > Something like > > diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c > index dcabfdb30d2..b1b77e91176 100644 Thanks so much for this. I will test it, and incorporate it with some ideas Jeff had suggested. Then I'll post it upstream for review/discussion. BTW, it seems that the code restricting paths should actually live in the loop world...since it's the loop experts who know what is allowed and what is problematic ;-).
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #12 from Aldy Hernandez --- Absolutely, but I didn't want to pollute the patch for this PR. Consider the patch to do so pre-approved :-). On Sat, Oct 2, 2021, 00:20 jakub at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 > > Jakub Jelinek changed: > >What|Removed |Added > > > CC||jakub at gcc dot gnu.org > > --- Comment #11 from Jakub Jelinek --- > Isn't the same thing true also for operator_rshift::op1_range? > I mean, (X >> Y) != 0 implies X != 0. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > >
[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
--- Comment #5 from Aldy Hernandez ---
> > BTW, the __MEM_REF output from the dumps does not work in -fgimple either.
> > More errors.
>
> Can you share an example?
This is from gcc.c-torture/execute/961125-1.c compiled with -fgimple:
char * begfield (int tab, char * ptr, char * lim, int sword, int schar);
int __GIMPLE (ssa)
main ()
{
char * lim;
char * s;
char * _1;
__BB(2):
_1 = begfield (58, ":ab", &__MEM ((void *)":ab" + _Literal
(void *) 3), 1, 1);
if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
goto __BB3;
else
goto __BB4;
__BB(3):
abort ();
__BB(4):
exit (0);
}
$ ./cc1 x.c -quiet -fgimple
x.c: In function ‘main’:
x.c:11:55: error: invalid type of ‘__MEM’ operand
11 | _1 = begfield (58, ":ab", &__MEM ((void *)":ab" +
_Literal (void *) 3), 1, 1);
| ^
x.c:11:60: error: expected ‘)’ before ‘+’ token
11 | _1 = begfield (58, ":ab", &__MEM ((void *)":ab" +
_Literal (void *) 3), 1, 1);
|^~
|)
x.c:12:13: error: expected expression before ‘&’ token
12 | if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
| ^
x.c: At top level:
x.c:12:67: error: expected identifier or ‘(’ before ‘)’ token
12 | if (_1 != &__MEM ((void *)":ab" + _Literal (void *) 2))
| ^
x.c:14:3: error: expected identifier or ‘(’ before ‘else’
14 | else
| ^~~~
x.c:17:8: error: expected declaration specifiers or ‘...’ before
numeric constant
17 | __BB(3):
|^
x.c:20:8: error: expected declaration specifiers or ‘...’ before
numeric constant
20 | __BB(4):
|^
x.c:23:1: error: expected identifier or ‘(’ before ‘}’ token
23 | }
| ^
Thanks for improving all this.
[Bug other/102605] address instruction from -fdump-tree-*-gimple doesn't work with -fgimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605 --- Comment #7 from Aldy Hernandez --- On Wed, Oct 6, 2021 at 10:14 AM rguenther at suse dot de wrote: > Btw, please report cases where -gimple doesn't produce valid GIMPLE FE > inputs (OK, there are known cases with mangled symbol names when > passes create temporaries whose name includes a '.' for example...) Thanks, will do.
[Bug tree-optimization/102622] [12 Regression] Wrong code with -O3 for skylake-avx512 and icelake-server by r12-3903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 --- Comment #10 from Aldy Hernandez --- Does :1-1 fail? In which case it's definitely the first thread.
[Bug tree-optimization/102646] large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646 --- Comment #3 from Aldy Hernandez --- Most if not all the performance changes I've seen so far have been, not due to the jump threader changes, but to the restrictions we've put into place for jump threadable paths. Before, we used to thread paths that destroyed loop form. We are much more cautious now. In theory, the vectorizer should be able to do an even better job with loops preserved longer. That being said, this has been a bit of a moving target, with the thread validity model changing a few times in the past month. A good exercise would be to compare the old and new threaders, with the vectorizer kept constant (whether -fno-tree-vectorize or -ftree-vectorize), but without the loop threading restrictions. That is, with something like this patch: diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c index 32ce1e3af40..1a49cb61ca3 100644 --- a/gcc/tree-ssa-threadupdate.c +++ b/gcc/tree-ssa-threadupdate.c @@ -2853,9 +2853,6 @@ jt_path_registry::register_jump_thread (vec *path) return false; } - if (cancel_invalid_paths (*path)) -return false; - if (dump_file && (dump_flags & TDF_DETAILS)) dump_jump_thread_path (dump_file, *path, true); On Mon, Oct 11, 2021 at 4:59 PM hubicka at kam dot mff.cuni.cz wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646 > > --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > > I think most of the regressions are fixed, we get even better numbers now. > Because we enabled vectorization. I would say they should still > reproduce with -fno-tree-vectorize, right? > > Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 --- Comment #8 from Aldy Hernandez --- On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 > > --- Comment #7 from Andrew Pinski --- > Because: > if (d_11 > 1) > goto ; [59.00%] > else > goto ; [41.00%] > >[local count: 391808389]: > >[local count: 955630225]: > # iftmp.1_6 = PHI <0(3), 2(4)> > > If the phi node was removed, the original al condition for d_11 > 1 would > be > remove. > As the IL stands, the 3->5 edge has relevant range information. If the IL should be different at this point, there is no way the threader can know this. Aldy
[Bug tree-optimization/102794] [12 Regression] missing vrp in evrp dealing with casts and ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794 --- Comment #2 from Aldy Hernandez --- I haven't looked at this, but there's a pending patch with more restrictions for loop threading in the presence of loops. Does this help? https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581637.html We really shouldn't be destroying loop info. On Sat, Oct 16, 2021, 07:01 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102794 > > Andrew Pinski changed: > >What|Removed |Added > > > CC||aldyh at gcc dot gnu.org > > --- Comment #1 from Andrew Pinski --- > Jump threading really messes up the loop here ... > about to thread: path: 4 -> 6, 6 -> 7, 7 -> 3, > just threaded: path: 4 -> 9, 6 -> 7, 7 -> 3, > > I don't know what else to say. Maybe move ethread after evpr? > > Note with -fno-thread-jumps, evpr is able to figure out the induction > variable > goes from [-100, -1] . It does look like jump threading is full on > messing up > how induction variable detection works; we get two a = a +1; statement > after > the jump threading improvements. > Maybe there is another bug about that case already. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > >
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #12 from Aldy Hernandez --- Thank you for your help on this (and the myriad of other PRs ;-)). I'll submit upstream. On Sat, Oct 23, 2021 at 11:06 AM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 > > --- Comment #11 from Andrew Pinski --- > (In reply to Aldy Hernandez from comment #10) > > Created attachment 51656 [details] > > proposed patch 2 > > > > How about this? > > I can confirm the patch works on aarch64-linux-gnu and x86_64-linux-gnu. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug middle-end/101671] pr83510 fails with -Os because threader confuses -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
--- Comment #2 from Aldy Hernandez ---
Yeah, that would be great. Thanks!
On Thu, Jul 29, 2021 at 6:05 PM msebor at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671
>
> Martin Sebor changed:
>
>What|Removed |Added
>
> CC||msebor at gcc dot gnu.org
>Last reconfirmed||2021-07-29
>Keywords||diagnostic
> Summary|pr83510 fails because |pr83510 fails with -Os
>|threader confuses |because threader confuses
>|-Warray-bounds |-Warray-bounds
> Ever confirmed|0 |1
> Status|UNCONFIRMED |NEW
>
> --- Comment #1 from Martin Sebor ---
> Confirmed. I've extracted the test case that fails from the bigger test.
> Rather than xfailing the whole test I think it would be better to split out
> just the failing case and/or xfail just that assertion. Unless you expect the
> others to start failing too due to some changes you still have planned?
>
> $ cat a.c && gcc -Os -S -Wall a.c
> extern int f (void);
> extern void sink (unsigned int);
>
> unsigned int a[10];
>
> static unsigned int g (int i, int j)
> {
> if (i == 9)
> return j;
> else if (i == 10)
> return a[i];// no warning here
> return 0;
> }
>
> void test_g (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (g (i, j));
> }
> }
>
> static unsigned int h (int i, int j)
> {
> switch (i)
> {
> case 9:
> return j;
> case 10:
> return a[i]; // { dg-bogus "-Warray-bounds" }
> }
> return 0;
> }
>
> void test_h (int j)
> {
> for (int i = 0; i < 10; i++)
> {
> if (f ())
> sink (h (i, j));
> }
> }
> In function ‘h’,
> inlined from ‘test_h’ at a.c:41:2:
> a.c:31:15: warning: array subscript 10 is above array bounds of ‘unsigned
> int[10]’ [-Warray-bounds]
>31 | return a[i]; // { dg-bogus "-Warray-bounds" }
> | ~^~~
> a.c: In function ‘test_h’:
> a.c:4:14: note: while referencing ‘a’
> 4 | unsigned int a[10];
> | ^
>
> --
> You are receiving this mail because:
> You reported the bug.
>
