Re: [PATCH]: Fix PR c++/22452

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Daniel Berlin <dberlin@dberlin.org> writes:

| This restores the behavior of decl_linkage to what it was before the
| decl restructuring patch went in, by not checking DECL_COMDAT on
| CONST_DECL (since CONST_DECL's can't be DECL_COMDAT).
| 
| If they were ever set to DECL_COMDAT, we'd get a tree check somewhere
| else anyway.
| 
| Gaby seems to believe the behavior of decl_linkage is wrong in some way
| in regard to CONST_DECL.
| 
| I have no real opinion on whether it is or not, i'll leave it to the C++
| people to battle it own in a bloody cage match.  I'm simply posting a

There needs not be a bloody cage match.  The observation was very
simple and straightforward.  We have the following comment:

   /* Returns nonzero if DECL has external linkage, as specified by the
      language standard.  (This predicate may hold even when the
      corresponding entity is not actually given external linkage in the
      object file; see decl_linkage for details.)  */
   #define DECL_EXTERNAL_LINKAGE_P(DECL) \
     (decl_linkage (DECL) == lk_external)

so clearly decl_linkage() is designed to match the language standard
notion of linkage.  The observation was that setting unconditionally
lk_internal for a CONST_DECL, where the language standard says it
depends on its type decl_linkage is wrong.  And since you've found
that happening, you have identified a bug in the compiler.

You can restore the wrong behaviour or you can fix it.  If you restore
the wrong behaviour, you should also fill a PR to track it.

| patch to fix the regression i caused by making it behave how it used to.
| 
| Bootstrapped and regtested i686-pc-linux-gnu.
| 
| Okay for mainline?
| --Dan
| 

-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net