Re: Force -O0 flags, inhibit the default -O2 flags

[Ralf Corsepius]

On Tue, 2005-09-27 at 19:38 -0600, Brian wrote:
> We have several files which are not able to be optimized, and when our mac
> mini tries to build the project it chokes up when attempting to do so. It
> seems incorrect to say that the package developer is the least qualified to
> judge compiler flags,
Sorry, but experience tells he is - a developer's view and knowledge are
very limited.

Normally, a developer only knows about the problems he is facing on his
development platforms. Additionally, he  might have received a couple of
reports from people using other development platforms. So he might have
some ideas on particular problems on a set of platforms he doesn't have
access to.



>  and it also seems to avoid the point. The package
> developer should be able to override the autotools, and the user should be
> able to override the developer.
The point is: Technically, package developers can override the
autotools, if they really like to, however in most of all such cases
they will not be able to do so, because though developers think they
know what they are doing, they do not actually know it.

>From my experience, in 99% of all of such cases, developers trying to
set up CFLAGS/CXXFLAGS end up outsmarting themselves.

For example:
Harald wants to override -O2
a) to work around a compiler bug
b) because the compilation speed/optimization ratio doesn't seem worth
it.

wrt. a):
He would have to detect if the compiler is affected by the bug and how
to work around it. 

What he actually knows is that "i386-redhat-gcc-4.0.1-20050731 -O2" as
shipped with "Fedora Core 3 updates as of 20050920" causes a
segmentation fault with a particular code example and that the same
example doesn't segfault with -O2. 
He probably doesn't know how the same compiler behaves on other
architectures, nor does he know how other compilers behave on other
hosts/OSes. I.e. he doesn't know the actual origin of the problem and
therefore can't actually provide a work-around. All he can try is to
reduce the likelihood of hitting this issue.


wrt. b)
His decision is based on personal observation on his development
machines and targets, but he has no chance to know about how this
situation is on other platforms. 
* Compilation speed on an i386 w/128MB RAM will be completely different
from that on an N-processor SMP sparc-development host w/XX GB RAM
* Compiler memory requirements will be different on different
development haost
* The object sizes for i386 targets will be different from that on
sparcs.
* The "optimal compiler flags" for GCC will be different from that for a
commercial compilers.

So all autoconf and the developer do here, must be somehow
wrong/sub-optimal somewhere. The only person to answer these questions
for a particular host is the "system integrator", i.e. the package's
user.

>  It is not a matter of qualification, it is a
> matter of the chain of command.
It is - It is a matter of personal knowledge.

For example: You seem to know about a particular problem on something
called "mini mac", a platform I have never seen nor used before.
I know about problems on platforms I use and you probably never have
heard about before. We both probably have no idea about what might be
required on other platforms.

I.e. you in your role as "user/system-integrator/packager" will be able
to supply work-arounds for your "mini mac", while I am able to provide
work-arounds for my target platforms.

Ralf