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

[Scott Robert Ladd]

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 disable
useful loop optimizations, optimizations which are enabled by default
by gcc's competitors.  The result will be to make gcc look worse than
it is.


The inclusion of -fwrapv is a good idea from the standpoint of producing 
reliable code; it is a bad idea from the point of GCC PR.


Which begs the question: Should GCC care about its PR?

GCC suffers from many misconceptions due to its complexity. When it 
comes to code optimization, GCC offers more options than any other 
compiler I know. Literally hundreds of options combine in sometimes 
surprising ways, allowing a knowledgeable GCC user to fine-tune their 
code generation.


Back in the "old days", GCC was only used by expert UNIX hackers who 
were educated about their tools. Today, GCC is being used by a more 
general audience to develop consumer code. As such, GCC needs to err on 
the side of reliability and backward compatibility, benchmarks be damned.


So if adding -fwrapv to autoconf keeps the current GCC from breaking 
existing code at the cost of some speed, that's a Good Thing. Vendors 
and Gentoo users who really care about performance can manually set 
flags to boost their performance.


I don't want to see GCC "dumbed down" -- experts need a compiler with 
this sort of fine-tuned power.


..Scott

Re: Thoughts on LLVM and LTO

[Scott Robert Ladd]

I've been quietly watching the conversation, largely as an interested 
user as opposed to a GCC developer. One of my concerns lies with:


GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL

That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here -- 
perhaps simple one, perhaps not. The line is very straight, but adding 
two more segments make me wonder if we're complicating the plumbing.


How will this effect compiler speed?

How will debugging information flow accurately through the process?

And will we be making it even more difficult to isolate problems?

Already, we have people who understand frontends, and others who know 
GIMPLE initimately, and still overs who focus on RTL generation. Is 
adding two additional passes going to further fragment expertise?


I understand Rafael's comment, as quoted here:

> In a first stage nothing will be done with the LLVM representation
> except convert it back to GIMPLE. This will make sure that all
> necessary information (including debug) can pass through the LLVM. The
> conversion will also receive very good testing with this.

Does this mean that the "LLVM pass" 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

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

[Scott Robert Ladd]

Steven Bosscher wrote:

It obviously doesn't do that.  ICC uses that larger register file, too,
for x86-64.


The Intel compiler can be set to compile for multiple processors,
keeping different versions of the same function in an executable and
picking which code to run based on the processor in use. Thus it is
quite possible to compile code (with Intel) on an Opteron, but have it
sereptitiously run using a lesser instruction and register set.


AMD's Opteron (AMD64) and Intel's Nocona (EM64T-cheap-ass-AMD64-clone)
are both just implementations of the x86-64 architecture.  And 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: Some GCC 4.1 benchmarks (Re: Thoughts on LLVM and LTO)

[Scott Robert Ladd]

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 provide a 
significant benefit; GCC has an unfair advantage if ICC only generated 
code for the small set of x86 registers.


..Scott

Re: Thoughts on LLVM and LTO

[Scott Robert Ladd]

Daniel Berlin wrote:

2. It natively supports Alpha, Sparc, IA64, X86, and PowerPC.  An
LLVM->RTL converter is not that hard, which simply removes the entire
argument anyway.


I see the phrase "doing X is not that hard" in response to many 
questions about this proposal. Now, I'm arguing the difficulty of the 
given tasks, but even a simple task requires someone to do it. And 
maintain it.


Which begs the question: Are these proposals practical within the 
existing GCC developer community, particularly over the long term 
(years, decades)?


How did moving to tree-ssa affect the developer community? Did more 
people come on board, are fewer people working on GCC now, or did it 
have no net influence on the developer base?


I honestly don't know, hence my queries.


The bottom line I just don't see any sane argument for redo'ing what
others have done very well, unless using that will require more
resources than doing it from scratch.

I can't honestly believe that the work required to make LLVM usable for
us is anywhere near the work we are going to need to tree-ssa to do the
same things LLVM does.


Reverse the question: What does tree-ssa do that LLVM does not? I know 
that's been covered to some extent in these threads, but maybe someone 
knowledgable could lay out a very simple bullet point list comparing 
what needs to be done with both plans.


I'm not saying which way GCC should go -- I merely think that all the 
consequences need to be considered carefully.


--
Scott Robert Ladd <[EMAIL PROTECTED]>
Coyote Gulch Productions
http://www.coyotegulch.com

Re: backslash whitespace newline

[Scott Robert Ladd]

Robert Dewar wrote:

It sounds like you are not familiar with ISO 9000 at all :-)

This standard is about following your internal rules, it is not
a set of rules itself, so if you have a rule which prohibits SED
scripts in your environment, this is a rule you have created
for yourself, and you cannot blame ISO 9000! One of the risks
in ISO 9000 environments is being stuck with silly rules. You
can get certification pretty much regardless of whether your
rules make sense, just as long as you can show you follow them
rigorously :-)


Ah! I worked in only one place, a defense contractor, where ISO 9000 was 
 "followed", and the way management talked, their procedures were 
dictated by ISO 9000. So I gather my one experience gave me an 
inaccurate view of the subject?


So I assume it is possible for an ISO 9000 environment to allow for ad 
hoc sed scripts to fix trivial problems, 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: backslash whitespace newline

[Scott Robert Ladd]

Bernd Jendrissek wrote:

Also, if a sed script that modifies comments is too great a burden to
bear for such a beaurocracy, then using a different compiler should be
even more of a red-tape jungle.  If it isn't, the management system is
broken and you might as well not bother with all those burdensome
processes anymore - they're not doing you any good.


Much as I agree with your sentiments, in many environments, the use of 
ISO 9000 is *required*, as in you don't get the contract if you don't 
follow ISO 9000. I have not seen any evidence, personally, that ISO 9000 
actually ensures a perfect product, but it is a political requirement of 
many environments.


I'm not familiar-enough with ISO 9000 to judge whether a sed script is 
"too great a burden", but I once worked in an environment where writing 
a Python script to clean some ugly code got someone (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

[Scott Robert Ladd]

Robert Dewar wrote:

Seems a weak argument to me. Changing gcc would create incompatibilities
with previous behavior of gcc, and that is FAR more significant than
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.


Wouldn't it be possible to implement a compile-time option to enable the 
desired behavior only for those poor folk who have this problem?


It's not as if GCC has been shy about adding options 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 Robert Ladd <[EMAIL PROTECTED]>

Coyote Gulch Productions
http://www.coyotegulch.com

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

[Scott Robert Ladd]

Jim Wilson wrote:
No, but we are working on OpenMP support, which is somewhat related. 
This isn't automatic parallelization; it requires programmer 
instrumentation via pragmas.  This is probably more directed at 
multiprocessor machines than threads, but it is a start in the right 
direction.  See

  http://gcc.gnu.org/projects/gomp/
This is still in early stages of implementation.  Don't expect anything 
to work yet.


Where is the gomp branch in terms of the SVN transition? Should I still 
grab it via CVS, or is it in the new SVN repository?


Congratulations the Gomp tema 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: incompatible 'improvements'

[Scott Robert Ladd]

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 the GCC developers.



Stop emulating Microsoft, who has little regard
for maintaining backwards computability...


Actually, Microsoft is very inconsistent on the issue. Their C++ is an 
abomination on many fronts, and certainly not standard -- and Microsoft 
has publicly and vocally stated they have no plan to follow either the 
C++ or C standards, but prefer to forge their own road.


GCC, on the other hand, maintains remarkable support for legacy code and 
platforms. And there is *nothing* to prevent you from using an older 
versions of GCC; quite a few people do.


..Scott

Re: 4.2 Project: "@file" support

[Scott Robert Ladd]

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
that expect to see Micrsoft's tools.


This isn;t that difficult to do now -- on Windows, I wrote a wrapper to 
mask the underlying compiler, so that tools expecting MSVC work 
transparently with Intel and GCC compilers. Emulating Microsoft exactly 
doesn't need to be part of GCC itself.


That said, I am a supported of the @file concept in GCC, since it has 
uses beyond simple MSVC compatibility.


..Scott

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

[Scott Robert Ladd]

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 GCC mailing list! ;)

