Re: FW: How does GCC implement dynamic binding?

David Daney wrote: Perhaps you are right, but it would not surprise me if there were commercial entities based around FOSS that would provide that type of support. Certainly for instance AdaCore is able to provide this kind of certification for its customers using its commercial version of GN

Re: compiling very large functions.

Kenneth Zadeck wrote: I actually think that you small talk example is the exception and not the rule. I would guess that the vast majority of very large functions are machine generated simulations where the optimizer most likely provides little benefit. Wouldn't it be best to base this discus

Re: Canonical type nodes, or, comptypes considered harmful

Doug Gregor wrote: These are different types. For instance, "int" and "long" are distinct types in C++, even if both map onto 32-bit integers. And in Ada, you can have any number of distinct integer types with identical representations.

Re: comments on getting the most out of multi-core machines

Howard Chu wrote: It also somewhat blurs the distinction between a fully linked executable file and an intermediate relocatable object, since executables can also be incrementally relinked. It's a real timesaver when you just need to fix one file in a very large program. a proper fix-and-con

Re: Threading the compiler

Geert Bosch wrote: Given that CPU usage is at 100% now for most jobs, such as bootstrapping GCC, there is not much room for any improvement through threading. Geert, I find this a bit incomprehensible, the whole point of threading is to increase CPU availability by using multiple cores. Even

Re: strict aliasing benefit examples

Paolo Bonzini wrote: for(i = 0;i<*t;i++) *f += 1.0; This one is pretty realistic, especially if you consider C++ and inlining: Don't you think that a convincing argument here has to be based on actual timings with and without strict aliasing. It would be interesting to see cases where that

Re: strict aliasing benefit examples

Richard Kenner wrote: Since humans have to do a bit of alias analysis when maintaining or writing code, the extra clarity of pulling things into temporary variables isn't wasted. Sorry, I don't follow. Why should we want to do "a bit of alias analysis" when maintaining or writing code? It wou

Re: Char shifts promoted to int. Why?

Chris Lattner wrote: Sorry, but you're incorrect. While it may be "logical" that shifting a value left more bits than its size will give you zero, this is not what C specifies. I am puzzled, what exactly *does* C specify in this case? I reread the thread, but it's not clear what the requi

Re: Char shifts promoted to int. Why?

Chris Lattner wrote: C99 says: The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is un

Re: Char shifts promoted to int. Why?

Chris Lattner wrote: It only retains the proper semantics when targeting a machine that zeros the result of oversized left shifts. The original question was about X86 codegen, which doesn't have this behavior, so it is not valid. RIght, I see, though it can still be applied in some cases .

Re: Char shifts promoted to int. Why?

Chris Lattner wrote: Thus, the transformation is safe in this specific case on i386. However, shifting a 32-bit value left by 33 bits would not be safe. That's the case where the transformation IS safe, since shifting a 32-bit value left by 33 bits gives an undefined result as I understand t

Re: GCC optimizes integer overflow: bug or feature?

Brooks Moses wrote: Now, if your argument is that following the LIA-1 standard will prevent optimizations that could otherwise be made if one followed only the C standard, that's a reasonable argument, but it should not be couched as if it implies that preventing the optimizations would not be

Re: GCC optimizes integer overflow: bug or feature?

Andrew Haley wrote: Robert Dewar writes: > Brooks Moses wrote: > > > Now, if your argument is that following the LIA-1 standard will > > prevent optimizations that could otherwise be made if one > > followed only the C standard, that's a reasonable argume

Re: GCC optimizes integer overflow: bug or feature?

Andrew Pinski wrote: I don't have the number of times this shows up or how much it helps but it does help out on being able to vectorize this loop. Just to be clear, when I ask for quantitative data, it is precisely data about "how much it helps". It is always easy enough to show cases where t

Re: GCC optimizes integer overflow: bug or feature?

Andrew Haley wrote: Robert Dewar writes: > Andrew Haley wrote: > > > We've already defined `-fwrapv' for people who need nonstandard > > arithmetic. > > Nonstandard implies that the result does not conform with the standard, I don't think it d

Re: GCC optimizes integer overflow: bug or feature?

