[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: module level flags
From: |
Bruce Korb |
Subject: |
Re: module level flags |
Date: |
Sat, 28 Sep 2002 16:46:21 -0700 |
Tim Prince wrote:
>
> On Saturday 28 September 2002 16:05, Bruce Korb wrote:
> > As best as I can determine, there is no easy way to say, "do
> > not optimize this particular module". The best way would be
> > with a #pragma around the problematical function, but I'll
> > be happy with anything that does not disable optimization for
> > the entire program and does not prevent someone from overriding
> > CFLAGS for that module, either. Suggestions? Thanks!
> So you've ruled out the old-fashioned way of dividing your source into
> separate files, and specifying specific compile flags for the one you don't
> want optimized? Every make-like compiler driver supports this. Certain
> compilers support in-file specification of compile flags, subroutine by
> subroutine, and more may do so. Do you mean something which works with all
> Fortran compilers, past, present, and future, since you haven't specified?
I was trying to do several things without getting excessively verbose.
Insead I was probably obtuse:
1. lobby for GCC to have #pragma push_optimize 0/#pragma pop_optimize
2. lobby for automake to support spitting out specialized rules
when it sees ``autogen_defReduce_c_CFLAGS = -O0''. Hopefully,
it (or libtool) is smart enough to strip extra optimizer specs
for compilers that choke and respell them for other compilers.
3. not force the compilers with working optimizers to use -O0
(This is a GCC-3.x issue. Prior releases and other compilers
do not have this problem.)
4. Query the community for usual and customary practices for
working around the issue, if there are any.
So, yes, I know about making a specialized rule. The problem is
it also gets all tangled up in configury issues. e.g., Sun
spells "optimize 2" as ``-xO2''. Yummy.
For the time being, I'll test for GCC 3.[12] and disable
optimization for that compiler, I guess. :-(