..Scott

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

[Scott Robert Ladd]

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: -floop-optimize2

[Scott Robert Ladd]

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: -floop-optimize2

[Scott Robert Ladd]

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

[Scott Robert Ladd]

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 code.

..Scott

-floop-optimize2

[Scott Robert Ladd]

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 something that should be analyzed and reported
as a bug?

..Scott

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

[Scott Robert Ladd]

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 compilation
of your code.

http://acovea.coyotegulch.com

..Scott

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

[Scott Robert Ladd]

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 have never considered GCC developers to be ignorant, and perhaps what
I perceive as "rudeness" is in fact frsutration accumulated over many
years. If anything, this is one of the brightest developer groups.

> That is not meant to excuse what you perceive to be rudeness, but to
> point out that the communication channel works both ways.

A good point. I shall attempt to be a bit less sensitive and more
understanding, on the assumption that others will return the favor.

..Scott

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

[Scott Robert Ladd]

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

[Scott Robert Ladd]

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
understand the frustration.

> We've also had people write to other mailing lists and say "plesae
> mail-bomb the gcc list so they'll listen to us"

And I have a homeless guy in Berkeley who takes great satisfaction in
raking anything I do over the coals in various Usenet groups. We all
have our crosses to bear...

> ...we've become very unfriendly about the small number of people who
> contend again and again that we should do it different, claiming simply
> that any viewpoint than theirs is *wrong* and *bad* instead of "a
> tradeoff that has been chosen".  And they are *not* particularly polite
> about it.

My silly goal is to try an accomodate all viewpoints; providing a
solution for bug 323 (for infamous example) could remove an irritant for
all sides. Wouldn't that be a Good Thing?

..Scott
(Who really will shut up now, until he presents some code.)

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

[Scott Robert Ladd]

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 interpret what appears to be constructive criticism as "not very
> friendly" at times.

There's a difference between constructive criticism and condescension.

Be that as it may, I actually agree with Steven that this conversation
has reach the point of no return. You may have the last word.

..Scott

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

[Scott Robert Ladd]

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 up is
> endless discussion about how they ought to do their
> business.

Try publishing a compiler review, and listen to the kibitzers. :)

I've been writing for publication all my adult life; just because people
don't like what you write (software or prose) is no reason to be rude.
They might actually have valid points...

..Scott

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

[Scott Robert Ladd]

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, one on one, to get over certain
> | conceptual humps.
> 
> Such a place does exist, as mentioned in several messages.

The IRC channel? No one stated that it was for "newbie" questions. Given
that it wasn't very well documented on the web site, it appeared to be a
private channel for existing GCC developers.

..Scott

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

[Scott Robert Ladd]

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: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

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 in the past, learning from the experience and gaining their
insights. Why did they use a certain type of construction? What sort of
storage did they build in? What worked and didn't work for someone else
who has already built a shed? What did they learn from their own work?
Any shed I build will be better for such discussions.

GCC's floating-point support can be improved by considering what people
want from their math in conjunction with the characteristics of
different systems. Discussions herein have clarified and expanded my
understanding of the issues.

> In all of the open source world I have seen, posting code is always better.

Better than what? Design? Analysis? Just because some people like to
nitpick doesn't mean there shouldn't be forethought to our work.

Be that as it may, one must work within the presiding culture, and if
design and analysis are frowned upon, it is directly to code that I will go.

..Scott

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

[Scott Robert Ladd]

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 e-mails with
conversations in IRC and other mailing lists, I have ample evidence that
many people feel that the GCC developer community is not very welcoming.

Why do people write me? I've been doing compiler reviews, and working on
compilers (other than GCC), for more than 15 years. Perhaps people just
think they know me, and are more comfortable talking to a "person" who
has publicly expressed concerns similar to thiers.

I am not the only voice in these threads, though. Several people have
expressed feelings herein that are similar to mine.

> How do you  expect things to adapt and change if you won't give us
> examples?

We've made productive suggestions. People have cited specific examples.
For example,

1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.

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, one on one, to get over certain
conceptual humps.

3) To keep Steven's bloodpressure down, I suggest a new mailing list,
gcc-design, where engineers like myself can propose designs and concepts
without upsetting those who find such discussions annoying.

As it is, I now have enough information to proceed with a couple of
patches related to these dicussions. We'll see how it goes.

..Scott

Re: Porposal: Floating-Point Options

[Scott Robert Ladd]

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 the inherent inefficiency 
> it bears.
> Fortran first due to tons of well tested legacy code out there,
> C and C++ next is indeed fine.

I wasn't ordering the languages in any particular way, just noting that
they have differences. Java developers have long disliked me for a
review I wrote some years ago that pointed out Java's weaknesses in
numerical work.

> However I advise you to read for example the documentation about
> Cray C to see how this kind of stuff is handled there. Taking a look  at
> Sun's C compiler will not hurt as well to see how a FPU which is quite  unique
> get's handled.

Thank you for the pointers.

..Scott

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

[Scott Robert Ladd]

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 isn't so much a matter of being "scared away" as it is of deciding
where to allocate one's "free" resources.

I prefer to apply my energies to situations where there is a good chance
of success; a negative comment by a bugmaster makes it less likely that
my efforts on that bug will bear fruit. It's a cost-benefit analysis for me.

As for people being grateful -- well, that's why I'm here. Despite
certain people here who have low opinions of my abilities, there are
some folk who appreciate my work.

..Scott

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

[Scott Robert Ladd]

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 report is not closed, then I think it often happens
> that people who will prepare a patch will look into the report, even
> with the comments from a bugmaster.  I know I do it that way, and I
> know other people more knowledgeable of GCC tham me do it that way too.
> When I find a bugmaster's comment incorrect, I say it for the record.
> 
> I think you'd need to be more careful in your generalization.

More precisely, then:

An objection from one of the bugmasters *is* enough to keep some people
who are new to GCC from presenting a patch.

Ugh. An inelegant sentence, but perhaps more accurate.

..Scott

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

[Scott Robert Ladd]

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. Many of the people
who work on GCC are employed or funded by corporations or institutions
with Linux interests -- or these developers have companies of their own
that sell services related to GCC.

And that's a Good Thing, in my opinion. I've been paid on a few
occassions to work on GCC, although it has usually been limited ($150
for fixing a bug critical to a friend's work, for example). If you look
at past threads, requests for new features are often met with "where's
the funding?" responses.

That's not to say that all, or even most, GCC developers are
mercenaries. There exist other motivations for working on GCC --
expanding ones skills, academic curiosity, the desire to help an ignored
consituency -- yet people do have families to feed, iguanas to house,
and cars to fix. And those other motivations can often be satisfied by
volunteering to work on other projects.

My entire immediate family works for the Red Cross, both on their
payroll and as volunteers. They have a very small paid staff, funded by
donations from interested parties; much of their work is carried out by
volunteers, and the Red Cross tries very hard to respect, train, and
thank volunteers.

It's a good model.

..Scott

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

[Scott Robert Ladd]

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 - bugs get fixed because either someone feels resposible,
> it's too easy to do, or someone has personal interest in getting the
> bug fixed.  Negative or positive comments do not change this.

When a bugmaster posts a pejorative response, it strongly implies that
any effort in patch will be rejected or ignored.

I know for a fact that several people have been chased away from working
on GCC by the pithy attitudes of some GCC developers. Heaven knows why I
stick around and keep trying to help out; it must be a perverse stubborn
streak, akin to masochism. ;)

Why go through the effort of creating a patch when it is likely to be
rejected or ignored? I don't get paid to fix GCC bugs, and if a bug does
not affect my code personally, I have little incentive but the goodness
in my heart to fix bugs that affect other people's code.

Mark has a valid concern: Why aren't bugs being fixed? One answer is:
The GCC community is often less than welcoming, friendly, and helpful.

You may not like or believe the answer, but if you want more people to
help GCC for free, an attitude adjustment may be required on your part.
It's not as if there aren't many other challenging projects for people
to participate in.

..Scott

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

