> It is fine to merge decls across static and external flags, but I am not
> sure this is a safe solution to the problem. In C it is perfectly normal to
> have one decl more specified or with different attributes.  Like:
> 
> extern int a __attribute__ ((warning("bar"));
> 
> int a=7 __attribute__ ((warning("foo")));
> 
> which must prevent merging otherwise the warnings will go out wrong way. In
> GCC 6 timeframe we decided to live with duplicated declarations and added
> support for syntactic aliases. Tree merging should be optional WRT
> correctness, so I think bug is in the canonical type calculation:
> 
>   /* For array types hash the domain bounds and the string flag.  */
>   if (TREE_CODE (type) == ARRAY_TYPE && TYPE_DOMAIN (type))
>     {
>       hstate.add_int (TYPE_STRING_FLAG (type));
>       /* OMP lowering can introduce error_mark_node in place of
>          random local decls in types.  */
>       if (TYPE_MIN_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
>         inchash::add_expr (TYPE_MIN_VALUE (TYPE_DOMAIN (type)), hstate);
>       if (TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
>         inchash::add_expr (TYPE_MAX_VALUE (TYPE_DOMAIN (type)), hstate);
>     }
> 
> which boils down to:
> 
>       if (tclass == tcc_declaration)
>         {
>           /* DECL's have a unique ID */
>           hstate.add_wide_int (DECL_UID (t));
>         }
> 
> (in asd_expr)
> 
> It is bit ugly, but I think for static/external/public decls we need to use
> assembler name here (as we can't rely on symtab to be around all the time)
> which will result in unstability WRT symbol renaming and also give false
> positives for static symbols. But even for static symbols it is not
> guaranteed they are not duplicated.  It may be possible to use combination
> of assembler name and translation unit that is available from symtab node,
> but not all decls will have it defined.

So something akin to what I initially proposed?
  https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00182.html

And, as mentioned in my previous message, I'm not sure that we would be able 
to merge all the global types with the unification scheme, it is too strict.  

-- 
Eric Botcazou

Reply via email to