This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: aliasing problem with va_arg


>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> hence assumes that they can't overlap.  This macro already
    Jim> knows that va_arg is unsafe, but it handles va_arg by
    Jim> checking to see if this is a stdarg or varargs function.
    Jim> That isn't sufficient, because we can call va_arg from a
    Jim> function that takes a va_list parameter.  It is also overkill

Rats, rats, rats.  Obviously, I did not think of this case.

    Jim> since it means there is no aliasing within a stdarg/varargs
    Jim> function, even though it is only MEMs from va_arg expansion
    Jim> that are unsafe.

    Jim> Long term, I'd suggest changing how we implement va_arg.
    Jim> Instead of a macro that expands to complicated non-ISO C
    Jim> code, we should instead have a target independent macro that
    Jim> expands to a call to a built-in function

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.

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 can see va-sparc.h, but it would
be simpler for me if you would preprocess the file for me.)  I, too,
am skeptical that the macros can be fixed, but I would like to take a
look just to see.

    Jim> Perhaps we can add code to dynamically enable/disable alias
    Jim> set computations.  E.g. add builtin functions
    Jim> __builtin_disable_aliasing, and __builtin_enable_aliasing,
    Jim> modify va_arg to call them at the beginning and end, and then
    Jim> modify get_alias_set to always return zero if
    Jim> __builtin_disable_aliasing has been called.  We could then
    Jim> get rid of the varargs/stdarg function checks in
    Jim> DIFFERENT_ALIAS_SETS_P, while fixing va_list functions at the
    Jim> same time.

This seems sort-of reasonable to me, but I'd rather hold off on this
until we consider the other alternatives.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]