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

Ian Lance Taylor wrote: I fully appreciate that there is a real problem here which needs to be addressed, but this does not seem like the best solution to me. A great number of C programs are built using autoconf. If we make this change, then they will all be built with -fwrapv. That will disa

GCC 4.0, Fast Math, and Acovea

Hello, I've been down (due to illness) for a couple of months, so I don't know if folk here are aware of something I discovered about GCC 4.0 on AMD64: -ffast-math is "broken" on AMD64/x86_64. Specifically, the -funsafe-math-optimizations flag doesn't work correctly on AMD64 because the default

Re: GCC 4.0, Fast Math, and Acovea

Uros Bizjak wrote: Hello Scott! Specifically, the -funsafe-math-optimizations flag doesn't work correctly on AMD64 because the default on that platform is -mfpmath=sse. Without specifying -mfpmath=387, -funsafe-math-optimizations does not generate inline processor instructions for most floating

Re: GCC 4.0, Fast Math, and Acovea

tbp wrote: Shameless plug with my own performance analysis regarding SSE on x86-64. I've ported my coherent raytracer which mostly uses intrinsics in the hot path (and no transcendentals). While gcc4.x compiled binaries are ~5% slower than those compiled with icc8.1 on ia32 (best case), it's the ot

GCC 4.0 Review

Hello, This morning, I've posted a short review of GCC 4.0, comparing it to the 3.4.3 on a number of real-world benchmarks (LAME, POV-Ray, the Linux kernel, and SciMark2). You'll find the results here: http://www.coyotegulch.com/reviews/gcc4/index.html Also, I've posted Acovea analysis fo

Re: GCC 4.0, Fast Math, and Acovea

tbp wrote: On 4/29/05, Uros Bizjak <[EMAIL PROTECTED]> wrote: Hello Scott! Hello Scott & Uros, Specifically, the -funsafe-math-optimizations flag doesn't work correctly on AMD64 because the default on that platform is -mfpmath=sse. Without specifying -mfpmath=387, -funsafe-math-optimizat

GCC and Floating-Point

Hello. I'm writing an extensive article about floating-point programming on Linux, including a focus on GCC's compilers. This is an outgrowth of many debates about topics like -ffast-math and -mfpmath=sse|387, and I hope it will prove enlightening for myself and others. Among the subjects covered

Re: GCC and Floating-Point (A proposal)

Allan Sandfeld Jensen wrote: >>Yes. I still don't understand why gcc doesn't do -ffast-math by >>default like all other compilers. Vincent Lefevre wrote: > No! And I really don't think that other compilers do that. > It would be very bad, would not conform to the C standard[*] > and would make lot

Re: GCC and Floating-Point (A proposal)

Scott Robert Ladd <[EMAIL PROTECTED]> wrote: >>May I be so bold as to suggest that -funsafe-math-optimizations be >>reduced in scope to perform exactly what it's name implies: >>transformations that may slightly alter the meanding of code. Then move >>the

Re: GCC and Floating-Point (A proposal)

Paul Brook wrote: > I thought the x86 sin/cos intrinsics were unsafe. ie. they don't gave > accurate > results in all cases. If memory serves, Intel's fsin (for example) has an error > 1 ulp for value flose to multiples of pi (2pi, for example). Now, I'm not certain this is true for the K8 and

Sine and Cosine Accuracy

Let's consider the accuracy of sice and cosine. I've run tests as follows, using a program provided at the end of this message. On the Opteron, using GCC 4.0.0 release, the command lines produce these outputs: -lm -O3 -march=k8 -funsafe-math-optimizations -mfpmath=387 generates: fsincos

Re: Sine and Cosine Accuracy

Andrew Haley wrote: > Try this: > > public class trial > { > static public void main (String[] argv) > { > System.out.println(Math.sin(Math.pow(2.0, 90.0))); > } > } > > zapata:~ $ gcj trial.java --main=trial -ffast-math -O > zapata:~ $ ./a.out > 1.2379400392853803E27 > zapata:~ $ gcj

Re: Sine and Cosine Accuracy

Richard Henderson wrote: > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: > >>static const double range = PI; // * 2.0; >>static const double incr = PI / 100.0; > > > The trig insns fail with large numbers; an argument > reduction l

