Re: error: unable to emulate 'DI'

Andrew Haley wrote: > Paul Schlie wrote: >> Andrew Haley wrote: >>> Omar Torres wrote: >>>> Hi Andrew, >>>> Looks like Paul did submitted a patch here: >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 >>>> >>>> C

Re: error: unable to emulate 'DI'

Andrew Haley wrote: > Omar Torres wrote: >> Hi Andrew, >> Looks like Paul did submitted a patch here: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 >> >> Can you or someone else take a look and comment on it? > > Oh my goodness, that is a huge patch. It's also incorrect, as > far as I ca

Re: US-CERT Vulnerability Note VU#162289

Mark Mitchell wrote: > ... > > And: > >> Addition or subtraction of a pointer into, or just beyond, an array object >> and an integer type produces a result that does not point into, or just >> beyond, the same array object (6.5.6). >> >> is undefined behavior. So then unless the compiler can det

Re: US-CERT Vulnerability Note VU#162289

> Robert Dewar <[EMAIL PROTECTED]> > >> Richard Guenther wrote: >> >> In absence of any declared object (like with this testcase where we just >> have an incoming pointer to some unknown object) the compiler can >> still assume that any valid object ends at the end of the address space. >> Thus,

Re: US-CERT Vulnerability Note VU#162289

>> (as an aside, as most target implementations treat pointers as unsigned >> values, its not clear that presuming signed integer overflow semantics are >> a reasonable choice for pointer comparison optimization) > > The point is not of presuming signed integer overflow semantics (I was > correcte

Re: US-CERT Vulnerability Note VU#162289

> Florian Weimer wrote: > >> Robert C. Seacord wrote: >> >> i agree that the optimization is allowed by C99. i think this is a >> quality of implementation issue, and that it would be preferable for >> gcc to emphasize security over performance, as might be expected. > > I don't think this is r

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> is required to be well specified [...] as otherwise the language >> couldn't be utilized to write even the most hardware drivers >> required of all computer systems. > > In a sense, the language *can't* be used

Re: Signed into overflow behavior in the security context

> Paul wrote >> Robert wrote: >>> Paul Schlie wrote: >>> - agreed, and thereby objects having no legitimate trap representation, >>> such as most if not all implementations of integers and floating point >>> objects on most if not all current target ma

Re: Signed into overflow behavior in the security context

> Robert wrote: >> Paul Schlie wrote: >> - agreed, and thereby objects having no legitimate trap representation, >> such as most if not all implementations of integers and floating point >> objects on most if not all current target machines, and thereby their >> ac

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> One can only hope that the recommendations won't see the light of day in >> their present form, as it's fairly clear that once an unspecified value is >> read (presuming absents of a trap representation), it beco

Re: Signed int overflow behavior in the security context

> Joseph Myers wrote: > DR#260 seems clear enough that indeterminate values may be treated > distinctly from determinate values including randomly changing at any > time. One can only hope that the recommendations won't see the light of

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap) > > Can you cite the part of the standard that says that? The fact that > an expression designates an object does not exclud

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie wrote: >> if it has an indeterminate value [...] has no bearing on an rvalue >> access to a well defined storage location > > You might think so, but that's actually not true in the C standard's > terminology. It sounds

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.

Re: Signed int overflow behavior in the security context

> Paul Schlie wrote: >>> Brooks Moses wrote: >>> <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the con

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: >> Paul Schlie wrote: >>> Brooks Moses wrote: >>> <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined

Re: Signed int overflow behavior in the security context

> Brooks Moses wrote: > ... > Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what ever value may resu

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote >> Paul Schlie wrote: >> - However x ^= x :: 0 for example is well defined because absent any >> intervening assignments, all reference to x must semantically yield the >> same value, regardless of what that value may be. > > Nope, th

Signed int overflow behavior in the security context

> Richard Guenther wrote: > On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote: >>>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >>> Likewise, if the program has an uninitialized variable, the behavior >>> will differ depending on det

Re: Signed int overflow behavior in the security context

