Re: open64 versus gcc

"Greg Lindahl" <>
3 Dec 2006 21:32:51 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: open64 versus gcc (dz) (2006-11-29)
Re: open64 versus gcc (Diego Novillo) (2006-11-29)
Re: open64 versus gcc (A.L.) (2006-12-01)
Re: open64 versus gcc (A.L.) (2006-12-01)
Re: open64 versus gcc (Jonathan Thornburg -- remove -animal to reply) (2006-12-03)
Re: open64 versus gcc (Diego Novillo) (2006-12-03)
Re: open64 versus gcc (Greg Lindahl) (2006-12-03)
Re: open64 versus gcc (Brooks Moses) (2006-12-03)
Re: open64 versus gcc (Gary Oblock) (2006-12-03)
Re: open64 versus gcc (ST) (2006-12-06)
| List of all articles for this month |

From: "Greg Lindahl" <>
Newsgroups: comp.compilers
Date: 3 Dec 2006 21:32:51 -0500
Organization: Compilers Central
References: 06-11-09406-11-104 06-11-113 06-11-120 06-11-124 06-12-015
Keywords: arithmetic, GCC
Posted-Date: 03 Dec 2006 21:32:51 EST

> >For alias analysis, GCC uses a fairly sophisticated constraint-based
> >points-to analysis and complements it with type-based disambiguation.

I believe Open64 basically claims the same features. Comparing
superficial feature lists from compilers will rarely teach you much;
it's much more interesting to see how well the compiler does on
benchmarks or your favorite application.

> One of the feature out of the list of "rich features" is that the
> results of numerical computations (such as inverting large matrix or
> solving large set of linear equations) strongly depends on activated
> options, especially optimization level.

Can you name a modern optimizing compiler for which this statement
*isn't* true? I don't think there are any. If you want results which
are the same every time, most compilers list additional flags in their
documentation which inhibit optimizations that change the answer.
Almost all numerically intensive number crunching doesn't use those

-- greg
[employed by, not speaking for, QLogic Corporation]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.