[Scott Robert Ladd]

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 objection from one of the bugmasters *is* enough to keep people
from presenting a patch. While the may not explicitly close the bug,
their negative reaction tends to suggest that they would not look
favorably on a patch.

..Scott

Re: Porposal: Floating-Point Options

[Scott Robert Ladd]

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

> Making the code generated by GCC somehow but not 100% compliant with
> some idealistic standard, will just increase the scope of the
> analysis you  will have to face. And in esp. changing behavior
> between releases will  just make it even worser.

Perhaps my understanding of math isn't as elite as yours, but I do know
that "worser" isn't a word. ;)

Then again, I *am* the fellow who started a thread with "Porposal" in
the title. It sounds like I'm making a suggestion about dolphins... :)

> Only the following options would make sense:
> 
> 1. An option to declare 100% IEEE compatibility if possible at all on
>  the particular arch, since it's a well known reference.
> 
> 2. An option to declare 100% FPU architecture exposure.
> 
> 3. A set of highly target dependent options to control some well
> defined features of a particular architecture. (Rounding mode,
> controll, use of MMX or SSE[1234567] for example...)

I would replace 3 above with:

3. When compiled without either of the above options, adhere strictly to
the relevant language standard.

Given that Java, Fortran 95, C and C++ all have differences in their
definitions of floating-point, this will need to be (as it already is,
to some extent) language-specific.

> Any kind of abstraction between point 1. and 2. and I would see
> myself analyzing the assembler output to see what the compiler
> actually did anyway.

On further reflection, I don't see how a middle ground can even be
defined. The three states above seem to make sense: IEEE, hardware, or
language standard.

> And last but not least: Most of this isn't really interesting at the 
> compilation unit level at all. This is the completely uninteresting
> scope. If anything one should discuss about the pragma directive
> level, since this is where fine control of numerical behavior happens
> in the world out there. The ability to say for example:
> 
> #pragma unroll 4 sturd 8
> 
> would be really of "infinite" more value then some fancy -fblah-blah.

GCC seems to have a fancy for options, since that is what most people
ask for. I agree that a set of "tuning" pragmas would be a good way of
defining the compilation requirements for a given algorithm.

I'm always open to friendly, intelligent conversation. Starting off by
being high-handed and insulting (as you did) accomplishes nothing.

..Scott

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

[Scott Robert Ladd]

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 doesn't prevent GCC from being *better* than
>>specified, does it? Are we somehow breaking ISO compliance by doing
>>math right? Is it so wrong to try and fix a problem that frustrates
>>many people and makes GCC look bad?
> 
> Where exactly do I say that it is wrong to provide a patch that makes GCC
> better in this regard? As a bugmaster, I just decided to consider this not a
> bug, in the strictest meaning of "bug". If you want to file in Bugzilla an
> enhancement proposal about adding options/modes about higher FPU precision, I
> would not object.

I've been suggesting various ways to enhance, or at better delineate,
floating-point in GCC. Once I've got a good idea of the best way to
approach this (and I've had some excellent feedback), I will indeed
submit a patch. I even have one started...

Given the number of "duplicate filings" associated with 323, I assumed
that filing another item on the topic would be ineffective.

> Also, it seems you have the wrong belief that, if bug 323 were confirmed in
> Bugzilla, a patch would automatically appear.

No; my objection is to having people's concerns flatly rejected. It is
not clear from reading the message on 323 that a "add an option" patch
would be considered.

If anything, I'm very pleased with the way people have handled the bugs
I've reported; all but one (or more than 20) have been fixed. Good stuff.

>>With the attitude shown by Giovanni, there's really no point in
>>submitting a patch, is there? Dozens of people have reported this
>>problem, potential solutions exist, but any patch is going to be
>>ignored because the bug isn't considered a bug by the Powers That Be.
> 
> You seem to believe that a patch can be accepted in GCC only if it fixes a 
> bug.

No, my experience is that a patch is only accepted if it has already
been approved, at least on a conceptual level. I've tried the "make a
patch without talking to anyone" approach, and wasted a lot of time.

> I hope to have clarified my position.

And I mine.

..Scott

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

[Scott Robert Ladd]

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!

And I'm burbling with joy!

Well, maybe not *that* enthused... :)

..Scott

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

[Scott Robert Ladd]

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 circles about if option
> a or option b is better, and which will lead to slowdowns, or intrusive
> changes, or whatever.

I'm more interested in "Does doing A make any sense?"

An example: In its formative stages, gfortran had a problem with certain
kinds of constants. Whether the problem needed to be solved depending on
how strictly one read the standard.

I simply went ahead and wrote a patch (actually, three of them), trying
to satisfy all sides involved. This resulted in long discussions of
whether the problem really *was* a problem or not. In the end, the
compiler was modified to behave as other Fortran 95s do (which was my
original suggestion, before people started quoting the standard), and I
wasted much of the time spent writing the original patch.

Had the problem been talked out in the beginning, I could have spent
more time working on an acceptable solution. This is one incident that
lead me to stop submitting patches; I have only so much time for GCC,
and am donating all of it out of my own pocket. Maybe others can afford
to do that, but I can't, after three months in the hospital followed by
an injury to my wife. If I'm going to contribute to GCC, it needs to be
something I know will be more than just a shot in the dark.

> While it's briefly annoying to write code which then isn't used
> the first time you do it, I've quickly learned it's faster and easier
> than extensive discussions, and most good code will go through 3 or 4
> iterations before it finally settles, and need a whole bundle of tests
> writing, so writing an initial test version is not actually that big a
> time investment compared to the total amount of time something will
> take. Working code is also of course by far the most convincing argument
> :).

Perhaps I'm too steeped in being an engineer, but in my experience,
quality upfront discussion saves a lot of time and produces better
results. I'd hate to build a bridge the way you suggest developing GCC.

..Scott

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

[Scott Robert Ladd]

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 contributions is a great
way of driving away potential contributors.

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*.

..Scott

Re: Porposal: Floating-Point Options

[Scott Robert Ladd]

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 -std=c99/c++98 -pedantic, and any deviation
should require specification of an option.

I have offered to make such a patch (in fact, I have one sitting
around), but the response was somewhat tepid.

> I think it would be simpler to think about individual compiler
> "behaviors" related to floating-point code generation and group
> them into classes later. I've said "behaviors", not "options",
> since pragmas (standard or not) could be used to get different
> behaviors.

Okay, the light went on. Must be the lingering effects of anaesthesia. :)

I need to do some thinking and studying.

..Scott

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

[Scott Robert Ladd]

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, someone has to fix the bugs before the users see benefit.

I wish I could do more, which is why I made (what I hoped were)
constructive suggestions for trying to get more people involved in
fixing bugs.

True, there are many lazy people who don't want to learn anything. I'm
more interested in attracting the people who, like myself, simply need
help getting around the more obscure corners of GCC. I still think that
Gentoo-style mentoring could be successful.

> Once I get my automated GCC bug-fixing bot finished I am going to have
> an easy life.  Unfortunately, I use GCC to build the bot, and I'm
> getting an ICE in reload...

Such software would make you rich beyond the dreams of avarice.

..Scott

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

[Scott Robert Ladd]

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 submitted under a switch. For
> example on a machine like the Alpha, the impact of following these
> recomendations is severe degradation of performance.

Agreed. I never said it should be a default option.

> Compilers are complex beasts, I don't think you would expect to be able
> to wade in and fix nuclear reactors without being somewhat of a nuclear
> reactor expert. You can't expect to wade in and fix compilers without
> being reasonably compiler literate. For those who are compiler literate,
> GCC is certainly accessible. Sure, it could be made more accessible,
> principally by adding more documentation. Patches to add correct useful
> additional documentation are definitely welcome.

That is exactly my point. Mark chastises people for talking about
testing, implying that we are lazy for not providing patches. Perhaps
some of us wish to contribute to GCC, but lacking the knowledge to patch
the compiler, we perform testing and make bug reports.

> These definitions are actually very clear, certainly they could not
> be written in some normal programming language since they are essentially
> denotational semantic definitions, for which a language like C would be
> perfectly horrible. You need to invest the effort to fully understand
> the machine definition language before you can do anything in this
> area, and it is hard to see how it could be otherwise.

