Bug 112432 – lapack-atlas-3.6.0-r1 ignores user's CFLAGS and substitutes its own (very bad) choice

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Ferris McCormick (RETIRED) 2005-11-13 09:48:40 UTC]

When lapack-atlas builds on sparc, it apparently ignores the CFLAGS from
make.conf and substitutes its own.  For me on my U60 sparc test system, that
means it tosses my
CFLAGS="-O2 -mcpu=ultrasparc -pipe"
for
CFLAGS="-fomit-frame-pointer -O3 -funroll-loops"
This guarantees about the worst performance possible on sparc (well, -O0 would
be worse) because it forces code to be generated for sparc -mcpu=v7 (instead of
cpu=ultrasparc).  So, for a heavily numeric application like I believe lapack to
be, I suspect most of the time is spent in the kernel busily emulating
instructions the compiler does not believe to be available.
Unless there are compelling reasons, if performqnce matters (as it does for
lapack), a package should leave sparc's CFLAGS alone.  (And probably, if Fortran
is involved, FFLAGS should default to CFLAGS.  You have the same
architecture-based performance issues with g77 as with gcc, but lapack seems
just to choose -O or -O2 only for g77, apparently depending on its mood at the
time:  It uses both.)

Long discussion at Bug 59506. ciaranm's CFLAGS metabug.

[Comment 1 Danny van Dyk (RETIRED) 2005-11-22 07:35:04 UTC]

Ferris: I think you helped fixing a similar problem in sci-libs/blas-atlas.

Here's the particular code in the ebuild:
--
# Added to allow compilation on sparc architecture. The default CCFLAG0
# and MMFLAGS are *bad*.
# Danny van Dyk <[e-mail]> 2004/07/02
#
reconfigure() {
    case "`uname -p`" in
        "sun4m")
            MY_CCFLAGS="-O3 -mcpu=v8"
            MY_CXXFLAGS="${MY_CCFLAGS}"
            MY_MMFLAGS="-O -mcpu=v8"
            MY_LDFLAGS=""
            ;;
        "sun4u")
            MY_CCFLAGS="-O3 -mcpu=ultrasparc"
            MY_CXXFLAGS="${MY_CCFLAGS}"
            MY_MMFLAGS="-O -mcpu=ultrasparc"
            MY_LDFLAGS=""
            ;;
        *)
            MY_CCFLAGS="${CFLAGS}"
            MY_CXXFLAGS="${CXXFLAGS}"
            MY_MMFLAGS="${CFLAGS}"
            MY_LDFLAGS="${LDFLAGS}"
            ;;
    esac

    MY_FILE="`find -name Make.Linux*`"

    sed -i -e "s/CCFLAG0 =.*/CCFLAG0 = \$(CDEFS) ${MY_CCFLAGS}/" \
        -e "s/CCFLAGS =.*/CCFLAGS = \$(CDEFS) ${MY_CCFLAGS}/" \
        -e "s/CLINKFLAGS =.*/CLINKFLAGS =\$(CDEFS) ${MY_LDFLAGS}/" \
        -e "s/XCCFLAGS =.*/XCCFLAGS =\$(CDEFS) ${MY_CXXFLAGS}/" \
        -e "s/MMFLAGS =.*/MMFLAGS = ${MY_MMFLAGS}/" \
        ${MY_FILE} || die "sed didnt complete"

}
--

Shall i apply this or something similar to lapack-atlas as well?

[Comment 2 Ferris McCormick (RETIRED) 2005-11-22 08:17:49 UTC]

Yes, although experience has taught us that '-O2' is generally a saner choice on
sparc than '-O3'.  Let me know if you need testing (although nothing is going to
happen with testing before 28 or 29 November because of US holidays).

Thanks,
Ferris

[Comment 3 Donnie Berkholz (RETIRED) 2006-06-21 08:06:45 UTC]

Danny, did you want to apply your suggested change?

[Comment 4 Jakub Moc (RETIRED) 2007-01-21 19:38:14 UTC]

Ping???

[Comment 5 Markus Dittrich (RETIRED) 2007-01-22 14:09:12 UTC]

The lapack-atlas/blas-atlas ebuilds in ~ARCH (currently 3.7.24) have been
completely overhauled and should do the right thing and honor the user's 
CFLAGS. If one of the sparc folks could check them out and report back with
any problems that would be great.

Thanks,
Markus

[Comment 6 Ferris McCormick (RETIRED) 2007-01-22 16:55:56 UTC]

With 3.7.24, CFLAGS (and FFLAGS) for both are fine (what I have in make.conf).  Thanks.

[Comment 7 Markus Dittrich (RETIRED) 2007-01-23 03:04:45 UTC]

Hi Ferris,

Thanks a lot for testing:) Would it be all right with you if I close this bug
then? I'd rather not mess with what we have in stable right now and
wait until 3.7.24 (or greater) hits stable.

Best,
Markus

[Comment 8 Ferris McCormick (RETIRED) 2007-01-23 12:18:59 UTC]

(In reply to comment #7)
> Hi Ferris,
> 
> Thanks a lot for testing:) Would it be all right with you if I close this bug
> then? I'd rather not mess with what we have in stable right now and
> wait until 3.7.24 (or greater) hits stable.
> 
> Best,
> Markus
> 
Markus,
It's fixed in 3.7.24 and I'll close it for you. :)
Thanks for the help.