Bug 24434 - [4.9/5/6 Regression] get_varargs_alias_set returns 0 always
Summary: [4.9/5/6 Regression] get_varargs_alias_set returns 0 always
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.1.0
: P5 minor
Target Milestone: 4.9.4
Assignee: Not yet assigned to anyone
Keywords: alias, FIXME, missed-optimization
Depends on:
Reported: 2005-10-18 19:56 UTC by Andrew Pinski
Modified: 2015-10-20 14:49 UTC (History)
5 users (show)

See Also:
Known to work:
Known to fail: 4.0.4
Last reconfirmed: 2012-11-09 23:13:16


Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-10-18 19:56:03 UTC
With the following change:
2004-06-08  Jason Merrill  <jason@redhat.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.  */
Comment 1 Andrew Pinski 2005-10-18 19:56:32 UTC
Setting target milestone to 4.2 so we don't forget about this since it is a regression.
Comment 2 Andrew Pinski 2005-11-11 17:55:39 UTC
Comment 3 Mark Mitchell 2006-05-25 02:36:29 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 4 Steven Bosscher 2006-05-28 09:53:02 UTC
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?
Comment 5 Joseph S. Myers 2008-07-04 20:06:28 UTC
Closing 4.1 branch.
Comment 6 Joseph S. Myers 2009-03-31 19:00:06 UTC
Closing 4.2 branch.
Comment 7 Richard Biener 2009-08-04 12:27:13 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 8 Richard Biener 2010-05-22 18:10:45 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 9 Steven Bosscher 2010-07-15 23:08:21 UTC
If the quoted comment in this bug's comment #0 is true, then this bug should be fixable with MEM_REF.
Comment 10 Steven Bosscher 2010-07-15 23:09:09 UTC
Pinski, got test case?
Comment 11 Andrew Pinski 2010-07-15 23:13:16 UTC
(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.
Comment 12 Richard Biener 2010-07-16 08:22:01 UTC
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?

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).
Comment 13 Segher Boessenkool 2010-07-17 19:04:16 UTC
(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,

[...] 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.
Comment 14 Richard Biener 2011-06-27 12:12:36 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 15 Jakub Jelinek 2012-03-13 12:45:21 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 16 Jakub Jelinek 2013-04-12 15:15:52 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 17 Richard Biener 2014-06-12 13:42:29 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 18 Jakub Jelinek 2014-12-19 13:32:14 UTC
GCC 4.8.4 has been released.
Comment 19 Richard Biener 2015-06-23 08:14:38 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 20 Jakub Jelinek 2015-06-26 19:56:49 UTC
GCC 4.9.3 has been released.