Clear to you, but not to many other bright people. And I have *never*
said there is no requirement for learning, or even criticized the
language of the machine definition files. I am saying that Mark can't
complain about a lack of bug-fixers when big-fixing is non-trivial
(which I believe agrees with your point.)

> There is no gentle way to become involved in any compiler, they are complex
> beasts, and require a considerable investment of effort.

Nope. Gentleness comes in many forms, and includes being polite to
newbies, not condescending. Providing mentors to work with people on
specific questions would do wonders for teaching GCC internals.

> I know of no bug (i.e. behavior non-conformant with ISO C) that someone
> has said should not be fixed.

No, what they do is redefine the bug such that it is no longer a bug.
Certain U.S. Presidents are quite fond of this tactic, recategorizing
things to avoid dealing with them. Bug 323 is an example of how GCC does
this.

> ANything to make it more welcoming and helpful is of course desirable, but
> I think you are expecting too much if you expect an artifact of this
> inherent complexity to be easily accessible, especially to people without
> reasonably comprehensive training (i.e. at least a familiarity with
> compilers > at the dragon book level, and reading some of the crucial papers 
> in the
> area).

I don't deny that reality. Mark seems to feel that fixing bugs is as
easy as testing and bug reporting, and it is not. Yet people then
complain that people don't file enough bugs! It seems that no matter
what someone "outside" tries to contribute, it isn't "right".

If you want more people fixing bugs, it requires patience and respect.

..Scott

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

[Scott Robert Ladd]

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 disagree, and I think you should invest the effort
> before you hazard an opinion here. Compilers are complex beasts, and
> all involve intermediate languages, and of course these intermediate
> languages must be learned before you can do anything.

Testing and bug reporting are ways people can contribute to GCC if they
haven't the time or knowledge to effect repairs themselves.

GCC isn't special; all areas of specialized knowledge have steep
learning curves, and I'm certain I could find applications that would
mystify GCC's illuminati.

Lowering the learning curve would bring in more GCC developers and get
bugs fixed faster. I know quite a few very bright people who find GCC's
current documentation inadquate and opaque, and the environment less
than inviting.

..Scott

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

[Scott Robert Ladd]

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)

[Scott Robert Ladd]

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 complaining because code
> generation bugs should be just reported and let the powers at be fix them.

Didn't Mark just complain that people should spend more time fixing bugs
than expecting others to do it for them? Mark complains that we already
have too many unresolved bugs, and I tend to agree. If the current
developers are so busy, it seems logical that we need more developers,
not bug reporters. Wasn;t that the gist of Mark's polite rant?

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.

In many ways, I see GCC as similar in model to the Red Cross. You have a
paid staff that handles the day-to-day business, and a horde of
volunteers who do much of the grunt work. The Red Cross provides
training and mentoring to bring people along. GCC and other free
software projects would do well to consider how non-technical volunteer
organizations succeed.

If there is a lack of people fixing bugs, don;t necessarily blame it on
people being lazy. Maybe being a volunteer GCC developer is more
difficult than it needs to be?

> Again I have not seen a simple bug report from you recently; just a simple
> this goes bonkers, this is what I want GCC to output will do.

I haven't filed many bug reports recently (though I have in the past)
because I didn't feel that the effort was justified by the result.

Not that I've given up entirely: I've recently asked about how certain
problems should be reported. For example, -floop-optimize2 is a
pessimism for many algorithms. Is that a bug, or simply a feature that
is not yet fully implemented?

..Scott

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

[Scott Robert Ladd]

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 FreeNode, it's been silent.

..Scott

Porposal: Floating-Point Options

[Scott Robert Ladd]

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, and consistency. No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason. Note that
this option can only go so far in ensuring portability, given that not
every system supports IEEE 754 floats.

-ffp-ieee754

To the best of our ability, assume and follow IEEE 754. Similar to the
above, but assuming IEEE floats and doubles. Note that IEEE 754 has been
undergoing some revision.

-ffp-balanced (default)

Balance correctness with speed, enabling performance optimizations that
may reduce portability or consistency, but which do not alter the
overall quality of results. Yeah, I know that's a bit fuzzy; formal
definition of such an option depends on categorizing existing FP code
generation (something I'm working on).

-ffp-damn-the-torpedoes-full-speed-ahead

Okay, maybe that should be something shorter, like -ffast-math or
-ffp-fast. This option enables dangerous hardware intrinsics, and
eschews all concerns about portability and consistency in the quest for
speed. The behavior is likely to be the same as the current -ffast-math.

Actually, I like *-ffp-damn-the-torpedoes-full-speed-ahead*. As
Stroustrup once said, if you're going to do somethimg ugly, it should
look ugly. ;)

..Scott

Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

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
> real users on real code.  So, it's not like we're running out of bugs
> to fix.

That's true, but several factors frustrate people who want to fix bugs.

Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323,
which was a matter of recent discussion on this list. Some rather
respectable people (e.g., Vincent Lefèvre) consider this a bug, and have
proposed solutions. Yet here's a quote from an earlier message by
Giovanni Bajo.

GB> You are mistaken, we think GCC isn't buggy about 323 because
GB> the C/C++ standards do not tell us to do better than this. If
GB> you have higher expectations about floating point and C/C++,
GB> you should file a bugreport against the C/C++ standards.

GB> Really, we can't make everybody happy. The best we can do is
GB> to adhere the international well-known ISO/ANSI standards.

The ISO Standard doesn't prevent GCC from being *better* than specified,
does it? Are we somehow breaking ISO compliance by doing math right? Is
it so wrong to try and fix a problem that frustrates many people and
makes GCC look bad?

With the attitude shown by Giovanni, there's really no point in
submitting a patch, is there? Dozens of people have reported this
problem, potential solutions exist, but any patch is going to be ignored
because the bug isn't considered a bug by the Powers That Be.

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)?

Documentation for the compiler itself is woefully inadequate for someone
"new". GCC may be old-hat to folks who've worked on it for years, but it
is very complex and foreign territory for most non-compiler experts.
Working on GCC requires a much broader knowledge than working on other
projects, and without some sort of tutorial or guidance, working on it
quickly becomes frustrating.

Here's an example: Building new targets and fixing some code generation
bugs involve changing the machine definitions, which are written in a
rather uncommon language. Frankly, I haven't figured out all the nuances
yet, mostly because I don't have the luxury of studying it, and I can't
find any clear and comprehensive documentation.

Gentoo provides a mentoring system for developers. This is far better
than GCC's "fix it yourself and send us the code" policy. There is no
gentle way to become involved in GCC; it's a sink-or-swim, trial by fire
environment. If I could get a half-dozen quick questions answered, and I
could submit a couple of patches that are lying about on my hard drive.

For that matter, Gentoo also has some very excellent IRC channels that
provide a lot of help, and usually *friendly* help at that. The GCC
mailing lists are useful, but there's nowhere to go and have a quick
chat about "this is confusing the heck out of me" or "how do I approach
this problem."

I have submitted patches; I have tried to help with various aspects of
GCC. I make no claim to having accomplished anything great, but I have
tried, and watched patches die of bit rot while being told that certain
bugs shouldn't be fixed.

Everything in life is a matter of give and take. People report bugs; you
want someone to fix the bugs -- perhaps GCC should be more welcoming and
helpful.

..Scott

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

[Scott Robert Ladd]

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 universe
about glibc; perhaps this page might be of interest:

http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks

..Scott

Re: Big differences on SpecFP results for gcc and icc

[Scott Robert Ladd]

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 critical loop has different optimization
characteristics -- what improves performance on algorithm A may degrade
performance on algorithm B. See my Acovea work for many supporting examples.

My conclusion is the composite switches like -O2 are good only for
general-purpose code. Anyone explicitly interested in squeezing out the
most performance needs to do analysis and use application-specific switches.

..Scott

Re: A Suggestion for Release Testing

[Scott Robert Ladd]

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-generation problem with KDE, and
questions I received from a couple of kernel developers who experienced
problems.

I'm not certain my suggestion is practical; it was just an idea.

