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

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

d.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) (_AC_CXX_CXX11_TES

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

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 b2f28ce66ea1618b50e14085059ce512d7245300 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date:

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. Sure, but someone

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

Re: [RFC] Add stdckdint.h header for C23

On 6/12/23 23:28, Jakub Jelinek via Libc-alpha wrote: On Mon, Jun 12, 2023 at 09:51:02PM +, Joseph Myers wrote: On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote: I have looked at gnulib stdckdint.h and they are full of workarounds for various compilers, EDG doesn't do this, clang

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

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

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

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 != 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);' disagrees

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

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

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

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

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

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

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

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

[PATCH] Document that -fno-trampolines is for Ada only [PR100735]

The GCC manual's documentation of -fno-trampolines was apparently written from an Ada point of view. However, when I read it I understandably mistook it to say that -fno-trampolines also works for C, C++, etc. It doesn't: it is silently ignored for these languages, and I assume for any language

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

On 10/2/20 4:44 PM, Alejandro Colomar wrote: I know, they aren't perfect. But they are still very useful, and don't see a good reason to not document them. "aren't perfect" is an understatement More important, lots of things in GNU C are useful but shouldn't be documented in the man

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

On 10/2/20 1:03 PM, Alejandro Colomar wrote: I know it's not in stdint, but I mean that it behaves as any other stdint type. It doesn't. There's no portable way to use scanf and printf on it. You can't reliably convert it to intmax_t. It doesn't have the associated _MIN and _MAX macros that

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

On 10/2/20 11:38 AM, Alejandro Colomar wrote: .I void * renders with a space in between. That's odd, as "man(7)" says "All of the arguments will be printed next to each other without intervening spaces". I'd play it safe and quote the arg anyway. > %p works with any object pointer type

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

On 10/2/20 12:01 PM, Alejandro Colomar wrote: If you propose not to document the stdint types either, This is not a stdint.h issue. __int128 is not in stdint.h and is not a system data type in any real sense; it's purely a compiler issue. Besides, do we start repeating the GCC manual too,

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

Why describe __int128_t in these man pages at all? __int128_t is not a property of either the kernel or of glibc, so it's out of scope.

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

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

On 10/2/20 8:14 AM, Alejandro Colomar wrote: +.I void * GNU style is a space between "void" and "*", so this should be '.I "void\ *"', both here and elsewhere. The backslash prevents a line break. +Conversions from and to any other pointer type are done implicitly, +not requiring casts at

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

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: Ping Re: Make max_align_t respect _Float128 [version 3]

On 09/19/2016 08:58 AM, Joseph Myers wrote: Ping. This patch is pending review. Thanks, the patch looks good to me. It should be safe for the uses of max_align_t that I know of (e.g., Emacs).

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 04:56 AM, Mark Wielaard wrote: I don't think there is anything valgrind can do to detect that compw really only depends on d[0] if the result is false. valgrind (with the default --partial-loads-ok=yes) could and should do the same thing with cmpw that it already does with cmpl.

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but uninitialised then it will just track the undefinedness complain later if such a value is used. I think the

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer calling it a defect, as most code I've seen

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 08:16 AM, Joseph Myers wrote: I don't think there's any such requirement in the case of flexible array members; if you use malloc to allocate a structure with a flexible array member, you can access as many trailing array elements as would fit within the allocated size, whether or

Re: Make max_align_t respect _Float128

On 08/26/2016 02:45 PM, Florian Weimer wrote: In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result. Hmm, well, in that case I suppose I should change Emacs to ignore max_align_t as well. Thanks for the heads-up.

Re: Make max_align_t respect _Float128

On 08/26/2016 01:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; It should be fine, though I would like

Re: [C/C++ PATCH] Implement -Wshift-negative-value (PR c/65179)

b8f4f998104e74fc2c4a3759317b5153e95db16e Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Fri, 8 May 2015 14:47:40 -0700 Subject: [PATCH] Avoid left-shift-into-sign-bit undefined behavior Problem reported by Joseph Myers in: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00704.html * localtime.c (detzcode

Re: [PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

(revision 210804) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-05-22 Paul Eggert egg...@cs.ucla.edu + + PR other/56955 + * doc/extend.texi (Function Attributes): Fix __attribute__ ((malloc)) + documentation; the old documentation didn't clearly state

[PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

/ChangeLog (revision 210629) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-05-20 Paul Eggert egg...@cs.ucla.edu + + PR other/56955 + * doc/extend.texi (Function Attributes): Fix __attribute__ ((malloc)) + documentation; the old documentation didn't clearly state the + constraints

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

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 http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00106.html for the problem with a gcc-4.3 snapshot with --std=gnu99 -O2 and glibc wchar.h. Ralf Wildenhues [EMAIL

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.gnu.org/bugzilla/show_bug.cgi?id=30477 The latter would

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

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

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

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

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

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

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 say that (sum

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

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 binary

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

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

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 helping

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 better. It's not all about benchmark scores. But so far, benchmark scores

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 gzip

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

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

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 real

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 (admittedly limited) real-world measurements

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

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

[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 = - h1;

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

[EMAIL PROTECTED] (Richard Kenner) writes: I found my copy of KR (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: KRv2 is post-C89. If memory serves, it was C89 that established

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 there

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 idea

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

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: 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; j *= 2; }

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 result

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

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

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 relevant section/paragraph in C99 standard where it allows

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

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

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. Thanks, I didn't

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

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

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 Eggert [EMAIL PROTECTED] * NEWS

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) is that if the C

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 break

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?

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

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 http://gcc.gnu.org/gcc-4.2/changes.html,

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?

) 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 commonly used. On Tue, 19 Dec 2006, Paul Eggert

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