Re: RFC: New pexecute interface

Ian Lance Taylor writes: > If you do use PEX_SAVE_TEMPS, then the caller provides the base name > and the suffix, and the caller is responsible for making good > choices. It doesn't look like the caller can specify a different base name for each stage in the pipeline, is the thing. zw

Re: RFC: New pexecute interface

Zack Weinberg <[EMAIL PROTECTED]> writes: > The interface looks sound to me with one exception: it's not safe to > conflate !-pipe with -save-temps, because that opens up the > possibility of a tempfile race -- if an attacker sees that the > compiler is producing /tmp/ccQWERTY.s, then they should

Re: Deprecating min/max extension in C++

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: | Mark Mitchell <[EMAIL PROTECTED]> wrote: | | > IMO, if these are C++-only, it's relatively easy to deprecate these | > extension -- but I'd like to hear from Jason and Nathan, and also the | > user community before we do that. Of all the extensions w

Re: RFC: New pexecute interface

The interface looks sound to me with one exception: it's not safe to conflate !-pipe with -save-temps, because that opens up the possibility of a tempfile race -- if an attacker sees that the compiler is producing /tmp/ccQWERTY.s, then they should not be able to predict that the assembler will pro

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

Ian Lance Taylor writes: > I think this change is a great idea. I want to point out something > you probably already noticed: some definitions of > LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in > reload.c in the only caller, find_reloads_address. For example, the > definition i

Re: Pascal front-end integration

Joseph S. Myers wrote: > > So IMHO the best thing for a smooth transition would be to add 4.x > > support as far as we can, with conditionals, so everyone can test it > > and we can drop earlier backend as soon as (safely) possible. > > If you can make such conditionals work, then fine. I'm just

Re: GCC 3.4.3 static constants, named sections, and -fkeep-static-consts

Gary Funck wrote: When compiled with GCC 3.4.3, at -O2, the ident string above will _not_ appear in the executable. This is apparently expected behavior. See the docs for __attribute__ ((used)). Contrary to the docs, it works for more than functions. However, interestingly, gcc -fkeep-static-

Re: Bug 20375 - ia64 varadic regression