..Scott

Re: Big differences on SpecFP results for gcc and icc

[Scott Robert Ladd]

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 big fan of Spec; too many compilers focus specifically on
getting good spec numbers at the expense of other tests, just like video
card manufacturers focus on getting Doom 3 running fast while failing to
perform well on other applications.

That said, I know that ICC consistently produces fast code for
computationally bound applications, on the Pentium 4 at least. This
includes real-world applications like video codecs, where ICC often
produces code that is 10-15% faster.

The paper I'm working on takes a slightly different view of floating
point, and will include some "different" benchmarks.

..Scott

Re: A Suggestion for Release Testing

[Scott Robert Ladd]

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.

> ...it would certainly be good for release testing if we built
> complete distros, or significant chunks thereof.  It would be even
> better if this could be coordinated with the people producing all
> that software; I think that (for example) GCC and KDE could both do
> better about trying each others' early code sooner than we do, and
> communicate any problems found.

I'm hoping that creating a formal "core software" test might foster some
of that communication. We have to start somewhere.

..Scott

Re: A Suggestion for Release Testing

[Scott Robert Ladd]

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/
> http://www.linuxfromscratch.org/
> http://www.diy-linux.org/

Of course there are several source-based distributions, but that's not
what I'm talking about. While they may do individual testing when a new
GCC release appears, I'm talking about a formal testing process, where
GCC would be regularly tested during development to ensure that nothing
unexpected is broken. Breaking KDE or the kernel demonstrates a serious
problem in a release, for example.

The test suite can check individual tests, but what may be needed is a
comprehensive test across several applications that comprise a whole.
Certainly GCC would be the better for being able to effectively compile
Linux, KDE, Gnome, Apache, and other "core" programs.

..Scott

Floating-Point, Round 2

[Scott Robert Ladd]

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 summary here for discussion.

If anyone has any thoughts on the topic, please e-mail me so I can
consider all viewpoints.

..Scott

A Suggestion for Release Testing

[Scott Robert Ladd]

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, running in a chroot,
that would rebuild a "standard" Linux install with a pending release of
GCC. The suite of applications would need to be relatively tight; I'd
suggest Linux, Gnome, KDE, their major appliations, and perhaps OpenOffice.

The downside is that the compile would take quite a while; even for my
dual Opteron, full builds take more than a day. On the other hand, this
might catch some problems before release.

I'm willing to implement this, if it's deemed useful.

..Scott

Re: Will Apple still support GCC development?

[Scott Robert Ladd]

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
>> this is rather uninteresting to general audience.

In general, the choice of compiler is unimportant for the performance of
most user-bound programs. I doubt KDE would run much faster if compiled
with ICC, for example.

However, for codecs, image processing, and other math-intensive
operations, Intel generally produces faster code, though
not always. This isn't just a matter of floating-point generation --
Intel's vectorizer gives their compiler a distinct advantage over GCC,
although I expect GCC to catch up in this regard.

Rather than speculate about Apple, it would be better to find more
funding for GCC development. I know that some people are working on this.

..Scott

Re: Will Apple still support GCC development?

[Scott Robert Ladd]

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
> componentry of GCC, or will such contributions be phased out as the
> transition is made to the x86-based systems? In turn, will Apple be
> providing more x86-related contributions to GCC?

A better question might be: Has Intel provided Apple with an OS X
version of their compiler? If so (and I think it very likely), Apple may
have little incentive for supporting GCC, given how well Intel's
compilers perform.

..Scott

Re: Tracking down gcc-4.0 performance regressions

[Scott Robert Ladd]

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
> performance regession first.  Has anyone else already done that?
> I'd hate to repeat work.

I've found a couple of other performance regressions on various
applications. Acovea is very good at narrowing the cause of regressions
to specific GCC options.

Should reports be made against 4.0, or against 4.1?

Also, I'm not certain how to classify "options that don't work as
expected" -- for example, -floop-optimize2, which is a pessimisim on
many tests with 4.0.0.

..Scott

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

[Scott Robert Ladd]

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 chair,
if memory serves.

In fact, NCEG *did* improve C's numerics if one uses the
Zortech/Symantec/Digital Mars compiler. I know, because I wrote a
90-page manual on numerical computing for Zortech/Symantec. I haven't
looked at Digital Mars C, but I believe it still supports the proposed
NCEG extensions.

Only a few fragments of NCEG's work made it into C99, much to my
disappointment. I suppose it would be possible to implement NCEG in GCC,
but I doubt anyone would pay for the work involved -- yet I'd love to
have a -ffloat-nceg on platforms that could support it.

If anyone's curious, I have a PDF of that old manual of mine I can make
available. I don't have any electronic copies of the NCEG documents,
unfortunately, but my book covers pretty much everything.

..Scott

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

[Scott Robert Ladd]

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 "result" portability.

If you follow Standard C, you are guaranteed source code portability, in
the program compiles and produce the "same" results with any Standard C
compiler.

When we start talking about floating-point code, however, we enter the
realm of "result" portability, in that different platforms (or different
compiler swicthes) return slightly different numbers from the same
source code.

An example of this is the use of long double, the implementation of
which differs from platform to platform. On Intel-inspired processors, a
long double is 80 bits long with a 64-bit mantissa, corresponding to the
x87 registers. On other systems, long double may be the same as double,
having 64 bits and a 53-bit mantissa. Calculations with 80-bit long
doubles will differ from the same computations performed using 64-bit
long doubles.

C does not enforce identical results on all platforms; Java does (or at
least tries to).

It's an easy problem to get tripped by, as I recently experienced on
this forum.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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) else nothing will
> happen, and if you choose to subtract some large multiple of 2*pi, your
> answer wouldn't end up accurate to anywhere near that many decimal
> places. Floating point numbers approximate real numbers, and at the size
> you are considering, the approximation contains values for which sin(x)
> takes all values in the range [-1,1].

Nonsense.

Show me an example where the following function should *not* print the
same values for a and b:

void same_sines(double x)
{
double a = sin(x);
double b = sin(fmod(x, 2.0 * PI));
printf("%20.15f,%20.15f\n",a,b);
}

Granted, -funsafe-math-optimizations *will* produce different values for
certain values, such as x = pow(2.0,90.0), on x87 hardware, but that is
an error in computing a, not a violation of principle.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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
shouldn't be able to use it for *my* application.

I asked for one very simple thing that in no way breaks any code for
anyone: A better break down of floationg-point switches to better serve
diverse users.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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

[Scott Robert Ladd]

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(x)?

Using an earlier example in these threads, do you deny that
sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
sin(-1.130044672903051) -- assuming no use of
-funsafe-math-optimizations, of course?

Shall we mark all potentially troublesome optimizations as "unsafe", and
chastise those who use them? Quite a few combinations of options can
cause specific applications to fail, and other programs to work very
well. Under such logic, we should replace -O3 with -Ounsafe, because
some programs break when compiled with -O3.

Since that's patently silly, perhaps we should be more concerned with
making useful choices and improvements to GCC.

> You can decide to restrict this stuff to plain old 2D geometry, and this would
> be fine for teaching in elementary school, but this makes absolutely 
> no sense with respect to any kind of modern mathematics.

The fact that trigonometric functions can extended beyond 2D geometry in
no way invalidates their use in their original domain. I've written many
2D and 3D applications over the years without need for a sine outside
the range [0, 2*PI] (or [-PI, PI] in some cases). Some people live and
die by one of those programs, and no one's died yet because I used
-ffast-math in compiling it.

