This is the mail archive of the 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: [C frontend] Fix construction of TYPE_STUB_DECL

it seems that the discussion here got stuck without arriving to a consensus.
I generally see three options here
 1) make TYPE_PUBLIC flag of TYPE_STUB_DECL to work consistently across frontends
    in a sense that types with flag !TYPE_PUBLIC (TYPE_STUB_DECL (t)) can be
    considered local to the translation unit and thus we can consider these types
    non-escaping (possibly changing the layout) and TBAA incompatible with types
    from other units for LTO.
 2) Add TYPE_ODR flag that will mark all types that comply the ODR rule.  This
    would be ideally set on C++ types by the FE.
 3) Make type_in_anonymous_namespace to walk context and look for non-public
    namespace instead of relying on TYPE_STUB_DECL alone and if TREE_PUBLIC
    flag on namespaces turns out to be not consistent across FEs, it may
    walk up to check TRANSLATION_UNIT_DECL and work out if it is C++ lang.

In general I still lean toward 1 as it has hope to be useful for non-C++
languages that have notion of local types. I am trying to keep all the
ODR/devirt code as generic as posisble to make it useful for non-C++ based
languages, too. 1) is one of very few cases where we can "solve" type escape.

3) feels like a hack and would make type_in_anonymous_namespace
non-constant (probably still cheap enough for my needs).  It seems like
something useful for verify_type to check that 1) or 2) works as expected.

Any solution here would let me to apply which otherwise
triggers false positives on Firefox. Mixing C and C++ units makes us to
think that one of global vars (originating from C unit) is declared with type
in anonymous namespace and thus can not match declaration from other unit.
This is workaroundable, too, because C++ variables in anonymous namespaces
are never global so I know all those warnings are false positives, but I
would preffer to not go this way.

Together with the -Wodr warning on types the patch tests that the ODR
equivalency as established by ipa-devrt at linktime exactly match what C++
standard says - if it was wrongly defining two different types equivalent, we
will eventually get ODR type mismatch warning.  If it was wrongly defining two
types different, we will get eventually incompatible declaration warning. I
would like to get this tested and keep an eye at ODR warnings double checking
that they really indicate bugs in compiled programs and not bugs in GCC.
(current implementation seems correct so far on the bigger apps I built)

Moreover the patch is useful to catch some real bugs in Firefox or Libreoffice.


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