https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109196
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Simpler reproducer:
https://godbolt.org/z/h3WcPP9q8
Looking at the gimple dump, I see:
<bb 5> :
iftmp.0_14 = 1;
goto <bb 7>; [INV]
<bb 6> :
iftmp.0_13 = 0;
<bb 7> :
# iftmp.0_4 = PHI <iftmp.0_14(5), iftmp.0_13(6)>
__analyzer_eval (iftmp.0_4);
i.e. that __analyzer_eval is being called with either 0 or 1. What you're
seeing here is a result of how the analyzer is merging state along different
paths.
Adding -fno-analyzer-state-merge:
https://godbolt.org/z/7Tn5xqo4x
converts the output to:
<source>: In function 'b':
<source>:9:9: warning: TRUE
9 | __analyzer_eval(((a())<(0))||((a())==(0)));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:9:9: warning: FALSE
i.e. the result of ||-ing the conditions could be true, and it could be false.
__analyzer_eval is intended as a feature for debugging the analyzer, rather
than being end-user-facing, so I'm going to mark this as WONTFIX. Hope this
makes sense.
