User account creation filtered due to spam.
With the following change:
2004-06-08 Jason Merrill <email@example.com>
Gimplify VA_ARG_EXPR into simpler forms.
get_varargs_alias_set will always return 0, which causes us to miss some loads/store elimination and such at the rtl level (and tree level also).
The comment in alias.c is:
/* We now lower VA_ARG_EXPR, and there's currently no way to attach the
varargs alias set to an INDIRECT_REF (FIXME!), so we can't
consistently use the varargs alias set for loads from the varargs
area. So don't use it anywhere. */
Setting target milestone to 4.2 so we don't forget about this since it is a regression.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
This looks like one that the mem-ssa folks may want to give a look.
Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes?
Closing 4.1 branch.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
If the quoted comment in this bug's comment #0 is true, then this bug should be fixable with MEM_REF.
Pinski, got test case?
(In reply to comment #10)
> Pinski, got test case?
No I don't have one. At this point I was filing bugs about the FIXME's inside the compiler itself. This comment is still there. If this is now fixable with MEM_REF, then we should be able to fix it and removed the FIXME. If it is not fixable at all, then we should remove the FIXME part of the comment.
What does the standard say here? What is the type in effect for aliasing
int i = va_arg (va, int);
? Is type-punning allowed when unpacking args?
Note that we would need to make sure to use the correct alias set when
setting up args at the callers site as well.
But yes, this now looks easily fixable (and also was with INDIRECT_REFs
via type casts).
(In reply to comment #12)
> What does the standard say here? What is the type in effect for aliasing
> when doing
> int i = va_arg (va, int);
> ? Is type-punning allowed when unpacking args?
From C99, 18.104.22.168/2:
[...] if type is not compatible with the type of the actual next argument (as
promoted according to the default argument promotions), the behavior is
undefined, except for the following cases:
— one type is a signed integer type, the other type is the corresponding
unsigned integer type, and the value is representable in both types;
— one type is pointer to void and the other is a pointer to a character type.
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed