This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: PATCH: Don't allow weak variables in COMMON


> I think the user is in error.  Sorry for being unclear.

I think you think the user is in error because you are a compiler
nerd. :-)

The user may not really even know about common.  (Heck, there are
systems without it.)  The user just knows that in C "int i;" and
"int i = 0;" have the same semantics for a global variable, and
that she doesn't like to type so much.

Well, now, that's kind of a weak (pun intended) argument since the
user must know about weak.

The pre-patch behavior was distinctly rude: an assembler error.  If
we really think this is erroneous, we should change my patch to
emit an error.

> I think we should also detect such conflicts and error.
> This is because the user is telling us two conflicting
> things and it is unwise to try and figure out what the
> user meant.
>
> What does this mean?
>
> int x __attribute__((section("data.foo")));
>
> Maybe this attribute came from some macro and the user
> applied it by accident to some of his BSS data.

Well, look at the code right above mine:

  /* Specifying a section attribute on a variable forces it into a
     non-.bss section, and thus it cannot be common.  */
  if (TREE_CODE (decl) == VAR_DECL
      && DECL_SECTION_NAME (decl) != NULL_TREE
      && DECL_INITIAL (decl) == NULL_TREE
      && DECL_COMMON (decl))
    DECL_COMMON (decl) = 0;

I was just going with the flow.

> Or maybe he really did mean to put it into this special
> section.  What would he like the initial value to be
> in such a case since it won't be in the BSS anymore?

Zero.

It's not presence in BSS that makes these things zero; that's just
an implementation detail.  The zero-ness comes from C.

> I got stung by a bug due to this the other day so I know exactly what
> kind of hell it can be to track the problem down.  Especially if you
> don't know it is because you've told the compiler two different things
> and it didn't at least warn about it.

Warning might be OK.

But this is going to make some things a real pain.  If you have a
structure with an array with 205 elements, you get warnings if you
provide an initializer without all the elements.  And now if you
write:

  struct S attribute((weak));

you're going to get a warning too.  So, you want to me to write all
those zeros?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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