https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #19 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Marc Glisse from comment #15)
> > Gcc's RTL internal representation sees the same thing for your code and for
> >
> > int diff = (unsigned)a - (unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #18 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote:
> In the testcase, there is nothing that violates ABI. It all happens in "g"
> that
> passes calculated result to a function. Selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #17 from Uroš Bizjak ---
(In reply to Marc Glisse from comment #15)
> Gcc's RTL internal representation sees the same thing for your code and for
>
> int diff = (unsigned)a - (unsigned)b;
>
> llvm represents both differently and g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> > It's valid to call a function in another file compiled with another
> > compiler that follows the ABI, or compiled with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #15 from Marc Glisse ---
Gcc's RTL internal representation sees the same thing for your code and for
int diff = (unsigned)a - (unsigned)b;
llvm represents both differently and generates different code for the two.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #14 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #13)
> It looks like -fstrict-overflow flag is there to enable exactly this kind of
> optimization.
Yes, and it is set by default. Meaning that ALL code has to be r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #13 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Maxim Egorushkin from comment #6)
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
> > not mistaken. So, this wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #11 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #12 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #9 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #6)
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a valid example, would it?
An example of "da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #10 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #5)
> > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
> > DF) undefined on funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #8 from Uroš Bizjak ---
(In reply to jos...@codesourcery.com from comment #5)
> Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
> DF) undefined on function entry and return. Thus, a function can never
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a valid ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #6 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Maxim Egorushkin from comment #2)
>
> > Could you provide an example where that "dangerous optimization" would break
> > well-formed code please?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #5 from joseph at codesourcery dot com ---
Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
DF) undefined on function entry and return. Thus, a function can never
assume anything about the value of OF unle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #4 from Uroš Bizjak ---
$ gcc --version
gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #3 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #2)
> Could you provide an example where that "dangerous optimization" would break
> well-formed code please?
--cut here--
#include
void positive (int a) { printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #2 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to Maxim Egorushkin from comment #0)
> > g function assembly contains a superflous test instruction. It should not
> > generate that instruction, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #1 from Uroš Bizjak ---
(In reply to Maxim Egorushkin from comment #0)
> g function assembly contains a superflous test instruction. It should not
> generate that instruction, since sub instruction already sets all the
> required flag
19 matches
Mail list logo
