Error due to function call while checking fn attributes

Hi all, I am working with gcc 4.1.1. I have a target dependent function attribute to check the function mode. Before emitting the call instruction, i just want to check the function attribute and depending on that i need to emit the call instruction. After making the modifications, while buildi

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 conditionally shifting left ((char)x) by ((int)c) if c >> is le

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?

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?

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?

On 20 December 2006 02:40, Mike Stump wrote: > On Dec 19, 2006, at 6:33 PM, Dave Korn wrote: >> On 20 December 2006 02:28, Andrew Pinski wrote: >> Paul Brook wrote: >> Compiler can optimize it any way it wants, >> as long as result is the same as unoptimized one. > > We have

Re: GCC optimizes integer overflow: bug or feature?

> > 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. > > Why isn't that just a buggy program with wilful disregard for t

Re: GCC optimizes integer overflow: bug or feature?

On Dec 19, 2006, at 6:33 PM, Dave Korn wrote: On 20 December 2006 02:28, Andrew Pinski wrote: 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

RE: GCC optimizes integer overflow: bug or feature?

On 20 December 2006 02:28, Andrew Pinski wrote: >> 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 p

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 stat

Re: alignment attribute for stack allocated objects

On Dec 19, 2006, at 5:31 PM, Maurizio Vitale wrote: I'm tying to hunt down the cause of a bug I'm experiencing and it all boils down to a possible misunderstanding on my part on the semantics of the 'aligned' attribute. Is the 'aligned' attribute supposed to work for objects allocated on

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?

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?

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

alignment attribute for stack allocated objects

I'm tying to hunt down the cause of a bug I'm experiencing and it all boils down to a possible misunderstanding on my part on the semantics of the 'aligned' attribute. Is the 'aligned' attribute supposed to work for objects allocated on the stack (I'm on x86_64, gcc 4.1.1)? The only caveat

RE: [RFC] ordered comparison of pointer with integer zero warning in Wextra

On 20 December 2006 00:39, Manuel López-Ibáñez wrote: > On 20/12/06, Dave Korn <[EMAIL PROTECTED]> wrote: >> Heh. Or you could always make it a divide-by-zero error instead :) > > Oh, sorry. I didn't get this. If you would be so kind to elaborate... Possibly the world's only attempt ever a

Re: [RFC] ordered comparison of pointer with integer zero warning in Wextra

On 20/12/06, Dave Korn <[EMAIL PROTECTED]> wrote: On 17 December 2006 12:56, Manuel López-Ibáñez wrote: > For me, the > best would be to NOT enable the warning for Wextra, so I don't need to > come up with a name for this warning flag. Otherwise, we would have to > document that the warning is en

RE: [RFC] ordered comparison of pointer with integer zero warning in Wextra

On 17 December 2006 12:56, Manuel López-Ibáñez wrote: > Currently Wextra warns about a pointer compared against integer zero > with <, <=, >, or >=. This warning is not available in C++ (the > documentation does not say this) and it is implemented in > gcc/c-typeck.c (build_binary_op) in this mann

[fixincludes] PR29867 - building libgfortran fails

Hi all, I spent the last couple of hours tracking down PR29867 through fixincludes. Now, as the actual problem is identified, I lack the knowledge to fix it appropriately. Could someone more involved with fixincludes comment on this? Thanks. The problem: fixes "glibc_c99_inline_1" and "glibc_

Re: GCC optimizes integer overflow: bug or feature? (was: avoid integer overflow in mktime.m4)

On Mon, 18 Dec 2006, Andrew Pinski wrote: > On Tue, [EMAIL PROTECTED]:54 +0100, Ralf Wildenhues wrote: > > > Wheeeoo! That optimization is going to break a _lot_ of GNU > > > software. (Silently. Oh my.) > > Just like say strict aliasing? :) I find an analogy with -ffast-math much less far-fetc

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 22:39, Denis Vlasenko wrote: > On Tuesday 19 December 2006 22:46, 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 optim

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 22:46, 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. Even x*2 -> x+x? O

Re: Char shifts promoted to int. Why?

> > ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) ) :: > ((char)x) = ((char)( ((char)x) << ((int)c) ) ) > > if the shift count ((int)x) is semantically preserved. > > thereby conditionally shifting left ((char)x) by ((int)c) if c is less than > the smaller of it's shifted operand's or

