Re: Handling C2Y zero-length operations on null pointers

On 2024-10-03 15:42, Florian Weimer wrote: I think attribute access already covers part of it: The GCC documentation for attribute access[1] is unclear as to whether the pointer is allowed to be null when the size is zero. Perhaps we could ask the GCC maintainers to document that it's allowed

Re: Proposed CHOST change for the 64bit time_t transition

On 2024-09-05 10:03, Andreas K. Huettel wrote: at least time64 implies largefile, so that will get sorted as side effect. Right, but this means the "t" in "t64" is somewhat misleading, as it's not just about time: it also affects off_t, ino_t, etc., effects that are in some cases more importa

Re: Proposed CHOST change for the 64bit time_t transition

One possible improvement would be to append "t32" if you want 32-bit time_t, instead of appending "t64" for 64-bit time_t. That way, people wouldn't be stuck with appending that confusing "t64" for the foreseeable future, and only specialists concerned with 32-bit time_t would need to know abou

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On 7/26/24 09:24, Joseph Myers wrote: Maybe someone who was around then could explain what "noalias" was, what the problems with it were and how it differs from "restrict" You can get a hint by reading Dennis Ritchie's 1988 email with the unforgettable bottom line "Noalias must go. This is n

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/8/24 00:52, Alejandro Colomar wrote: > a small set of functions > accept pointers that alias each other, but one of them is never > accessed; in those few cases, restrict was added to the parameters in > ISO C, but I claim it would be better removed. Are these aliasing pointers the nptr and

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/7/24 14:42, Alejandro Colomar wrote: On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: Also, “global variables” is not right here. The C standard allows strtol, for example, to read and write an internal static cache. (Yes, that would be weird, but it’s allowed.) That's not

Re: WG14 paper for removing restrict from nptr in strtol(3)

On 7/7/24 03:58, Alejandro Colomar wrote: I've incorporated feedback, and here's a new revision, let's call it v0.2, of the draft for a WG14 paper. Although I have not followed the email discussion closely, I read v0.2 and think that as stated there is little chance that its proposal will be a

Re: configure adds -std=gnu++11 to CXX variable

On 5/28/24 11:27, Jason Merrill wrote: AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that relies on features from a particular standard. It's called "_AC_PROG_CXX_STDCXX_EDITION_TRY" with a leading underscore, which means it's private to Autoconf and apps shouldn't (and I thi

Re: configure adds -std=gnu++11 to CXX variable

