Re: [patch] Assert assemble_external is only called during or after expanding to RTL

[Richard Guenther]

On Sat, Mar 24, 2012 at 9:25 PM, Steven Bosscher stevenb@gmail.com wrote:
 Hello,

 This patch tightens the conditions on when assemble_external() may be
 called. It also removes a comment that most platforms do not define
 ASM_OUTPUT_EXTERNAL, because hasn't been true since r119764 added a
 definition of ASM_OUTPUT_EXTERNAL to elfos.h.

 This is the first step toward addressing PR17982 on the trunk for GCC
 4.8. The next step is to change pending_assemble_externals to
 pending_assemble_visibility, and fold assemble_external_real() back
 into assemble_external.

 But first, this patch. I don't think this is very risky, because GCC
 now always works in unit-at-a-time mode. But I think it would be good
 to have this on the trunk for a week or so before proceeding.

 Bootstrapped  tested on x86_64-unknown-linux-gnu. OK for trunk?

Ok.  Though I wonder why callers cannot simply push these decls to
the pending varpool queue and we might do a final run over it,
assembling things?  [or why we call assemble_external that late at all ...]

Richard.

 Ciao!
 Steven



        * varasm.c (assemble_external): Assert this function is only called
        during or after expanding to RTL.

 Index: varasm.c
 ===
 --- varasm.c    (revision 185762)
 +++ varasm.c    (working copy)
 @@ -2166,12 +2166,18 @@ static GTY(()) tree weak_decls;
  void
  assemble_external (tree decl ATTRIBUTE_UNUSED)
  {
 -  /* Because most platforms do not define ASM_OUTPUT_EXTERNAL, the
 -     main body of this code is only rarely exercised.  To provide some
 -     testing, on all platforms, we make sure that the ASM_OUT_FILE is
 -     open.  If it's not, we should not be calling this function.  */
 +  /*  Make sure that the ASM_OUT_FILE is open.
 +      If it's not, we should not be calling this function.  */
   gcc_assert (asm_out_file);

 +  /* This function should only be called if we are expanding, or have
 +     expanded, to RTL.
 +     Ideally, only final.c would be calling this function, but it is
 +     not clear whether that would break things somehow.  See PR 17982
 +     for further discussion.  */
 +  gcc_assert (cgraph_state == CGRAPH_STATE_EXPANSION
 +              || cgraph_state == CGRAPH_STATE_FINISHED);
 +
   if (!DECL_P (decl) || !DECL_EXTERNAL (decl) || !TREE_PUBLIC (decl))
     return;

Re: [patch] Assert assemble_external is only called during or after expanding to RTL

[Steven Bosscher]

On Mon, Mar 26, 2012 at 9:25 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Sat, Mar 24, 2012 at 9:25 PM, Steven Bosscher stevenb@gmail.com 
 wrote:
 Hello,

 This patch tightens the conditions on when assemble_external() may be
 called. It also removes a comment that most platforms do not define
 ASM_OUTPUT_EXTERNAL, because hasn't been true since r119764 added a
 definition of ASM_OUTPUT_EXTERNAL to elfos.h.

 This is the first step toward addressing PR17982 on the trunk for GCC
 4.8. The next step is to change pending_assemble_externals to
 pending_assemble_visibility, and fold assemble_external_real() back
 into assemble_external.

 But first, this patch. I don't think this is very risky, because GCC
 now always works in unit-at-a-time mode. But I think it would be good
 to have this on the trunk for a week or so before proceeding.

 Bootstrapped  tested on x86_64-unknown-linux-gnu. OK for trunk?

 Ok.  Though I wonder why callers cannot simply push these decls to
 the pending varpool queue and we might do a final run over it,
 assembling things?  [or why we call assemble_external that late at all ...]

The idea is to only call assemble_external as late as possible, i.e.
in final. See PR17982. The pending_assemble_external queue was a hack
/ work-around for a problem with c-decl calling DECL_RTL early. Before
that hack was introduced, any call to assemble_external would set
DECL_ASSEMBLER_NAME and DECL_RTL, and write out something to
asm_out_file, during parsing. I'm trying to clean up that
pending_assemble_external mess, because it causes some nasty compile
time problems (PR 52640).

Ciao!
Steven