How can I get rid of __main ?

Hi All, When I compile the following code (using the -S switch) under windows, GCC outputs an assembly file containing the symbol "__main" (two underscores) Code: int main() { return 0; } The reason I know that on some systems, gcc inserts a call to __main() at the start of the code that it gene

Re: GCC and Floating-Point

On 2005-05-26 09:14:40 -0400, Daniel Berlin wrote: > On Thu, 26 May 2005, Vincent Lefevre wrote: > >On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote: > >>Yes. I still don't understand why gcc doesn't do -ffast-math by > >>default like all other compilers. > > > >No! And I really don't thin

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > Your code just tests every 3.6°, perhaps you won't trip at the > problems... Actually, it tested every 1.8°, but who wants to be picky. I've rerun the test overnight at greater resolution, testing every 0.0018 degress, and saw no change in the result. ..Scott

Re: GCC and Floating-Point

On Fri, 2005-05-27 at 12:47 +0200, Vincent Lefevre wrote: > On 2005-05-26 09:14:40 -0400, Daniel Berlin wrote: > > On Thu, 26 May 2005, Vincent Lefevre wrote: > > >On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote: > > >>Yes. I still don't understand why gcc doesn't do -ffast-math by > > >>

Re: GCC and Floating-Point

On 2005-05-26 20:49:13 +0200, Allan Sandfeld Jensen wrote: > I can't speak of all compilers, only the ones I've tried. ICC > enables it always, Sun CC, Dec CXX, and HP CC at certain levels of > optimizations (equivalent to -O2). I've tried with "cc: Sun WorkShop 6 2000/04/07 C 5.1", and there does

Re: GCC and Floating-Point

Vincent Lefevre wrote: > So, yes, -ffast-math by default would really be a bad idea and would > make gcc much worse than other compilers. Who has advocated making -ffast-math the default? I certainly haven't. ..Scott

GCC 3.3.1 -O2 problem with sqrt.c

I am using gcc 3.3.1 release as my port, and looks like I have hit a problem with greg. The source program is the sqrt.c math function __ieee754_sqrt. ( I am pasting the relevent part here) typedef union { double value; struct { unsigned int lsw; unsigned int msw; } parts; } ieee_

Re: Sine and Cosine Accuracy