> David Daney wrote: >> Paul Schlie wrote: >> (however as you appear to be describing an algorithm attempting to rely on >> the implicit addresses of object storage locations resulting from an assumed >> calling or allocation convention; and as such assumptions are well

Re: Signed int overflow behavior in the security context

With hind sight, it would appear that as many of these difficulties seem rooted in the historical implicit declaration/conversions of variables/parameters to signed int which has correspondingly tended to be implemented as having wrapping semantics regardless of overflow being undefined; and as typ

Re: Signed int overflow behavior in the security context

>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >> > Robert Dewar wrote: >> > >> > People always say this, but they don't really realize what they are >> > saying. This would mean you could not put variables in registers, and >

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: > > People always say this, but they don't really realize what they are > saying. This would mean you could not put variables in registers, and > would essentially totally disable optimization. - can you provide an example of a single threaded program where the assignment of

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

> Richard Kenner wrote: > ... > In other words, -fwrapv says that we are modifying the language semantics > to define signed overflows as wrapping and this will have effects on the > optimizer (so the language effect is primary), while -fno-strict-aliasing > says what the optimizer will do and henc

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

> Robert Dewar wrote: > ... > I think it is a bad idea for the optimization levels to deal with > anything other than optimization. -fwrapv is not about optimization, > it is about changing the language semantics. > > So this proposal would be tantamount to implementing a different > language at -

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

> Ian Lance Taylor wrote: > ... > I don't personally see that as the question. This code is > undefined, and, therefore, is in some sense not C. If we take > any other attitude, then we will be defining and supporting > a different language. I think that relatively few people want > the language

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

> Robert wrote: >> Paul Schlie wrote: >> Upon attempted careful reading of the standard's excerpts quoted by >> Gabriel Dos Reis per <http://gcc.gnu.org/ml/gcc/2006-12/msg00763.html>, >> it's not clear that GCC's current presumption of LIA-1 overfl

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

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 standard. As by my rea

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

> Richard Guenther wrote: >> Robert Dewar wrote: >>> 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 declaration

Re: GCC optimizes integer overflow: bug or feature?

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

Re: Char shifts promoted to int. Why?

> Dorit Nuzman wrote: >> Paul Schlie wrote: >> ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) ) :: >> ((char)x) = ((char)( ((char)x) << ((int)c) ) ) >> >> if the shift count ((int)c) is semantically preserved. >> >> thereby con

Re: Char shifts promoted to int. Why?

> From: Paul Brook <[EMAIL PROTECTED]> > On Monday 18 December 2006 01:15, Paul Schlie wrote: >> Chris Lattner wrote: >>> On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote: >>>> I seem unable to get a QImode shift instruction from this code: >

Re: Char shifts promoted to int. Why?

Chris Lattner wrote: > On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote: >> I seem unable to get a QImode shift instruction from this code: >> >> unsigned char x; >> >> void qishifttest2 (unsigned int c) >> { >>x <<= c; >> } >> >> should have been generated. Also, notice the redunda

Re: Storage for uninitialized objects (PR 24626)

> From: Ian Lance Taylor >> Paul Schlie <[EMAIL PROTECTED]> writes: >> Given that it would appear that the only time the compiler may attempt >> to optimize the allocation/use of an un-initialized variable, is when it >> knows for certain it hasn't been

Re: Storage for uninitialized objects (PR 24626)