Re: Sine and Cosine Accuracy

Paul Koning wrote: > Scott> Yes, but within the defined mathematical ranges for sine and > Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite > Scott> accurate. > > Huh? Sine and consine are mathematically defined for all finite > inputs. Defined, yes. However, I'm speaking a

Re: Sine and Cosine Accuracy

Dave Korn wrote: > It's difficult to tell from that quote, which lacks sufficient context, > but you *appear* at first glance to be conflating the fundamental > trignometric *functions* with the trignometric *identities* that are > generally built up from those functions. That is to say, you ap

Re: Sine and Cosine Accuracy

Morten Welinder wrote: > If you were to look up a serious math book like Abramowitz&Stegun1965 > you would see a definition like > > sin z = ((exp(iz)-exp(-iz))/2i [4.3.1] Very true. However, the processor doesn't implement intrinsics for complex functions -- well, maybe som

Re: Sine and Cosine Accuracy

Paul Koning wrote: > I'm really puzzled by that comment, partly because the text book quote > you gave doesn't match any math I ever learned. Does "knowing your > math" translates to "believing that trig functions should be applied > only to arguments in the range 0 to 2pi"? If so, I must object.

Re: Sine and Cosine Accuracy

Dave Korn wrote: > Well, as long as they're under the control of a flag that also makes it > clear that they are *also* unsafe math optimisations, I wouldn't object. But they are *not* unsafe for *all* applications. An ignorant user may not understand the ramifications of "unsafe" math -- howev

Re: Sine and Cosine Accuracy

Andrew Pinski wrote: > b) means that (-a)*(b-c) can be changed to a*(c-b) and other reassociation > opportunities. This is precisely the sort of transformation that, in my opinion, should be separate from the hardware intrinsics. I mentioned this specific case earlier in the thread (I think; maybe

Re: GCC and Floating-Point

Allan Sandfeld Jensen wrote: > Basically any compiler that cares about benchmarks have it enabled by default. > > Many of them however have multiple levels of relaxed floating point. The > lowest levels will try to be as accurate as possible, while the higher will > loosen the accuracy and just

Re: Sine and Cosine Accuracy

Gabriel Dos Reis wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > | 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. > >

Re: Sine and Cosine Accuracy

Richard Henderson wrote: > On Thu, May 26, 2005 at 12:04:04PM -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 applicat

Re: Sine and Cosine Accuracy

Gabriel Dos Reis wrote: > Yeah, the problem with people who work only with angles is that they > tend to forget that sin (and friends) are defined as functions on > *numbers*, not just angles or whatever, and happen to appear in > approximations of functions as series (e.g. Fourier series) and ther

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > This is not true. Compare results on an x86 systems with those on an > x86_64 or ppc. As I said before, shortcuts were taken in x87 that > sacrificed accuracy for the sake of speed initially and later of > compatibility. It *is* true for the case where the argument is i

Re: Sine and Cosine Accuracy

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 accepted on principle? Given the

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > Besides, you're also comparing 80-bit calculations with 64-bit > calculations, not only the accuracy of sin and cos. Try using > -ffloat-store along with -mfpmath=387 and see yet another set of > results. At the end of the day, which one do you trust? I wouldn't > trust

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

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

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

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 enumera

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: GCC and Floating-Point

Toon Moene wrote: > Good Luck :-) > > http://gcc.gnu.org/ml/gcc/2001-08/msg00368.html > > (it's only four years ago - I can also show you my contributions in this > thread in 1999, i.e., the previous millennium). Just out of curiosity, why did previous efforts fail in this regard? Was it sim

Re: GCC and Floating-Point

Joseph S. Myers wrote: > They didn't fail altogether; -ffast-math was split into multiple > options (-funsafe-math-optimizations -fno-trapping-math etc.) in > March 2001, following an analysis of everything that checked > flag_fast_math >

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

