This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] add support for GCC 9 attribute copy

On Mon, 12 Nov 2018, Martin Sebor wrote:

> > Could you look at the powerpc soft-float, s390x and mips failures, which
> > look somewhat different (and thus could indicate issues with the details
> > of how this warning / attribute are specified, as opposed to simply
> > needing a few more copy attributes somewhere)?
> Do you by chance have an easy way to get the preprocessed sources
> for these files so I can easily verify that my quick test cases
> match the real problems?


> Based on the warning alone I think the test case below shows
> the problem:
>   __thread int i __attribute__ ((tls_model ("local-exec")));
>   extern __attribute__ ((alias ("i"), copy (i))) int j;
> tls_model is one of the few attributes I didn't test.  The warning
> suggests the copy attribute code might need to filter out some more
> attributes.  Let me work on that.

Or maybe some variable of libc_hidden_data_def is needed that uses 
__thread when defining aliases, in which case tls_model attributes might 
not be considered to be ignored?  (The declarations in soft-supp.h use 
libc_hidden_tls_proto which does use __thread when defining aliases.)

> Does it look close to what's going on in the file?  If so, does
> it make sense to define an alias target inline/always_inline?
> (I can filter attribute always_inline out of copy but I wonder
> if changing the target to avoid always_inline would be more
> appropriate.)

I can imagine there might be uses for having some aliases that should be 
inlined and others that shouldn't be (provided there is actually an 
external definition for the function - if it's GNU extern inline with no 
separate definition provided, aliases aren't exactly useful).

> So it sounds like the mips16 attribute is meaningful on definitions
> but doesn't impact callers, correct?  I think it would be useful to

Strictly speaking I think it *can* impact callers by telling them whether 
they might need to generate code compatible with interlinking mips16 and 
non-mips16 for that call (in the absence of the attribute, the caller 
needs to make safe assumptions about not knowing what instruction set the 
function is built for).

The purpose of the alias, however, is definitely to avoid problems with 
declarations of __longjmp being inconsistent as to whether they have the 
attribute; see 

Joseph S. Myers

Attachment: sim-full.i.gz
Description: application/gzip

Attachment: utf8-utf16-z9.i.gz
Description: application/gzip

Attachment: __longjmp.i.gz
Description: application/gzip

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]