http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314



--- Comment #24 from Jason Merrill <jason at gcc dot gnu.org> 2013-01-27 
01:44:49 UTC ---

(In reply to comment #21)

> I must say I'm surprised by the gimple-fold.c test, I'd really expect

> additional && DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT .



I'd actually expect DECL_VISIBILITY (decl) < VISIBILITY_PROTECTED, and not

check DECL_VISIBILITY_SPECIFIED at all.  I don't think it matters whether the

visibility that the decl ends up with is specified or inferred.



> Another alternative to make those always hidden (which could be an exported

> ABI change for some shared libraries, though unlikely to be actually a real

> problem)



At worst, it removes some unnecessarily exported symbols.  Which might cause

ABI checkers to complain, but nothing else should refer to them; if something

else had, we would have seen this bug before.  I think marking them as hidden

is desirable, as it avoids unnecessary exports for user libraries that don't

use linker scripts or explicit visibility as well as fixing this bug.



(In reply to comment #23)

> It seems C++ frontend has to mark those

> declarations as unusable for referencing.  Is it easy to do on C++ side?

> I think we want tree visibility flag here, because we do not really represent

> stuff that may get into the game with TBAA.



I don't understand.  My patch sets DECL_VISIBILITY to hidden; are you talking

about a different tree visibility flag?

Reply via email to