Uros Bizjak wrote: > At this point, I wonder what is wrong with Bugzilla, that those > programmers don't fill a proper bug report. In my experience, people don't file Bugzilla reports because it feels impersonal and unresponsive. The form is not very user-friendly (as in friendly to users of GCC,

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

William Beebe wrote: > For example, whenever I feel the temperature rising a bit > too high, I just wonder over to the lkml and lurk awhile until I > realize once more what wonderfully sainted individuals the gcc > developers are. With the departure of Larry McVoy and BitKeeper, LKML is going to b

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Heck, I can plot trajectories on a sphere that do not follow great circles, > and that extend over 360 degrees in longitude. I don't see why I should be > restricted from doing that. Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi) are not equal to sin(

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Heck, I can plot trajectories on a sphere that do not follow great circles, > and that extend over 360 degrees in longitude. I don't see why I should be > restricted from doing that. Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi) are not equal to sin(

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Funny, I don't expect any message from that signature. > > Gabriel dos Reis, on the other hand, may have something to say... A regrettable mistake, brought on by spending too many years in Spanish-speaking areas, where "rio" is river. ..Scott

Re: Sine and Cosine Accuracy

Bernhard R. Link wrote: > Breaking things like sin(-x) or sin(x+y) will definitly hurt people, > because it is natural to expect this to work. Where in the name of [insert diety here] did I *ever* say I wanted to break anything? Just because something breaks *your* application doesn't mean I shou

Re: Sine and Cosine Accuracy

chris jefferson wrote: > I would like to say yes, I disagree that this should be true. By your > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how > the heck do you intend to actually calculate that value? You can't just > keep subtracting multiples of 2*pi from pow(2.0, 90.0)

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

Andreas Schwab wrote: >> No, this is not portable, > > Sure they are, since they are required since C89. > > You can use to find that out. That's what portability is > about. "Portability" means different things to different people. There's a difference between source code portability and "res

Improving GCC Floating-Point [was: What is wrong with Bugzilla?]

Vincent Lefevre wrote: > Changing the rounding precision is. The C standard defines how you > can change the rounding direction, but not the rounding precision. Back in the early 1990's, work on solving this inadequacy was being done by the X3J11 Numerical C Extensions Group. Rex Jaeschke was the

Re: Tracking down gcc-4.0 performance regressions

Daniel Kegel wrote: > So, I'm looking around for other reports of performance > regressions in gcc-4.0. So far, the only other ones I've > heard of are those reported in http://www.coyotegulch.com/reviews/gcc4/ > I'm tempted to have a student try reproducing and boiling down the POV-Ray > performa

Re: Will Apple still support GCC development?

Samuel Smythe wrote: > It is well-known that Apple has been a significant provider of GCC > enhancements. But it is also probably now well-known that they have > opted to drop the PPC architecture in favor of an x86-based > architecture. Will Apple continue to contribute to the PPC-related > compon

Re: Will Apple still support GCC development?

Mirza Hadzic wrote: >> Intel already handed icc + performace libs to apple, but from my >> experience icc doesn't create any faster code then gcc. Is there >> any *recent* benchmark that shows otherwise? Define "recent". >> I know that heavy math code is likely to perform better on icc but >> th

A Suggestion for Release Testing

Given the recent problems with the 4.0.0 release and major packages like KDE and the kernel, has anyone considered testing releases by completely compiling a Linux system? As one of those infamous "Gentoo users", I don't think it would be at all difficult to build an automated test harness, runnin

Floating-Point, Round 2

Yes, I'm still working on the idea of improving floating-point in GCC. I've been having a number of offline discussions (for which I'm certain you're all grateful) with folk who have concerns and suggestions for GCC floating-point. My plan is to coallate all these thoughts, and present a simple su

Re: A Suggestion for Release Testing

Arthur Nascimento wrote: >>Given the recent problems with the 4.0.0 release and major packages like >>KDE and the kernel, has anyone considered testing releases by completely >>compiling a Linux system? > Yes, people do it all the time. Check Sourcemage, LFS and DIY: > > http://www.sourcemage.org

Re: A Suggestion for Release Testing

Joe Buck wrote: > With 4.0.0, compiling a complete GNU/Linux distribution reveals bugs > in GCC, but even more bugs in C++ software that is not valid C++. > Assuming we can get the distros to fix the latter set of problems... I don't have a good solution for this problem, other than education. >

Re: Big differences on SpecFP results for gcc and icc

Uros Bizjak wrote: > I think I'm not the only person, that finds these results rather > "dissapointing". As Scott is currently writing a paper on gcc's FP > performance, perhaps someone has an explanation, why gcc's results are > so low on Pentium4 for these tests? Interesting results. I'm not a

Re: A Suggestion for Release Testing

Gerald Pfeifer wrote: > Are you sure nobody is doing this? Or to phrase it differently: have > you checked Bugzilla and the ChangeLogs as to what kind of reports and > patches SUSE and Red Hat have contributed to GCC 4.0 in recent months > and weeks? :-) My suggestion stems from the code-generati