On 2005-05-26 12:04:04 -0400, Scott Robert Ladd wrote: > I've never quite understood the necessity for performing trig > operations on excessively large values, but perhaps my problem > domain hasn't included such applications. This can happen in some numerical applications (the same expressions a

Re: GCC and Floating-Point (A proposal)

On 2005-05-26 14:40:33 +0100, Paul Brook wrote: > I thought the x86 sin/cos intrinsics were unsafe. ie. they don't > gave accurate results in all cases. Yes, and here, this is a bug. See: http://web.archive.org/web/20040409144725/http://www.naturalbridge.com/floatingpoint/intelfp.html -- Vincen

Re: GCC and Floating-Point

On 2005-05-27 07:58:28 -0400, Scott Robert Ladd wrote: > Vincent Lefevre wrote: > > So, yes, -ffast-math by default would really be a bad idea and would > > make gcc much worse than other compilers. > > Who has advocated making -ffast-math the default? I certainly haven't. Allan Sandfeld Jensen h

Re: How can I get rid of __main ?

Monika Chaddha wrote: When I generate relocatable file (*.o) of (*.s) file then the disassembly of 'jal __main" does not display properly in GDB disassmebler. It displays as "jal 0x0" because __main linked only during linking process. why is this a problem? You'll notice it happens for all func

Re: Sine and Cosine Accuracy

On Fri, May 27, 2005 at 12:26:13AM +0200, Gabriel Dos Reis wrote: > If it was and angle! Not everything that is an argument to sin or cos > is an angle. They are just functions! Suppose you're evaluating an > approximation of a Fourrier series expansion. If you're evaluating it at the floating

Re: Sine and Cosine Accuracy

On 2005-05-26 16:33:00 -0500, Menezes, Evandro wrote: > Keep in mind that x87 transcendentals are not the most accurate > around, but all x86 processors from any manufacturer produce roughly > the same results for any argument as the 8087 did way back when, > even if the result is hundreds of ulps

mixing gcc-4.0 and g++-3.3 generated code

The Fink project has adopted the use of the g++-3.3 compiler as their default for compiling fink packages under MacOS X 10.4. However they are allowing the default gcc compiler to remain as gcc-4.0. Are there likely to be any odd issues with mixing code from the two compiler generations? In par

Re: Sine and Cosine Accuracy

On 2005-05-27 15:36:51 +0200, Olivier Galibert wrote: > If you're evaluating it at the floating point value 2^90 you're just > evaluating a fancy prng. Floating point values represent intervals, They don't. Have you never heard of correlation? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]

Greetings! "Boehm, Hans" <[EMAIL PROTECTED]> writes: > The collector also tries to address this with a complicated hack that > occasionally checks for opportune times to clear sections of the > stack that are not currently in use. (See GC_clear_stack() > in misc.c.) > BTW, where is the officia

Removal of 4.0.0 last minute page from Wiki?

Mark, is it OK to remove the link "Last-Minute Requests for 4.0.0" from the Wiki main page? The page is obviously unneded there. If you want, we can keep the link somewhere else (like collected in a page "obsolete misc pages"). -- Giovanni Bajo

Re: GCC 3.3.1 -O2 problem with sqrt.c

Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes: > I am using gcc 3.3.1 release as my port, and looks > like I have hit a problem with greg. You neglected to mention what target you are using. > I couldn't understand why the insns 620 and 621 are > being generated here as DI moves. I'm not sure s

Re: GCC and Floating-Point

On Friday 27 May 2005 13:51, Vincent Lefevre wrote: > So, yes, -ffast-math by default would really be a bad idea and would > make gcc much worse than other compilers. > Thanks for the tests. I had no idea GCCs fast-math was that different from other compilers. Maybe the real goal like other hav

Re: GCC and Floating-Point

> "Allan" == Allan Sandfeld Jensen <[EMAIL PROTECTED]> writes: Allan> Maybe the real goal like other have mentioned should be to Allan> divide the -ffast-math into multiple switches. Yes, and document them so both users and implementers can tell what they mean, which is not currently the ca

Re: Removal of 4.0.0 last minute page from Wiki?

Giovanni Bajo wrote: Mark, is it OK to remove the link "Last-Minute Requests for 4.0.0" from the Wiki main page? The page is obviously unneded there. If you want, we can keep the link somewhere else (like collected in a page "obsolete misc pages"). I tried to remove it -- but I didn't seem to

Re: Sine and Cosine Accuracy

On 2005-05-27, at 15:36, Olivier Galibert wrote: Floating point values represent intervals, This is mathematically wrong. The basic concept is that the calculations domain as given by floating point numbers is used to *model* the real number calculus. Certain constrains apply of course. But th

Re: GCC and Floating-Point

Paul Koning wrote: > Allan> Maybe the real goal like other have mentioned should be to > Allan> divide the -ffast-math into multiple switches. > > Yes, and document them so both users and implementers can tell what > they mean, which is not currently the case. I'm more than willing to do this,

Re: GCC and Floating-Point

On 5/27/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > Paul Koning wrote: > > Allan> Maybe the real goal like other have mentioned should be to > > Allan> divide the -ffast-math into multiple switches. > > > > Yes, and document them so both users and implementers can tell what > > they mean,

More front end type mismatch problems

This is happening in gcc.dg/tree-ssa/20040121-1.c. The test specifically tests that (p!=0) + (q!=0) should be computed as int: char *foo(char *p, char *q) { int x = (p !=0) + (q != 0); ... } During VRP, we get this IL D.1294_10 = first_8 != 0B; D.1295_11 = last_9 != 0B; x_12 = D.1

Re: GCC and Floating-Point

Richard Guenther wrote: > On 5/27/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: >>I can post a suggested set of switches and their meanings? We could >>actually document what the switches do *before* implementing them. > > Well, as I said before, actually enumerating the transformations we > cu

Re: More front end type mismatch problems

Diego Novillo <[EMAIL PROTECTED]> writes: > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test > specifically tests that (p!=0) + (q!=0) should be computed as > int: > > char *foo(char *p, char *q) { > int x = (p !=0) + (q != 0); > ... > } > ... > When we call int_const_binop

Re: GCC and Floating-Point

> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes: Scott> Paul Koning wrote: Allan> Maybe the real goal like other have mentioned should be to Allan> divide the -ffast-math into multiple switches. >> Yes, and document them so both users and implementers can tell >> what they mean,

Re: More front end type mismatch problems

On May 27, 2005, at 11:05 AM, Diego Novillo wrote: This is happening in gcc.dg/tree-ssa/20040121-1.c. The test specifically tests that (p!=0) + (q!=0) should be computed as int: char *foo(char *p, char *q) { int x = (p !=0) + (q != 0); ... } Is this program legal C? != is defined

Re: More front end type mismatch problems

On Fri, May 27, 2005 at 02:23:02PM -0400, Ian Lance Taylor wrote: > The program is legal C. The _Bool values should be promoted to int > before doing the addition. > OK, thanks. > I guess that type cast is being lost somewhere. > It doesn't seem to be ever emitted. There are no casts in .origi

Re: More front end type mismatch problems

> > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test > specifically tests that (p!=0) + (q!=0) should be computed as > int: > > char *foo(char *p, char *q) { > int x = (p !=0) + (q != 0); > ... > } > > During VRP, we get this IL > > D.1294_10 = first_8 != 0B; > D.1295_11

Re: More front end type mismatch problems

On Fri, May 27, 2005 at 02:32:46PM -0400, Andrew Pinski wrote: > > > > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test > > specifically tests that (p!=0) + (q!=0) should be computed as > > int: > > > > char *foo(char *p, char *q) { > > int x = (p !=0) + (q != 0); > > ... > >

Re: More front end type mismatch problems

> > On Fri, May 27, 2005 at 02:32:46PM -0400, Andrew Pinski wrote: > > > > > > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test > > > specifically tests that (p!=0) + (q!=0) should be computed as > > > int: > > > > > > char *foo(char *p, char *q) { > > > int x = (p !=0) + (q != 0

Re: More front end type mismatch problems

On Fri, May 27, 2005 at 02:45:14PM -0400, Andrew Pinski wrote: > Are you sure, the NE_EXPR does not have a type of INTEGER_TYPE? > This sounds like a missing fold_convert somewhere. > Ah, yes. I see what you mean now. The comparison was of type int but the evaluation was generating a _Bool valu

Re: Bootstrap problem

On May 25, 2005, at 9:38 AM, Andrew Pinski wrote: Attached is also the .i file for tree-ssa-operands.c The failure happens in copyprop3 but that is all I can tell, I have no idea what is going wrong. This is blocking me working on the tree combiner. Could someone look into this? I noticed

Numerous ObjC DejaGNU failures on i686-pc-linux-gnu

On i686-pc-linux-gnu, ObjC DejaGNU tests against mainline perform miserably: === objc Summary === # of expected passes466 # of unexpected failures559 # of unresolved testcases 532 # of unsupported tests 21 Upon closer inspection, the vast majo

Need GCC 3.3.6 PGP Signing Public Key

Dear all, This is imacat from Taiwan. I was downloading GCC 3.3.6. I saw it was signed by PGP key 902C9419, and it displayed its owner as Gabriel Dos Reis. But I can't find any other public source that can prove this key as her/his, not even on GCC website http://gcc.gnu.org/ or Savannah.

Re: mixing gcc-4.0 and g++-3.3 generated code

On May 27, 2005, at 6:55 AM, Jack Howarth wrote: Are there likely to be any odd issues I'm sure there are likely to be issues... for example, c++ isn't going to link across these versions. As long as one links with gcc-4.0, the issues of not finding a routine should be minimized. For C

RE: Sine and Cosine Accuracy

Scott, > Actually, it tested every 1.8°, but who wants to be picky. > I've rerun the test overnight at greater resolution, testing every > 0.0018 degress, and saw no change in the result. That's because the error is the same but symmetrical for sin and cos, so that, when you calculate the

Re: Sine and Cosine Accuracy

Evandro, > Any perceived increase in accuracy in this test comes > from intermediary calculations being done with 80 bits and > because the errors in fsin are complementary to those in fcos. I'm always willing to see my mistakes revealed, if it can be done so eloquently and politely. Unlike some

RE: Sine and Cosine Accuracy

Scott, > I still maintain that hardware fsin and fcos are valid and > valuable for certain classes of applications, I agree. I've just been trying to demonstrate that your test doesn't check sin and cos accuracies, but that sin^2 + cos^2 == 1. If I had a sin that always returned 1.0 and a c

Recall:

Tony Mueller would like to recall the message, "".

RE: Sine and Cosine Accuracy

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Menezes, Evandro > Sent: Friday, May 27, 2005 1:55 PM [...] > > That's because the error is the same but symmetrical for sin and > cos, so that, when you calculate the sum of their squares, one > cance

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: > Gabriel Dos Reis wrote: >> Scott Robert Ladd <[EMAIL PROTECTED]> writes: >> | Then, as someone else said, why doesn't the compiler enforce -ansi >> | and/or -pedantic by default? >> Care submitting a ptach? > Would a strictly ansi default be accept

Re: GCC 3.3.6 has been released

Gabriel Dos Reis wrote: The list of changes is available at http://gcc.gnu.org/gcc-3.3/changes.html a tiny detail, but i figured i would mention it. congratulations. --- changes.html.orig 2005-05-27 18:56:02.0 -0600 +++ changes.html2005-05-27 18:56:36.000

Re: More front end type mismatch problems

>> On Fri, May 27, 2005 at 02:45:14PM -0400, Andrew Pinski wrote: >>> re: >>> char *foo(char *p, char *q) { >>> int x = (p !=0) + (q != 0); >>> ... >>> } >> >> Are you sure, the NE_EXPR does not have a type of INTEGER_TYPE? >> This sounds like a missing fold_convert somewhere. >> > Ah, yes

Induction Variable

Hi, Can someone tell me how to obtain the following: 1) Given a rtx, find out if it is an induction variable. 2) For an induction variable, find all the loop nest 3) For each loopnest, find the corresponding upper and lower bounds (compile-time) 4) For an induction variables, find the increment/d