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
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
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
> 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'
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).
> On Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > > Also I should mention, this also fixes a possible bug with libcalls that
> > > are embedded in one another. Before we were just assuming if we have a
> > > REG_RETVAL, then the previous REG_LIBCALL would be the start of the
> > > libcall
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
(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 Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > Also I should mention, this also fixes a possible bug with libcalls that
> > are embedded in one another. Before we were just assuming if we have a
> > REG_RETVAL, then the previous REG_LIBCALL would be the start of the
> > libcall but that
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
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
>
> 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:
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
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
[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
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
Hi,
I do apologize for the breakage, apparently I tested the only target
that didn't break. Andrew's patch seems to be OK for me (as well as the
patch just omitting copy_insn_1 call in the second branch that should
make situation no worse than before my patch and still save the
quadratic memory con
> 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
>
> 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
"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
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
>
> Hello All,
>
> I am interested in getting the source location (at least the start
> source file, linenumber, and possibly column number and end source
> file, linenumber, ...) of
>
> a GIMPLE/SSA tree (I want the corresponding source location, I very
> much realize that the source location m
Hello All,
I am interested in getting the source location (at least the start
source file, linenumber, and possibly column number and end source
file, linenumber, ...) of
a GIMPLE/SSA tree (I want the corresponding source location, I very
much realize that the source location might not exist)
a
> 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
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > >
> > > > > Hi,
> > > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > > and comitted it as obvious.
> > > >
> > > > Since this is an insn, we should not be copying it as it is just a link
> > > > to that
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > >
> > > > Hi,
> > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > and comitted it as obvious.
> > >
> > > Since this is an insn, we should not be copying it as it is just a link
> > > to that
> > > insn.
> >
Andrew Pinski wrote:
Hi,
thanks for testing. I've bootstrapped/regtested this variant of patch
and comitted it as obvious.
This causes a bootstrap regression on powerpc-darwin while compiling
libgfortran.
And linux-ppc 32-bit.
we call copy_insn_1 with the following RTL:
(gdb) p debug_rtx(
Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > Hi,
> > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > and comitted it as obvious.
> >
> > Since this is an insn, we should not be copying it as it is just a link to
> > that
> > insn.
> >
> > Attached is a pat
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
Andrew Haley wrote:
Douglas B Rupp writes:
> DJ Delorie wrote:
> > Is your target a newlib target? If so, are you including --with-newlib?
> >
>
> Thanks, that was the problem.
> Why isn't --with-newlib the default for newlib targets?
AIX is a newlib target? Really?
Andrew.
Don't
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.
>
On 2006-12-28 23:11:08 -0800, Paul Eggert wrote:
> 2006-12-28 Paul Eggert <[EMAIL PROTECTED]>
>
> * 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
Snapshot gcc-4.3-20061230 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061230/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Vincent Lefevre <[EMAIL PROTECTED]> writes:
[...]
| Shouldn't GCC provide an extension to obtain the maximum and minimum
| values of integer types?
GCC already does. I suspect you meant a _generic_ way a la numeric_limits?
That is doable.
-- Gaby
>
> > Hi,
> > thanks for testing. I've bootstrapped/regtested this variant of patch
> > and comitted it as obvious.
>
> Since this is an insn, we should not be copying it as it is just a link to
> that
> insn.
>
> Attached is a patch which fixes the ICE though I have not bootstrapped and
> te
> Hi,
> thanks for testing. I've bootstrapped/regtested this variant of patch
> and comitted it as obvious.
This causes a bootstrap regression on powerpc-darwin while compiling
libgfortran.
we call copy_insn_1 with the following RTL:
(gdb) p debug_rtx(orig)
(insn 858 857 859 106
/Volumes/develo
On 2006-12-29 00:55:18 -0800, Paul Eggert wrote:
[...]
> Obviously this code is buggy, at least in theory, due to the signed
> integer overflows. But rewriting it is not so easy, since we have no
> INT_MAX to rescue us as we did in the bigtime_test loop. Here's what
> I eventually came up with:
>
-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 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
Douglas B Rupp writes:
> DJ Delorie wrote:
> > Is your target a newlib target? If so, are you including --with-newlib?
> >
>
> Thanks, that was the problem.
> Why isn't --with-newlib the default for newlib targets?
AIX is a newlib target? Really?
Andrew.
Hi,
thanks for testing. I've bootstrapped/regtested this variant of patch
and comitted it as obvious.
Honza
2006-12-30 Jan Hubicka <[EMAIL PROTECTED]>
Vladimir Yanovsky <[EMAIL PROTECTED]>
* emit-rt.c (emit_copy_of_insn_after): Fix bug causing exponential
a
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
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
On 12/30/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
Once upon a time, the --disable-bootstrap configure option wasn't
necessary. "make" built gcc, and "make bootstrap" bootstrapped it.
Is this behavior useful? Should we have it back again?
For me the current behavior works Just Fine.
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
"Seongbae Park" <[EMAIL PROTECTED]> writes:
| On 30 Dec 2006 03:20:11 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| ...
| > The C standard, in effect, has an appendix (Annex H) that was not
| > there in the C89 edition, and that talks about the very specific issue
| > at hand
| >
| >
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
In particular, IMHO the commands to re-generate the configure scripts
should be documented if the documentation also targets potential GCC
contributors.
I agree, that sounds useful. DJ, Alexandre, Paolo, what's your take
on this. Any recommendations?
Patches are always welcome. :-)
Basil
The problem is that last step: it takes a LONG time to build libjava,
for example. If I make a change that I need to give a sanity check to,
I want to compile GCC with it, but not all the other additional code: that's
for a later state in the development/testing cycle. Since building a stage
o
>
> "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
78 matches
Mail list logo
