This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Compiling glibc-2.3.2 with gcc-3.4 yields "string2.h:80: warning:`packed' attribute ignored"
- From: Dan Kegel <dank at kegel dot com>
- To: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 14 Aug 2003 17:38:48 -0700
- Subject: Compiling glibc-2.3.2 with gcc-3.4 yields "string2.h:80: warning:`packed' attribute ignored"
Compiling glibc-2.3.2 with a gcc-3.4 snapshot, I'm seeing
a whole bunch of warnings like this:
../string/bits/string2.h:80: warning: `packed' attribute ignored
../string/bits/string2.h:81: warning: `packed' attribute ignored
../string/bits/string2.h:82: warning: `packed' attribute ignored
../string/bits/string2.h:83: warning: `packed' attribute ignored
../string/bits/string2.h:84: warning: `packed' attribute ignored
../string/bits/string2.h:85: warning: `packed' attribute ignored
../string/bits/string2.h:86: warning: `packed' attribute ignored
The code in question is from http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/bits/string2.h?rev=1.68&cvsroot=glibc
...
#else
/* These are a few types we need for the optimizations if we cannot
use unaligned memory accesses. */
# define __STRING2_COPY_TYPE(N) \
typedef struct { unsigned char __arr[N]; } \
__STRING2_COPY_ARR##N __attribute__ ((packed))
__STRING2_COPY_TYPE (2);
__STRING2_COPY_TYPE (3);
__STRING2_COPY_TYPE (4);
__STRING2_COPY_TYPE (5);
__STRING2_COPY_TYPE (6);
__STRING2_COPY_TYPE (7);
__STRING2_COPY_TYPE (8);
# undef __STRING2_COPY_TYPE
#endif
What's the story there? Is the latest gcc-3.4 snapshot funny here,
or should glibc change that file? (Not sure why that struct would
need to be packed, anyway... does that attribute have any effect
on a struct containing nothing but a char array?)
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045