Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Paul Eggert
Andrew Pinski [EMAIL PROTECTED] writes: the one thing I have not heard through this discussion is the real reason why the C standards comittee decided signed overflow as being undefined. I wasn't there, but my impression is that many of the optimization issues we've talked about in this

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Paolo Bonzini
The C Standard says that if a program has signed integer overflow its behavior is undefined, and the undefined behavior can even precede the overflow. To take an extreme example: @c Inspired by Robert Dewar's example in @c http://gcc.gnu.org/ml/gcc/2007-01/msg00038.html (2007-01-01). @example

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Paolo Bonzini
The C Standard says that if a program has signed integer overflow its behavior is undefined, and the undefined behavior can even precede the overflow. To take an extreme example: @c Inspired by Robert Dewar's example in @c http://gcc.gnu.org/ml/gcc/2007-01/msg00038.html (2007-01-01). @example

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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 mean the programs work on

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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

Re: changing configure to default to gcc -g -O2 -fwrapv ...

2007-01-03 Thread Laurent GUERBY
On Mon, 2007-01-01 at 22:27 -0500, Richard Kenner wrote: I don't think -frisky is a good name for that option. A better name would be -fstrict. Or -pedantic? ;-) -pedantic-codegen :) Laurent

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Andrew Haley
Andrew Pinski writes: This will always cause a trap on x86, even with -fwrapv so really -fwrapv has a bug on x86. I will file this bug sometime later tomorrow. Oh and fixing this bug will actually slow down users of -fwrapv even more than what it is currently does because you can no

Re: changing configure to default to gcc -g -O2 -fwrapv ...

2007-01-03 Thread Laurent GUERBY
On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote: Duncan Sands wrote: The C front-end performs this transformation too. I'm not claiming that the back-end optimizers would actually do something sensible if the front-end didn't transform this code (in fact they don't seem too), but

Re: changing configure to default to gcc -g -O2 -fwrapv ...

2007-01-03 Thread Robert Dewar
Laurent GUERBY wrote: On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote: Duncan Sands wrote: The C front-end performs this transformation too. I'm not claiming that the back-end optimizers would actually do something sensible if the front-end didn't transform this code (in fact they

Re: AC_PROG_CC_C89

2007-01-03 Thread Steven G. Johnson
Harlan Stenn wrote: When was AC_PROG_CC_C89 introduced? 2.59c, released 2006-04-12, according to the NEWS. Speaking of which, how difficult would it be to list the oldest version that will support each autoconf macro? It's just a Small Matter of Programming to write a Perl script that 1)

Re: AC_PROG_CC_C89

2007-01-03 Thread Harlan Stenn
Thanks, Steven! H ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: target triplet

2007-01-03 Thread Steven G. Johnson
Bob Rossi wrote: I know the target triplet is the cpu-vendor-os triplet where the executable runs. Does changing the cpu from i386-pc-mingw32 to i686-pc-mingw32 actually change executable that is created? No (not unless your configure script does something unusual). If not, does anyone know

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Paul Eggert
Andrew Pinski [EMAIL PROTECTED] writes: the one thing I have not heard through this discussion is the real reason why the C standards comittee decided signed overflow as being undefined. I wasn't there, but my impression is that many of the optimization issues we've talked about in this

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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 mean the programs work on

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Andrew Haley
Andrew Pinski writes: This will always cause a trap on x86, even with -fwrapv so really -fwrapv has a bug on x86. I will file this bug sometime later tomorrow. Oh and fixing this bug will actually slow down users of -fwrapv even more than what it is currently does because you can no

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Paul Eggert
Andrew Pinski [EMAIL PROTECTED] writes: the one thing I have not heard through this discussion is the real reason why the C standards comittee decided signed overflow as being undefined. I wasn't there, but my impression is that many of the optimization issues we've talked about in this

Re: Building m4 on BSDI 4.0.1

2007-01-03 Thread Chris McGuire
Stepan, I guess you may have found something there. The fact that this option is available again shows an acknowledgement that wchar.h has been an issue in the past. I have more e-mails to read in this thread, but is this the best solution or should the configure script itself be made smarter

Re: Building m4 on BSDI 4.0.1

2007-01-03 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, and happy new year, According to Chris McGuire on 1/3/2007 7:41 AM: I guess the following hack forces configure to ignore wchar.h: ./configure ac_cv_header_wchar_h=no I guess you may have found something there. The fact that this

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Richard Kenner
A few comments: Many portable C programs assume that signed integer overflow wraps around reliably using two's complement arithmetic. I'd replace portable C programs with widely-used C programs. The normal use of portable means that it conforms to the standard. Conversely, in at least one

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread 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 also

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Richard Kenner
Many portable C programs assume that signed integer overflow wraps around reliably using two's complement arithmetic. I was looking for an adjective that mean the programs work on a wide variety of platforms, and portable seems more appropriate than widely-used. Maybe just say what you

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Andrew Pinski
[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 mean the programs work on a wide variety of platforms, and portable seems

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Andrew Pinski
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 converting to unsigned and back. (At least, I

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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 mean the programs work on

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Gabriel Dos Reis
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

Re: Autoconf manual's coverage of signed integer overflow portability

2007-01-03 Thread Andrew Haley
Andrew Pinski writes: This will always cause a trap on x86, even with -fwrapv so really -fwrapv has a bug on x86. I will file this bug sometime later tomorrow. Oh and fixing this bug will actually slow down users of -fwrapv even more than what it is currently does because you can no