This is an archive of the discontinued LLVM Phabricator instance.

[AST] Use -fvisibility value when ignoring -fv-i-h* inline static locals
ClosedPublic

Authored by rnk on Oct 9 2018, 3:58 PM.

Details

Summary

In r340386 we added code to give static locals in inline functions
default visibility. Instead, we should use the "default" visibility
passed on the command line, which could be hidden or protected, as GCC
does.

Most codebases probably only use either -fvisibility=hidden or
-fvisibility-inlines-hidden, since marking inlines hidden should be a
no-op if everything was already going to be hidden, but it looks like
Chromium uses both.

Fixes PR39236

Diff Detail

Repository
rC Clang

Event Timeline

rnk created this revision.Oct 9 2018, 3:58 PM
thakis accepted this revision.Oct 9 2018, 6:22 PM
This revision is now accepted and ready to land.Oct 9 2018, 6:22 PM
hans accepted this revision.Oct 10 2018, 1:08 AM

Most codebases probably only use either -fvisibility=hidden or
-fvisibility-inlines-hidden, since marking inlines hidden should be a
no-op if everything was already going to be hidden, but it looks like
Chromium uses both.

I think using both flags is useful in code bases that want hidden visibility by default, but mark some classes visible explicitly, and then still want the inline functions hidden as an optimization:

struct __attribute__((visibility("default"))) S {
  int foo() {
    static int x;
    return x++;
  }
  int bar();
};

int S::bar() { return 45; }
void use(S *s) { s->foo(); }

With both -fvisibility=hidden and -fvisibility-inlines-hidden, S::bar() will be visible, but S::foo() will be hidden. S::foo()'s static local should be visible though. If the class didn't have the attribute, everything including the static local should be hidden.

The patch looks good to me, but perhaps we should add the above as a test case?

rnk added a comment.Oct 10 2018, 1:50 PM

Mmm, looks like we get that wrong. I would've expected us to go down the "explicit attribute" path, but apparently not.

rnk updated this revision to Diff 169103.Oct 10 2018, 2:58 PM
  • substantial rewrite
rnk added a comment.Oct 10 2018, 3:00 PM

This is rewritten enough that you might want to re-review it, but I'm going to push it today so we don't have to wait another day/night cycle for the fix.

This revision was automatically updated to reflect the committed changes.
hans added a comment.Oct 11 2018, 1:00 AM
In D53052#1261158, @rnk wrote:

This is rewritten enough that you might want to re-review it, but I'm going to push it today so we don't have to wait another day/night cycle for the fix.

Looks good to me. It's hard to follow the logic, but the testing seems pretty comprehensive now. It's a lot like the dll attributes in that way :-)