(I expect Gabriel dos Rios to respond with something pithy here; please
don't disappoint me!)

I keep saying that GCC can and should support the different needs of
different applications. What is wrong with that?

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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(x)?

Using an earlier example in these threads, do you deny that
sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
sin(-1.130044672903051) -- assuming no use of
-funsafe-math-optimizations, of course?

Shall we mark all potentially troublesome optimizations as "unsafe", and
chastise those who use them? Quite a few combinations of options can
cause specific applications to fail, and other programs to work very
well. Under such logic, we should replace -O3 with -Ounsafe, because
some programs break when compiled with -O3.

Since that's patently silly, perhaps we should be more concerned with
making useful choices and improvements to GCC.

> You can decide to restrict this stuff to plain old 2D geometry, and this would
> be fine for teaching in elementary school, but this makes absolutely 
> no sense with respect to any kind of modern mathematics.

The fact that trigonometric functions can extended beyond 2D geometry in
no way invalidates their use in their original domain. I've written many
2D and 3D applications over the years without need for a sine outside
the range [0, 2*PI] (or [-PI, PI] in some cases). Some people live and
die by one of those programs, and no one's died yet because I used
-ffast-math in compiling it.

(I expect Gabriel dos Rios to respond with something pithy here; please
don't disappoint me!)

I keep saying that GCC can and should support the different needs of
different applications. What is wrong with that?

..Scott

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

[Scott Robert Ladd]

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 be
rather tame, I think. ;)

Probably wishful thinking, though. ;)

..Scott

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

[Scott Robert Ladd]

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, not its developers.)

I have some thoughts on GCC customer support that would likely help both
developers and users, but I need to get my ducks in a row before I start
them quacking.

> I guess that these persons don't know that bugreports are extremmely
>  important for the development of gcc. The users themself are
> actaully a QA department of open source development;)

Asking users to do QA makes for poor relationships and quality, whether
we're talking about proprietary or free software. Ask anyone who
purchased a game like Dungeon Lords... ;)

Now, you can argue that people's expectations are unrealistic, and I
will agree with you, but we all know that the ideal situation is
only rarely reflected in reality.

>> However, the atmosphere of GCC development is... well, let's just 
>> say that my investment in asbestos underware has not been wasted. 
>> ;)
>> 
> I would call it an atmosphere of brainstorming. Different opinions 
> and different point of views. The only problem is, that words can be
>  different if people sit 3000 km/miles/whatever apart ;)

Brainstorming there may be, but certain folk in the GCC community simply
like being annoying, perhaps to feed their own sense of self-importance.
It is quite possible to disagree with someone without be disagreeable,
as exemplified by Evandro Menezes recently.

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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 
> .
> 
> Unfortunately this never got followed up properly by defining 
> separate preprocessor macros for each option, so if you use the 
> individual options then glibc headers checking __FAST_MATH__ may not 
> enable optimizations which would in fact be safe with the subset of 
> options specified.

Which implies, of course, that breaking -funsafe-math-optimizations into
components involves modifying glibc for corresponding __???_MATH__
definitions.

The separation of glibc and GCC leads to many problems not faced by
commercial compilers; not only can a commercial compiler focus on a
single platform, it also ships a C library as an integral part of the
compiler package. Thus a commercial compiler, with a narrow focus, can
ensure that the C library tracks changes in the compiler, while such is
not the case with GCC.

GCC ships with an integral Standard C++ library; it seems to me that it
could also provide a Standard C90/99 library as well. But I suspect that
is a kettle of fish that should stay closed. ;)

> And as the current discussion illustrates, 
> -funsafe-math-optimizations itself has become a catch-all for many 
> different optimizations, such as -ffast-math was.

Breaking up -funsafe-math-optimizations would also require a policy for
how future optimizations should be organized, lest we end up right where
we started with one option that implies many things.

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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 simply too much effort to identify all the transformations? Did the
GCC community fail to come to a consensus? Or was it simply -- as I'm
coming to suspect -- that the work involved is not justified by the result?

I do know this: Many, many scientific and mathematical programmers find
GCC frustrating and annoying, and most of those folk know far more about
numbers than I do. I wish more of these people would feel comfortable
posting to the GCC list, rather than sending private e-mails to my
inbox. However, the atmosphere of GCC development is... well, let's just
say that my investment in asbestos underware has not been wasted. ;)

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 people in this thread, you've been
both eloquent and polite; thank you.

I still maintain that hardware fsin and fcos are valid and valuable for
certain classes of applications, and that we need better options and
documentation -- both of which I'm more than happy to work on. I look
forward to your future comments.

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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
> currently do would be a start.  And it would aid at finding useful
> subclasses of transformations.  As well as then having documentation
> by enumerating of (current) transformations together with the switches
> that affect them.

This is where I've already started, just trying to get an idea of what
is going on inside the compiler. Is there any documentation of this sort
already? I think I know the answer to that question, but figure it
doesn't hurt to ask... ;)

I'm likely to pull my old UltraSPARC out of retirement (it hasn't been
turne don in months), just so I have something other than x86_64 and x86
to look at.

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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, and relatively quickly, but as I said
in a prior message, I need some sort of assurance that I wouldn't be
wasting my time.

I can post a suggested set of switches and their meanings? We could
actually document what the switches do *before* implementing them.

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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: Sine and Cosine Accuracy

[Scott Robert Ladd]

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: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 my check balance to x87 microcode... ;-)

I wouldn;t trust my bank accounts to the x87 under any circumstances;
anyone doing exact math should be using fixed-point.

Different programs have different requirements. I don't understand why
GCC needs to be one-size fits all, when it could be *better* than the
competition by taking a broader and more flexible view.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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
existing code base of non-standard code, such a change may be unrealistic.

I'm willing to make the "-ansi -pedantic" patch, if I wouldn't be
wasting my time.

What about separating hardware intrinsics from
-funsafe-math-optimizations? I believe this would make everyone happy by
allowing people to use the compiler more effectively in different
circumstances.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 in the range [0, 2*PI),
at least according to the tests I published earlier in this thread. If
you think there is something erroneous in the test code, I sincerely
would like to know.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 therefore
> those functions can be applied to things that are not just "angles". 

To paraphrase the above:

"Yeah, the problem with people who only work with Fourier series is that
they tend to forget that sin (and friends) can be used in applications
with angles that fall in a limited range, where the hardware intrinsics
produce faster and more accurate results."

I've worked on some pretty fancy DSP code in the last years, and some
spherical trig stuff. Two different kinds of code with different needs.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 applications.
> 
> 
> Whether you think it necessary or not, the ISO C functions allow
> such arguments, and we're not allowed to break that without cause.

Then, as someone else said, why doesn't the compiler enforce -ansi
and/or -pedantic by default? Or is ANSI purity only important in some
cases, but not others?

I do not and have not suggested changing the default behavior of the
compiler, and *have* suggested that it is not pedantic enough about
Standards.

*This* discussion is about improving -funsafe-math-optimizations to make
it more sensible and flexible.

For a wide variety of applications, the hardware intrinsics provide both
faster and more accurate results, when compared to the library
functions. However, I may *not* want other transformations implied by
-funsafe-math-optimizations. Therefore, it seems to me that GCC could
cleanly and simply implement an option to use hardware intrinsics (or a
highly-optimized but non-ANSI library) for those of us who want it.

No changes to default optimizations, no breaking of existing code, just
a new option (as in optional.)

How does that hurt you or anyone else? It's not as if GCC doesn't have a
few options already... ;)

I (and others) also note other compilers do a fine job of handling these
problems.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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.
> 
> The world is flat; I never quite understood the necessity of spherical
> trigonometry.

For many practical problems, the world can be considered flat. And I do
plenty of spherical geometry (GPS navigation) without requiring the sin
of 2**90. ;)

..Scott

Re: GCC and Floating-Point

[Scott Robert Ladd]

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 try to be as fast as possible.

Perhaps we need something along these lines:

When -ansi or -pedantic is used, the compiler should disallow anything
"unsafe" that may break compliance, warning if someone uses a paradox
like "-ansi -funsafe-math-optimizations".

As has been pointed out elsewhere in this thread,
-funsafe-math-optimizations implies too many different things, and is
vaguely documented. I'd like to see varying levels of floating-point
optimization, including an option that uses an internal library
optimized for both speed and correctness, which are not mutually exclusive.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 it went to a private mail).

The documentation should quote you above, instead of being general and
vague (lots of "mays", for example, in the current text).

Perhaps we need to have a clearer name for the option,
-funsafe-transformations, anyone? I may want to use a hardware
intrinsics, but not want those transformations.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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
-- however, the current documentation is quite vague as to why these
optimizations are unsafe, and people thus become paranoid and avoid
-ffast-math when it would be to their benefit.

