[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 Ariel Torti changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Ariel Torti --- (In reply to jos...@codesourcery.com from comment #4) > On Sat, 26 Oct 2019, arieltorti14 at gmail dot com wrote: > > 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). Fair point, I can see why it would be very problematic, didn't really knew the full scope when I considered the issue.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 --- Comment #4 from 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 --- > (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.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-26 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- >One could make the code more readable by using: This is very problematic. How do you know what statement, __builtin_overflow_p should be associated with? Take C++ code, where the types of a and b are not integer, how do you handle that? Likewise about floating point types? What does it mean to overflow floating point types. Even unsigned types, there is no overflow for them in the C/C++ language itself but the definitions of __builtin_umul*_overflow describe it as not a property of the language but rather if the multiple would not fit exactly from the infinite percission case.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 --- Comment #2 from Ariel Torti --- (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. > 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.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 --- Comment #1 from joseph at codesourcery dot com --- Built-in functions related to integer overflow should be defined in terms of the C abstract machine model, not in terms of processor flags. See recent WG14 discussions around this issue for various language design ideas.
