IMA: backward-compatible behavior from lhd_set_decl_assembler_name

[Geoffrey Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> One of the biggest stumbling blocks to re-enabling IMA has been the C
> front end's special set_decl_assembler_name hook.  It exists because
> the generic hook isn't aware of the special significance of having
> DECL_CONTEXT point to a TRANSLATION_UNIT_DECL.

No, there was no accident here and no lack of knowledge.  The entire
purpose of a TRANSLATION_UNIT_DECL is to invoke this behaviour in
the generic code.

> The new behavior is: Declarations with internal linkage at file scope in
> the first input file get DECL_ASSEMBLER_NAME set equal to DECL_NAME.
> This is what the aforementioned scripts expect.  Declarations with
> internal linkage at file scope in the second and successive input files
> get DECL_NAME + "." + a number; the number chosen is the DECL_UID of the
> containing TRANSLATION_UNIT_DECL.  This number will always be in the
> range 1 ... num_in_fnames-1; make_node and so on are adjusted such that
> DECL_UIDs 0 through num_in_fnames are reserved for TRANSLATION_UNIT_DECLs.

I considered implementing something like this, but I rejected it,
because of:

---a.c---
static int x = 5;
int y(void) { return x++; }
---b.c---
extern int x;
int z(void) { return x++; }
---c.c---
int x = 2;
extern int y(void);
extern int z(void);
int main(void)
{
  if (y() + z() != 7)
    abort();
  exit(0);

$ gcc a.c b.c c.c -c -o a.o
$ gcc a.o -o a
$ ./a

$ gcc a.c b.c -c -o a2.o
$ gcc a2.o c.c -o a2
$ ./a2

I really think it would be better for you to send your designs to the list
for review before you start coding.  That way, things like this can be
caught early.

I presume you'll now back your patch out.

...
> Internal linkage declarations with null DECL_CONTEXT also get no numeric
> suffix.  For C, this should only happen for synthetic declarations
> created by language-independent code (e.g. cgraph_build_static_cdtor).
> I believe this to be harmless wrt IMA - these things tend to be created
> just once in the entire object file, anyway.

This is what has always been done, so it should work as well as it
always did.

> The only wart is that reserving the first few DECL_UIDs for
> TRANSLATION_UNIT_DECLs places a new constraint on front ends: they must
> not create any DECL nodes prior to calling build_common_tree_nodes.  The
> only front end that did that was C++ and it didn't have to; I just moved
> the call to build_common_tree_nodes a few lines up in cxx_init.  The
> *proper* fix here would be to call build_common_tree_nodes from
> language-independent code, just before lang_hooks.init, but that would
> require me to untangle flag_signed_char which is too tangential.

Why are you insisting that the DECL_UIDs for TRANSLATION_UNIT_DECLs
(past the first) must be small?  Is it just for convenience of someone
reading the assembly?

> Bootstrapped i686-linux (all languages but Ada); committed.