Re: [RFC] centralizing vector support info in the testsuite

Janis Johnson <[EMAIL PROTECTED]> wrote on 18/12/2006 20:25:47: > On Mon, Dec 18, 2006 at 01:19:03PM +0200, Dorit Nuzman wrote: > > Janis Johnson <[EMAIL PROTECTED]> wrote on 15/12/2006 03:12:44: > > > > > > I seem to recall from long ago that some processors support generating, > > > and possibly

Re: GCC optimizes integer overflow: bug or feature?

> * Andrew Pinski: > > > A simple loop like: > > int foo () > > { > > int a[N]; > > int i; > > int n; > > > > for (i = 0; i <= n; i++) > > ca[i] = 2; > > } > > > > we cannot find how many iterations it runs without knowing that signed > > types overflow. > > In this case, the assumpti

Re: GCC optimizes integer overflow: bug or feature?

On Tue, Dec 19, 2006 at 10:25:41PM +0100, Denis Vlasenko wrote: > ... It's not about standards. It's about sanity. So what happens when two different people's concept of "sanity" differs? That's why we have standards, so both can consult a reference and wind up with the same concept, even though o

Re: [bug-gnulib] GCC optimizes integer overflow: bug or feature?

Paul Eggert wrote: > Compiling everything with -fwrapv is simple. It has > optimization drawbacks, but if that's the best we can do > now, then we'll probably do it. And once we do it, human > nature suggests that we will generally not bother with the > painstaking analysis needed to omit -fwrapv

Re: GCC optimizes integer overflow: bug or feature?