First and foremost, GCC should conform to standards. *However*, I see
nothing wrong with providing additional capability for those who need
it, without combining everything "unsafe" under one umbrella.

> But you can't just replace a call to the ANSI C 'sin' function with an
> invocation of the x87 fsin intrinsic, because they aren't the same, and the
> intrinsic is non-ansi-compliant.

Nobody said they were.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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.

I'll correct myself to say "people who know their application." ;) Some
apps need sin() over all possible doubles, while other applications need
sin() over the range of angles.

> What *may* make sense is the creation of a new option (off by default)
> that says "you're allowed to assume that all calls to trig functions
> have arguments in the range x..y".  Then the question to be answered
> is what x and y should be.  A possible answer is 0 and 2pi; another
> answer that some might prefer is -pi to +pi.  Or it might be -2pi to
> +2pi to accommodate both preferences at essentially no cost.

I prefer breaking out the hardware intrinsics from
-funsafe-math-optimizations, such that people can compile to use their
hardware *without* the other transformations implicit in the current
collective.

If someone can explain how this hurts anything, please let me know.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 some do, and I've never encountered them!

As such, I was sticking to a discussion specific to reals.


> And there is the answer to your question: if you just think of "sin"
> as something
> with angles and triangles, then sin(2^90) makes very little sense.  But "sin"
> occurs other places where there are no triangles in sight.

That's certainly true; the use of sine and cosine depend on the
application. I don't deny that many applications need to perform sin()
on any double value; however there are also many applications where you
*are* dealing with angles.

I recently wrote a GPS application where using the intrinsics improved
both accuracy and speed (the latter substantially), and using those
intrinsics was only "unsafe" because -funsafe-math-optimizations
includes other transformations.

I am simply lobbying for the separation of hardware intrinsics from
-funsafe-math-optimizations.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 appear to be
> quoting a statement that says

Perhaps I didn't say it as clearly as I should, but I do indeed know the
difference between the implementation and definition of the
trigonometric identifies.

The tradeoff is between absolute adherence to the C standard and the
need to provide fast, accurate results for people who know their math.
What I see is a focus (in some areas like math) on complying with the
standard, to the exclusion of people who need speed. Both needs can be met.

> And in fact, and in any case, this is a perfect illustration of the point,
> because what we're discussing here is *not* the behaviour of the
> mathematical sine and cosine functions, but the behaviour of the C runtime
> library functions sin(...) and cos(...), which are defined by the language
> spec rather than by the strictures of mathematics.

The sin() and cos() functions, in theory, implement the behavior of the
mathematical sine and cosine identities, so the two can not be
completely divorced. I believe it is, at the very least, misleading to
claim that the hardware intrinsics are "unsafe".

> And that spec makes *no*
> restriction on what values you may supply as inputs, so gcc had better
> implement sin and cos in a way that doesn't require the programmer to have
> reduced the arguments beforehand, or it won't be ANSI compliant.

I'm not asking that the default behavior of the compiler be non-ANSI;
I'm asking that we give non-perjorative options to people who know what
they are doing and need greater speed. The -funsafe-math-optimizations
encompasses more than hardware intrinsics, and I don't see why
separating the hardware intrinsics into their own option
(-fhardware-math) is unreasonable, for folk who want the intrinsics but
not the other transformations.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 as a mathematician in this case, not
a programmer. Pick up an trig book, and it will have a statement similar
to this one, taken from a text (Trigonometry Demystified, Gibilisco,
McGraw-Hill, 2003) randomly grabbed from the shelf next to me:

"These trigonometric identities apply to angles in the *standard range*
of 0 rad <= theta < 2 * PI rad. Angles outside the standard range are
converted to values within the standard range by adding or subtracting
the appropriate multiple of 2 * PI rad. You might hear of an angle with
negative measurement or with a measure more than 2 * PI rad, but this
can always be converted..."

I can assure you that other texts (of which I have several) make similar
statements.

> Yes, normally the first step is to reduce the arguments to a small
> range around zero and then do the series expansion after that, because
> the series expansion convergest fastest near zero.  But sin(100) is
> certainly a valid call, even if not a common one.

I *said* that such statements are outside the standard range of
trigonometric identities. Writing sin(100) is not a matter of necessity,
nor should people using "regular" math be penalized in speed or accuracy
for extreme cases.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 loop is required with their use.

Yes, but within the defined mathematical ranges for sine and cosine --
[0, 2 * PI) -- the processor intrinsics are quite accurate.

Now, I can see a problem in signal processing or similar applications,
where you're working with continuous values over a large range, but it
seems to me that a simple application of fmod (via FPREM) solves that
problem nicely.

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.

..Scott

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

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 trial.java --main=trial -ffast-math   
> zapata:~ $ ./a.out 
> -0.9044312486086016

You're comparing apples and oranges, since C (my code) and Java differ
in their definitions and implementations of floating-point.

I don't build gcj these days; however, when I have a moment later, I'll
build the latest GCC mainline from CVS -- with Java -- and see how it
reacts to my Java version of my benchmark. I also have a Fortran 95
version as well, so I guess I might as well try several languages, and
see what we get.

..Scott

Sine and Cosine Accuracy

[Scott Robert Ladd]

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

  cumulative accuracy:   60.830074998557684 (binary)
 18.311677213055471 (decimal)

-lm -O3 -march=k8 -mfpmath=387

  generates:
  call sin
  call cos

  cumulative accuracy:   49.415037499278846 (binary)
 14.875408524143376 (decimal)

-lm -O3 -march=k8 -funsafe-math-optimizations

  generates:
  call sin
  call cos

  cumulative accuracy:   47.476438043942984 (binary)
 14.291831938509427 (decimal)

-lm -O3 -march=k8

  generates:
  call sin
  call cos

  cumulative accuracy:   47.476438043942984 (binary)
 14.291831938509427 (decimal)

The default for Opteron is -mfpmath=sse; as has been discussed in other
threads, this may not be a good choice. I also note that using
-funsafe-math-optimizations (and thus the combined fsincos instruction)
*increases* accuracy.

On the Pentium4, using the same version of GCC, I get:

-lm -O3 -march=pentium4 -funsafe-math-optimizations

  cumulative accuracy:   63.000 (binary)
 18.964889726830815 (decimal)

-lm -O3 -march=pentium4

  cumulative accuracy:   49.299560281858909 (binary)
 14.840646417884166 (decimal)

-lm -O3 -march=pentium4 -funsafe-math-optimizations -mfpmath=sse

  cumulative accuracy:   47.476438043942984 (binary)
 14.291831938509427 (decimal)

The program used is below. I'm very open to suggestions about this
program, which is a subset of a larger accuracy benchmark I'm writing
(Subtilis).

#include 
#pragma STDC FENV_ACCESS ON
#include 
#include 
#include 
#include 
#include 

static bool verbose = false;
#define PI 3.14159265358979323846

// Test floating point accuracy
inline double binary_accuracy(double x)
{
return -(log(fabs(x)) / log(2.0));
}

inline double decimal_accuracy(double x)
{
return -(log(fabs(x)) / log(10.0));
}

// accuracy of trigonometric functions
void trigtest()
{
static const double range = PI; // * 2.0;
static const double incr  = PI / 100.0;

if (verbose)
   printf("  xdiff accuracy\n");

double final = 1.0;
double x;

for (x = -range; x <= range; x += incr)
{
double s1  = sin(x);
double c1  = cos(x);
double one = s1 * s1 + c1 * c1;
double diff = one - 1.0;
final *= one;

double accuracy1 = binary_accuracy(diff);

if (verbose)
printf("%20.15f %14g %20.15f\n",x,diff,accuracy1);
}

final -= 1.0;

printf("\ncumulative accuracy: %20.15f (binary)\n",
   binary_accuracy(final));

printf(" %20.15f (decimal)\n",
   decimal_accuracy(final));
}

// Entry point
int main(int argc, char ** argv)
{
int i;

// do we have verbose output?
if (argc > 1)
{
for (i = 1; i < argc; ++i)
{
if (!strcmp(argv[i],"-v"))
{
verbose = true;
break;
}
}
}


// run tests
trigtest();

// done
return 0;
}

