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

> > 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,

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

> > [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 pla

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

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 hope it's r

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

[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

Andrew Pinski <[EMAIL PROTECTED]> writes: > Let me make the point that signed overflow has been undefined since > before the C standard was finialized and in fact there is a nice > paper/book called "C Traps and Pitfalls[2]" which mentions all of this > back in 1988. C Traps and Pitfalls, like K&

Re: declaring only the functions that are defined

Bruno Haible <[EMAIL PROTECTED]> writes: > 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> > > * lib/timespec.h (nanosleep): Declare only if GNULIB_NANOSLEEP. I'm a bit dubious about this one, as it adds to the .h maintenance burden and I'm not sure the benefit is worth the cost. For the spe

Re: gnulib-tool: indicating the presence of gnulib modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/2/2007 1:55 PM: > Hi, > > Several modules already define a C macro that indicates the presence of the > particular module: > ... > > Some more new modules need the same pattern as well. So I'm adding this > automatic d

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

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 -fconforming flag similar to -fstrict-aliasing. I haven't ye

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

Richard Kenner wrote: 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.

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

> >> 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 jus

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

[EMAIL PROTECTED] (Richard Kenner) writes: > A few comments: Thanks for the quick review. >> 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 >

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

> > 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

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

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 lea

Re: timespec.h

Bruno Haible <[EMAIL PROTECTED]> writes: > 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> > > * modules/settime (Include): Require timespec.h. > * modules/nanosleep (Include): Likewise. Thanks, I installed it. One thing, though: > Include: > + #include "timespec.h" > ... > Includ

Autoconf manual's coverage of signed integer overflow & portability

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 belongs in

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

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

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

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I don't think -frisky is a good name for that option. Aaaaww. Nobody will remember boring and forbidding option names like -fstrict or -fstandard. Everybody will remember -frisky. Where's your sense of pun and -foetry? Anyway, thanks for your sum

Re: Buildbot failures

> Seems to have fixed several of the modules I mentioned, although the > builder is still working on some remaining ones. Thanks! One failure is still there, at http://autobuild.josefsson.org/gnulib/log-200701021304717357000.txt In file included from ../../gllib/fts.c:54: ../../gllib/fts_.h:68:

Re: [bug-gnulib] sed --posix change to gnulib-tool broke coreutils on Solaris

Paul Eggert wrote: > The recent 'sed --posix' change leaked into Makefiles, which broke > coreutils on Solaris. Rather than fix the problem one instance of > $SED at a time, I took a different tack by undoing the change and > installing the following less-intrusive change instead. Thanks and sorr

unicode string functions

Hi, Since 2000 the need for elementary functions on Unicode strings has been apparent and increasing: - some utility functions exist in GNOME's glib, - clisp, gettext, emacs, python, ... need a programmatic access to the character name tables, - gettext's linebreak module relies on sever

new module fchdir

Hi, Following Jim's and Paul's ideas for portability of the coreutils to BeOS, Woe32 and DJGPP, which all lack an fchdir(), here is a first working fchdir module. The module installs wrappers around open(), close(), opendir(), closedir(), dup(), dup2(). Quite heavy; especially the relation to the

sawewd problem

Hi, When I use the fchdir emulation on a Linux 2.4.x system (that doesn't have openat() and similar), the coreutils-6.7 tests install/basic-1 and mkdir/p-3 fail. The reason is this part: $ mkdir -p sub1/d $ cd sub1/d $ chmod a-rx .. $ chmod a-r . $ ginstall -d rel/a rel/b ginstall: cannot create

declaring only the functions that are defined

Hi, Some .h files declare functions which are defined in several modules. This currently has the drawback that if your program is using, for example, the gettime() function from the gettime module, and it also uses the nanosleep() function without the nanosleep module, the program will compile fin

lchmod.h

Hi Jim, This looks like a typo. OK to fix? 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * modules/lchmod (Include): Require lchmod.h, not lchown.h. *** modules/lchmod.bak 2006-10-13 01:27:12.0 +0200 --- modules/lchmod 2007-01-01 17:00:42.0 +0100 *** *

timespec.h

The settime and nanosleep functions are declared in timespec.h; therefore I think the module descriptions of the corresponding modules should reflect this. How about this patch, Paul? 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * modules/settime (Include): Require timespec.h. *

canonicalize: remove redundant macro definitions

Hi Jim, Now that gnulib-tool defines GNULIB_CANONICALIZE when the canonicalize module is in use, the PROVIDE_CANONICALIZE_FILENAME_MODE macro is redundant. Here is a proposed patch: 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * m4/canonicalize.m4 (AC_FUNC_CANONICALIZE_FILE_NAME): Remov

gc: remove redundant macro definitions

Hi Simon, Now that gnulib-tool defines GNULIB_* macros for every module in use, the GC_USE_* macros are redundant. Here is a proposed patch. 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * m4/gc-arcfour.m4 (gl_GC_ARCFOUR): Remove GC_USE_ARCFOUR macro definition. * m4/gc-a

fts: remove redundant macro definitions

Hi Jim, Now that gnulib-tool defines GNULIB_FTS when the fts module is in use, and GNULIB_FTS_LGPL when the fts-lgpl module is in use, the _LGPL_PACKAGE macro is redundant. Here is a proposed patch: 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * m4/fts.m4 (gl_FUNC_FTS_LGPL): Remove _LGP

remove redundant macro definitions

Hi, Following the gnulib-tool change, we can remove the explicit definitions of macro names. Paul, Jim: Objections? 2007-01-01 Bruno Haible <[EMAIL PROTECTED]> * m4/close-stream.m4 (gl_CLOSE_STREAM): Remove GNULIB_CLOSE_STREAM macro definition. * m4/fcntl-safer.m4 (gl_F

gnulib-tool: indicating the presence of gnulib modules

Hi, Several modules already define a C macro that indicates the presence of the particular module: close-stream.m4: AC_DEFINE([GNULIB_CLOSE_STREAM], [1], fcntl-safer.m4: AC_DEFINE([GNULIB_FCNTL_SAFER], [1], fts.m4: AC_DEFINE([_LGPL_PACKAGE], 1, gc-arcfour.m4: AC_DEFINE(GC_USE_ARCFOUR, 1, gc-a

havelib: better support for OpenBSD

Hi, The --with-libxyz-prefix option did not actually work on OpenBSD. This patch should fix it. 2006-12-24 Bruno Haible <[EMAIL PROTECTED]> Improve support for OpenBSD. * build-aux/config.rpath (libname_spec): Export. (library_names_spec): New variable. Export.

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

On Jan 1, 2007, at 21:14, Ian Lance Taylor wrote: [...] extern void bar (void); void foo (int m) { int i; for (i = 1; i < m; ++i) { if (i > 0) bar (); } } Here the limit for i without -fwrapv becomes (1, INF]. This enables VRP to eliminate the test "i > 0". With -fwra

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

Richard Guenther wrote: >> Perhaps Richard G. would be so kind as to turn this off in VRP, and >> rerun SPEC with that change? > > I can do this. Thank you very much! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: make safe_read usable in a mixed C/C++ build

Eric Blake asked: > Is it also necessary to wrap safe-read.c with extern "C", for use when > using g++ as a type-safe variant of a C compiler, to match the header? Normally not. The 'extern "C"' is only needed in mixed C/C++ builds. > And should you be symmetric with safe-write.h? I deal with th

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

> Well, while the effect of -fstrict-aliasing is hard to describe > (TBAA _is_ a complex part of the standard), -fno-strict-aliasing > rules are simple. All loads and stores alias each other if they > cannot be proven not to alias by points-to analysis. Yes, the rules are "simple", but are writte

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

Richard Guenther wrote: On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote: We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to descr

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

On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to describe the effect it has o

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

> We do that with -fstrict-aliasing, which also changes language semantics. Well, yes, but not quite in the same way. Indeed it's rather hard to describe in what way it changes the language semantics but easier to describe the effect it has on optimization. I think -fwrapv is the other way aroun

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

Richard Guenther wrote: We do that with -fstrict-aliasing, which also changes language semantics. -fstrict-aliasing is disabled for -O0 and -O1 and enabled for -O[23s]. Yes, and as others have said, this is a bad precedent, and should not be followed further. Inclusion of -fwrapv would be much

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

On 1/2/07, Robert Dewar <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: > On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: specfp. > > I would support the proposal to enable -fwrapv for -O[01], but > not for -O2 as that is supposed to be "optimize for speed" and > as -O3 is not widely used

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

Richard Kenner wrote: What about -fno-wrapv for the first? Actually I don't like this. Why? Because it seems weird to have a flag that you can turn on and off, but the default is neither on nor off.

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

Richard Kenner wrote: Then we have two switches: -fstandard which allows all optimizations (name can be changed, I don't care about the name) -fwrapv which changes the semantics to require wrapping in all cases (including loops) What about -fno-wrapv for the first? Possible .. my view was

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

> Then we have two switches: > > -fstandard > > which allows all optimizations (name can be changed, I > don't care about the name) > > -fwrapv > > which changes the semantics to require wrapping in > all cases (including loops) What about -fno-wrapv for the first?

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

Richard Guenther wrote: On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: specfp. I would support the proposal to enable -fwrapv for -O[01], but not for -O2 as that is supposed to be "optimize for speed" and as -O3 is not widely used to optimize for speed (in fact it may make code slower). I

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

> | >|> for (i = 1; i < m; ++i) > | >|> { > | >|> if (i > 0) > | >|> bar (); > | >|> } > > I suspect part of Richard K.'s questions has been to determine, based > on data, what improvements we actually gain from doing that kind of > elimination predicated on undefined-ness o

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

> I can do this. What I also will do is improve VRP to still fold comparisons > of the for a - 10 > 20 when it knows there is no overflow due to available > range information for a (it doesn't do that right now). I thought fold-const.c optimizes that right now and has been for a long time? If tha

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

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 is doing | >| something very silly or else is expe

Re: [bug-gnulib] updating with gnulib-tool

Eric Blake wrote: > According to Lorenzo Bettini on 12/20/2006 12:44 PM: >>> Thanks for the feedback. Last time we discussed whether gnulib-cache.m4 >>> should be added to EXTRA_DIST by gnulib-tool, so that anyone getting a >>> tarball can do "gnulib-tool --update", there was no consensus. A majori

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

On 1/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: >> Richard Guenther added -fwrapv to the December 30 run of SPEC at >> >> and >>

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

On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote: On Dec 31, 2006, at 19:13, Daniel Berlin wrote: > Note the distinct drop in performance across almost all the benchmarks > on Dec 30, including popular programs like bzip2 and gzip. Not so. To my eyes, the specint 2000 mean went UP by about 1% f

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

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 is doing >| something very silly or else is expecting overflow and depending on >| wrap semantics, so it