Re: Big differences on SpecFP results for gcc and icc

Menezes, Evandro wrote: > Each HPC application tends to be unlike others, making it difficult > to optimize GCC for an elusive typical FP application. Not that > there isn't room for improvement though. The performance of almost any HPC application can be isolated to specific key loops, and every

Re: GCC 4.0.1 Status (2005-06-13)

Mark Mitchell wrote: > 2. Jakub Jelinek reports that we're miscompiling GLIBC. > > The latter problem seems to me to be as severe as the KDE bug that was > the impetus for this release. The libstdc++ problem also seems serious. Agreed. I've had mixed reports from folks over in the Gentoo univers

Fixing Bugs (Was: A Suggestion for Release Testing)

Mark Mitchell wrote: > I'm all for more testing -- but I have a standard rant about it being > easier to run tests than to fix problems. We actually have a wealth > of known regressions -- some pretty serious -- in Bugzilla, and > plenty more known bugs. Most come from real problems reported by

Porposal: Floating-Point Options

To support different expectations, I suggest defining the following floating-point options for GCC. This is a conceptual overview; once there's a consensus the categories, I'll propose something more formal. -ffp-correct This option focuses code generation on mathematical correctness, portability

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > This is wrong, there is an IRC channel which talks about technical issues > deal with developing GCC (not with though but that should be in an > UNIX/C/C++ IRC channel instead). Where? A Google search on "GCC IRC" doesn't find much, and the few times I've visited #gcc on Fr

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > > No you don't need to learn a new language. You need to learn RTL which is a > language yes but it is based on LISP. Also some of the recent bugs are on > the tree level so you just need to know GIMPLE which is really just simple > expressions. So I don't see why you are c

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Andrew Pinski wrote: > FreeNode is not the only IRC server. irc.oftc.net is where #gcc is hosted. You are ebing positively rude. Just because I mention FreeNode doesn't mean I'm so ignorant as to be unaware of other servers. Where is irc.oftc.net #gcc above documented? ..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as >> well. I'm not saying that expectation is wrong, I am saying it is an >> impediment to working on GCC. > > with respect, I disagr

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: >> If I were to present a patch that implements the recomendations of the >> Numerical C Extensions Group, would it be accepted or rejected (on the >> subject alone; ignore for the moment potential technical bugs in the >> submitted code)? > Again, it would probably be better s

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Mark Mitchell wrote: > Actually, I don't agree with either of the statements ascribed to me, > and if I conveyed that sentiment, I apologize. And I apologize for perhaps reading more into your statements than was intended. > My point was simply that once you have the tests > and bug reports, some

Re: Porposal: Floating-Point Options

Vincent Lefevre wrote: > I don't like the word "correct" here, since the correctness > depends very much on the context. Good point. > I disagree. The default should be a conforming C99 implementation. I suppose I need to be consistent... ;) I've said in past threads, GCC should default to -ansi

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Richard Guenther wrote: > Take a break and come back with results of actual work done, > this impresses people a lot more than (repeated) ranting about > gcc development in general. I have worked on GCC; not much, and probably trivial in your eyes, but practical work nonetheless. To trivialize con

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

chris jefferson wrote: > One thing I have come across, both in gcc and in other projects, is that > often discussion is not the best option, but instead just writing some > code is better. There's a fine line between too much talk and not enough. > It's very easy to have discussions go around in

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Robert Dewar wrote: > Scott Robert Ladd wrote: >> I would like to improve floating-point in GCC; doing so scratches my >> personal itch. My silly idea is to determine the best approach >> *through discussion*. > Perfectly appropriate, and you are getting lots of discussion

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Giovanni Bajo wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > First of all, I would consider polite to CC: me on the mail if you quote and > debate my statements. I meant no offense, and thought that I *had* CC'd you on the message. >>The ISO Standard does

