[Bug tree-optimization/69184] [6 Regression] ICE in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69184 Sujoy changed: What|Removed |Added CC||ssaraswati at gmail dot com --- Comment #3 from Sujoy --- Hi, I see the same error on Linux/X86 for the new test case. For the previous test case you had sent, I see a different failure with trunk - gcc -w -O3 -floop-interchange pr69184.c pr69184.c: In function âfunc_27â: pr69184.c:27:1: internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175 func_27 (void) ^~~ 0x11f5b95 outer_projection_mupa /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1175 0x11f5b95 add_loop_schedule /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1223 0x11f6063 build_schedule_loop_nest /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1319 0x11f610d build_schedule_loop /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1257 0x11f6063 build_schedule_loop_nest /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1319 0x11f855e build_original_schedule /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1337 0x11f855e build_poly_scop(scop*) /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite-sese-to-poly.c:1368 0x11e20d8 graphite_transform_loops() /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite.c:319 0x11e2680 graphite_transforms /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite.c:356 0x11e2680 execute /wsp2/sujoys/gcc/gcc_ssh_trunk/gcc/graphite.c:433 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062
Sujoy changed:
What|Removed |Added
CC||ssaraswati at gmail dot com
--- Comment #1 from Sujoy ---
(In reply to huangcunjian from comment #0)
Hi,
I can reproduce this on x86_64 as well. The test case as such has an issue
that it does an out of bound access for an array. However, I believe gcc
shouldn't crash in any case. This can be reproduced with a shorter test case as
shown below.
#include
#include
#include
struct S0 {
unsigned int i : 2;
};
static struct S0 g[5] = {{0}, {1}, {0}, {1}, {0}};
static int64_t idx = 0x979516CD4BBA2AEDLL;
int main()
{
struct S0 l = {0};
g[(idx + 1)] = l;
return g[3].i;
}
$ gcc -O2 small_test.c
small_test.c: In function âmainâ:
small_test.c:15:16: internal compiler error: in expand_assignment, at
expr.c:4721
g[(idx + 1)] = l;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccueDw3V.out file, please attach this to
your bugreport.
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 --- Comment #2 from Sujoy --- This bug is in UNCONFIRMED state. Since I am new to gcc, just wanted to know if one should work for this fix only after it is confirmed.
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 --- Comment #4 from Sujoy --- (In reply to Markus Trippelsdorf from comment #3) > gcc-4.8 isn't supported anymore. > I cannot reproduce the issue with 4.9.3 or above. Thanks for checking. Yes, looks like this got fixed with PR65680.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Sujoy changed: What|Removed |Added CC||ssaraswati at gmail dot com --- Comment #2 from Sujoy --- I could reproduce this on x86_64-linux-gnu with 4.9 and trunk. As far as the issue is concerned, the ccp propagates the sNaN value at -O1 or higher optimization level. Should this be done only when -fsignaling-nans is on? From the man page of gcc, -fsignaling-nans says - "Compile code assuming that IEEE signaling NaNs may generate user-visible traps during floating-point operations. Setting this option disables optimizations that may change the number of exceptions visible with signaling NaNs." Going by this, should we stop ccp from folding sNaN values when -fsignaling-nans is on? However, the man page also says the following for -fsignaling-nans - "This option is experimental and does not currently guarantee to disable all GCC optimizations that affect signaling NaN behavior." Given this, may be we can probably let ccp propagate the sNaN value if -fsignaling-nans is on, and change it to qNaN otherwise. With this though, we would still see different behavior for the test case at -O0 and -O1 when -fsignaling-nans is used. Is my understanding right? I would be interested in pushing a patch for this if this issue is confirmed. What would be the process to get this confirmed?
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #4 from Sujoy --- Yes, I agree to your comment. With -fno-signaling-nans (which is the default), we need to fix the ccp so that the sNaN is converted to qNaN when the value is propagated. With -fsignaling-nans, we need to ensure that we disable the folding since it reduces the number of exceptions visible with sNaNs. I notice that even if I disable ccp, other optimizations like dead code elimination with cddce also needs to be disabled. Let me know if you agree.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #6 from Sujoy --- (In reply to jos...@codesourcery.com from comment #5) > With -fno-signaling-nans we don't really care about the result value. I am not sure about this. -fno-signaling-nans is default and the original issue mentions that "under default exception handling, any operation signaling an invalid operation exception and for which a floating-point result is to be delivered shall deliver a quiet NaN". If we have to honor the default exception handling case, we need to convert the sNaN to qNaN here. Let me know if I missed something. > More precisely, exceptions are relevant with -fsignaling-nans > -ftrapping-math but even with -fno-trapping-math it's still visible if the > result is wrongly a sNaN instead of a qNaN. (-ftrapping-math is the > default. It's not clear there's any use for -fsignaling-nans > -fno-trapping-math. But -fsignaling-nans is the option that says there > may be signaling NaN arguments, and -ftrapping-math is the option that > says we care about exceptions.) The man page entry for -fno-trapping-math says "This option requires that -fno-signaling-nans be in effect." The description for -fsignaling-nans says "This option implies -ftrapping-math." Hence, only the following combinations should be valid - 1) -fno-trapping-math and -fno-signaling-nans 2) -ftrapping-math and -fno-signaling-nans (default) 3) -ftrapping-math and -fsignaling-nans Here is my understanding - For case 1, we can go ahead with optimizations that may remove operations that may lead to exceptions, as we don't care about them. Also, we convert sNaN to qNaN since -fno-signaling-nans is on. For case 2, we can do the transformation like folding and they should convert sNaN to qNaN since -fno-signaling-nans is on. For case 3, we have to disallow certain transformation so that any operation leading to exception due to sNaN is not optimized away. > The *number* of exceptions isn't relevant, only the set raised at any > point (e.g. function call) where the raised exceptions may be tested or > modified; it's valid to change one nonzero number of times raising a given > exception between two such points to a different nonzero number of times > raising that exception. Thanks for this information. Does this mean that the man page description of -fsignaling-nans is too restrictive? > I'm sure there are lots of optimizations that wrongly discard exceptions, > whether for signaling NaNs or other operands. > > Roughly, the present -ftrapping-math seems to be implemented as meaning > that an expression shouldn't be transformed to change the exceptions > raised, but exceptions aren't treated as side effects so it can still be > discarded if apparently unused, or moved past code that might test or > modify exceptions. Something stricter that actually follows Annex F would > treat exceptions more like side effects and eliminate a lot of code > movement / dead code removal. It might be less suitable for the default > compilation mode, however. > > I expect there are plenty of bugs even with that more limited description > of what -ftrapping-math tries to do. I was referring to the Annex F of C99 ISO IEC 9899 1999, it says - "An operation on constants that raises no floating-point exception can be folded during translation, except, if the state of the FENV_ACCESS pragma is ‘‘on’..." What is the equivalent of checking FENV_ACCESS on within gcc? As for this issue, do you think modifying gcc to handle the default case would be the right start? Regards, Sujoy
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #8 from Sujoy ---
(In reply to jos...@codesourcery.com from comment #7)
> With -fno-signaling-nans, signaling NaN representations are trap
> representations - the compiler can assume that nothing ever manipulated as
> a floating-point value has such a representation. (It cannot assume
> anything about unions of floating-point and other types where the
> floating-point field is not accessed. But 58416 is a bug even in the
> absence of -fsignaling-nans.)
Ok, have a further question though. For the current test case, which has the
following code -
float sNaN = __builtin_nansf ("")
the sNaN will have a signaling NaN representation. What does
-fno-signaling-nans imply for this situation? Should the compiler assume that
this signaling NaN need not be preserved as this would not lead to a trap? In
other words, can the compiler assume that it can carry out optimizations
without having to care for traps?
As for 58416, looks like this got resolved with revision 196841, where the
i386.md now generates movsd instructions depending on type attribute.
> In both these cases, we formally don't care about the result (but if
> folding, it still would seem odd to fold incorrectly, so may as well fold
> to a qNaN).
Ok.
> This point is nothing to do with -fsignaling-nans. It's a simple matter
> of C11 F.9.1 paragraph 3, "This specification does not require support for
> trap handlers that maintain information about the order or count of
> floating-point exceptions" (which TS 18661-1:2014, adding support for
> signaling NaNs, doesn't change). But it's true that any references to a
> number of exceptions should make clear it's only referring to the
> distinction between zero and nonzero numbers.
Right, I think I interpreted the man page text "number of exceptions visible
with signaling NaNs". It probably means the number of types of exceptions and
not the number of exceptions for any given type.
> Local fixes for particular signaling NaNs issues seem reasonable (as in:
> if you fold an operation involving a signaling NaN, you may as well quiet
> it in the process, even though signaling NaNs aren't meant to occur in any
> mode where folding them is likely to be safe).
Thanks, I will prepare a patch to do this. Should I wait for the bug to move to
"new" state, or is it ok to send a fix even though it is marked as
"unconfirmed"?
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #10 from Sujoy --- (In reply to jos...@codesourcery.com from comment #9) > There is no need to wait for bugs to move state (rather, if working on a > bug, you may wish to change it to ASSIGNED yourself with yourself as > assignee). Ok, I started working on this and hope to send a fix soon.
