summaryrefslogtreecommitdiff
path: root/gnu/gcc
diff options
context:
space:
mode:
authorJonathan Gray <jsg@cvs.openbsd.org>2015-10-07 10:26:24 +0000
committerJonathan Gray <jsg@cvs.openbsd.org>2015-10-07 10:26:24 +0000
commit68c2f66c0d155e4cfba0392dd4da5e4c3ae9db46 (patch)
tree2c85c7da97aa29a4dd7f82a08395409a2e9780f9 /gnu/gcc
parent5224a5e41a802053f9b269e779eaa27feb6fa5f9 (diff)
Correct handling of enum attributes with g++
gcc and g++ can currently have different ideas on the size of a packed enum type: enum __attribute__((packed)) foo { a = 0, b}; gcc: 1 g++: 4 enum foo { a = 0, b} __attribute__((packed)); gcc: 1 g++: 1 The first format is actually the preferred one according to the documentation. https://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Type-Attributes.html g++ will accept the first format and silently not actually choose a smaller size. This was responsible for memory corruption with recent versions of Mesa where c and c++ code share a header with a packed enum type. The problem was reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219 and fixed in gcc >= 4.3.6 in rev 144284. This was after the switch from gplv2 but it's a trivial one line change. ok guenther@ deraadt@ kettenis@
Diffstat (limited to 'gnu/gcc')
-rw-r--r--gnu/gcc/gcc/cp/parser.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/gnu/gcc/gcc/cp/parser.c b/gnu/gcc/gcc/cp/parser.c
index e060d49c343..11685688fdf 100644
--- a/gnu/gcc/gcc/cp/parser.c
+++ b/gnu/gcc/gcc/cp/parser.c
@@ -10482,6 +10482,7 @@ cp_parser_enum_specifier (cp_parser* parser)
if (cp_parser_allow_gnu_extensions_p (parser))
{
tree trailing_attr = cp_parser_attributes_opt (parser);
+ trailing_attr = chainon (trailing_attr, attributes);
cplus_decl_attributes (&type,
trailing_attr,
(int) ATTR_FLAG_TYPE_IN_PLACE);