> 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. The important distinction is whether that difference is observable in valid progra

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 20:05, Andrew Haley wrote: > Denis Vlasenko writes: > > > > I wrote this just a few days ago: > > > > do { > > int32_t v1 = v << 1; > > if (v < 0) v1 ^= mask; > > v = v1; > > printf("%10u:

Re: GCC optimizes integer overflow: bug or feature?

On Tue, Dec 19, 2006 at 12:05:44PM -0800, Ian Lance Taylor wrote: > Here is a quick list of optimizations that mainline gcc performs which > rely on the idea that signed overflow is undefined. All the types > are, of course, signed. I made have made some mistakes. I think this > gives a good fee

Re: GCC optimizes integer overflow: bug or feature?

Paul Eggert <[EMAIL PROTECTED]> writes: > What worries me is code like this (taken from GNU expr; the vars are > long long int): > > val = l->u.i * r->u.i; > if (! (l->u.i == 0 || r->u.i == 0 >|| ((val < 0) == ((l->u.i < 0) ^ (r->u.i < 0)) >

Re: GCC optimizes integer overflow: bug or feature?

Paul Eggert <[EMAIL PROTECTED]> writes: | "Joseph S. Myers" <[EMAIL PROTECTED]> writes: | | > Encapsulate reliable overflow checks for the various | > arithmetic operations and types in functions or macros in | > gnulib (for long long multiply, in this case). | | That might be the best approach

Re: GCC optimizes integer overflow: bug or feature?

Denis Vlasenko writes: > > I wrote this just a few days ago: > > do { > int32_t v1 = v << 1; > if (v < 0) v1 ^= mask; > v = v1; > printf("%10u: %08x\n", c++, v); > } while (v != 1); > > I would become rath

Re: GCC optimizes integer overflow: bug or feature?

On Tuesday 19 December 2006 11:37, Paolo Bonzini wrote: > > > By the way, as I've tried to describe here: > > > > variable range tracking can result in reintroduction of > > supposedly-fixed security vulnerabilities. 8-( > > Interes

Re: GCC optimizes integer overflow: bug or feature?

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > Encapsulate reliable overflow checks for the various > arithmetic operations and types in functions or macros in > gnulib (for long long multiply, in this case). That might be the best approach in the long run, but it would take a lot of painstaking

gcc-4.2-20061219 is now available

Snapshot gcc-4.2-20061219 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061219/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

[ecj] Bump ABI version

Java 5 has an extended class file format for annotations. We have to support that in gcj-compiled code too, and it requires an ABI change. Tom Tromey, I'd appreciate it if you'd have a quick check of this one. We should probably port the code that throws a ClassFormatError if we're not ABI-compa

Re: Getting declaration tree node using func. name

tree fn_decl; tree fn_id; fn_id = get_identifier("test_fn_call"); fn_decl = lookup_name(fn_id); /* returns you a pointer to the function declaration tree */ On 12/19/06, Rohit Arul Raj <[EMAIL PROTECTED]> wrote: Hi all, I am working with GCC 4.1.1. By using the function name, is it possible t

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: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

> Hi, Jan, > Thanks for fast response! > > I've tested the change you proposed and we still failed in the assert > checking that the number of SCRATCHes being too large (>30) while > copying the REG_NOTES of the instruction (see below) using just 9 > SCRATCH registers. Hi, apparently there seems

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?

On Tue, 19 Dec 2006, Robert Dewar wrote: > > GCC does not use the latitude given in C99 only to treat certain > > aspects of signed @samp{<<} as undefined, but this is subject to > > change. > > That hardly seems sufficient documentation, when documenting undefined, > you had better s

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?

On Tue, 19 Dec 2006, Paul Eggert wrote: > What worries me is code like this (taken from GNU expr; the vars are > long long int): > > val = l->u.i * r->u.i; > if (! (l->u.i == 0 || r->u.i == 0 >|| ((val < 0) == ((l->u.i < 0) ^ (r->u.i < 0)) >

Re: GCC optimizes integer overflow: bug or feature?

* Robert Dewar: > What is (a*2)/2 optimized to? certainly it has the value a if you > wrap, Huh? Isn't (INT_MAX*2)/2 negative (and thus not equal to INT_MAX) in 2-complement arithmetic?

Re: GCC optimizes integer overflow: bug or feature?

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. No, it has not. For example, if a is 0x

Re: GCC optimizes integer overflow: bug or feature?

* Joseph S. Myers: > 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 relie

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

Getting declaration tree node using func. name

Hi all, I am working with GCC 4.1.1. By using the function name, is it possible to get the declaration tree node of that function. e.g. using maybe_get_identifier("name"), i get the identifier node. similarly are there any functions or macros available to get the declaration tree node. Regards

Re: GCC optimizes integer overflow: bug or feature?

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

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Hi, Jan, Thanks for fast response! I've tested the change you proposed and we still failed in the assert checking that the number of SCRATCHes being too large (>30) while copying the REG_NOTES of the instruction (see below) using just 9 SCRATCH registers. Thanks, Vladimir On 12/18/06, Jan Hubic

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?

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

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?

* 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 somewhere? Without doc

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?

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 result does not conform with the standard, |

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 does; it merely implies that any program whi

Re: Paolo Bonzini appointed build system maintainer

Mark Mitchell wrote: Paolo -- The GCC SC has appointed you as a co-maintainer of the build machinery. Please add an appropriate MAINTAINERS entry. Congratulations, and thank you for accepting this position! Thanks very much, I committed the following. 2006-12-19 Paolo Bonzini <[EMAIL PROT

Re: GCC optimizes integer overflow: bug or feature?

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

Re: GCC optimizes integer overflow: bug or feature?

By the way, as I've tried to describe here: variable range tracking can result in reintroduction of supposedly-fixed security vulnerabilities. 8-( Interesting read. I agree with the proposed fix; however, note that GCC does not

Re: GCC optimizes integer overflow: bug or feature?

* Andrew Pinski: > A simple loop like: > int foo () > { > int a[N]; > int i; > int n; > > for (i = 0; i <= n; i++) > ca[i] = 2; > } > > we cannot find how many iterations it runs without knowing that signed > types overflow. In this case, the assumption is not needed because the lac

Re: GCC optimizes integer overflow: bug or feature?

Gabriel Dos Reis writes: > 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 result does not confo

Re: GCC optimizes integer overflow: bug or feature?

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 result does not conform with the standard, | | I don't think it does; it

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?

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 does; it merely implies that any program which requires "-fwrapv" fo

Re: GCC optimizes integer overflow: bug or feature?

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

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

On Tue, 2006-12-19 at 03:42 -0500, Robert Dewar wrote: > > When I worked on SPITBOL, people all the time were suggesting > optimizations in letters to the SPITBOL newsletter. I imposed > a rule saying that no one could propose an optimization unless > they could show ONE example program where the

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 argument, but > > it should not be couch

Re: GCC optimizes integer overflow: bug or feature?

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 argument, but > > it should not be couched as if it implies tha

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