[Bug tree-optimization/69682] New: expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682

Bug ID: 69682
   Summary: expression (a && (b==c)) with side effects rewritten
to ((b==c) & a)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtliang at synopsys dot com
  Target Milestone: ---

Created attachment 37586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37586&action=edit
test case

The attached test case should print pass in a cases but fails with SIGFPE when
built at -O1 and run with "1" to enable signaling NaNs.

Building with -fdump-tree-all shows that at -O0 the 004t.gimple for { if (same
&& (oldPriority == oldGroup)); } expands into { if (same) if (oldPriority ==
oldGroup); } as expected, but that at -O1 it's already transformed into { if
(oldPriority == oldGroup) & same); } .

At this point, oldPriority holds a signaling NaN but shouldn't be evaluated
because same is false.

With -fverbose-asm, I've gotten the 30+ extra flags that are set between -O0
and -O1 and have tried building the code with -O0 + all flags and with -O1 +
-fno-flags.  Neither way seems to make any difference.

By the way, even if the initial tree is generated properly, there is another
known issue where ifcombine will join them together again and that step will
need to be suppressed for testing purposes.  See bug 69308 for details.

[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682

--- Comment #1 from Mike Liang  ---
Created attachment 37587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37587&action=edit
Makefile

[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682

--- Comment #2 from Mike Liang  ---
Created attachment 37588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37588&action=edit
run tests

[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682

--- Comment #4 from Mike Liang  ---
I see.  With -fsignalling-nans the 004t.gimple at -O1 is generated as I
expected and all is well.  Thanks for you help!

[Bug tree-optimization/69308] New: ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

Bug ID: 69308
   Summary: ifcombine joins together floating point expression
with side effects
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtliang at synopsys dot com
  Target Milestone: ---

Created attachment 37366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37366&action=edit
test case

With floating point exceptions enabled, passing a signaling NaN into the
expression ( !isnan(x) && x > 0.0 ) ends up with the second half evaluating and
raising an FPE.  Compiling with the -fsignaling-nans flag does not help, and
the only way to get past this is to disable this pass with the
-fdisable-tree-ifcombine flag.

Should ifcombine look at the -fsignaling-nans flag and disqualify floating
point expressions for that case?

The attached test case should print "pass" for all cases.
With the current GCC the optimized build fails with FPE unless built with
ifcombine disabled.

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

--- Comment #1 from Mike Liang  ---
Created attachment 37367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37367&action=edit
Makefile

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

--- Comment #2 from Mike Liang  ---
Created attachment 37369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37369&action=edit
run tests

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

--- Comment #4 from Mike Liang  ---
The test case passes both a signaling NaN and a quiet NaN through the
expression and FPE is only triggered by the signaling NaN.

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

--- Comment #6 from Mike Liang  ---
Oh, I see.  You're saying this can be a problem for both QNaN and SNaN because
an ordered comparison instruction could be generated.  Does this mean floating
point expressions should never be combined?

[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects

[mtliang at synopsys dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308

--- Comment #8 from Mike Liang  ---
No, -ftrapping-math does not change the outcome.
I'm building x86_64 on RHEL 6.6.