[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 26 Oct 2019, arieltorti14 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229
> 
> --- Comment #2 from Ariel Torti <arieltorti14 at gmail dot com> ---
> (In reply to joseph@codesourcery.com from comment #1)
> > Built-in functions related to integer overflow should be defined in terms 
> > of the C abstract machine model, not in terms of processor flags.
> 
> They should indeed, but what I want to implement here is a function that
> outputs the value of the OV flag, a behavior that cannot be achieved as a
> consequence of optimizations.

You can write an asm to access a flag, it will just be whatever value the 
flag has for whatever code the compiler found matched the language-level 
semantics of your code, which may have nothing to do with your notion of 
what the flag "should" be.

Language semantics are only matched to processor features at ABI 
boundaries, not within functions (and not across calls to inline / static 
functions etc. either, because those aren't ABI boundaries; any good 
language feature in this area also needs to work in the presence of 
multiple functions, and of inlining and similar transformations, not just 
where the arithmetic is in the same function as the code that cares about 
whether it overflowed).

> > See recent WG14 discussions around this issue for various language design 
> > ideas.
> 
> Could you provide a link to the discussion in WG14 ? I'm not subscribed to it
> and I cannot find it.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2428.pdf has discussions 
of some ideas.  I wasn't dialed into the WG14 meeting at the point where 
that paper was discussed so you'll need to wait for the Ithaca minutes for 
more on what WG14 thought of it there.