Gabriel Dos Reis wrote: Andrew Haley <[EMAIL PROTECTED]> writes: | Robert Dewar writes: | > Andrew Haley wrote: | > | > > We've already defined `-fwrapv' for people who need nonstandard | > > arithmetic. | > | > Nonstandard implies that the r

Re: GCC optimizes integer overflow: bug or feature?

Andrew Haley wrote: > I suspect the actual argument must be somewhere else. I'm sure it is. The only purpose of my mail was to clarify what I meant by "nonstandard", which in this case was "not strictly conforming". I didn't intend to imply anything else. But a compiler that implements wra

Re: GCC optimizes integer overflow: bug or feature?

Florian Weimer wrote: * Paolo Bonzini: Interesting read. I agree with the proposed fix; however, note that GCC does not make the result of overflowing signed left-shifts undefined, exactly because in this case the overflow is relied upon by too many existing programs Is this documented somew

Re: GCC optimizes integer overflow: bug or feature?

Zdenek Dvorak wrote: IMHO, using loops relying on the behavior of overflow of an induction variable (*) is an ugly hack and whoever writes such a code does not deserve for his program to work. I suspect everyone would agree on this, and in practice I would guess that a) there are no programs

Re: GCC optimizes integer overflow: bug or feature?

Joseph S. Myers wrote: On Tue, 19 Dec 2006, Florian Weimer wrote: * Paolo Bonzini: Interesting read. I agree with the proposed fix; however, note that GCC does not make the result of overflowing signed left-shifts undefined, exactly because in this case the overflow is relied upon by too man

Re: GCC optimizes integer overflow: bug or feature?

Florian Weimer wrote: Something like: GCC does not use the latitude given in C99 only to treat certain aspects of signed @samp{<<} as undefined: If the right operand @var{n} is non-negative and less than the width of the left operand @var{val}, the resulting valu

Re: GCC optimizes integer overflow: bug or feature?

Paolo Bonzini wrote: No, it has not. For example, if a is 0x4000 in a 32 bit type and arithmetic wraps, a*2 = -0x8000 (overflow), and hence (a*2)/2 = -0x4000 = -1073741824. Paolo Yes indeed, my mistake, I was thinking unsigned :-( and of course signed is the whole point here!

Re: GCC optimizes integer overflow: bug or feature?

Paolo Bonzini wrote: We've optimized expressions such as (a*2)/2 on the basis of overflow being undefined for a very long time, not just loops. What is (a*2)/2 optimized to? certainly it has the value a if you wrap, so you are not necessarily depending on undefined here. it's interesting that

Re: GCC optimizes integer overflow: bug or feature?

Denis Vlasenko wrote: I want sane compiler. One in which N-bit integer variables stay exactly N-bit. Without "magic" N+1 bit which is there "somethimes". a*2/2: If I say "multiply by 2 and _after that_ divide by 2, I meant that. Compiler can optimize it any way it wants, as long as result is the

Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: Compiler can optimize it any way it wants, as long as result is the same as unoptimized one. We have an option for that. It's called -O0. Pretty much all optimization will change the behavior of your program. Now that's a bit TOO strong a statement, critical optimizations l

Re: GCC optimizes integer overflow: bug or feature?

Richard B. Kreckel wrote: By the same token it would be wise to refrain from turning on any optimization that breaks programs which depend on wrapping signed integers. Silently breaking LIA-1 semantics is imprudent. I am not so sure about that conclusion, which I why I would like to see more d

Re: GCC optimizes integer overflow: bug or feature?

Andrew Pinski wrote: Actually they will with multi threaded program, since you can have a case where it works and now it is broken because one thread has speed up so much it writes to a variable which had a copy on another thread's stack. So the argument about it being too strong is wrong beca

Re: GCC optimizes integer overflow: bug or feature?

Dave Korn wrote: Why isn't that just a buggy program with wilful disregard for the use of correct synchronisation techniques? Right, I think most people would agree it is. But for sure, if you consider that making the code go faster is itself a change in behavior, then obviously all optimiz

Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: As opposed to a buggy program with wilful disregard for signed overflow semantics? ;-) I know there is a smiley there, but in fact I think it is useful to distinguish these two cases.

