On Wed, Jun 20, 2012 at 11:33 PM, David Blaikie <[email protected]> wrote:

> On Wed, Jun 20, 2012 at 11:26 PM, Chandler Carruth <[email protected]>
> wrote:
> > On Wed, Jun 20, 2012 at 11:12 PM, Daniel Jasper <[email protected]>
> wrote:
> >>
> >> I have looked into both suggestions, but I am not sure what the right
> >> thing is:
> >>
> >> __attribute__((used)): According to the gcc docs, "this attribute,
> >> attached to a function, means that code must be emitted for the function
> >> even if it appears that the function is not referenced". It doesn't
> really
> >> say anything about silencing warnings and the code emitting part does
> not
> >> really apply to fields. I am happy to make this attribute silence the
> >> warning, but I don't know whether that makes sense.
> >>
> >> -Wused-but-marked-unused: We run into trouble if certain field usages
> are
> >> only conditionally included (#ifdefs, ...).  In that case, it would be
> >> impossible to create source code that produces neither
> >> -Wused-but-marked-unused nor -Wunused-private-field if compiled in
> different
> >> modes.
> >>
> >> Any thoughts?
> >
> >
> > I really should have thought of this when we chatted. It's quite verbose,
> > but it works:
> >
> > struct S {
> >   int platform_specific_member
> > #ifdef __x86_64__
> >     __attribute__((unused))
> > #endif
> >     ;
> > };
> >
> >
> > We just have to make the attribute itself be conditioned on the same
> thing
> > as the use of the member. As long as this attribute never impacts
> semantics,
> > this should be fine. Do others thing this is too cumbersome?
>
> If you're going to conditionally define its usage, why not just
> conditionally define the whole variable? (admittedly there are some
> cases where that might not work, but I'm not sure they're the cases
> we're dealing with)


Certainly, that's another option.

But in many cases, ABI or other concerns prevent that. I should have used a
better example: NDEBUG.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to