This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] add support for GCC 9 attribute copy
On 11/12/2018 06:49 AM, Joseph Myers wrote:
On Sun, 11 Nov 2018, Martin Sebor wrote:
I should have mentioned this up front: the patch only avoids warnings
in the x86_64 files (and was only tested there). It doesn't touch
files for any other targets and (as Jeff just noted to me privately)
there are warnings in builds for some non-x86_64 targets, including
i686. This is not unexpected and those targets will need tweaks
similar to those in the patch. Joseph, let me know if you need my
help with any of it.
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?
powerpc soft-float:
../sysdeps/powerpc/nofpu/sim-full.c:26:1: error: 'tls_model' attribute ignored [-Werror=attributes]
26 | libc_hidden_data_def (__sim_exceptions_thread);
| ^~~~~~~~~~~~~~~~~~~~
../sysdeps/powerpc/nofpu/sim-full.c:30:1: error: 'tls_model' attribute ignored [-Werror=attributes]
30 | libc_hidden_data_def (__sim_disabled_exceptions_thread);
| ^~~~~~~~~~~~~~~~~~~~
../sysdeps/powerpc/nofpu/sim-full.c:33:1: error: 'tls_model' attribute ignored [-Werror=attributes]
33 | libc_hidden_data_def (__sim_round_mode_thread);
| ^~~~~~~~~~~~~~~~~~~~
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.
s390x produces a long series of errors starting with:
../sysdeps/s390/multiarch/utf8-utf16-z9.c:26:18: error: always_inline function might not be inlinable [-Werror=attributes]
I think the following might be it:
static inline __attribute__ ((always_inline)) void f (void) { }
extern __attribute__ ((alias ("f"), copy (f))) void g (void);
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.)
mips (o32) produces:
../sysdeps/mips/__longjmp.c:84:1: error: '__longjmp' redeclared with conflicting 'nomips16' attributes
84 | strong_alias (____longjmp, __longjmp);
| ^~~~~~~~~~~~
I think this is it:
extern void g (void);
static __attribute__ ((nomips16)) void f (void) { }
extern __attribute__ ((alias ("f"), copy (f))) __typeof__ (f) g;
and in this case I think it's clearly correct for ____longjmp
(ABI-specific definition) to have the attribute, but the alias __longjmp
(declared in an architecture-independent header) not to have it in that
header (and so shouldn't get it copied either).
So it sounds like the mips16 attribute is meaningful on definitions
but doesn't impact callers, correct? I think it would be useful to
reflect this distinction in GCC's struct attribute_spec. That way
attribute copy could simply check a bit in the struct rather than
the handler having to hardcode knowledge of these (sometimes target
specific) details.
Martin