Re: GCC optimizes integer overflow: bug or feature?

Paul Schlie wrote: As a compromise, I'd vote that no optimizations may alter program behavior in any way not explicitly diagnosed in each instance of their application. Sounds reasonable, but it is impossible and impractical! And I think anyone familiar with compiler technology and optimizatio

Re: GCC optimizes integer overflow: bug or feature?

Andrew Haley wrote: Is it simply that one error is likely to be more common than another? Or is there some more fundamental reason? I think it is more fundamental. Yes, of course any optimization will change resource utilization (space, time). An optimization may well make a program larger, wh

Re: GCC optimizes integer overflow: bug or feature?

Zdenek Dvorak wrote: actually, you do not even need (invalid) multithreaded programs to realize that register allocation may change behavior of a program. If the size of the stack is bounded, register allocation may cause or prevent program from running out of stack, thus turning a crashing prog

Re: GCC optimizes integer overflow: bug or feature?

[EMAIL PROTECTED] wrote: it should be fairly easy to indicate each and every undefined/unspecified value/semantic assumption being applied to both explicitly declared variables and implicit intermediate results of programmer specified expressions and their resulting hopefully logically equival

Re: GCC optimizes integer overflow: bug or feature?

Gabriel Dos Reis wrote: I don't believe this particular issue of optimization based on "undefined behaviour" can be resolved by just telling people "hey look, the C standard says it is undefined, therefore we can optimize. And if you're not happy, just tell the compiler not to optimize". For not

Re: -fwrapv enables some optimizations

Geert Bosch wrote: This is completely wrong. Making operations undefined is a two-edged sword. At the one hand, you can make more assumptions, but there's also the issue that when you want to rewrite expressions, you have to be more careful to not introduce undefined behavior when there was none

Re: GCC optimizes integer overflow: bug or feature?

On 2006-12-21, at 22:19, David Nicol wrote: It has always seemed to me that floating point comparison could be standardized to regularize the exponent and ignore the least significant few bits and doing so would save a lot of headaches. This would be a real nuisance. This myth that you sho

Re: GCC optimizes integer overflow: bug or feature?

Marcin Dalecki wrote: On 2006-12-21, at 23:17, Robert Dewar wrote: Marcin Dalecki: Well actually it wouldn't "save the world". However adding an op-code implementing: x eqeps y <=> |x - y| < epsilion, would be indeed helpful. Maybe some m-f has already patented it,

Re: GCC optimizes integer overflow: bug or feature?

Marcin Dalecki wrote: Of course I didn't think about a substitute for ==. Not! However I think that checks for |x-y| < epsilion, could be really given a significant speed edge if done in a single go in hardware. One thing to ponder here is that "thinks" like this are what lead to CISC instr

Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: On Friday 22 December 2006 00:58, Denis Vlasenko wrote: On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote: There are a lot of 100.00% safe optimizations which gcc can do. Value range propagation for bitwise operations, for one Or this, absolutely typical C code. i386 ar

Re: GCC optimizes integer overflow: bug or feature?

Paul Brook wrote: Who says the optimisation is valid? The language standard? The example was given as something that's 100% safe to optimize. I'm disagreeing with that assertion. The use I describe isn't that unlikely if the code was written by someone with poor knowledge of C. My point is

Re: GCC optimizes integer overflow: bug or feature?

Dave Korn wrote: On 22 December 2006 00:59, Denis Vlasenko wrote: Or this, absolutely typical C code. i386 arch can compare 16 bits at a time here (luckily, no alighment worries on this arch): Whaddaya mean, no alignment worries? Misaligned accesses *kill* your performance! is it really

Re: GCC optimizes integer overflow: bug or feature?

Andrew Pinski wrote: On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote: Misaligned accesses *kill* your performance! Maybe on x86, but on PPC, at least for the (current) Cell's PPU misaligned accesses for most cases unaligned are optimal. is that true across cache boundaries? Thanks, Andr

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

Daniel Berlin wrote: I'm sure no matter what argument i come up with, you'll just explain it away. The reality is the majority of our users seem to care more about whether they have to write "typename" in front of certain declarations than they do about signed integer overflow. I have no idea