Re: Porposal: Floating-Point Options

Marcin Dalecki wrote: > Sorry but I just got completely fed up by the references to "math" by > the original post, since the authors leak of basic experience in the > area of numerical computation was more then self evident. My apologies for not meeting your high intellectual standards, ;P > Maki

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Giovanni Bajo wrote: > Agreed. But keep in mind that it is not necessary to reply: once the bug is > open and confirmed, the last comment "wins", in a way. If the bugmaster > wanted to close it, he would just do it, so an objection in a comment does > not make the bug invalid per se. But an object

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Richard Guenther wrote: > On 6/15/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: >>But an objection from one of the bugmasters *is* enough to keep people >>from presenting a patch. > > How do you come to this conclusion? From my experience this > is untrue -

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Dave Korn wrote: > Perhaps I've missed something here, because I'm mystified how you could > think that gcc development is conducted by an organisation with full-time > staff. Perhaps not a formal staff, but there is a core group of developers whose incomes are closely tied to GCC development. M

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Gabriel Dos Reis wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > | But an objection from one of the bugmasters *is* enough to keep people > | from presenting a patch. > > Well, I'm not sure. If the report is closed, then you're right. > However, if the

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Richard Guenther wrote: > May I turn this into a suggestion: don't be scared away by negative > comments of one of the bugmasters, instead continue working on a > patch; you are definitely encouraged to do so! And if not the > bugmasters, other people affected by the bug will be grateful! It's i

Re: Porposal: Floating-Point Options

Marcin Dalecki wrote: > Please bear with me. English is my 3th foreign language. No offense intended, You're lucky you haven't been subjected to my Spanish... my wife cringes. > You should always place Java last in discussions about numerical work. > It's largely irrelevant in this area due to th

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Daniel Berlin wrote: > Maybe you should start naming names, so we can take stock of the > problem. Because of Acovea and my reviews of GCC (there are two more coming, one in a print magazine), a lot of people write me privately. This happens with commercial compilers as well... and combining those

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

Aaron W. LaFramboise wrote: > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > the "Bicycle shed effect." > > If I'm building a bicycle shed, I may want to talk with others who have done so

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Mark Hahn wrote: > LKML is no different, except that it is probably somewhat more prominent, > and has developed some immunity/bouncers (kernel janitors, etc). Linux as has a vast body of educational material, including "kernel newbies". ..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Gabriel Dos Reis wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > > | 2) A mentoring system could help bring along new GCC developers. I'm not > | talking about hand-holding, I'm suggesting that having some place for > | people to ask a few questions,

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Dan Kegel wrote: > And then there's the GCC summit, if you're really serious. I'd certainly love to attend, but can't afford it with the medical bills we've accumulated. Hospitalizing both the primary bread-winners has a dramatic affect on finances. ;) > I think what gets peoples' blood pressure

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Daniel Berlin wrote: > Again, *please* provide examples other than "The bugmasters are mean". Don't invent quotes. I never said anyone was "mean." And other people have provided explicitly links to germane bugs. > You are more than free to post designs on gcc@ if you want. However, you > seem to

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Darn me all the heck. I said I wasn't going to say anything more... bad Scott, bad Scott! > again and again and again and again (which i'm sure you'll say is us > "not listening to the user community", which is not the case). I hate to disappoint you, but those words won't grace this message. I u

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Daniel Berlin wrote: > If you consider that "unfriendly", then you really need to get out of > the development business, because you need a thicker skin. Oh, my skin's thick enough. And my skull, too. :) Perhaps there is misinterpretation all around. ..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Gabriel Dos Reis wrote: > Sometimes, some people come to GCC developers with the assumptions > that they must be obscure ignorant and miles-of-code-writers-without- > thinking and as such are very willing to endlessly lecture them about > how ignorant they are and how they should do their jobs. I

Re: How to replace -O1 with corresponding -f's?

