This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: aliasing problem with va_arg
- To: Jim Wilson <wilson at cygnus dot com>
- Subject: Re: aliasing problem with va_arg
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 27 Oct 1998 10:36:25 -0700
- cc: mark at markmitchell dot com, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199810262036.MAA12026@rtl.cygnus.com>you write:
> Right, as per our discussion on Tuesday. Is it really as hard as you
> say to do this? This is clearly the right fix. For now, we don't
> have to give good alias sets to the things we're loading; just 0 will
> do for safety sake.
>
> It shouldn't be hard for most targets. Primarily it will be time consuming
> ,
> because there are 30 different ports that will need to be fixed. I'd rathe
> r
> see them all fixed than to just fix a few, because if we don't fix them
> all now, we probably never will, and that could lead to long term maintenan
> ce
> problems.
>
> There are a few targets where making the change will be hard. The MIPS
> for instance supports many different macros, big endian vs little endian,
> hard-float vs soft-float, 32 bit vs 64 bit, plus the effects of supporting
> multiple ABIs (o32, n32, n64, EABI). I'd expect it to get a little tricky
> to get them all right.
>
> How hard would fixing the macros be? Would you mind sending me the
> preprocessed sun-solaris2 source for your example, so that I could
> look at it with a cross-compiler?
>
> I didn't even think of fixing va-sparc.h. I just assumed it couldn't be.
> It is possible that we might be able to do something there.
One possibility would be to have the va_arg macro expand in the normal fashion,
but also emit something similar to __builtin_saveregs -- ie a marker to
indicate that we're accessing stuff on a varargs list.
When we see the marker we turn off type based alias analysis, or just generate
alias set zero for all mems.
We then have a different marker emitted by va_end which returns us to normal
behavior.
That's easier than fixing the varargs stuff to work strictly with builtins.
We could even have the builtins be named __builtin_va_arg (ap, type) and
__builtin_va_end (ap) as a step towards actually implementing them as builtins.
jeff