led the attached.From 056518b94ecd487bcbefdb69046b3f52c4168222 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 May 2024 09:31:11 -0700 Subject: [PATCH] AC_PROG_CXX no longer adjusts C++ language version * lib/autoconf/c.m4 (_AC_CXX_CXX98_TEST_GLOBALS) (_AC_CXX_CXX98_TEST_MAIN, _AC_CXX_CXX11_TEST_GLOBALS) (_A

Re: configure adds -std=gnu++11 to CXX variable

On 2024-05-28 01:20, Jonathan Wakely wrote: I am not aware of any distro ever changing the default -std setting for g++ or clang++. Are you attempting to solve a non-problem, but introducing new ones? If it's a non-problem for C++, why does Autoconf upgrade to C++11 when the default is C++98?

Re: configure adds -std=gnu++11 to CXX variable

On 2024-05-27 12:18, Jakub Jelinek wrote: Maybe respect the carefully chosen compiler default (unless explicitly overridden in configure.ac)? Autoconf gave up on that idea long ago, as we had bad experiences with compiler defaults being chosen for the convenience of distro maintainers rather

Re: configure adds -std=gnu++11 to CXX variable

og_cxx_cxx23=no', and a developer can discourage C++23 by putting ': ${ac_cv_prog_cxx_cxx23=no}' early in configure.ac. As I mentioned earlier, I volunteered to document this sort of thing if Zack doesn't come up with something nicer soon.From b2f28ce66ea1618b50e14085059ce512d724

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/9/24 15:22, Sam James wrote: Paul Eggert writes: On 4/9/24 14:58, Sam James wrote: Meson doesn't allow user-defined functions Meson has ways to execute arbitrary user-defined code, so it's not immune to this sort of exploit. To be clear - not saying it's immune. Su

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/9/24 14:58, Sam James wrote: Meson doesn't allow user-defined functions Meson has ways to execute arbitrary user-defined code, so it's not immune to this sort of exploit. It's of course better (all other things being equal) to use a build system with a smaller attack surface. However,

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/9/24 14:40, Jeffrey Walton wrote: Code provenance and code integrity was not enforced. Part of the problem is the Autotools design. It is from a bygone era. No, Andreas is right. This isn't an Autotools-vs-Meson thing. Most of the Autotools-based projects I help maintain would have been

Re: Sourceware mitigating and preventing the next xz-backdoor

On 4/2/24 12:54, Sandra Loosemore wrote: Do we to harden our process, too, to require all patches to be signed off by someone else before committing? It's easy for an attacker to arrange to have "someone else" in cahoots. Although signoffs can indeed help catch inadvertent mistakes, they're r

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 11/17/22 13:35, Bruno Haible wrote: Clang will surely not acquire knowledge about "every library", right, only about the C library according to relevant standards (ISO C, POSIX)? I don't know the Clang developers' plans. But if I wanted Clang to be picky then yes, I'd have it know about ev

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 10:59, Zack Weinberg wrote: I'm generally in agreement with Rich Felker's argument (inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for linkability of a symbol So am I. I'm not saying Autoconf should never change here, only that the change would not be tr

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 10:40, Jeffrey Walton wrote: This line of arguments is not persuasive. It is full of logical fallacies. ... none of which you stated. No matter how we solve the problem, it will be a hack that exploits "logical fallacies" (whatever that means). However, a reaction "You violated

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 06:26, Michael Matz wrote: char foobar(void); int main(void) { return &foobar != 0; } That still has undefined behavior according to draft C23, which says behavior is undefined when foobar is (say) 'memset_explicit' because the declaration 'char memset_explicit(void);' disagr

Re: How can Autoconf help with the transition to stricter compilation defaults?

Can you cite any examples of a real-world security flaw what would be found by Clang erroring out because 'char foo(void);' is the wrong prototype? Is it plausible that any such security flaw exists? CVE-2006-1174 is a possibly reasonable example. CVE-2006-1174 is not an example, because no p

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-15 11:27, Jonathan Wakely wrote: Another perspective is that autoconf shouldn't get in the way of making the C and C++ toolchain more secure by default. Can you cite any examples of a real-world security flaw what would be found by Clang erroring out because 'char foo(void);' is the

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-15 06:50, Jonathan Wakely wrote: Could you clarify what you mean, with a concrete example? Surely as long as errors are reported on stderr and the compiler exits with non-zero status, that's an acceptable way to report errors? Not if the "error" is harmless as far as Autoconf is conc

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-14 04:41, Aaron Ballman wrote: it's generally a problem when autoconf relies on invalid language constructs Autoconf *must* rely on invalid language constructs, if only to test whether the language constructs work. And Clang therefore must be careful about how it diagnoses invalid

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 07:11, Aaron Ballman wrote: Clang doesn't require such a linker (we work with various system linkers). As long as the system linkers continue to work as they have traditionally worked, we're fine. the frontend perspective, we can't tell the difference between "trust me this is

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 07:11, Aaron Ballman wrote: We believe the runtime behavior is sufficiently dangerous to warrant a conservative view that any call to a function will be a call that gets executed at runtime, hence a definitive signature mismatch is something we feel comfortable diagnosing (in some f

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 15:25, Sam James wrote: That's not a judgement on whether the changes will ultimately remain in autoconf, I'm just hesitant to allow a discussion I've kicked off to derail something that we were planning on doing anyway. What do you think? I'm hesitant to do that partly because

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-10 10:19, Aaron Ballman wrote: In terms of the Clang side of things, I don't think we've formed any sort of official stance on how to handle that yet. It's UB (you can declare the C standard library interface without UB but calling any function with a mismatched signature is UB) The

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-10 09:16, Zack Weinberg wrote: Changes to handle C23 built-in ‘bool’ better are under development but the design has not yet been finalized. [I'm cc'ing this to bug-gnulib too.] To my mind this is the biggest outstanding issue in Autoconf as far as C23 goes, as the upgrade path for

Re: Adding file descriptor attribute(s) to gcc and glibc

On 7/14/22 08:22, David Malcolm via Libc-alpha wrote: The analyzer now attempts to track both file descriptors and stdio streams, so we probably need to special-case fdopen You probably also need to special-case fileno, which goes the opposite direction. If you're handling DIR *, fdopendir a

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

On 10/2/20 2:10 AM, David Laight wrote: > Also, you should > warn that because one can convert from any pointer type to void * and > then to any other pointer type, it's a deliberate hole in C's > type-checking. That isn't what the C standard says at all. What is says is that you can ca

Re: [PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types

On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote: +The narrowest signed integer type +of a width of at least N bits, Motivation is missing here. Why is there an int_leastN_t type at all? Also, on all glibc platforms, int_leastN_t is equivalent to intN_t; this should probably be ment

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

If you're going to document this at all, I suggest documenting 'void' as well as 'void *', and putting both sets of documentation into the same man page. For 'void *' you should also mention that one cannot use arithmetic on void * pointers, so they're special in that way too. Also, you should

Re: Dealing with compilers that pretend to be GCC

On 01/19/12 06:24, Ludovic Courtès wrote: > I don’t see what can be done on “our” side (perhaps Autoconf’s feature > test could be strengthened, but how?) Which feature test would that be? I certainly understand the problem, and have run into issues where clang fools 'configure' into thinking a G

Re: gcc-4.3, glibc and AC_PROG_CC_STDC

I am CC'ing this message to gcc@gcc.gnu.org to give GCC developers a heads-up on the situation. For GCC developers: please see for the problem with a gcc-4.3 snapshot with --std=gnu99 -O2" and glibc wchar.h. Ralf Wildenhues <[EM

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

Thorsten Glaser <[EMAIL PROTECTED]> writes: > Paul Eggert dixit: > >> […] gcc -O2 makes no promises without >> -fwrapv. > > gcc -O1 -fwrapv even doesn't work correctly for gcc3, > and gcc2 and gcc <3.3(?) don't even have -fwrapv: > http://gcc.g

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

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 t

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

it's reliable) 2007-01-02 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Integer Overflow): Revised based on today's feedback. The most important changes document what happens when you convert an out-of-range value to a signed integer type, and

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

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

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: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Mark Mitchell <[EMAIL PROTECTED]> writes: > let's disable the assumption about signed overflow not wrapping for > VRP, but leave it in place for loop analysis. As far as I know this will work for all the wrapv-assuming code that we've found, so it should be an improvement. Thanks to all for help

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

[EMAIL PROTECTED] (Richard Kenner) writes: >> More important, we don't yet have an easy way to characterize the >> cases where (2) would apply. For (2), we need a simple, documented >> rule that programmers can easily understand, so that they can easily >> verify that C code is safe > > I'm not s

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

Mark Mitchell <[EMAIL PROTECTED]> writes: > * Dan Berlin says that xlc assumes signed overflow never occurs, gets > much better performance as a result, and that nobody has complained. Most likely xlc and icc have been used to compile the gnulib mktime-checking code many times without incident (t

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

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Also, it does not make sense to me to lump together all potentially > troublesome optimizations under a single name. As a compiler developer, you see the trees. But most users just see a forest and want things to be simple. Even adding a single bin

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

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I'm not entirely happy with what I take to be stampeding it by > introducing what I believe would be a completely inappropriate patch > to autoconf, rather than, say, opening a gcc bugzilla problem report > for the cases you feel gcc should handle dif

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

Bernd Schmidt <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> But so far, benchmark scores are the only scores given by the people >> who oppose having -O2 imply -fwrapv. > > And you expect real-world results will be different because...? Because of the (adm

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

Robert Dewar <[EMAIL PROTECTED]> writes: > We have not seen ONE imaginary example, let > alone a real example, where the optimziation of loop invariants > (by far the most important optimization in the class we are > discussing) would break existing code. But didn't this thread get started by a r

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

"Daniel Berlin" <[EMAIL PROTECTED]> writes: >> http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html >> and >> http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html >> > Note the distinct drop in performance across almost all the benchmarks > on Dec 30, including pop

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

[EMAIL PROTECTED] (Richard Kenner) writes: > that one is a weak example because it's *much* more likely that > the author of that code didn't even *think* about the INT_MIN case I think this seriously underestimates the programming abilities of the original Unix developers. But if that example d

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

"Daniel Berlin" <[EMAIL PROTECTED]> writes: > These are not performance needing applications. No, I chose gzip -9 and sha512sum precisely because they are CPU-bound (integer arithmetic only). On my platform, if the input file is cached sha512sum is approximately 300 times slower than 'cat', and

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

"Steven Bosscher" <[EMAIL PROTECTED]> writes: > On 12/31/06, Paul Eggert <[EMAIL PROTECTED]> wrote: >> Also, as I understand it this change shouldn't affect gcc's >> SPEC benchmark scores, since they're typically done with -O3 >> or be

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

Joe Buck <[EMAIL PROTECTED]> writes: >> > *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1; >> >> Can't that conversion overflow? > > Not on a two's complement machine, Sure it can. Suppose we have a 64-bit two's complement machine with no padding, and h1 is - 2**63. Then (unsigned HOS

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

Robert Dewar <[EMAIL PROTECTED]> writes: > Of course there is a way out that satisfies both > sides here, and that is to declare that gcc code > should adhere to the standard *including* LIA > and then make sure the default mode of gcc is > LIA compliant. Yes, this should solve the problem. The

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

"Dave Korn" <[EMAIL PROTECTED]> writes: > Maybe the answer (as far as autoconf goes) is that autoconf tests should be > compiled at -O0. No, since one of the first rules of Autoconf is that you should test the compiler with the same options that you intend to use use when compiling. Otherwise th

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

[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&Rv2 is post-C89. If memory serves, it was C89 that establis

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

[EMAIL PROTECTED] (Richard Kenner) writes: >> I'm sure there are many other instances where the GCC source >> code assumes wrapv semantics. > > I'm not. I am. I just now looked and found another example. gcc-4.3-20061223/gcc/fold-const.c's neg_double function contains this line: *hv = -

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

[EMAIL PROTECTED] (Richard Kenner) writes: > Date: Sat, 30 Dec 2006 08:01:37 EST > I'd actually be very surprised if there were ANYPLACE where GCC has code > that's otherwise correct but which would malfunction if signed overflow > weren't required to wrap. > Date: Sat, 30 Dec 2006 08:09:33 EST >

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

Andrew Pinski <[EMAIL PROTECTED]> writes: > You are just giving up on the undefined issue No, I'm taking a multiple-phase approach. I'm not giving up at all. Please don't confuse the first phase with the whole thing. The first phase is to keep existing GNU software working with GCC 4.2 and late

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

>> Nor would I relish the prospect of keeping wrapv assumptions out of >> GCC as other developers make further contributions, as the wrapv >> assumption is so natural and pervasive. > > It's neither natural not pervasive to me! I would never write code > that way That's great, but GCC has had man

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

"Daniel Berlin" <[EMAIL PROTECTED]> writes: > Just to address the other compiler issue >> >> No, they will work on other compilers, since 'configure' >> won't use -O2 with those other compilers. > > icc defaults to -O2 without any options, so unless you are passing > -O0, it will enable this. Tha

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

>> GCC itself relies on wrapv semantics. As does glibc. And >> coreutils. And GNU 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? It's not like the

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

[EMAIL PROTECTED] (Richard Kenner) writes: > (1) What is the maximum performance loss that can be shown using a real > program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when > one assumes wrapping semantics? > > (2) In the current SPEC, how many programs benefit from undefined ov

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

"Seongbae Park" <[EMAIL PROTECTED]> writes: > On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote: >> -O2 does not currently imply '-ffast-math'ish optimizations even >> though the C standard would allow it to. > > Can you point me to the

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

> On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: >> I think it would be a very bad choice for the GNU project to work >> around itself. If we can't come to an agreement on the list, >> please ask the Steering Committee. This is a textbook example of >> what they're for. The issue doe

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

"Richard Guenther" <[EMAIL PROTECTED]> writes: > Authors of the affected programs should adjust their makefiles That is what the proposed patch is for. It gives a way for developers to adjust their makefiles. A developer of portable software cannot simply put something like this into a makefile

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

"Daniel Berlin" <[EMAIL PROTECTED]> writes: > Nobody has yet showed that any significant number of > programs actually rely on this undefined behavior. GCC itself relies on wrapv semantics. As does glibc. And coreutils. And GNU tar. And Python. I'm sure there are many other significant progr

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

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I fully appreciate that there is a real problem here which > needs to be addressed, but this does not seem like the > best solution to me. I agree. It's meant to be a stopgap. I support coming up with a better solution than the stopgap. > The resu

Re: GCC optimizes integer overflow: bug or feature?

Paolo Bonzini <[EMAIL PROTECTED]> writes: >> Or you can do, since elsewhere in the code you compute time_t_max: >> for (j = 1; j <= time_t_max / 2 + 1; j *= 2) > > No, this does not work. It would work to have: > > for (j = 1;;) > { > if (j > time_t_max / 2) > break; >

Re: GCC optimizes integer overflow: bug or feature?

Roberto Bagnara <[EMAIL PROTECTED]> writes: > My reading, instead, is that C99 requires unsigned long long int > to have exactly the same number of bits as long long int. Yes, that's correct. Sorry, I got confused between C89 (which is what that Tandem NSK version supports) and C99.

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

of the patch to write, and I'd appreciate any comments/reviews for it. For those coming to this discussion late, the original version of the patch and the followup thread are here: http://lists.gnu.org/archive/html/autoconf-patches/2006-12/msg00091.html 2006-12-28 Paul Egge

Re: GCC optimizes integer overflow: bug or feature?

Roberto Bagnara <[EMAIL PROTECTED]> writes: > (The platform I'm thinking of is Tandem NSK/OSS.) > > Is this correct? Doesn't C99's 6.2.5#6 mandate that... This is straying from the subject of GCC and into the problems of writing portable C code, but since you asked The Tandem NSK/OSS enviro

Re: GCC optimizes integer overflow: bug or feature?

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. It is a knotty problem. Thanks for thinking about it

Re: GCC optimizes integer overflow: bug or feature?

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > Conversion of out-of-range integers to signed types is > implementation-defined not undefined, Thanks for the correction; I keep forgetting that. However, a conforming implementation is allowed to raise a signal for those conversions, which could

Re: GCC optimizes integer overflow: bug or feature?

Paolo Bonzini <[EMAIL PROTECTED]> writes: > On the autoconf mailing list, Paul Eggert mentioned as a good > compromise that GCC could treat signed overflow as undefined only for > loops and not in general. What I meant to propose (and perhaps did not propose clearly enough) i

Re: GCC optimizes integer overflow: bug or feature?

ecking code (like the example below) as the programmer intended, while still doing loop induction optimizations, then we'd no doubt use that option instead of -fwrapv. That sounds like a reasonable compromise. I would argue that such an option should be the default for -O2, as -O2 is so comm

Re: GCC optimizes integer overflow: bug or feature?

>> Does the test hang forever? > No, the timeout works. So the app builds. But it has latent bugs. Wonderful. Is the performance gain by this change to gcc -O2 really worth all this software engineering hassle and breakage for typical applications? I'm talking about apps like 'date', 'touch',

Re: GCC optimizes integer overflow: bug or feature?

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Maybe it's also just an unintended bug I happened to observe > (and take for given behavior)? I read up a bit more and it looks like it is intended behavior. However, this disruptive change isn't documented in

Re: proposed Opengroup action for c99 command (XCU ERN 76)

Thanks, everybody, for writing about this. The standardization process is one of consensus, and if the GCC developers find some areas of disagreement here I think it unlikely that the other POSIX implementers will agree with the proposed action. Hence I am thinking of weakening it. Currently the

proposed Opengroup action for c99 command (XCU ERN 76)

I recently proposed to the Open Group an action that would modify the POSIX specification for the c99 command that is often implemented using GCC. I thought the action would not affect GCC's conformance, but Joseph S. Myers raised the issue of UCNs and multibyte characters and I'd like to double-c