------- Additional Comments From jakub at gcc dot gnu dot org 2004-11-03 07:45 -------
Seems the attribute worked before (and with the patch I posted on gcc-3_4-branch
as well) when used on a decl with enum type, but not when used on enum's typedef.
On the other side, current trunk works when it is used on the typedef, but not
when it is used on the decl:
typedef enum { B1 = 1, B2 = 2, B4 = 4, B8 = 8, B16 = 16 } B;
typedef enum { C1 = 1, C2 = 2, C4 = 4, C8 = 8, C16 = 16 } __attribute__ ((mode
(QI))) C;
typedef enum { D1 = 1, D2 = 2, D4 = 4, D8 = 8, D16 = 16 } __attribute__ ((mode
(word))) D;
B __attribute__ ((mode (QI))) bqi;
B __attribute__ ((mode (word))) bword;
int sqi[sizeof (bqi) == sizeof (int __attribute__((mode (QI)))) ? 1 : -1];
int sword[sizeof (bword) == sizeof (int __attribute__((mode (word)))) ? 1 : -1];
int sc[sizeof (C) == sizeof (int __attribute__((mode (QI)))) ? 1 : -1];
int sd[sizeof (D) == sizeof (int __attribute__((mode (word)))) ? 1 : -1];
GCC 3.3, 3.4.2, 3_4-branch + my patch:
I.c:10: error: size of array `sc' is negative
I.c:11: error: size of array `sd' is negative
GCC HEAD:
I.c:8: error: size of array 'sqi' is negative
I.c:9: error: size of array 'sword' is negative
If sizeof (bqi) == sizeof (int __attribute__((mode (QI)))) is supposed to be
1, then not applying the patch would mean there is a regression on 3_4-branch
and that is exactly the case DHCP is using, where apparently the mode was
not ignored.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18282
