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