Paul Eggert <[EMAIL PROTECTED]> writes:
| Here are further patches I checked into the Autoconf documentation to
| reflect today's comments (some of which I received privately). Thanks
| to all of you. The trickiest bit was documenting one simple way to
| reliably detect overflow without converti
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > >> >> Many portable C programs assume that signed integer overflow wraps
around
| > >> >> reliably using two's complement arithmetic.
| > >> >
| > >>
| > >> I was looking for an adjective that m
Diego Novillo <[EMAIL PROTECTED]> writes:
| Mark Mitchell wrote on 01/01/07 14:46:
|
| > What a thread this has turned out to be.
| >
| Indeed.
|
| In general, I'm not too thrilled with the idea of disabling
| transformations for the sake of non-conforming code. However, I would
| not mind a -f
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Tue, 2 Jan 2007, Gabriel Dos Reis wrote:
| >|> for (i = 1; i < m; ++i)
| >|> {
| >|> if (i > 0)
| >|> bar ();
| >|> }
| >| Of course, this is an example where either the programmer i
[EMAIL PROTECTED] (Richard Kenner) writes:
[...]
| > for (i = 1; i < m; ++i)
| > {
| > if (i > 0)
| > bar ();
| > }
|
| 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, so
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > I do hope your and Richard G's constructive search for middle ground
| > will find echoes within the middle-end maintainers.
|
| This seems likely, since Richard and I are
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
| I believe the best option is
| going to be to take an case by case approach to selecting which
| optimizations should be enabled by default, and which optimizations
| should not be done except via a special
Bernd Schmidt <[EMAIL PROTECTED]> writes:
[...]
| >> You say you doubt it affects performance. Based on what? Facts
| >> please, not guesses and hand-waiving...
| > The burden of proof ought to be on the guys proposing -O2
| > optimizations that break longstanding code, not on the skeptics.
|
Paul Eggert <[EMAIL PROTECTED]> writes:
| > 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 documenta
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| In fact K&R is much stronger than you think in terms of providing
| a precise definition of the language. Too bad people did not read it.
|
| As I said earlier in this thread, people seem to think that the
| standards committee invented something
[EMAIL PROTECTED] (Richard Kenner) writes:
| > And the idea that people were not used to thinking seriously about
| > language semantics is very odd, this book was published in 1978,
| > ten years after the algol-68 report, a year after the fortran
| > 77 standard, long after the COBOL 74 standard
[EMAIL PROTECTED] (Richard Kenner) writes:
[...]
| > but from other evidence it's clear that common traditional practice assumes
| > wrapv semantics.
|
| "Common traditional C" was actually yet another language that was even more
| ill-defined because it included such things as structure assignm
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gerald Pfeifer wrote:
| > On Sun, 31 Dec 2006, Robert Dewar wrote:
| >> If you do it in signed expecting wrapping, then the optimization
| >> destroys your code. Yes, it is technically your fault, but this
| >> business of telling users
| >>
| >> "sorry,
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| Yes, I have some patches in the queue to clean this up (and add some
| more stuff to VRP).
Great!
-- Gaby
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > > 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 t
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| though I vaguely
| recall some complaints that you couldn't build v7 Unix if your compiler
| generated integer overflow traps.
this matches what I've told recently by some people who worked at bell
Paul Eggert <[EMAIL PROTECTED]> writes:
| [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
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| 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 tha
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
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 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
| > | <[
"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.
| > |
| > |
[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
"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
"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
"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
"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 th
"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
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
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
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. These optimizations now default to "-
Paul Eggert <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor <[EMAIL PROTECTED]> writes:
|
| > We could disable VRP's assumptions about signed overflow. I don't
| > know what else we could do to fix this case. I don't even know how we
| > could issue a useful warning. Perhaps there is a way.
|
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| C is no longer a kind of high-level assembly laguage:
| it's defined by a standard, in terms of an abstract machine, and some
| operations are not well-defined.
that does not mean C is not a kind of high-level assembly language.
:-/
-- Gaby
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| > We (in a major, commercial application) ran into exactly this issue.
| > 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
| > (it is a barrier across which neither the compiler nor CPU will reorder
| > things). Failing that
Paul Brook <[EMAIL PROTECTED]> writes:
| > Compiler can optimize it any way it wants,
| > as long as result is the same as unoptimized one.
|
| We have an option for that. It's called -O0.
|
| Pretty much all optimization will change the behavior of your program. The
| important distinction is
Paul Eggert <[EMAIL PROTECTED]> writes:
| "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
|
| > Encapsulate reliable overflow checks for the various
| > arithmetic operations and types in functions or macros in
| > gnulib (for long long multiply, in this case).
|
| That might be the best approach
Andrew Haley <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis writes:
| > Andrew Haley <[EMAIL PROTECTED]> writes:
| >
| > | Robert Dewar writes:
| > | > Andrew Haley wrote:
| > | >
| > | > > We've already defined `-fwrapv' fo
Andrew Haley <[EMAIL PROTECTED]> writes:
| Robert Dewar writes:
| > Andrew Haley wrote:
| >
| > > We've already defined `-fwrapv' for people who need nonstandard
| > > arithmetic.
| >
| > Nonstandard implies that the result does not conform with the standard,
|
| I don't think it does; it
40 matches
Mail list logo