Re: Compiler loop optimizations

Ian Lance Taylor wrote: Christian Sturn <[EMAIL PROTECTED]> writes: Thank you for your answer. Is there any chance to have gcc dump out an optimized code in the form the source level language, e.g. can I run gcc with some optimizations and see how the compiler modified my C source code? You

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

Paul Eggert wrote: In practice, I expect that most C programmers probably assume wrapv semantics, if only unconsciously. The minimal C Standard may not entitle them to that assumption, but they assume it anyway. Part of this is the Java influence no doubt. Sorry, but that is just the way the

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

Marc Espie wrote: Specifically, because we value reliability over speed and strict standard conformance... Still as a long term goal, it would be good to try to have your C programs written in C, and not some ill-defined dialect thereof!

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

Richard Kenner wrote: Specifically, because we value reliability over speed and strict standard conformance... Seems to me that programs that strictly meet the standard of the language they are written in would be more reliable than programs that are written in some ill-defined language. In t

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

Richard Kenner wrote: which clearly says LIA-1 isn't a requirement - notice "if" in the second setence. H.1 makes it clear that the entire Annex H doesn't add any extra rule to the language but merely describes what C is in regard to LIA-1. H.2 doubly makes it clear that C as it defined isn't LIA

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

Paul Eggert wrote: 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

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

Richard Kenner wrote: Not so appalling really, given that relying on wrapping is as has been pointed out in this thread, the most natural and convenient way of testing for overflow. It is really *quite* difficult to test for overflow while avoiding overflow, and this is something that is probably

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

Gabriel Dos Reis wrote: I have been looking into infer_loop_bounds_from_signedness() called from infer_loop_bounds_from_undefined(). At some places, nowrap_type_p() is used but this function operates only on types, so there will be too many false positive there; yet we will miss warning through

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

Andrew Pinski wrote: -fwrapv-in-all-cases-except-loop-bounds Again, please don't this the default for Fortran as integer overflow has been undefined since at least 1977 so I don't think it is a good idea for GCC in general anyways as evidence of Fortran. -- Pinski Well the question is whet

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

Richard Kenner wrote: Note the interesting places in VRP where it assumes undefined signed overflow is in compare_values -- we use the undefinedness to fold comparisons. Unfortunately, comparisons are the trickiest case because you have to be careful to avoid deleting a comparison that exists t

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

Paul Eggert wrote: For writing new code, it's easy: the C standard is all that should be assumed. Old code should be modified, as time allows, to be consistent with that standard. This may be the policy of the GCC developers for the code they maintain, but it's not a realistic policy for ever

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

Richard Kenner wrote: I can't speak for any other GCC developer, but I personally am quite comfortable viewing any code that assumes wrapping semantics as broken and needing fixing with the exception of these cases of checking for overflow: there simply is no good way in C to do these checks in

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

Andrew Pinski wrote: It does buy you something for code like: if (a - 10 < 20) Well that particular example is far fetched in code that people expect to run efficiently, but with a bit of effort you could come up with a more realistic example. Compilers are always full of such optimizations wh

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

Gaby said K&R C leaves arithmetic overflow undefined (except for unsigned types), in the sense that you get whatever the underlying hardware gives you. If it traps, you get trapped. If it wraps, you get wrapped. Is that really what the K&R book says, or just what compilers typically did? My mem

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

(first, sorry for breaking the thread, pilot error on my part) Here is the message again properly threaded. The other broken thread by dewar's evil twin can be discarded. Andrew Pinski wrote: It does buy you something for code like: if (a - 10 < 20) Well that particular example is far fetch

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

(again I apologize for breaking the thread), Here is the reply I sent properly threaded Gaby said > K&R C leaves arithmetic overflow undefined (except for unsigned > types), in the sense that you get whatever the underlying hardware > gives you. If it traps, you get trapped. If it wraps, you g

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

Richard Kenner wrote: I found my copy of K&R (Second Edition). Page 200: "The handling of overflow, divide check, and other exceptions in expression evaluation is not defined by the language. Most existing implementations of C ignore overflow in evaluation of signed integral expressions and as

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