> From: Michael Veksler <[EMAIL PROTECTED]> > In theory you could be right: > ... > Now, consider the case where the compiler can prove that > is_debug_enabled(i) is always zero. So `a' is never initialized. > Why can't the compiler assume that is_debug_verbose_enabled(i) is > zero as well? By igno

Re: Storage for uninitialized objects (PR 24626)

ch as 0 which it may then presume during optimization, given all remaining alternatives would seem to have less desirable potential consequences? > From: Ian Lance Taylor >. Paul Schlie <[EMAIL PROTECTED]> writes: >> As a simple example, although x may be indeterminate -

Re: Storage for uninitialized objects (PR 24626)

actually make substantially more sense for a compiler to do what the code logically specified in absents of any more reliably predictable alternative; under the premise that consistency is good.) > From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> tools which indis

Re: Storage for uninitialized objects (PR 24626)

L PROTECTED]> >> Paul Schlie wrote: >>> Ian Lance Taylor writes: >>> >>> gcc assumes that if a variable is uninitialized, it can use any value >>> whatsoever for any use of the variable. gcc does not assume that all >>> uses of an uninitia

Re: Storage for uninitialized objects (PR 24626)

> Ian Lance Taylor writes: > > gcc assumes that if a variable is uninitialized, it can use any value > whatsoever for any use of the variable. gcc does not assume that all > uses of an uninitialized variable must have the same value. > > It is of course possible to write a correct program which us

Re: insv vs one-bit field

> DJ Delorie wrote > Revisiting an old thread... >> > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: >> > So... why is it illegal to put a constant into a single bit field? >> >> Probably because it was more efficient to use some other pattern >> for some other target. > > That's a ba

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> Jim Blandy wrote: > On 1/2/06, Paul Schlie wrote: >> - at the most basic level, I feel like I've too often needlessly wasted >> time debugging programs at one level of optimization, to only see a >> different behavior needlessly expressed at a different level

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Mike Stump <[EMAIL PROTECTED]> >> On Dec 31, 2005, at 9:26 PM, Paul Schlie wrote: >> be able define NULL as being some value other than 0. > > Do you have a specific chip in mind you want to do this for? Why > would you want to do this? How many users wo

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Robert Dewar <[EMAIL PROTECTED]> > .. there is no requirement that optimization preserve the behavior of > undefined programs ... It is fine to argue that defining the semantics > is useful in a particular case, but arguing solely from the point of > view of trying to preserve observed beha

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Michael Veksler wrote: > I am not sure if the original poster meant the same as I do. What I have > in mind is optimizations opportunities like the one of the following > linked list: (for reference: http://gcc.gnu.org/ml/gcc/2006-01/msg7.html ) - although not specifically what I was

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Robert Dewar <[EMAIL PROTECTED]>> > though Paul's mention of saturating arithmetic seems way out of left field to > me, since very few common architectures implement saturating arithmetic at the > hardware level. - Only every single dsp, and an increasing number of otherwise conventional

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> Gabriel Dos Reis wrote: > I predict we will end up changing nothing for GCC; I also predict that > he'll be unsatisfied with unsupported claims; then, there is a high > chance the discussion will be restarted again in a different form > (hey, this is not the first time you, Paul and me are involv

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Mike Stump wrote: > On Dec 31, 2005, at 10:51 AM, Paul Schlie wrote: >> As although C/C++ define some expressions as having undefined >> semantics; > > I'd rather it be called --do-what-i-mean. :-) > > Could you give us a hint at what all the semant

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Robert Dewar <[EMAIL PROTECTED]> > > Paul Schlie wrote: > >> As although C/C++ define some expressions as having undefined semantics; >> it would seem desirable to be able to conveniently force GCC to presume >> a target's true native semantics i

Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

As although C/C++ define some expressions as having undefined semantics; it would seem desirable to be able to conveniently force GCC to presume a target's true native semantics in lieu of presuming their being undefined. Thereby more conveniently and optimally enabling use of GCC as a high-level,

Re: [C, C++] fundamental type object representation

Gabriel Dos Reis wrote > Paul Schlie writes: > [...] > | > OK, thanks. I was rewriting part of valarray and I saw I made that > | > assumption, and since it is bug chasing time I thought I should make > | > sure my use of memset() isn't going to bomb out. > |

Re: [C, C++] fundamental type object representation

> Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | Ian Lance Taylor writes: > | > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > | > Does GCC support any target where the object representation of a > | > fundamental type T (e.g. int, float, double, pointers) whose all bits > | > are zero does no

Re: insv vs one-bit fields

> From: DJ Delorie <[EMAIL PROTECTED]> >> - so then any valid width bit-field should be considered a >> correspondingly valid const and/or volatile bit-field, which may >> potentially be more efficiently accessed as a function of a target's >> specific ISA? > > The "insv" pattern *already* does th

Re: insv vs one-bit fields

> From: DJ Delorie <[EMAIL PROTECTED]> >> As it would seem that as HW control/I/O registers are often >> typically mapped into a processor's data memory address space, >> they may be correspondingly addressable via a read/mask/write as >> any N bit field may be? > > In the case of the m32c

Re: insv vs one-bit fields

Richard Henderson writes: > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: > http://gcc.gnu.org/ml/gcc/2005-09/msg00064.html > > So... why is it illegal to put a constant into a single bit field? > > Probably because it was more efficient to use some other pattern > for some other tar

Re: Pointers in comparison expressions

> Geoffrey Keating wrote: >> Mirco Lorenzon wrote: >> >> .., are comparisons in the following program legal code? > > No. > >> ... >> void *a, *b; >> ... >> if (a < b) > > Because 'a' and 'b' are not part of the same array, > the behaviour is undefined. Although I don't mean to contest the conclu

Re: volatile semantics

(sorry, with intended statement this time) > From: Geoff Keating <[EMAIL PROTECTED]> > On 22/07/2005, at 7:15 PM, Paul Schlie wrote: > >>> Geoffrey Keating writes: > >>> without 'volatile', then this object cannot be modified unknown to >&

Re: volatile semantics

> From: Geoff Keating <[EMAIL PROTECTED]> > On 22/07/2005, at 7:15 PM, Paul Schlie wrote: > >>> Geoffrey Keating writes: > >>> without 'volatile', then this object cannot be modified unknown to >>> the implementation, even if someone also

Re: volatile semantics

> Geoffrey Keating writes: > > int i; - merely means: allocate and treat all references to the object as referencing an unqualified int object, unless re-qualified within a more local scope. > without 'volatile', then this object cannot be modified unknown to the > implementation, even if som

Re: volatile semantics

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> > Paul Schlie <[EMAIL PROTECTED]> writes: > > | > Gabriel Dos Reis writes: > | > If by analysis, you can determine ... > | > | The problem with this type of logic is that it leads to arbitrary > | inconsistent

Re: volatile semantics

> Gabriel Dos Reis writes: > If by analysis, you can determine ... The problem with this type of logic is that it leads to arbitrary inconsistent designation of an object's reference as a function of the breadth of the "analysis", therefore seems clearly undesirable. Resulting in only two possibi

Re: volatile semantics

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> > | - Just as if given: > | > | void foo(void) { > |int *x = 4; > | *x = 3; The point I was attempting to make, was that just because a specified statement's effective behavior/side-effects are not well defined, it doesn't mean tha

Re: volatile semantics

> From: Jonathan Wakely <[EMAIL PROTECTED]> > On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote: > >>> Note that I'm explicitly not taking a position on what the standard says. >>> The standard is notoriously incomplete with respect to object model

Re: volatile semantics

> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Gabriel Dos Reis <[EMAIL PROTECTED]> >> I don't understand what you mean here. Are you seriously suggesting >> that >> >> int main(void) { >> const int x = 4; >>

Re: volatile semantics

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> > | Paul Schlie <[EMAIL PROTECTED]> writes: > | > Note that I'm explicitly not taking a position on what the standard says. > | > The standard is notoriously incomplete with respect to object model > | > issu

Re: volatile semantics

> Note that I'm explicitly not taking a position on what the standard says. > The standard is notoriously incomplete with respect to object model issues, > including volatility, so I think that trying particularly hard to parse its > words in this area is probably not a good use of time for people

Re: volatile semantics

> I did see Ian's summary, > > http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html > > wherein he ascribed the semantics of the volatile qualifier to the > access, and not to the object. I agree with his description completely, > as I believe it embodies the intuition that C programmers have used > w

Re: Where does the C standard describe overflow of signed integers?

> From: Georg Bauhaus <[EMAIL PROTECTED]> > 2) if putting local variables in registers becomes impossible > there will be a significant cost. I wanted to get an impression > of the cost. That's the reason for writing volatile in the > declaration lines. Just for demo.) I believe that was jus

Re: Where does the C standard describe overflow of signed integers?

> From: Georg Bauhaus <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> From: Robert Dewar <[EMAIL PROTECTED]> >>>> Paul Schlie wrote: >>>> I don't contest that it may, I simply don't believe it should. >>> you can't seriou

Re: Where does the C standard describe overflow of signed integers?

> From: Paul Koning <[EMAIL PROTECTED]> >>>>>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: >>> From: Robert Dewar <[EMAIL PROTECTED]> >>>> Paul Schlie wrote: >>>>> What about optimising x*2/2 to x? >>&

Re: Where does the C standard describe overflow of signed integers?

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: > >> I don't contest that it may, I simply don't believe it should. > > you can't seriously mean that with respect to uninitialized > variables. this would mean you could not put lo

Re: Where does the C standard describe overflow of signed integers?

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> What about optimising x*2/2 to x? >> >> Given that "C" requires the above be evaluated as (x*2)/2, as the language >> specifies that the syntax defines the precedence of the oper

Re: Where does the C standard describe overflow of signed integers?

> Matthew Woodcraft writes: >> Paul Schlie wrote: >>As optimization seems to be a non-argument, as by analogy all >>optimizations which are available for unsigned arithmetic are >>correspondingly available for signed integer operations; as any signed >>valu

Re: Where does the C standard describe overflow of signed integers?

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> Although I don't intend to extend the debate; doesn't anyone find it curious >> that given this hard requirement, combined with the fact that all current >> machine architectures rely on 2

RE: Where does the C standard describe overflow of signed integers?

> " ... A computation involving unsigned operands can never overflow, because > a result that cannot be represented by the resulting unsigned integer type > is reduced modulo the number that is one greater than the largest value that > can be represented by the resulting type." Although I don't i

Re: named address spaces (update)

James E Wilson writes: >> On Sun, 2005-07-03 at 07:31, Martin Koegler wrote: >> * need to rewrite recursivly each element of type (which my contain >> structures, unions, ...) if a address space is set >> In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as >> bad idea. > > It is

Re: potential simple loop optimization assistance strategy?

> From: Giovanni Bajo <[EMAIL PROTECTED]> >> Diego Novillo <[EMAIL PROTECTED]> wrote: >>> There has been some opposition in the past about allowing conditions in >>> asserts to be used as hints to the optimizers. In fact, I would like to >>> know if there is a current statement of purpose about thi

Re: potential simple loop optimization assistance strategy?

> From: Gabriel Dos Reis <[EMAIL PROTECTED]> > | Paul Schlie <[EMAIL PROTECTED]> writes: > | As in general it seems that as the compiler knows what it needs to know to > | enable ideal loop optimization, why not simply have it assert: if it knew x, > | then it could d

potential simple loop optimization assistance strategy?

As in general it seems that as the compiler knows what it needs to know to enable ideal loop optimization, why not simply have it assert: if it knew x, then it could do y? For example, if given something like: for (i = x; i < y; i++){ ... } Where it may not be known statically if x < y, or wha

Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?

> Joe Buck <[EMAIL PROTECTED]> > Undefined behavior doesn't mean that we should attempt to arbitrarily > punish those who cross the line; that's why I don't think forcing integer > overflows to trap (at least by default) is a good idea. In many cases, > "assume no overflow, but don't trap" can pro

Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?

> Joe Buck <[EMAIL PROTECTED]> > Undefined behavior doesn't mean that we should attempt to arbitrarily > punish those who cross the line; that's why I don't think forcing integer > overflows to trap (at least by default) is a good idea. In many cases, > "assume no overflow, but don't trap" can pro

Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?

(sorry, meant additive/multiplicative inverse +/- MAX/MIN_ value; but even that's wrong, which is why it seems that leaving signed overflow as being undefined is such a bad idea, as it becomes correspondingly very difficult to even try determine if a program is warranted to have a deterministic

Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?

Given that the formal implication of GCC's choice not define signed integer overflow semantics as being other than undefined will be to guaranteed that all programs, with reachable signed integer arithmetic operations which can not warrant that their respective operand expressions are recursively c

Re: Do CO++ signed types have modulo semantics?

> From: Daniel Berlin <[EMAIL PROTECTED]> >> Overall, I guess I still simply believe the the first rule of optimization >> is to preserve existing semantics unless explicitly authorized otherwise, >> and then only if accompanied with corresponding warnings for all potentially >> behavior altering a

Re: Do CO++ signed types have modulo semantics?

tive, and I'm >>> saddened to learn that doing that would result in inferior code.) >> >> However, it's not clear that an "optimization" which alters side effects >> which have subsequent dependants is ever desirable (unless of course the >>

Re: Do CO++ signed types have modulo semantics?

> Mark Mitchell wrote: >> Joe Buck wrote: >> ... >> I don't think we should give the user any such promise, and if we do >> give such a promise, we will never catch icc. The main problem is that >> we will no longer be able to optimize many loops. > > It's entirely possible that I was naive in ass

Re: signed is undefined and has been since 1992 (in GCC)

Gabriel Dos Reis writes: > Steven Bosscher <[EMAIL PROTECTED]> writes: >| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote: >| > For the concrete case at issue, if the hardware I'm writing the C/C++ >| > programs for consistently displays modulo arithmetics for signed >| > integer type, Andrew

Re: basic VRP min/max range overflow question

> From: Michael Veksler <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16: >>> From: Michael Veksler <[EMAIL PROTECTED]>> >>> As for overflow, you can say that you want instead of "undefined" >

Re: basic VRP min/max range overflow question

> From: Michael Veksler <[EMAIL PROTECTED]>> >> Paul Schlie wrote on 20/06/2005 14:13:33: >>> From: Robert Dewar <[EMAIL PROTECTED]> > ... >>> Note that in the cases where something is statically optimized away >>> (these are the easy cas

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: > >> - You may be correct, although it's not obviously the case? (As requiring >> all undefined behavior be encapsulated between sequence points already >> seems implied to me, as

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> > Paul Schlie wrote: > >> I too believe I understand your position, however don't believe it's the >> compiler's job to make life for the programmer harder than it need be when >> a program may contain

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> > Paul Schlie wrote: > >> As in my mind, the semantics of foo() dictate that it print the value of >> the storage location which was allocated to the variable "a", where unless >> "a" is initialized wit

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> > Robert Dewar wrote: > >> That may be your position, but it is not the position of the standard, and >> indeed it is not a well-formed position. Why, because the whole point is >> that >> when the behavior is undefined, then the change DOES yield a logical

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> > Paul Schlie wrote: > >> My position is simply that an optimization should never remove a specified >> operation unless it is known to yield logically equivalent behavior, as >> producing a program which does not behav

Re: basic VRP min/max range overflow question

> From: Michael Veksler <[EMAIL PROTECTED]> > Paul Schlie wrote on 20/06/2005 08:55:20: >> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2] > Invalid syntax, what did you mean? Sorry, meant: y = z + x; // y == [INT_MIN, INT_MAX] + [1, 2] == [INT_MIN+1, INT_MAX+2] >&g

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> The root of the concern being expressed is with respect to the compilers use >> of statically identified undefined behaviors as opportunities to invoke >> alternative semantics which are easily iden

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> From: "Joseph S. Myers" <[EMAIL PROTECTED]> >>> "no requirements" means that *any* translation conforms in the case of >>> undefined behavior. Only those e

Re: basic VRP min/max range overflow question

> From: "Joseph S. Myers" <[EMAIL PROTECTED]> > "no requirements" means that *any* translation conforms in the case of > undefined behavior. Only those executions not involving undefined > behavior have any requirements. What delineates the bounds between undefined and non-undefined behaviors? (

Re: basic VRP min/max range overflow question

avior, although it's obviously ill defined? although can find reference that a dereference of an overflowed pointer is undefined? ] > From: "Joseph S. Myers" <[EMAIL PROTECTED]> > On Sat, 18 Jun 2005, Paul Schlie wrote: > >>[#1] Behavior, upo

Re: basic VRP min/max range overflow question

prove the whole program is itself would have an undefined behavior (reinforcing the notion that the language's semantics remain in force even in the presence of a expression with undefined semantics). > From: Paul Schlie <[EMAIL PROTECTED]> >> From: "Joseph S. Myers"

  1   2   3   >