On 25/01/2012 03:27, Rafael Ávila de Espíndola wrote:
> Sorry, one more case that gcc accepts where it is not clear what the
> result should be:
>
> -
> #pragma GCC visibility push(protected)
>
> int x;
> class __attribute__((visibility("hidden"))) foo {
> static i
> While we can change it, it is certainly valid as is, #pragma GCC visibility
> can happen in lots of places and just marks where the default visibility
> is adjusted. If clang errors on this, it is broken.
Sorry, one more case that gcc accepts where it is not clear what the
result should be:
--
> While we can change it, it is certainly valid as is, #pragma GCC visibility
> can happen in lots of places and just marks where the default visibility
> is adjusted. If clang errors on this, it is broken.
It doesn't. As far as I can tell, in the absence of templates clang
produces the same resu
Thanks for raising the issue. To me the above looks like a
straightforward typo, which we should fix as soon as possible (not
sure whether we could also diagnose it).
Jason, Jakub, can you confirm?
While we can change it, it is certainly valid as is, #pragma GCC visibility
can happen in lots of
On Tue, Jan 24, 2012 at 11:45:55AM +0100, Paolo Carlini wrote:
> Hi,
> >While trying to improve clang's handling of "#pragma GCC visibility" I
> >found out that libstdc++-v3/libsupc++/typeinfo looks like
> >
> >#pragma GCC visibility push(default)
> >extern "C++" {
> >#pragma GCC visibility pop
> >
Hi,
While trying to improve clang's handling of "#pragma GCC visibility" I
found out that libstdc++-v3/libsupc++/typeinfo looks like
#pragma GCC visibility push(default)
extern "C++" {
#pragma GCC visibility pop
}
Is that supposed to work or just happens to? If desired, the attached
patch moves
