commending
-fwrapv for those people who depend on signed overflow is wrong.
Thanks,
Andrew Pinski
is why I am agrueing against even changing VRP, as it
punishes people who don't depend on overflow being wrapping. Ian's
change in fact punishes people's code who does not depend on that
as it is causes compile time slow down (and an increase of memory usage
inside GCC itself) which people will complain about.
Thanks,
Andrew Pinski
>
> Today I updated the Autoconf manual to contain the following
> description of the current situation with signed integer overflow.
> This section of the manual is intended to advise programmers what to
> do about portable C programs in this area.
>
> I think some discussion along these lines a
On Mon, 2007-01-01 at 22:21 -0500, Richard Kenner wrote:
>
> Of course, this is an example where either the programmer is doing
> something
> very silly or else is expecting overflow and depending on wrap
> semantics.
or it comes from inlining of something like get() which has bounds
checking.
-
lict in some are wrapping, others are saturation (most of the
VRP and a-'0'>9) and then more are extending (a*10/5).
Thanks,
Andrew Pinski
>
> 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 g
>
> 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
in code even if GCC did not create the "wrong" code yet.
The developer
was able to fix his code before he even started to compile the code.
Thanks,
Andrew Pinski
U 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?
If you can point out specific spots, please file a bug and
I will go and fix them.
Thanks,
Andrew Pinski
printf("Need another integeral type sized, %d\n", sizeof(type)); \
abort (); \
} \
}
Yes people think macros can be less reabable, but this one case actually makes
it readable.
Thanks,
Andrew Pinski
>
> 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
and then see if an overflow happened
}
//etc. for the other type
This way you don't depend on either implemenetation defined behavior
of converting between integer with different sizes and undefined behavior
with signed type overflow.
Thanks,
Andrew Pinski
On Fri, 2006-12-22 at 12:30 -0500, Robert Dewar wrote:
>
> > Maybe on x86, but on PPC, at least for the (current) Cell's PPU
> > misaligned accesses for most cases unaligned are optimal.
>
> is that true across cache boundaries?
For Cell, crossing the 32byte boundary causes the microcode to hap
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
> Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
Thanks,
Andrew Pinski
ut it being too strong is wrong because timming matters now a days.
Instruction
scheduling can cause the same issue as it forces a write too early for another
thread
to act on.
Thanks,
Andrew Pinski
d since loops are now more
important to optimize than anything else, well knowing the number of
iterations is very important.
Thanks,
Andrew Pinski
me on
this list.
> and I haven't tested GCC in several months before, so I have no idea
> when this was introduced.
-fwrapv was introduced on 2003-05-31, so for 3.4 to fix some Java
testcases which were failing already from the 1992 patch. We are only
recently taken into overflow being undefined more recently which is why
people are just seeing it now rather than back in 1992 :).
Thanks,
Andrew Pinski
17 matches
Mail list logo