Zack Weinberg wrote: So, in other words, if (current_function_stdarg) data->last_named = true; Actually, no: data->last_named = !TREE_CHAIN (parm); (This is the last "named" parameter iff it's the last parameter.) But, right idea. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (91

Re: Bug 20375 - ia64 varadic regression

Mark Mitchell <[EMAIL PROTECTED]> writes: > Zack Weinberg wrote: > >> It would certainly be nice to get rid of this mess, but Jim Wilson >> expressed concerns last time it came up: >> > > Well, sidestepping that, what the compiler really se

Re: Bug 20375 - ia64 varadic regression

Zack Weinberg wrote: It would certainly be nice to get rid of this mess, but Jim Wilson expressed concerns last time it came up: Well, sidestepping that, what the compiler really seems to want is "the last argument that was declared by the

Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary

On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > For example, I believe that Alex's proposed solution to PR c++/19199 > isn't an appropriate fix. It's perfectly reasonable for fold to convert > a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++ > front-end all three of

Re: IA64 record alignment rules, and modes?

Gary Funck wrote: Question: If we assume that a TImode would've been a more efficient mode to represent the record type above, would it not have been acceptable for the compiler to promote the alignment of this type to 128, given there are no apparent restrictions otherwise, or are there other C co

Re: Building GCC on Native Platform

On Fri, 2005-03-04 at 21:32, Vivek Takalkar wrote: > Could some one help me in building GCC as NATIVE GCC on platform other > than INTEL PC, say ARM, SPARC, etc. The procedure for building a native gcc is generally the same regardless of target. If you know how to build it on one machine, then yo

Re: Solaris gcc 4.0.0 static linking of libgcc.a

> ok, it seems that it was my error, I recompile gcc-4.0-10012005 to verify > the behaviour, but libgcc_s.so needs to be linked in any case. gcc-3.4 > works because I changed the specs file, but then I thougth it was due to > the compiler flags, which wasn't the case. OK, thanks for the clarificat

Shall we take a short break from my fold changes?

Hi, Roger Sayle and I are wondering if we should take a short break (maybe a few days!?) from my fold changes. The reason is that I've already broken fold once. (Thanks goes to David Edelsohn for fixing the problem!) If we wait for a few days, it's likely that people bootstrap and test GCC on t

RE: Bug 20375 - ia64 varadic regression

Original Message >From: Zack Weinberg >Sent: 08 March 2005 18:25 > Nathan Sidwell <[EMAIL PROTECTED]> writes: > >> Dave Korn wrote: >> >>> There was under varargs, which didn't require to pass a named >>> argument to va_start; it's only with stdargs that it would be >>> impossible. I su

RE: Bug 20375 - ia64 varadic regression

Original Message >From: Richard Henderson >Sent: 08 March 2005 18:24 > On Tue, Mar 08, 2005 at 10:15:09AM -0700, Jeffrey A Law wrote: >> FWIW, there is actually a system which varies its ABI based on whether >> or not an argument is named -- my old favorite, the 32bit PA SOM ABI >> behaves

Re: [OT] __builtin_cpow((0,0),(0,0))

> Ronny Peine > > Maybe i found something: > > http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps > page 9 says: > > "A number of real expressions are sometimes implemented as INVALID > by mistake, or declared Undefined by illconsidered > language standards; a few examples are ... > 0.0**

Re: Bug 20375 - ia64 varadic regression

Nathan Sidwell <[EMAIL PROTECTED]> writes: > Dave Korn wrote: > >> There was under varargs, which didn't require to pass a named >> argument to va_start; it's only with stdargs that it would be >> impossible. I suspect that this is the underlying reason for the >> code having developed this way:

Re: Bug 20375 - ia64 varadic regression

On Tue, Mar 08, 2005 at 10:15:09AM -0700, Jeffrey A Law wrote: > FWIW, there is actually a system which varies its ABI based on whether > or not an argument is named -- my old favorite, the 32bit PA SOM ABI > behaves in this manner. In fact, I believe it is the only port which > gives a hoot about

Re: request for timings - makedepend

> "Zack" == Zack Weinberg <[EMAIL PROTECTED]> writes: >> Computed headers are dealt with somewhat clumsily in automake. As a >> user you specify "BUILT_SOURCES", and then these are built by 'all' >> before anything else is done. Zack> This might not be all that bad in gcc land. It's good to

Re: Bug 20375 - ia64 varadic regression

Dave Korn wrote: There was under varargs, which didn't require to pass a named argument to va_start; it's only with stdargs that it would be impossible. I suspect that this is the underlying reason for the code having developed this way: sometimes the first variadic arg is the last named arg (

Re: request for timings - makedepend

On Tue, 2005-03-08 at 17:25 +, Paul Brook wrote: > > (a) the numbers reported by the "time" command, > > real3m52.604s > user3m15.490s > sys 0m29.550s > > > (b) what sort of machine this is and how old > > hp-pa 712/80. At least 7 years only, probably more. This machine takes man

RE: Bug 20375 - ia64 varadic regression

Original Message >From: Andrew Pinski >Sent: 08 March 2005 16:13 > On Mar 8, 2005, at 10:59 AM, Nathan Sidwell wrote: > >> Bug 20375 is logged as a C++ bug, but it is a middle end >> bug that cannot be expressed in C. Here's a reduced testcase >> >> union U >> { >> void *m[7]; >> }; >

Re: request for timings - makedepend

> (a) the numbers reported by the "time" command, real3m52.604s user3m15.490s sys 0m29.550s > (b) what sort of machine this is and how old hp-pa 712/80. At least 7 years only, probably more. This machine takes many hours to bootstrap gcc. > (c) whether or not you would be willing t

Re: Bug 20375 - ia64 varadic regression

On Tue, 2005-03-08 at 09:06 -0800, Mark Mitchell wrote: > Nathan Sidwell wrote: > > > Notice that the last specified argument 'union U' has no name. when > > compiled for ia64-hp-hpux11.23 with -mlp64 this ICEs because of this > > bit of code in assign_parm_find_data_types > > > > /* Set LAST_

Re: Bug 20375 - ia64 varadic regression

Nathan Sidwell wrote: Notice that the last specified argument 'union U' has no name. when compiled for ia64-hp-hpux11.23 with -mlp64 this ICEs because of this bit of code in assign_parm_find_data_types /* Set LAST_NAMED if this is last named arg before last anonymous args. */ if (current_fun

Re: problem with the scheduler in gcc-4.0-20040911

Hello, Thanks alot Vladimir and Daniel. Regards, Kunal On Tue, 8 Mar 2005 11:12:46 -0500, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Tue, Mar 08, 2005 at 09:38:19PM +0530, Kunal Parmar wrote: > > Hello, > > I have attached the dump after the scheduler. The branch instruction > > is a condi

Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary

On Mar 8, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: >> As has been described earlier on this thread, GCC has folded the C++ >> source "(a >= b ? a : b) = c" into "MAX_EXPR (a,b) = c" and equivalently >> "(a > b ? a : b) = c" into "MAX_EXPR (b,a) = c" since the creation of >> current CVS.

Re: Bug 20375 - ia64 varadic regression

Andrew Pinski <[EMAIL PROTECTED]> writes: > On Mar 8, 2005, at 10:59 AM, Nathan Sidwell wrote: > >> Bug 20375 is logged as a C++ bug, but it is a middle end >> bug that cannot be expressed in C. Here's a reduced testcase >> >> union U >> { >> void *m[7]; >> }; >> >> struct C; >> >> void f(struc

Re: Bug 20375 - ia64 varadic regression

On Mar 8, 2005, at 10:59 AM, Nathan Sidwell wrote: Bug 20375 is logged as a C++ bug, but it is a middle end bug that cannot be expressed in C. Here's a reduced testcase union U { void *m[7]; }; struct C; void f(struct C *c, float f, union U, ...) { } I almost want to say this is undefined as the

Re: problem with the scheduler in gcc-4.0-20040911

On Tue, Mar 08, 2005 at 09:38:19PM +0530, Kunal Parmar wrote: > Hello, > I have attached the dump after the scheduler. The branch instruction > is a conditionally executed branch instruction. So it is represented > as RTL COND_EXEC. Vladimir was right. It's an INSN, when it should be a JUMP_INSN.

Re: problem with the scheduler in gcc-4.0-20040911

Hello, I have attached the dump after the scheduler. The branch instruction is a conditionally executed branch instruction. So it is represented as RTL COND_EXEC. Regards, Kunal On Tue, 08 Mar 2005 10:14:05 -0500, Vladimir Makarov <[EMAIL PROTECTED]> wrote: > Kunal Parmar wrote: > > >Following

Bug 20375 - ia64 varadic regression

Bug 20375 is logged as a C++ bug, but it is a middle end bug that cannot be expressed in C. Here's a reduced testcase union U { void *m[7]; }; struct C; void f(struct C *c, float f, union U, ...) { } Notice that the last specified argument 'union U' has no name. when compiled for ia64-hp-hpux11

Re: problem with dependencies in gcc-4.0-20040911

Kunal Parmar wrote: Hello, I am working with a VLIW processor and GCC-4.0-20040911. There is a problem in the dependency calculation of GCC. GCC is giving write-after-read a higher priority than write-after-write. Thus, as in the following code, GCC gives a write-after-read dependency between the 2

Re: Solaris gcc 4.0.0 static linking of libgcc.a

> > I must admit that my first description of the problem was a bit > outdated, > > but I will give you some more information: I first tried the > > gcc-4.0-10012005 snapshot, together with the -fno-exceptions flag, and > > there was no dynamic linking of libgcc_s.so necessary. gcc-3.4.3 works > in

Re: matching constraints in asm operands question

Hi, On Sat, 5 Mar 2005 [EMAIL PROTECTED] wrote: > > Well, I assumed the same thing when I started poking at that code, but > > then someone pointed out that it didn't actually work that way, and as > > I recall the code does in fact assume a register. I certainly would > > not object to making '

Re: problem with the scheduler in gcc-4.0-20040911

Kunal Parmar wrote: Following is the debugging dump by the scheduler - ** ;; == ;; -- basic block 1 from 17 to 89 -- after reload ;; == ;;

problem with dependencies in gcc-4.0-20040911

Hello, I am working with a VLIW processor and GCC-4.0-20040911. There is a problem in the dependency calculation of GCC. GCC is giving write-after-read a higher priority than write-after-write. Thus, as in the following code, GCC gives a write-after-read dependency between the 2 instructions. Due t

Re: Deprecating min/max extension in C++

On Mar 8, 2005, at 8:04 AM, Giovanni Bajo wrote: Andrew Pinski <[EMAIL PROTECTED]> wrote: Well, that sounds largely impossible. Can you point exactly which bug are you talking of? I know for a fact that the extension itself has always worked for basic rvalue usage, with basic types. Instead, I wou

problem with the scheduler in gcc-4.0-20040911

Hello, I am working with c6x processor from TI. It has a VLIW architecture. It has 32 registers namedly a0-a15 and b0-b15. b15 is used as the SP in the current port. I am facing a problem with the scheduler of GCC. Following is the c code I was compiling - *** int mult

problem with the scheduler

Hello, I am working with c6x processor from TI. It has a VLIW architecture. It has 32 registers namedly a0-a15 and b0-b15. b15 is used as the SP in the current port. I am facing a problem with the scheduler of GCC. Following is the c code I was compiling - *** int mul

Re: [OT] __builtin_cpow((0,0),(0,0))

Duncan Sands wrote: Hi Robert, Well if you tell me there are people about there implementing cpow with log and exp, that's enough for me to decide that Ada should continue to stay away (the Ada RM has accuracy requirements that would preclude a broken implementation of this kind) :-) the referenc

Re: Deprecating min/max extension in C++

On Tue, Mar 08, 2005 at 02:06:48PM +0100, Giovanni Bajo wrote: > Mark Mitchell <[EMAIL PROTECTED]> wrote: > > > IMO, if these are C++-only, it's relatively easy to deprecate these > > extension -- but I'd like to hear from Jason and Nathan, and also the > > user community before we do that. Of a

Re: [OT] __builtin_cpow((0,0),(0,0))

Hi Robert, > Well if you tell me there are people about there implementing cpow > with log and exp, that's enough for me to decide that Ada should > continue to stay away (the Ada RM has accuracy requirements that > would preclude a broken implementation of this kind) :-) the reference manual all

Re: __builtin_cpow((0,0),(0,0))

This proof is absolutely correct and in no way bogus, it is lectured to nearly every mathematics student PERIOD But you are right, if the standards handles this otherwise, then this doesn't help in any case. Robert Dewar wrote: Ronny Peine wrote: I hope that this make things clearer for some who

Re: __builtin_cpow((0,0),(0,0))

Ronny Peine wrote: I hope that this make things clearer for some who don't believe 0^0 = 1 in the real case. Believe??? so now its a matter of religeon. Anyway, your bogus proof is irrelevant for the real case, since the language standard is clear in the real case anyway. It really is completely p

Deprecating min/max extension in C++

Mark Mitchell <[EMAIL PROTECTED]> wrote: > IMO, if these are C++-only, it's relatively easy to deprecate these > extension -- but I'd like to hear from Jason and Nathan, and also the > user community before we do that. Of all the extensions we've had, this > one really hasn't been that problemati

Deprecating min/max extension in C++

Andrew Pinski <[EMAIL PROTECTED]> wrote: >> Well, that sounds largely impossible. Can you point exactly which bug >> are >> you talking of? I know for a fact that the extension itself has always >> worked for basic rvalue usage, with basic types. Instead, I would not >> be >> surprised if some mor

Question about "#pragma pack(n)" and "-fpack-struct"

Hello! Consider the following simple code. #pragma pack(2) struct TEST{ charx1; int x2; }; #pragma pack() main() { struct TEST t; printf("%d\n", sizeof(t)); } When I compile with "gcc" ,the output is 6.But the output is 5 when using "-fpack-struct"

Re: [OT] __builtin_cpow((0,0),(0,0))

Paolo Carlini wrote: Duncan Sands wrote: aren't __builtin_cpow and friends language independent? I mean, if a front-end sees a x^y then presumably it ends up being turned into a call to a __builtin_?pow by the back-end. If so, then conforming to the C99 and C++ standards isn't enough: the standar

Re: __builtin_cpow((0,0),(0,0))

Maybe i should make it more clearer, why 0^x is not defined for real exponents x, and not continual in any way. Be G a set ("Menge" in german) and op : G x G -> G, (a,b) -> a op b. If op is associative than (G,op) is called a half-group. Therefore then exponentiation is defined as: a from G, n fr

Re: [OT] __builtin_cpow((0,0),(0,0))

Duncan Sands wrote: aren't __builtin_cpow and friends language independent? I mean, if a front-end sees a x^y then presumably it ends up being turned into a call to a __builtin_?pow by the back-end. If so, then conforming to the C99 and C++ standards isn't enough: the standards for all gcc suppor

Re: [OT] __builtin_cpow((0,0),(0,0))

Hi Paolo, > > What we are debating here isn't really maths at all, just the > > definition which will be most useful and least suprising (and perhaps > > also what various standards tell us to use). > > Also, since we are definitely striving to consistently implement the > current C99 and C++

Re: [OT] __builtin_cpow((0,0),(0,0))

Well, you are right, this discussion becomes a bit off topic. I think 0^0 should be 1 in the complex case, too. Otherwise the complex and real definitions would collide. Example: use complex number 0+i*0 then this should be handled equivalent to the real number 0. Otherwise the programmer would get

Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary

On Mon, Mar 07, 2005 at 08:29:48PM -0700, Roger Sayle wrote: > Which docs?! There's currently *no* documentation for MIN_EXPR > or MAX_EXPR in c-tree.texi. Ah, I misremembered the docs for the rtl patterns. Signed minimum and maximum operations. When used with floating point, if both operan

Re: [OT] __builtin_cpow((0,0),(0,0))

Chris Jefferson wrote: What we are debating here isn't really maths at all, just the definition which will be most useful and least suprising (and perhaps also what various standards tell us to use). Also, since we are definitely striving to consistently implement the current C99 and C++ Standar

Re:[OT] __builtin_cpow((0,0),(0,0))

Ronny Peine wrote: Well, i'm studying mathematics and as i know so far 0^0 is always 1 (for real and complex numbers) and well defined even in numerical and theoretical mathematics. Could you point me to some publications which say other things? cu, Ronny Just wanting to put in my mathematical

Re:[OT] __builtin_cpow((0,0),(0,0))

Ronny Peine wrote: Well, i'm studying mathematics and as i know so far 0^0 is always 1 (for real and complex numbers) and well defined even in numerical and theoretical mathematics. Could you point me to some publications which say other things? cu, Ronny Just wanting to put in my mathematical

are link errors caused by mixing of versions?

I tried the actual snapshot of gcc 4.1.0 on ACE 5.4.2 and got an ICEs. To complete the compilation I used gcc from last week to compile the erroneous files. Later on I got link errors like: /usr/bin/ld: Warning: size of symbol `ACE_At_Thread_Exit::~ACE_At_Thread_Exit()' changed from 46 in .shobj/

Re: Pascal front-end integration

> I also don't recommend trying to keep compatibility before 4.0; working > with 4.0 would suffice to keep the new GPC developments usable with a GCC > release and the differences between 4.0 and earlier compilers are > sufficiently large that the saving from not trying to be compatible with > e

Re: __builtin_cpow((0,0),(0,0))

Ronny Peine wrote: Well this article was referenced by http://grouper.ieee.org/groups/754/, so i don't think it's an unreliable source. Since Kahan is one of the primary movers behind 754 that's not so surprising. For me, 754 is authoritative significantly because of this connection. If there wer

Re: __builtin_cpow((0,0),(0,0))

Well this article was referenced by http://grouper.ieee.org/groups/754/, so i don't think it's an unreliable source. It would be nice if you wouldn't try to insult me Joe Buck, that's not very productive. Robert Dewar wrote: Marcin Dalecki wrote: Are we a bit too obedient today? Look I was talk

Re: __builtin_cpow((0,0),(0,0))

Hi Florian, > From a mathematical point of view, 0^0 = 1 is the more convenient one > in most contexts. Otherwise, you suddenly lack a compact notation of > polynomials (and power series). However, this definition is only used > in a context were the exponent is an integer, so it's not really >

Re: __builtin_cpow((0,0),(0,0))

Florian Weimer wrote: * Robert Dewar: Marcin Dalecki wrote: There is no reason here and you presented no reasoning. But still there is a *convenient* extension of the definition domain for the power of function for the zero exponent. The trouble is that there are *two* possible convenient extensi

Re: __builtin_cpow((0,0),(0,0))

* Robert Dewar: > Marcin Dalecki wrote: > >> There is no reason here and you presented no reasoning. But still >> there is a >> *convenient* extension of the definition domain for the power of >> function for the >> zero exponent. > > The trouble is that there are *two* possible convenient extensi

Re: Solaris gcc 4.0.0 static linking of libgcc.a

> I must admit that my first description of the problem was a bit outdated, > but I will give you some more information: I first tried the > gcc-4.0-10012005 snapshot, together with the -fno-exceptions flag, and > there was no dynamic linking of libgcc_s.so necessary. gcc-3.4.3 works in > the same

Re: __builtin_cpow((0,0),(0,0))

Marcin Dalecki wrote: Are we a bit too obedient today? Look I was talking about the paper presented above not about the author there of. But a paper like this must be read in context, and if you don't know who the author is, you a) don't have the context to read the paper b) you show yourself to b

Re: __builtin_cpow((0,0),(0,0))

Hi Robert, > > It's not true because it's neither true nor false. It's a not well > > formulated statement. (Mathematically). > > I disagree with this, we certainly agree that 0.0 ** negative value > is undefined, i.e. that this is outside the domain of the ** function, > and I think normally in

Re: Solaris gcc 4.0.0 static linking of libgcc.a

thanks for your fast answer, I must admit that my first description of the problem was a bit outdated, but I will give you some more information: I first tried the gcc-4.0-10012005 snapshot, together with the -fno-exceptions flag, and there was no dynamic linking of libgcc_s.so necessary. gcc-3.4