This thread is becomming silly.
Sorry Patrik, but your arguments about heuristics are very strange. The
difference between a heuristic and an algorithm is that for an algorithm
one can _prove_ certain properties (such as big-O complexity, etc), where
as a heuristic has some interesting
This thread is becomming silly.
Yes.
Sorry Patrik, but your arguments about heuristics are very
strange.
The
difference between a heuristic and an algorithm is that for
an algorithm
one can _prove_ certain properties (such as big-O complexity,
etc), where
as a heuristic has some
At 11:02 AM 12/8/00 +0100, you wrote:
That said I remember reading somewhere that there are _some_
optimizations that GNU C employs at higher (like -O6)
optimization level that tries to be _too_ clever and thereby
causing it to generate wrong code for some strange cases.
-O6 has no meaning. If
On Fri, 8 Dec 2000, Patrik Stridvall wrote:
What I mean is that a "heuristic" do not cover all strange
cases like normal "algoritms" does and tries to be clever
and make assumptions on how the input usually looks like.
What you seem to miss is that there are many problems where an
optimal
In short I refer to algoritms that tries to be _too_ "clever" as
heuristics while some uses it for normal "clever" algoritms as well.
I think that's the point. Your definition is rather non-standard.
OK, well, it isn't really import for the issue at hand.
That said I remember reading
So the one and only type of optimization not done by leaving the
optmization level at -O2 (like Wine is doing), is the
'flag_inline_functions'
- from the only piece of code using it, it seems that
flag_inline_functions
is making the compiler trying to inline a function even if
the
On Wed, 6 Dec 2000, Patrik Stridvall wrote:
I think we have different definitions of heuristics.
Definitely.
But that is not an heuristic. If it it referenced or recusive it is
always correct to not inline it. There is no incorrect cases and
therefore it is not an heuristic it is an
On Wed, 6 Dec 2000, Patrik Stridvall wrote:
I find your line of reasoning ridiculous at best. A compiler
is certainly
in the best position of all reasonable things to determine
whether a piece
of code it has just compiled is actually used in the module that it is
commanded to
On Wed, 6 Dec 2000, Patrik Stridvall wrote:
I find your line of reasoning ridiculous at best. A compiler
is certainly
in the best position of all reasonable things to determine
whether a piece
of code it has just compiled is actually used in the
module that it is
On Wed, 6 Dec 2000, Patrik Stridvall wrote:
The compiler is also *expected* to
remove dead code,
*especially* if attribute((unused)) is used, as this
attribute is very
often used in inline functions in .h files.
OK perhaps "attribute((unused))" does something
Yes, but old portable code doesn't use
__attribute__((unused)) does it?
Someone may want to use a #ifdef __GNUC__ #define UNUSED
__attribute__((unused)) #else #defined UNUSED #endif in
portable code to
suppress warnings for a particular inline function. I don't
see problems
with
I got this when compiling wine20001202 configured with CFLAGS set to
'-mpentiumpro -march=i686 -O6'. When I removed '-O6' from
CFLAGS it compiled
without problems. I am using gcc 2.95.2 (debian version 2.95.2-18).
So your are trying to compile the _alpha_ version of a piece of software
with
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
I think there is a bug in the compiler, optimizations shouldn't
really effect linking.
Bug? It's not a bug for a compiler to remove static code that appears
unused (in fact a lot of common .h inline functions depend on such
behaviour)!
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
I think there is a bug in the compiler, optimizations shouldn't
really effect linking.
Bug? It's not a bug for a compiler to remove static code that appears
unused (in fact a lot of common
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
So if optimization can't analyze what inline assembler does it
shouldn't do any optimizations that depends on what the assembler
code does.
Can you please provide a minimal example? (I missed the original mail,
but will try to have a look and have
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
I think there is a bug in the compiler, optimizations shouldn't
really effect linking.
Bug? It's not a bug for a compiler to remove static code
that appears
unused (in fact a lot
On Tue, 5 Dec 2000, Patrik Stridvall wrote:
So if optimization can't analyze what inline assembler does it
shouldn't do any optimizations that depends on what the assembler
code does.
Can you please provide a minimal example? (I missed the original mail,
but will try to have a look and
17 matches
Mail list logo