Vincent Lefevre wrote: On 2006-12-30 20:07:09 -0500, Robert Dewar wrote: In my view, this comparison optimization should not have been put in without justification given that it clearly does affect the semantics of real code. Indeed if you really see code like if (a - 10 < 20) in pl

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

Richard Kenner wrote: Wait, though: K&Rv2 is post-C89. Not completely: it's published in 1988, but the cover says "based on draft-proposed ANSI C". Naturally K&Rv2 documents this, but if you want to know about traditional practice the relevant wording should come from K&Rv1, not v2. I don't

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

Richard Kenner wrote: The burden of proof ought to be on the guys proposing -O2 optimizations that break longstanding code, not on the skeptics. There's also a burden of proof that proposed optimizations will actually "break longstanding code". So far, all of the examples of code shown that as

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

Richard Kenner wrote: The burden of proof ought to be on the guys proposing -O2 optimizations that break longstanding code, not on the skeptics. There's also a burden of proof that proposed optimizations will actually "break longstanding code". So far, all of the examples of code shown that as

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

Vincent Lefevre wrote: My point was that if you see this in a source program, it is in fact a possible candidiate for code that can be destroyed by the optimization. Well, only for non-portable code (i.e. code based on wrap). I also suppose that this kind of code is used only to check for over

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

Richard Kenner wrote: And the idea that people were not used to thinking seriously about language semantics is very odd, this book was published in 1978, ten years after the algol-68 report, a year after the fortran 77 standard, long after the COBOL 74 standard, and a year before the PL/1 standa

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

Vincent Lefevre wrote: If done in unsigned, this won't lead to any optimization, as unsigned arithmetic doesn't have overflows. So, if you write "a - 10" where a is unsigned, the compiler can't assume anything, whereas is a is signed, the compiler can assume that a >= INT_MIN + 10, reducing the

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

Vincent Lefevre wrote: No, this isn't what I meant. The C standard doesn't assume wrapping, so I don't either. If the compiler doesn't either, then it can do some optimizations. Let's take a very simple example: We perfectly understand that if the compiler does not assume wrapping, but instead

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

Gerald Pfeifer wrote: On Sun, 31 Dec 2006, Robert Dewar wrote: If you do it in signed expecting wrapping, then the optimization destroys your code. Yes, it is technically your fault, but this business of telling users "sorry, your code is non-standard, gcc won't handle it as you expe

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

Vincent Lefevre wrote: On 2006-12-31 10:08:32 -0500, Richard Kenner wrote: Well, that's not equivalent. For instance, MPFR has many conditions that evaluate to TRUE or FALSE on some/many implementations (mainly because the type sizes depend on the implementation), even without the assumption tha

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

Richard Kenner wrote: ] Essentially, there are three choices: with -fwrapv, you must preseve wrapping semantics and do NONE of those optimizations; with -fno-wrapv, you can do ALL of them; in the default cause, a heuristic can be used that attempts to balance optimization quality against breakage

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

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 since the optimal way of doing the check presumably depends on

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

Paul Schlie wrote: Upon attempted careful reading of the standard's excerpts quoted by Gabriel Dos Reis per , it's not clear that GCC's current presumption of LIA-1 overflow semantics in absents of their true support is actually advocated by the st

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

Paul Eggert wrote: The question is not whether GCC should support wrapv semantics; it already does, if you specify -fwrapv. The question is merely whether wrapv should be the default with optimization levels -O0 through -O2. That over simplifies, because it presents things as though there are

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

Bruce Korb wrote: Changing that presumption without multiple years of -Wall warnings is a Really, Really, Really Bad Idea. I am still not ready to agree that this is a RRRBI for the case of loop invariants. We have not seen ONE imaginary example, let alone a real example, where the optimziatio

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

Richard Kenner wrote: the seemingly prevalent attitude "but it is undefined; but it is not C" is the opinion of the majority of middle-end maintainers. Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that signed overflow wraps. I've heard nobody argue that it is. The q

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

