On Mon, 25 Apr 2016, Nathan Sidwell wrote:
> On 04/22/16 10:04, Alexander Monakov wrote:
> > echo 'int v __attribute__((section("foo")));' |
> > x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -o /dev/null
> > <stdin>:1:5: error: section attributes are not supported for this target
>
> Presumably it's missing a necessary hook? Couldn't such a hook check the
> section name is acceptable?
No, that really doesn't sound viable. You'd need to somehow take into account
every instance where the compiler attempts to switch sections internally
(.text/.data/.bss, -ffunction-sections/-fdata-sections etc.).
> > > Why can it not apply to variables of auto storage? I.e. function scope,
> > > function lifetime? That would seem to be a useful property.
> >
> > Because PTX does not support auto storage semantics for .shared data. It's
> > statically allocated at link time.
>
> I suppose it's not worth going through hoops to define such function-scoped
> variables if PTX isn't going to take advantage of that.
It's not even about 'taking advantage', basic correctness expectations would be
violated (with auto storage you get new instances of the variable when
reentering function scope recursively).
> > > What happens if an initializer is present, is it silently ignored?
> >
> > GCC accepts and reemits it in assembly output (if non-zero), and ptxas
> > rejects
> > it ("syntax error").
>
> ptx errors are inscrutable.
>
> It would be better for nvptx_assemble_decl_end to check if an initializer has
> been output and emit an error (you'll need to record the decl itself in the
> initializer structure to do that). Record the decl in
> nvptx_assemble_decl_begin if the symbol's data area is .shared, and then check
> in NADE?
Ugh. Checking DECL_INITIAL in nvptx_encode_section_info would be much
simpler (and that's how other backends perform a similar test).
Note, rejecting zero-initializers is debatable:
C and C++ don't have a concept of uninitialized global-scope data; if
the initializer is missing, it's exactly as if it was 0. However, GCC has
-fcommon enabled by default (which, btw, shouldn't we change on NVPTX?), and
that makes a difference: 'int v = 0;' is a strong definition, while 'int v;'
becomes a common symbol, and ultimately a weak definition on NVPTX.
So if all-zeros initializers are rejected, to make a strong definition of a
shared variable one would have to write:
int v __attribute__((shared,nocommon));
With -fno-common enabled by default on this target that wouldn't be an issue.
Thanks.
Alexander
