* Paul Eggert wrote on Wed, Dec 20, 2006 at 08:38:56AM CET:
> Here's a patch that would allow programs to avoid running afoul of
> unexpected gotchas with signed integer overflow when being compiled by
> GCC using the default compilation flags. It also attempts to document
> the issue. Comments?
Ralf Wildenhues wrote:
* Paul Eggert wrote on Wed, Dec 20, 2006 at 08:38:56AM CET:
Here's a patch that would allow programs to avoid running afoul of
unexpected gotchas with signed integer overflow when being compiled by
GCC using the default compilation flags. It also attempts to document
the
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> I have never, ever found a problem with the optimizations
> that GCC currently implements when -fwrapv is given;
Surely you meant to write "when -fwrapv is _not_ given"?
Anyway, this thread started because someone found a problem
with gcc -O2 (without
Surely you meant to write "when -fwrapv is _not_ given"?
Yes, sorry.
Now -fwrapv in its current form is overkill, since it
disables many useful optimizations that won't break anything
(notably loop induction in the common case). Perhaps we can
think of a stripped-down version that enables t
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> However, prudence suggests that, if a maintainer
>> expresses no preference, the Autoconf default should prefer
>> safety to speed when we get into tricky areas like this.
>
> I disagree. One such bug (and one in loops, in particular) went
> unnoticed
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02126.html
Sorry, I don't understand the point of this reference. Are
you saying that -fwrapv sometimes speeds things up? Or that
-O2 without -fwrapv is often harmless in practice? (The URL
suggests both things.) If so, I agree.
That hunk was ad
This is a horrible idea. Please do not cripple the compiler on projects
that use Autoconf because some people write code that makes assumptions it
shouldn't. This would be like automatically adding -fpermissive to
CXXFLAGS or adding -fno-strict-aliasing to CFLAGS, and just as wrong.
--
Russ All
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> But the code here
>> is not broken -- it merely assumes C99 + wrapping LIA-1,
>> which is a perfectly reasonable assumption
>
> You said that when loops are involved, it's not.
I don't insist on -fwrapv everywhere. But I do want
applications to work w
> In that case, we should make the Autoconf change optional.
> I'll propose a further patch along those lines.
OK, here's that proposed patch to Autoconf. Also, this patch attempts
to discuss the matter better in the documentation. The documentation
was by far the hardest part of the patch to wr
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizations now default to "-O2 -fwrapv"
> instead of to "-O2". This partly at
> For this _specific_ instance of the general problem, C++ users could
> use numeric_limits::max() and get away with it, but I don't
> believe such a solution (or the one you propose or similar I've seen)
> to this specific instance generalizes to portable, readable and
> maintainable solution to t
>
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> > optional second argument specifying the default optimization
> > options for GCC. These optimizations now default to "-O2 -fwrapv"
> > instead of to "-O2". This pa
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Paul Eggert <[EMAIL PROTECTED]> writes:
| >
| > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > > optional second argument specifying the default optimization
| > > options for GCC. These optimizations now default to "-
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Paul Eggert <[EMAIL PROTECTED]> writes:
|
| > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > optional second argument specifying the default optimization
| > options for GCC. These optimizations now default to "-O2 -fw
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Paul Eggert <[EMAIL PROTECTED]> writes:
> | >
> | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> | > > optional second argument specifying the default optimization
> | > > options for GCC.
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > Paul Eggert <[EMAIL PROTECTED]> writes:
| > | >
| > | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > | > > optional second argument specifying the
>
> | > If the above is the only without Autoconf change, I would highly
> | > recommend Autoconf change if GCC optimizers highly value benchmarks
> | > over running real world code.
> |
> | Which one, mine or Paul's?
>
> If what you propose is the only way out, and there is no way to make
> GCC
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > If the above is the only without Autoconf change, I would highly
| > | > recommend Autoconf change if GCC optimizers highly value benchmarks
| > | > over running real world code.
| > |
| > | Which one, mine or Paul's?
| >
| > If what you pro
On 29 Dec 2006 07:55:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizati
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the change recently and got yy reports. That might say
something about both compiler
On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the chan
Daniel Berlin wrote:
I'm sure no matter what argument i come up with, you'll just explain it away.
The reality is the majority of our users seem to care more about
whether they have to write "typename" in front of certain declarations
than they do about signed integer overflow.
I have no idea
On 12/29/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm sure no matter what argument i come up with, you'll just explain it away.
> The reality is the majority of our users seem to care more about
> whether they have to write "typename" in front of certain declarations
>
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me was that since they made their change in
| > | 1991, they have had *1* pers
On 29 Dec 2006 20:15:01 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm,
Otherwise, you have a serious problem hearing anything contrary to
your
On 29 Dec 2006 21:04:08 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I fully appreciate that there is a real problem here which
> needs to be addressed, but this does not seem like the
> best solution to me.
I agree. It's meant to be a stopgap. I support coming up
with a better solution than the stopgap.
> The resu
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Does anybody think that Paul's proposed patch to autoconf would be
> better than changing VRP?
I don't.
I haven't noticed anyone else addressing this question,
which I think is a good one.
I don
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Nobody has yet showed that any significant number of
> programs actually rely on this undefined behavior.
GCC itself relies on wrapv semantics. As does glibc. And
coreutils. And GNU tar. And Python. I'm sure there are
many other significant progr
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| This is so funny coming from you it's ridiculous.
You have decided to get personal, that certainly will elevate the
debate I suppose.
I don't see what is so funny about you coming and declaring minority
any voice, data that go contrary to you
Paul Eggert wrote:
In practice, I expect that most C programmers probably
assume wrapv semantics, if only unconsciously. The minimal
C Standard may not entitle them to that assumption, but they
assume it anyway. Part of this is the Java influence no
doubt. Sorry, but that is just the way the
Ian Lance Taylor wrote:
I fully appreciate that there is a real problem here which needs to be
addressed, but this does not seem like the best solution to me. A
great number of C programs are built using autoconf. If we make this
change, then they will all be built with -fwrapv. That will disa
* Andrew Pinski:
>> If what you propose is the only way out, and there is no way to make
>> GCC optimizers reasonable, then I believe Paul's proposal is the next
>> option.
>
> But that still does not address the issue is that this is not just about
> GCC any more since autoconf can be used many
* Daniel Berlin:
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
> Given this seems to be some small number of people and some small
> amount of code (since nobody has produced any examples showing this
> problem is rampant, in which case i'm
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this should be reflected in the compiler's
> defaults.
I absolutely
On Fri, 29 Dec 2006, Daniel Berlin wrote:
[...]
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
Wrong. Many people have relied on that "feature" because they thought it
was leagal and haven't had the time to check every piece of code they
wrot
On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this shou
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like this into a makefile
> On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>> I think it would be a very bad choice for the GNU project to work
>> around itself. If we can't come to an agreement on the list,
>> please ask the Steering Committee. This is a textbook example of
>> what they're for.
The issue doe
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the relevant section/paragraph in C99 standard
> where it allows
>
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
> > Nobody has yet showed that any significant number of
> > programs actually rely on this undefined behavior.
>
> GCC itself relies on wrapv semantics. As does glibc. And
> coreutils. And GNU tar. And Python. I'm sure there are
> many othe
[EMAIL PROTECTED] (Richard Kenner) writes:
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
> one assumes wrapping semantics?
>
> (2) In the current SPEC, how many programs benefit from undefined ov
>> GCC itself relies on wrapv semantics. As does glibc. And
>> coreutils. And GNU tar. And Python. I'm sure there are
>> many other significant programs. I don't have time to do a
>> comprehensive survey right now.
>
> Where does GCC rely on that? I don't see it anywhere?
It's not like the
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrap
On 12/29/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > I'm not sure what data you're asking for.
>
> Here's the data *I'd* like to see:
>
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPE
Just to address the other compiler issue
No, they will work on other compilers, since 'configure'
won't use -O2 with those other compilers.
icc defaults to -O2 without any options, so unless you are passing
-O0, it will enable this.
Unless you know of some real-world C compiler that breaks
> Wrong. Many people have relied on that "feature" because they thought it
> was leagal and haven't had the time to check every piece of code they
> wrote for conformance with the holy standard. And they don't have the time
> now to walk trough the work of their lifetime to see where they did wrong
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrapping semantics?
(2) In the current SPEC, how many prog
Paul Eggert wrote:
> I don't feel a strong need for 'configure' to default to
> -fstrict-aliasing with GCC. Application code that violates
> strict aliasing assumptions is often unportable in practice
> for other reasons, and needs to be rewritten anyway, even if
> optimization is disabled. So -f
> Those questions are more for the opponents of -fwrapv, so
> I'll let them answer them. But why are they relevant?
> Having -fwrapv on by default shouldn't affect your SPEC
> score, since you can always compile with -fnowrapv if the
> application doesn't assume wraparound.
(1) If -fwrapv isn't t
> But since you asked, I just now did a quick scan of
> gcc-4.3-20061223 (nothing fancy -- just 'grep -r') and the first
> example I found was this line of code in gcc/stor-layout.c's
> excess_unit_span function:
>
> /* Note that the calculation of OFFSET might overflow; we calculate it so
>
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> the much more often reported problems are with
> -fstrict-aliasing, and this one also doesn't get any
> special treatment by autoconf.
That's a good point, and it somewhat counterbalances the
opposing point that -O2 does not currently imp
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the releva
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Just to address the other compiler issue
>>
>> No, they will work on other compilers, since 'configure'
>> won't use -O2 with those other compilers.
>
> icc defaults to -O2 without any options, so unless you are passing
> -O0, it will enable this.
Tha
>> Nor would I relish the prospect of keeping wrapv assumptions out of
>> GCC as other developers make further contributions, as the wrapv
>> assumption is so natural and pervasive.
>
> It's neither natural not pervasive to me! I would never write code
> that way
That's great, but GCC has had man
>
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
> > Just to address the other compiler issue
> >>
> >> No, they will work on other compilers, since 'configure'
> >> won't use -O2 with those other compilers.
> >
> > icc defaults to -O2 without any options, so unless you are passing
> > -O0, it w
Andrew Pinski <[EMAIL PROTECTED]> writes:
> You are just giving up on the undefined issue
No, I'm taking a multiple-phase approach. I'm not giving up at all.
Please don't confuse the first phase with the whole thing.
The first phase is to keep existing GNU software working with GCC 4.2
and late
Paul Eggert wrote:
Nor would I relish the prospect of keeping wrapv assumptions out of
GCC as other developers make further contributions, as the wrapv
assumption is so natural and pervasive.
It's neither natural not pervasive to me! I would never write code
that way
That's great, but GCC has
On 12/30/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
For example, GCC itself assumes wrapv semantics internally,
but according to the -fwrapv opponents GCC is obviously "at
fault" here and should be fixed, so that shouldn't count,
right? (If that's the way the data will be collected, I
think I k
Paul Eggert wrote:
(2) In the current SPEC, how many programs benefit from undefined overflow
semantics and how much does each benefit?
Those questions are more for the opponents of -fwrapv, so
I'll let them answer them. But why are they relevant?
It's relevant in a "did my system just becom
Paul Eggert wrote:
That's great, but GCC has had many other hands stirring the pot.
I daresay a careful scan would come up with many other examples of
undefined behavior due to signed integer overflow. (No doubt
you'll be appalled by them as well, but there they are.)
That's handwaving, not ev
Paul Eggert wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like
> Paul Eggert wrote:
> > That's great, but GCC has had many other hands stirring the pot.
> > I daresay a careful scan would come up with many other examples of
> > undefined behavior due to signed integer overflow. (No doubt
> > you'll be appalled by them as well, but there they are.)
>
> That's
> Not so appalling really, given that relying on wrapping is as has
> been pointed out in this thread, the most natural and convenient way
> of testing for overflow. It is really *quite* difficult to test for
> overflow while avoiding overflow, and this is something that is
> probably not in the le
> Where does GCC assume wrapv semantics?
The macro OVERFLOW_SUM_SIGN in fold-const.c.
Richard Kenner wrote:
Not so appalling really, given that relying on wrapping is as has
been pointed out in this thread, the most natural and convenient way
of testing for overflow. It is really *quite* difficult to test for
overflow while avoiding overflow, and this is something that is
probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bernd Schmidt on 12/30/2006 3:24 AM:
> Paul Eggert wrote:
>> That's great, but GCC has had many other hands stirring the pot.
>> I daresay a careful scan would come up with many other examples of
>> undefined behavior due to signed integer
Richard B. Kreckel wrote:
Bottom line: without such a warning, -fwrapv should be the default and
should not be turned off by any -O option.
I agree with this. At least until -O2 no optimizations should be done
by default if they can modify the result of an operation even if this
might be a nai
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
[...]
| I'd like to see a -Warning flag added to GCC to spot places where GCC does
| something potentially too aggressive. Having that would do two things, it
| would make it easier for maintainers to audit their code, and it would
| make it easier fo
[EMAIL PROTECTED] (Richard Kenner) writes:
> Date: Sat, 30 Dec 2006 08:01:37 EST
> I'd actually be very surprised if there were ANYPLACE where GCC has code
> that's otherwise correct but which would malfunction if signed overflow
> weren't required to wrap.
> Date: Sat, 30 Dec 2006 08:09:33 EST
>
> Here's an example from the intprops module of gnulib.
These are interesting case.
Note that all the computations are constant-folded.
And I think this points the fact that we can "have our cake and eat it too"
in many cases. Everything we're seeing points to the fact that the cases
where as
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Here's an example from the intprops module of gnulib.
|
| These are interesting case.
|
| Note that all the computations are constant-folded.
|
| And I think this points the fact that we can "have our cake and eat it too"
| in many cases. Everyt
On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Here's an example from the intprops module of gnulib.
|
| These are interesting case.
|
| Note that all the computations are constant-folded.
|
| And I think this points the
> [EMAIL PROTECTED] (Richard Kenner) writes:
>
> > Date: Sat, 30 Dec 2006 08:01:37 EST
> > I'd actually be very surprised if there were ANYPLACE where GCC has code
> > that's otherwise correct but which would malfunction if signed overflow
> > weren't required to wrap.
>
> > Date: Sat, 30 Dec 200
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > | > Here's an example from the intprops module of gnulib.
| > |
| > | These are interesting case.
| > |
| > | Note th
On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| >/* Wrapper around int_const_binop. If the operation overflows and we
| > are not
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]> writes:
| >
| > | On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| > | <[EMAIL PROTECTED]> wrote:
| > | >/* Wrapper around i
> What would you suggest this function to do, based on your comments?
I'm not familiar enough with VRP to answer at that level, but at a higher
level, what I'd advocate is that the *generator* of information would track
things both ways, assuming wrapping and non-wrapping semantics (of course, if
> Note the interesting places in VRP where it assumes undefined signed
> overflow is in compare_values -- we use the undefinedness to fold
> comparisons.
Unfortunately, comparisons are the trickiest case because you have to
be careful to avoid deleting a comparison that exists to see if overflow
o
[EMAIL PROTECTED] (Richard Kenner) writes:
>> I'm sure there are many other instances where the GCC source
>> code assumes wrapv semantics.
>
> I'm not.
I am. I just now looked and found another example.
gcc-4.3-20061223/gcc/fold-const.c's neg_double function
contains this line:
*hv = -
> I am. I just now looked and found another example.
> gcc-4.3-20061223/gcc/fold-const.c's neg_double function
> contains this line:
>
> *hv = - h1;
OK, granted. But it is followed by code testing for overflow.
That means that (1) we can find these by looking for cases where we are
setti
Paul Eggert wrote:
For writing new code, it's easy: the C standard is all
that should be assumed. Old code should be modified, as
time allows, to be consistent with that standard.
This may be the policy of the GCC developers for the code
they maintain, but it's not a realistic policy for
ever
Richard Kenner wrote:
I can't speak for any other GCC developer, but I personally am quite
comfortable viewing any code that assumes wrapping semantics as broken
and needing fixing with the exception of these cases of checking for
overflow: there simply is no good way in C to do these checks in
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| By the way, does traditional C really assume this? Is
| it the case that the original K&R document guarantees
| wrapping, or is what you meant here "traditional C
| compilers". There is quite a difference!
K&R C leaves arithmetic overflow undefine
(again I apologize for breaking the thread),
Here is the reply I sent properly threaded
Gaby said
> K&R C leaves arithmetic overflow undefined (except for unsigned
> types), in the sense that you get whatever the underlying hardware
> gives you. If it traps, you get trapped. If it wraps, you g
On Sat, 30 Dec 2006, Bernd Schmidt wrote:
> Paul Eggert wrote:
> > "Richard Guenther" <[EMAIL PROTECTED]> writes:
> >
> >> Authors of the affected programs should adjust their makefiles
> >
> > That is what the proposed patch is for. It gives a way for
> > developers to adjust their makefiles.
>
On Sat, 30 Dec 2006, Gabriel Dos Reis wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd like to see a -Warning flag added to GCC to spot places where GCC does
> | something potentially too aggressive. Having that would do two things, it
> | would make it easier for maintai
On 30 December 2006 11:49, Robert Dewar wrote:
> Paul Eggert wrote:
Nor would I relish the prospect of keeping wrapv assumptions out of
GCC as other developers make further contributions, as the wrapv
assumption is so natural and pervasive.
>>> It's neither natural not pervasive to
Gabriel Dos Reis wrote:
I have been looking into infer_loop_bounds_from_signedness() called
from infer_loop_bounds_from_undefined().
At some places, nowrap_type_p() is used but this function operates
only on types, so there will be too many false positive there; yet we
will miss warning through
>
> Gabriel Dos Reis wrote:
>
> > I have been looking into infer_loop_bounds_from_signedness() called
> > from infer_loop_bounds_from_undefined().
> > At some places, nowrap_type_p() is used but this function operates
> > only on types, so there will be too many false positive there; yet we
> > w
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I have been looking into infer_loop_bounds_from_signedness() called
| > from infer_loop_bounds_from_undefined().
| > At some places, nowrap_type_p() is used but this function operates
| > only on types, so there will be too
Andrew Pinski <[EMAIL PROTECTED]> writes:
[...]
| Again, please don't this the default for Fortran as integer
| overflow has been undefined since at least 1977 so I don't think
| it is a good idea for GCC in general anyways as evidence of Fortran.
The -Wundefined I'm working on is for C and C++
Andrew Pinski wrote:
-fwrapv-in-all-cases-except-loop-bounds
Again, please don't this the default for Fortran as integer
overflow has been undefined since at least 1977 so I don't think
it is a good idea for GCC in general anyways as evidence of Fortran.
-- Pinski
Well the question is whet
Richard Kenner wrote:
Note the interesting places in VRP where it assumes undefined signed
overflow is in compare_values -- we use the undefinedness to fold
comparisons.
Unfortunately, comparisons are the trickiest case because you have to
be careful to avoid deleting a comparison that exists t
Andrew Pinski wrote:
It does buy you something for code like:
if (a - 10 < 20)
Well that particular example is far fetched in code that people
expect to run efficiently, but with a bit of effort you could
come up with a more realistic example.
Compilers are always full of such optimizations wh
Gaby said
K&R C leaves arithmetic overflow undefined (except for unsigned
types), in the sense that you get whatever the underlying hardware
gives you. If it traps, you get trapped. If it wraps, you get wrapped.
Is that really what the K&R book says, or just what compilers typically
did? My mem
(first, sorry for breaking the thread, pilot error on my part)
Here is the message again properly threaded. The other broken
thread by dewar's evil twin can be discarded.
Andrew Pinski wrote:
It does buy you something for code like:
if (a - 10 < 20)
Well that particular example is far fetch
On Sat, Dec 30, 2006 at 04:13:08PM -0800, Paul Eggert wrote:
> I am. I just now looked and found another example.
> gcc-4.3-20061223/gcc/fold-const.c's neg_double function
> contains this line:
>
> *hv = - h1;
>
> This one is a bit less obvious because it doesn't have a
> "Danger Will Robi
>
> Andrew Pinski wrote:
>
> >> -fwrapv-in-all-cases-except-loop-bounds
> >
> >
> > Again, please don't this the default for Fortran as integer
> > overflow has been undefined since at least 1977 so I don't think
> > it is a good idea for GCC in general anyways as evidence of Fortran.
> >
> >
1 - 100 of 287 matches
Mail list logo
