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 jos...@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.