..Scott

Re: GCC and Floating-Point (A proposal)

[Scott Robert Ladd]

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 later Pentiums. Looks
like I need to run another round of tests. ;)

..Scott

Re: GCC and Floating-Point (A proposal)

[Scott Robert Ladd]

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 use of hardware intrinsics to a new -fhardware-math switch.

Richard Guenther wrote:
> I think the other options implied by -ffast-math apart from
> -funsafe-math-optimizations should (and do?) enable the use of
> hardware intrinsics already.  It's only that some of the optimzations
> guarded by -funsafe-math-optimizations could be applied in general.
> A good start may be to enumerate the transformations done on a
> Wiki page and list the flags it is guarded with.

Unless I've missed something obvious, -funsafe-math-optimizations alone
enables most hardware floating-point intrinsics -- on x86_64 and x86, at
least --. For example, consider a simple line of code that takes the
sine of a constant:

x = sin(1.0);

On the Pentium 4, with GCC 4.0, various command lines produced the
following code:

gcc -S -O3 -march=pentium4

movl$1072693248, 4(%esp)
callsin
fstpl   4(%esp)

gcc -S -O3 -march=pentium4 -D__NO_MATH_INLINES

movl$1072693248, 4(%esp)
callsin
fstpl   4(%esp)

gcc -S -O3 -march=pentium4 -funsafe-math-optimizations

fld1
fsin
fstpl   4(%esp)

gcc -S -O3 -march=pentium4 -funsafe-math-optimizations \
  -D__NO_MATH_INLINES

fld1
fsin
fstpl   4(%esp)

As you can see, it is -funsafe-math-optimizations alone that determines
the use of hardware intrinsics, on the P4 at least.

As a side note, GCC 4.0 on the Opteron produces the same result with all
four command-line variations:

gcc -S -O3 -march=k8
movlpd  .LC2(%rip), %xmm0
callsin

gcc -S -O3 -march=k8 -D__NO_MATH_INLINES
movlpd  .LC2(%rip), %xmm0
callsin

gcc -S -O3 -march=k8 -funsafe-math-optimizations
movlpd  .LC2(%rip), %xmm0
callsin

gcc -S -O3 -march=k8 -funsafe-math-optimizations -D__NO_MATH_INLINES
movlpd  .LC2(%rip), %xmm0
callsin


..Scott

Re: GCC and Floating-Point (A proposal)

[Scott Robert Ladd]

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 lots of codes fail.

Perhaps what needs to be changed is the definition of -ffast-math
itself. Some people (myself included) view it from the standpoint of
using the full capabilities of our processors' hardware intrinsics;
however, -ffast-math *also* implies the rearrangement of code that
violates Standard behavior. Thus it does two things that perhaps should
not be combined.

To be more pointed, it is -funsafe-math-optimizations (implied by
-ffast-math) that is in need of adjustment.

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 use of hardware intrinsics to a new -fhardware-math switch.

Does anyone object if I experiment a bit with this modification? Or am I
completely wrong in my understanding?

..Scott

GCC and Floating-Point

[Scott Robert Ladd]

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: accuracy, precision, data organization, code
speed, threading issues, and a bit about interval arithmetic and
significant digits.

Naturally, due to hardware availability, I'll be focusing on x86 and
x86_64 systems.

I'd appreciate comments, ideas, and suggestions from the folk on this
mailing list.

Thank you.

..Scott

Re: GCC 4.0, Fast Math, and Acovea

[Scott Robert Ladd]

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-optimizations does not generate inline processor
instructions for most floating-point functions.
 

[snip]
 

It was found that moving data from SSE registers to X87 registers (and
back) only to call an x87 builtin degrades performance. Because of this,
x87 builtins are disabled for -mfpmath=sse and a normal libcall is
issued for sin(), etc functions. If someone wants to use x87 builtins,
then _all_ math operations should be done in x87 registers to avoid
costly SSE->x87 moves.
   

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 other way around on x86-64 if not
more (on my opteron with icc8.1 and beta 9.0).
Obviously there's much less pressure on the (cough weak cough)
register allocator and in the end the generated code is way leaner.
My only gripe with fast-math is that it's the only way to enable some
optimizations while making NaNs verbotten; couple that with the lack
of cross unit IPO and you're stuck with a kind of nasty "global"
switch (unless you have room for some function calls).
 

Granted, POV-Ray may not be state-of-the-art, but then, I know quite a 
few people who say that (even legitimately) about just about every 
software product in existence.

If you have a suggestion for better benchmarks, I'm listening. Is your 
ray tracer available?

..Scott

GCC 4.0 Review

[Scott Robert Ladd]

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 for GCC 4.0 on the Opteron and Pentium 4:
   http://www.coyotegulch.com/products/acovea/aco5k8gcc40.html
As always, I look forward to considered comments.
..Scott

Re: GCC 4.0, Fast Math, and Acovea

[Scott Robert Ladd]

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 other way around on x86-64 if not
more (on my opteron with icc8.1 and beta 9.0).
Obviously there's much less pressure on the (cough weak cough)
register allocator and in the end the generated code is way leaner.
 

You might want to a look at my just-published review of GCC 4.0, where I 
compare it's performance on some well-known applications, including LAME 
and POV-Ray, on Pentium 4 and Opteron. In terms of POV-Ray, 4.0 produced 
a smaller executable that was slightly slower than did 3.4.3. You can 
find the full review at:

   http://www.coyotegulch.com/reviews/gcc4/index.html
..Scott

Re: GCC 4.0, Fast Math, and Acovea

[Scott Robert Ladd]

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-point functions.

Let's put it another way: Manually selecting -mfpmath=387 cuts 
run-times by 50% for programs dependent on functions like sin() and 
sqrt(), as compared to -funsafe-math-optimizations by itself.

It was found that moving data from SSE registers to X87 registers (and 
back) only to call an x87 builtin degrades performance. Because of 
this, x87 builtins are disabled for -mfpmath=sse and a normal libcall 
is issued for sin(), etc functions. If someone wants to use x87 
builtins, then _all_ math operations should be done in x87 registers 
to avoid costly SSE->x87 moves.

BTW: Does adding -D__NO_MATH_INLINES improve performance for 
-mfpmath=sse? That would be PR19602.

Uros.

Well, on every function-intensive (i.e., using lots of sqrt(), sin(), 
and such) program I've tried, using -funsafe-math-optimizations provides 
not significant benefit on the Opteron *unless* it is combined with 
-mfpmath=387.

I note that Intel and other compilers do not seem to have this problem.
Now, I'm more than happy to live with the situation, since it has a 
simple work-around -- but I think it at least needs to be made clear in 
the GCC documentation that this situation exists. Otherwise, GCC 4.0 
looks *terribly* for many mathematical tasks on AMD64. And right now, 
AMD64 is a hot property in the mathematical circles, especially in 
clustered supercomputing.

..Scott

GCC 4.0, Fast Math, and Acovea

[Scott Robert Ladd]

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 on that platform is -mfpmath=sse. 
Without specifying -mfpmath=387, -funsafe-math-optimizations does not 
generate inline processor instructions for most floating-point functions.

Let's put it another way: Manually selecting -mfpmath=387 cuts run-times 
by 50% for programs dependent on functions like sin() and sqrt(), as 
compared to -funsafe-math-optimizations by itself.

I'm not so sure this is much a bug as it is an error in the way 
-funsafe-math-optimizations is handled. My suggestion is the 
-funsafe-math-optimizations set -mfpmath=387 on AMD64 -- otherwise, it 
is completely useless, as is (of course) -ffast-math.

For those who are interested, I've updated Acovea (my optimization 
analyzer) to version 5.0, and have published an analysis of GCC's 3.4 
and 4.0 on Opteron, where I'm finding a *consistent* 6-20% improvement 
in code speed over any -On option. You can find the main Acovea web page at:

http://www.coyotegulch.com/products/acovea/index.html
I'll be doing Pentium and other tests as time permits.
..Scott