This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Finally a main line version that passes LAPACK's test suite ...
- To: mark at markmitchell dot com
- Subject: Re: Finally a main line version that passes LAPACK's test suite ...
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Fri, 26 Feb 1999 13:12:34 -0700
- cc: craig at jcb-sc dot com, toon at moene dot indiv dot nluug dot nl, egcs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <199902262012.MAA07375@adsl-206-170-148-33.dsl.pacbell.net>you wri
te:
> If -fno-strict-aliasing makes the expansion go away, that will confirm
> this hypothesis.
Doh. Forgot about that change.
> There are a few ways to fix this problem:
>
> o Don't use -fstrict-aliasing. This might make sense if type-based
> alias analysis is not useful in Fortran. In the long run, we plan
> to use alias sets for other things as well, like temporary
> variables, so this might not be a great long-term solution.
>
> o Teach g77 about alias sets. (It doesn't use them now, right?)
> You can see c_get_alias_set for the kind of thing you might
> want to do. I don't remember enought about recent Fortran (F90)
> to know if this makes sense.
>
> o Enhance the stack-slot allocating code. This is the best plan,
> but hardest. We need a way to tell the compiler that a stack
> slot is dead, and being reused.
>
> You can search the archives for a few days prior to the 2/22 to find
> some discussion of the problem that prompted my patch.
Another thought -- for arrays on the stack, maybe we could set the alias
set based on the underlying type instead of the array itself. That way
arrays with different lifetimes, but the same underlying type could share
stack slots.
I don't know how feasible this really is, just an idea that popped into
my head.
jeff