[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-14 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

Heinrich Seebauer  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Heinrich Seebauer  ---
Alexander, you are right, it is only strange behaviour. Using -O1 drops the
'then' clause, but the results are the same, if one takes a broader view.

The program deals with controlling schedules using actual time. Each test run
has different input values (current UTC time). I set up a situation where I was
able to control system time, and the outcomes were consistent, either using -O0
oe -O1.

What confused me was the fact that -O2/-Os did NOT drop the then clause. So -O2
ist not just optimizing the -O1 outcome, but different from the beginning of
the optimizer pass.

I apologize for not getting this point quickly.
Thank you very much for your support and your work for the commuinty,

kind regards
Heinrich

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #9 from Alexander Monakov  ---
Thanks. I still don't see what's wrong. Are you testing only by single-stepping
in gdb, or does your program overall behave differently with/without
if-conversion?

In other words, do you see if-conversion causing wrong code, or only worse
debug experience?

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #8 from Heinrich Seebauer  ---
Sorry, my comment was lost completely after uploading the attachment.
Try again...

So I hope, I got this right.

-fdbg-cnt=if_conversion:xx,if_after_combine:yy

xx  yy  result
---
20  20  success
20  21  fail
0   21  fail
21  20  fail

tested with -fdbg-cnt=if_conversion:20,if_after_combine:21 -fno-if-conversion
and got functioning code.

I did gdb stepping in the source file where I observed, that the condition was
true, but the branch was not executed. Same with the tests here - they were all
strepped via source code.

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #7 from Heinrich Seebauer  ---
Created attachment 45232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45232=edit
zipped asm files for three cases

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #6 from Alexander Monakov  ---
And just to be sure, can you confirm that -fno-if-conversion changes program
behavior (the testcase is not executable so I cannot check), and the issue is
not about debug info quality (i.e. that single-stepping in the debugger does
not behave as you expect, but overall the function computes correct values)?

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #5 from Alexander Monakov  ---
The code shown in the opening comment looks fine to me, so please isolate the
issue further using debug counters.

Add -fdbg-cnt=if_conversion:99,if_after_combine:99 to -O1. This should lead to
broken code as with plain -O1.

Add -fdbg-cnt=if_conversion:0,if_after_combine:0 to -O1. This should lead to
correct code as with -O1 -fno-if-conversion.

Then you can try 99/0 and 0/99 combinations to find which of two passes is
broken. After that you can bisect by the value of debug counter to find exact
threshold at which it becomes broken (e.g. 0/42 works, 0/43 breaks). Please
attach the two resulting assembly dumps obtained with -S after that.

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #4 from Heinrich Seebauer  ---
To isolate the cause, I suppressed several optimization options from thge -O1
group. Adding -fno-if-conversion to the options got the code correct, other -O1
options didn't change anything.
I think, this is some strong evidence that -fif-conversion causes the bug.

Proposed workaround: use option "-fno-if-conversion" in combination with -O1.

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #3 from Heinrich Seebauer  ---
Thanks, Alexander, for your advice, I will try to isolate this symptom further.
Added the attachment ...

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread heinrich.seebauer at swistec dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

--- Comment #2 from Heinrich Seebauer  ---
Created attachment 45227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45227=edit
precompiled source of fsch.c

[Bug c/88481] -O1 causes optimizer to drop 'then' clause in conditional

2018-12-13 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-12-13
 CC||amonakov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Alexander Monakov  ---
Without -O, optimization passes are not enabled, even if individual -f options
are passed on the command line. If you want to manually find optimizations that
affect the outcome, you need to start with -O1 and add -fno options to
selectively disable optimizations.

The attachment is missing, so changing bug status to "waiting".