Geert Bosch wrote: As undefined execution can result in arbitrary badness, this is really at odds with the increasing need for many programs to be secure. Since it is almost impossible to prove that programs do not have signed integer overflow, That seems a bit pessimistic, given the work Prax

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

Andrew Pinski wrote: Look at Fortran argument aliasing, we get almost no bugs about that undefinedness. We have an option to change the way argument aliasing works, in the same way we have an option for signed overflow. I don't see why overflow will be any different from argument aliasing. W

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

Ian Lance Taylor wrote: I don't think -frisky is a good name for that option. A better name would be -fstrict. or perhaps -fstandard which says "my program is 100% compliant ISO C. please mr. compiler make any assumptions you like based on knowing this is the case. If my claim that I am 100%

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

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

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

Paul Schlie wrote: So this proposal would be tantamount to implementing a different language at -O1 and -O2, and having -O2 change the formal semantic interpretation of the program. That seems a very bad idea to me. ... Yes, it would be laudable for GCC to adopt the principle that whatever lan

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

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

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

Re: compile time enforcement of exception specification

James Dennett wrote: There has been much debate, and a large fraction of those involved feel that static checking of exceptions in C++ is *not* an improvement from the current situation. There has also been much written on the weaknesses of the Java approach. Note: I'm not expressing my person

Re: Miscompilation of remainder expressions

It's interesting that the same issue arose with GNAT, but we had no option to ignore the special case, since one of the official Ada validation test programs tested this case, and indeed as you see below there is a special test: function q (a, b : integer) return integer is begin return a rem

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bu

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: Reading the thread "Autoconf manual's coverage of signed integer overflow & portability" I was horrified to discover about GCC's miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. Are there plans to fix this bu

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: Andrew Haley wrote: Roberto Bagnara writes: > > Reading the thread "Autoconf manual's coverage of signed integer > overflow & portability" I was horrified to discover about GCC's > miscompilation of the remainder expression that causes INT_MIN % -1 > to cause a SIGF

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: To the point that, when a/b is not representable, raising SIGFPE for a%b is standard conformant behavior? possibly so .. Note however that I am not saying that the standard is not defective. Who knows how to write and submit C/C++ standard defect reports? Let us do tha

Re: Miscompilation of remainder expressions

Gabriel Paubert wrote: \ No, because the instruction has actually two result values: - the remainder, which you could safely set to zero (not 1!) - the quotient, which is affected by the overflow and there may be compiler and languages that rely on the exception being generated. But the div

Re: Miscompilation of remainder expressions

David Daney wrote: Roberto Bagnara wrote: Everyone knows that dividing a number by -1 or 1 gives a 0 remainder. To the contrary, no one expects a%b to raise SIFPE when b != 0. On the contrary, since the beginning of time SIGFPE has been generated on GCC/x86/linux under these conditions. T

Re: Miscompilation of remainder expressions

Dave Korn wrote: On 16 January 2007 18:23, Robert Dewar wrote: Gabriel Paubert wrote: \ No, because the instruction has actually two result values: - the remainder, which you could safely set to zero (not 1!) - the quotient, which is affected by the overflow and there may be compiler and

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: I am sorry if I brought you to think that I am asking something for me. There is no longer a problem for me personally: I will simply stop using % in my projects (which, by the way are in C++) and will use custom functions instead. I have almost finished an Autoconf test

Re: Miscompilation of remainder expressions

Roberto Bagnara wrote: You are right: I am not familiar with DO-178B certification. Fair enough, but it means you should never use avionics code as an example in such discussions. No life has ever been lost due to a software bug in the realm of commercial aviation, and that was not achieved by

Re: Miscompilation of remainder expressions

Andrew Haley wrote: Roberto Bagnara writes: > Robert Dewar wrote: > > > Yes, it's a bug, is it a serious bug, no? Will real software > > be affected? no. Indeed I find any program that actually > > does this remainder operation in practice to be highly >

Re: Miscompilation of remainder expressions

H .. I wish some of the more important bugs in gcc received the attention that this very unimportant issue is receiving :-) I guess the difference is that lots of people can understand this issue. Reminds me of the hullabaloo over the Pentium division problem. The fact of the matter was that

  1   2   3   4   5   6   7   8   9   10   >