Sergei Organov wrote: > Using gcc compiled from gcc-4_0-branch, in an attempt to see which > particular optimization option makes my test case to be mis-optimized, This sort of problem is exactly what my Acovea program was designed for; it will identify the pessimistic option by analyzing GCC's co

-floop-optimize2

I've noticed that -floop-optimize2 tends to be a pessimism on many algorithms. I'm hesitant to file this as a "bug", given that -floop-optimize2 is a "new" replacement for the older loop optimizer. Is -floop-optimize2 still in development, and not ready yet -- or are the problems I'm seeing somet

Re: -floop-optimize2

Richard Guenther wrote: > As the old loop optimizer is (hopefully) going away sooner or later > small testcases are surely welcome that identify weak spots of the new > loop optimizer. I shall attempt the creation of small test cases, then. SHouldn;t be too difficult, given the nature of my test c

Re: -floop-optimize2

Andrew Pinski wrote: > What version of GCC, if not the mainline, we don't care... I'm speaking terms of mainline at the moment. I've just started running Acovea through a new set of benchmarks with 4.1-cvs. ..Scott

Re: -floop-optimize2

Zdenek Dvorak wrote: > if you have testcases, I would be definitely interested. I'm preparing for an impromtu business meeting, but I'll put together test cases tonight and post them to Bugzilla. I should have at least two small, well-defined cases. ..Scott

Re: GCC 4.0.1 Status (2005-06-27)

Mark Mitchell wrote: > I'm sorry this is dragging out, but I think it's worth getting this bug > fixed. No need for apologies; you're doing the "right thing". ..Scott

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

Marcin Dalecki wrote: > The only thing this thread teaches me is the conviction that *every* > instruction set architecture, which relies on compilers to make the most > out if it is severely ill guided. I've learned that I'm not the only guy who can start a really long, contentious thread on the

Re: 4.2 Project: "@file" support

Tristan Wibberley wrote: I certainly agree with (a). For (b), I think a gcc compiler that is intended to produce normal Windows binaries should have the same commandline interface as Microsoft's compiler (I mean *all* of the commandline interface) - for build scripts and development environments

Re: incompatible 'improvements'

George White wrote: Frankly, I don't care what standards say is no longer acceptable syntax. The standards have existed for quite some time, giving you plenty of time to get acquainted with the rules. Standards exist for a reason, and if you choose not to follow them, it is not the fault of t

Grabbing Gomp (was: Is gcc optimized for thread level parallelism?)

a on their progress. I've been detained elsewhere by a variety of issues, and unable to follow Gomp since earlier this year, but I hope to get back into it when time permits in a few weeks. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com

Re: backslash whitespace newline

ons before. :) The *default* behavior of the compiler should follow published standards first and past GCC behavior second (and both whenever possible). Support for "other compilers" is desirable, if it can be implemented without compromising those primary objectives. -- Scott

Re: backslash whitespace newline

omeone (not me) fired for using an "unauthorized tool", even when the script produced a clear benefit for the project. I did not stay at that workplace very long. Is anyone using GCC in an ISO 9000 environment? Just curious. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com

Re: backslash whitespace newline

ms, and it would be the specific institution, and not ISO 9000, that is broken (IMHO) if anal rule prevented such utilitarian acts? -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com

Re: Thoughts on LLVM and LTO

he consequences need to be considered carefully. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com

Re: Some GCC 4.1 benchmarks (Re: Thoughts on LLVM and LTO)

Jan Hubicka wrote: I should note that comparison to ICC is not quite fair since it lacks Opteron tunning... I think you may be comparing oranges to tangerines -- not as bad as apples and oranges, but still potentially an invalid comparison. In my experience the extra registers of the Opteron

Re: Some GCC 4.1 benchmarks (Re: Thoughts on LLVM and LTO)

nd ICC is tuned for EM64T, I would guess. GCC is tuned for AMD64. Yes, I'm aware of that. Which makes me suspicious of any benchmark that uses Intel's "EM64T tuned" compiler on the Opteron. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com

Re: Thoughts on LLVM and LTO

will initially invoked only via an option, and that a normal compile will continue the current path until LLVM is fully tested and accepted? Just questions; if they are stupid, please be gentle. ;) -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com