Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> for this specific function (vrp_int_const_binop), I'm issuing a
> warning inside the else-if branch that tests for the overflowed
> result. I'm unclear why that is a false positive since the result is
> known to overflow. Could you elaborate?
Wit
Joe Buck <[EMAIL PROTECTED]> writes:
>> > *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1;
>>
>> Can't that conversion overflow?
>
> Not on a two's complement machine,
Sure it can. Suppose we have a 64-bit two's complement
machine with no padding, and h1 is - 2**63. Then (unsigned
HOS
On Sat, Dec 30, 2006 at 08:57:12PM -0500, Richard Kenner wrote:
> > I suppose there is
> >
> > *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1;
> >
> > to make it safe.
>
> Can't that conversion overflow?
Not on a two's complement machine, and I know of no gcc ports
to a non-two's-comp
On Sat, Dec 30, 2006 at 09:52:24PM -0800, Paul Eggert wrote:
> Wait, though: K&Rv2 is post-C89. If memory serves, it was C89
> that established the rule that signed integer overflow has
> undefined behavior whereas unsigned overflow is well-defined.
I don't have the original K&R book so can't tel
[EMAIL PROTECTED] (Bob Proulx) writes:
> If this bootstrapping issue could be avoided it would be nice.
I installed this patch to do that. Thanks for reporting it. Also, I
noticed the code uses "tail -1" which POSIX does not require support
for, so I fixed that too.
2006-12-30 Paul Eggert <[
Robert Dewar <[EMAIL PROTECTED]> writes:
> Of course there is a way out that satisfies both
> sides here, and that is to declare that gcc code
> should adhere to the standard *including* LIA
> and then make sure the default mode of gcc is
> LIA compliant.
Yes, this should solve the problem. The
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Maybe the answer (as far as autoconf goes) is that autoconf tests should be
> compiled at -O0.
No, since one of the first rules of Autoconf is that you should test
the compiler with the same options that you intend to use use when
compiling. Otherwise th
[EMAIL PROTECTED] (Richard Kenner) writes:
> I found my copy of K&R (Second Edition)
Robert Dewar <[EMAIL PROTECTED]> writes:
> so in fact the new C standard has changed
> nothing from a definitional point of view,
Wait, though: K&Rv2 is post-C89. If memory serves, it was C89
that establis
> 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.
Not at all far-fetched. The normal way these things come up is macros:
#define DIGIT_TO_INT(D) (D - '0'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bob Proulx on 12/30/2006 9:03 PM:
> Bootstrapping a new architecture from bare metal is often a
> problematic exercise in circular dependencies. I ran into a case of
> this while building the coreutils.
This is often the case for a numbe
Bootstrapping a new architecture from bare metal is often a
problematic exercise in circular dependencies. I ran into a case of
this while building the coreutils.
Bootstrapping coreutils on a pristine HP-UX 11.23 ia64 machine
produces the following error:
./bootstrap: gnulib/gnulib-tool --imp
Richard Kenner wrote:
I found my copy of K&R (Second Edition). Page 200: "The handling of overflow,
divide check, and other exceptions in expression evaluation is not defined
by the language. Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and as
Eric Blake wrote:
/* The maximum and minimum values for the integer type T. These
macros have undefined behavior if T is signed and has padding bits.
If this is a problem for you, please let us know how to fix it for
your host. */
#define TYPE_MINIMUM(t) \
((t) (! TYPE_SIGNED (t) \
> I suppose there is
>
> *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1;
>
> to make it safe.
Can't that conversion overflow?
> 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 typical
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> Does autoconf enable higher optimization levels for other compilers by
> default?
Yes.
Rather, some other compilers default to optimization on, unless the
user explicitly turns it off with -O0. (Example: icc).
(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
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
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
>
> 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.
> >
> >
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:
-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
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++
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
>
> 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
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
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
(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
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
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
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
> 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
[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 = -
> 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
> 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
"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
"Henning Nielsen Lund" <[EMAIL PROTECTED]> writes:
> I guess this is not the right place for this, but I have made a few
> changes to grep for my AmigaOS4 port of your great implementation of grep.
Thanks. Part of that change is to getpagesize.h, which came from
gnulib. grep should update to 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 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
> [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
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:
| > 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
> 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:
> 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
>
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
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
"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
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.
>
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
-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
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:
(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
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
> Where does GCC assume wrapv semantics?
The macro OVERFLOW_SUM_SIGN in fold-const.c.
> 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
> 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
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:
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
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
>
> "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
61 matches
Mail list logo
