| Message ID | 1430114140-15817-4-git-send-email-tbsaunde+gcc@tbsaunde.org |
|---|---|
| State | New |
| Headers | show |
spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20150429/Build/gcc/ /daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime -I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc -B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm -o /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
PASS: objc/execute/bf-1.m compilation, -O0 -fgnu-runtime
Executing on aranym: OMP_NUM_THREADS=2 LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0 (timeout = 300)
Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0, status 1
Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
ivar 'isa', type '#', offset 0d
ivar 'f', type 'f', offset 4d
ivar 'a', type 'c', offset 8d
ivar 'flags', type '{?="i"b0i2"j"b2i3"k"b5i12}', offset 9d
ivar 'c', type 'c', offset 12d
real ivar 'isa' offset 0d
computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
real ivar 'f' offset 4d
computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
real ivar 'a' offset 8d
computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
real ivar 'flags' offset 9d
computed type '{?=b0i2b2i3b5i12}c}' offset 10
offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
child process exited abnormally
FAIL: objc/execute/bf-1.m execution, -O0 -fgnu-runtime
Andreas.
On Wed, Apr 29, 2015 at 02:35:39PM +0200, Andreas Schwab wrote: > spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20150429/Build/gcc/ /daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime -I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc -B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm -o /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0 > PASS: objc/execute/bf-1.m compilation, -O0 -fgnu-runtime > Executing on aranym: OMP_NUM_THREADS=2 LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0 (timeout = 300) > Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0, status 1 > Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c} > ivar 'isa', type '#', offset 0d > ivar 'f', type 'f', offset 4d > ivar 'a', type 'c', offset 8d > ivar 'flags', type '{?="i"b0i2"j"b2i3"k"b5i12}', offset 9d > ivar 'c', type 'c', offset 12d > real ivar 'isa' offset 0d > computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0 > real ivar 'f' offset 4d > computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4 > real ivar 'a' offset 8d > computed type 'c{?=b0i2b2i3b5i12}c}' offset 8 > real ivar 'flags' offset 9d > computed type '{?=b0i2b2i3b5i12}c}' offset 10 > offset 9d and computed position 10 don't match on ivar 'flags' (i = 3) > child process exited abnormally > FAIL: objc/execute/bf-1.m execution, -O0 -fgnu-runtime it passes for me on x86_64-linux after that commit, what platform is this? Trev > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
Trevor Saunders <tbsaunde@tbsaunde.org> writes: > it passes for me on x86_64-linux after that commit, what platform is > this? Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Andreas.
On 04/29/2015 03:55 PM, Andreas Schwab wrote: > Trevor Saunders <tbsaunde@tbsaunde.org> writes: > >> it passes for me on x86_64-linux after that commit, what platform is >> this? > > Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. Can't you just answer the question Andreas instead of making Trevor go looking around? You already have this information, why make his job harder? Trevor, try m68k-elf cross. jeff
On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: > On 04/29/2015 03:55 PM, Andreas Schwab wrote: > >Trevor Saunders <tbsaunde@tbsaunde.org> writes: > > > >>it passes for me on x86_64-linux after that commit, what platform is > >>this? > > > >Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. > Can't you just answer the question Andreas instead of making Trevor go > looking around? You already have this information, why make his job harder? actually pointing out libojc/encoding.c was more useful since that makes it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to be changed to #if ! > Trevor, try m68k-elf cross. ok, lets see if I can get this to work (its an execution test that breaks, so I'll need to setup binutils and qemu) Trev > > jeff
On 04/29/2015 04:25 PM, Trevor Saunders wrote: > On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: >> On 04/29/2015 03:55 PM, Andreas Schwab wrote: >>> Trevor Saunders <tbsaunde@tbsaunde.org> writes: >>> >>>> it passes for me on x86_64-linux after that commit, what platform is >>>> this? >>> >>> Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. >> Can't you just answer the question Andreas instead of making Trevor go >> looking around? You already have this information, why make his job harder? > > > actually pointing out libojc/encoding.c was more useful since that makes > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > be changed to #if ! > >> Trevor, try m68k-elf cross. > > ok, lets see if I can get this to work (its an execution test that > breaks, so I'll need to setup binutils and qemu) I've actually got a aranym m68k emulator here... So I can do native bootstrapping and testing for m68k linux. If you want me to test something, just let me know -- FWIW, it takes a week or so to bootstrap ;-) jeff
On 04/29/2015 04:25 PM, Trevor Saunders wrote: > On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: >> On 04/29/2015 03:55 PM, Andreas Schwab wrote: >>> Trevor Saunders <tbsaunde@tbsaunde.org> writes: >>> >>>> it passes for me on x86_64-linux after that commit, what platform is >>>> this? >>> >>> Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. >> Can't you just answer the question Andreas instead of making Trevor go >> looking around? You already have this information, why make his job harder? > > > actually pointing out libojc/encoding.c was more useful since that makes > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > be changed to #if ! In that case, Andreas, please accept my apologies. jeff
Trevor Saunders <tbsaunde@tbsaunde.org> writes: > actually pointing out libojc/encoding.c was more useful since that makes > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > be changed to #if ! That probably won't work on arm or powerpc or vax: gcc/config/arm/arm.h:#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED gcc/config/rs6000/sysv4.h:#define PCC_BITFIELD_TYPE_MATTERS (TARGET_BITFIELD_TYPE) gcc/config/vax/vax.h:#define PCC_BITFIELD_TYPE_MATTERS (! TARGET_VAXC_ALIGNMENT) Andreas.
On Thu, Apr 30, 2015 at 08:40:50AM +0200, Andreas Schwab wrote: > Trevor Saunders <tbsaunde@tbsaunde.org> writes: > > > actually pointing out libojc/encoding.c was more useful since that makes > > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > > be changed to #if ! > > That probably won't work on arm or powerpc or vax: > > gcc/config/arm/arm.h:#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED > gcc/config/rs6000/sysv4.h:#define PCC_BITFIELD_TYPE_MATTERS (TARGET_BITFIELD_TYPE) > gcc/config/vax/vax.h:#define PCC_BITFIELD_TYPE_MATTERS (! TARGET_VAXC_ALIGNMENT) hrmph, I don't see how this code ever worked correctly on those targets. Consider the arm case the value of PCC_BITFIELD_TYPE_MATTERS depends on arm_abi so if the bitfield type matters depends on what abi libobjc is being built for, but its not obvious how libobjc is dealing with that. I suppose it could be that libobjc is using this macro to know something else that only sort of relaed somehow. Unfortunately this code seems to come from the creation of libobjc/ in 11998 and though the commit says it is a move from gcc/objc/ nothing appears to have been removed from gcc/objc/. I guess the "best" thing to do is justadd a __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? Trev > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
On Thu, Apr 30, 2015 at 08:25:14AM -0400, Trevor Saunders wrote: > On Thu, Apr 30, 2015 at 08:40:50AM +0200, Andreas Schwab wrote: > > Trevor Saunders <tbsaunde@tbsaunde.org> writes: > > > > > actually pointing out libojc/encoding.c was more useful since that makes > > > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > > > be changed to #if ! > > > > That probably won't work on arm or powerpc or vax: > > > > gcc/config/arm/arm.h:#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED > > gcc/config/rs6000/sysv4.h:#define PCC_BITFIELD_TYPE_MATTERS (TARGET_BITFIELD_TYPE) > > gcc/config/vax/vax.h:#define PCC_BITFIELD_TYPE_MATTERS (! TARGET_VAXC_ALIGNMENT) > > hrmph, I don't see how this code ever worked correctly on those targets. > Consider the arm case the value of PCC_BITFIELD_TYPE_MATTERS depends on > arm_abi so if the bitfield type matters depends on what abi libobjc is > being built for, but its not obvious how libobjc is dealing with that. > I suppose it could be that libobjc is using this macro to know something > else that only sort of relaed somehow. Unfortunately this code seems to > come from the creation of libobjc/ in 11998 and though the commit says > it is a move from gcc/objc/ nothing appears to have been removed from > gcc/objc/. > > I guess the "best" thing to do is justadd a > __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? I think adding way too many predefines, especially rarely used ones, is harmful, certainly it isn't free, consider -g3 or -dD where it will all end up in, additional gcc start overhead, ... Can't just libobjc configury test for that? Jakub
On Thu, Apr 30, 2015 at 02:33:44PM +0200, Jakub Jelinek wrote: > On Thu, Apr 30, 2015 at 08:25:14AM -0400, Trevor Saunders wrote: > > On Thu, Apr 30, 2015 at 08:40:50AM +0200, Andreas Schwab wrote: > > > Trevor Saunders <tbsaunde@tbsaunde.org> writes: > > > > > > > actually pointing out libojc/encoding.c was more useful since that makes > > > > it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > > > > be changed to #if ! > > > > > > That probably won't work on arm or powerpc or vax: > > > > > > gcc/config/arm/arm.h:#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED > > > gcc/config/rs6000/sysv4.h:#define PCC_BITFIELD_TYPE_MATTERS (TARGET_BITFIELD_TYPE) > > > gcc/config/vax/vax.h:#define PCC_BITFIELD_TYPE_MATTERS (! TARGET_VAXC_ALIGNMENT) > > > > hrmph, I don't see how this code ever worked correctly on those targets. > > Consider the arm case the value of PCC_BITFIELD_TYPE_MATTERS depends on > > arm_abi so if the bitfield type matters depends on what abi libobjc is > > being built for, but its not obvious how libobjc is dealing with that. > > I suppose it could be that libobjc is using this macro to know something > > else that only sort of relaed somehow. Unfortunately this code seems to > > come from the creation of libobjc/ in 11998 and though the commit says > > it is a move from gcc/objc/ nothing appears to have been removed from > > gcc/objc/. > > > > I guess the "best" thing to do is justadd a > > __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? > > I think adding way too many predefines, especially rarely used ones, is > harmful, certainly it isn't free, consider -g3 or -dD where it will all end > up in, additional gcc start overhead, ... there was a reason I said "best" I don't think its a great design either. > Can't just libobjc configury test for that? I suppose it can test what happens with alignment of different types in structs. I guess I'm not really awake yet, and I'm pretty wary of this since I really have no idea what its trying to do. Trev > > Jakub
On Thu, 30 Apr 2015, Jakub Jelinek wrote: > > I guess the "best" thing to do is justadd a > > __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? > > I think adding way too many predefines, especially rarely used ones, is > harmful, certainly it isn't free, consider -g3 or -dD where it will all end > up in, additional gcc start overhead, ... That's why we have -fbuilding-libgcc. It would seem reasonable enough to me to use that when building other target libraries that need such information. (See bug 24775 regarding the general issue with libobjc using GCC's struct layout target macros - I think there was an idea of a way to rework that libobjc code, but haven't looked at the details of Andrew Pinski's old work referred to in that bug; -fbuilding-libgcc may not be the optimal way of dealing with PCC_BITFIELD_TYPE_MATTERS, but ought to work as an interim fix. More generally, regarding host-side target macros used in target code, see my suggestions at <https://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>. It's always necessary, when changing the semantics of a target macro or converting it into a hook, to watch out for uses outside the gcc/ directory, until all the remaining uses in target code have been dealt with.)
On Thu, Apr 30, 2015 at 05:41:57PM +0000, Joseph Myers wrote: > On Thu, 30 Apr 2015, Jakub Jelinek wrote: > > > > I guess the "best" thing to do is justadd a > > > __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? > > > > I think adding way too many predefines, especially rarely used ones, is > > harmful, certainly it isn't free, consider -g3 or -dD where it will all end > > up in, additional gcc start overhead, ... > > That's why we have -fbuilding-libgcc. It would seem reasonable enough to > me to use that when building other target libraries that need such > information. > > (See bug 24775 regarding the general issue with libobjc using GCC's struct > layout target macros - I think there was an idea of a way to rework that > libobjc code, but haven't looked at the details of Andrew Pinski's old > work referred to in that bug; -fbuilding-libgcc may not be the optimal way > of dealing with PCC_BITFIELD_TYPE_MATTERS, but ought to work as an interim I think I saw this and forgot about it and then resaw it just now in documenting this macro tm.texi provides a program that supposedly can check the behavior of the compiler here so writing a autoconf test seems about as simple as it can get when m4 is involved. > fix. More generally, regarding host-side target macros used in target > code, see my suggestions at > <https://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>. It's always > necessary, when changing the semantics of a target macro or converting it > into a hook, to watch out for uses outside the gcc/ directory, until all > the remaining uses in target code have been dealt with.) if we want to be pedantic this patch didn't actually change semantics, here's what tm.texi says. If the macro is defined, its definition should be a C expression; a nonzero value for the expression enables this behavior. Note that if this macro is not defined, or its value is zero, some bit-fields may cross more than one alignment boundary. The compiler can support such references if there are @samp{insv}, @samp{extv}, and @samp{extzv} insns that can directly reference memory. so, its valid for PCC_BITFIELD_TYPE_MATTERS to be defined to 0 in defaults.h. Of course documentation should never really be trusted that much and its still broken :) Trev > > -- > Joseph S. Myers > joseph@codesourcery.com
diff --git a/gcc/cp/class.c b/gcc/cp/class.c index d80d312e..be5f5c2 100644 --- a/gcc/cp/class.c +++ b/gcc/cp/class.c @@ -6258,7 +6258,7 @@ layout_class_type (tree t, tree *virtuals_p) padding = size_binop (MINUS_EXPR, DECL_SIZE (field), TYPE_SIZE (integer_type)); } -#ifdef PCC_BITFIELD_TYPE_MATTERS + /* An unnamed bitfield does not normally affect the alignment of the containing class on a target where PCC_BITFIELD_TYPE_MATTERS. But, the C++ ABI does not @@ -6270,7 +6270,7 @@ layout_class_type (tree t, tree *virtuals_p) was_unnamed_p = true; DECL_NAME (field) = make_anon_name (); } -#endif + DECL_SIZE (field) = TYPE_SIZE (integer_type); DECL_ALIGN (field) = TYPE_ALIGN (integer_type); DECL_USER_ALIGN (field) = TYPE_USER_ALIGN (integer_type); diff --git a/gcc/defaults.h b/gcc/defaults.h index 7e04be2..0af7a02 100644 --- a/gcc/defaults.h +++ b/gcc/defaults.h @@ -1201,6 +1201,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #define DEFAULT_PCC_STRUCT_RETURN 1 #endif +#ifndef PCC_BITFIELD_TYPE_MATTERS +#define PCC_BITFIELD_TYPE_MATTERS false +#endif + #ifndef INSN_SETS_ARE_DELAYED #define INSN_SETS_ARE_DELAYED(INSN) false #endif diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index a04e6f6..8591cd7 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -15120,7 +15120,6 @@ field_byte_offset (const_tree decl) bitpos_int = wi::to_offset (bit_position (decl)); -#ifdef PCC_BITFIELD_TYPE_MATTERS if (PCC_BITFIELD_TYPE_MATTERS) { tree type; @@ -15218,7 +15217,6 @@ field_byte_offset (const_tree decl) } } else -#endif /* PCC_BITFIELD_TYPE_MATTERS */ object_offset_in_bits = bitpos_int; object_offset_in_bytes diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index f18f1ac..6150d85 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -85,10 +85,8 @@ static tree self_referential_size (tree); static void finalize_record_size (record_layout_info); static void finalize_type_size (tree); static void place_union_field (record_layout_info, tree); -#if defined (PCC_BITFIELD_TYPE_MATTERS) || defined (BITFIELD_NBYTES_LIMITED) static int excess_unit_span (HOST_WIDE_INT, HOST_WIDE_INT, HOST_WIDE_INT, HOST_WIDE_INT, tree); -#endif extern void debug_rli (record_layout_info); /* Show that REFERENCE_TYPES are internal and should use address_mode. @@ -698,11 +696,9 @@ layout_decl (tree decl, unsigned int known_align) { zero_bitfield = true; packed_p = false; -#ifdef PCC_BITFIELD_TYPE_MATTERS if (PCC_BITFIELD_TYPE_MATTERS) do_type_align (type, decl); else -#endif { #ifdef EMPTY_FIELD_BOUNDARY if (EMPTY_FIELD_BOUNDARY > DECL_ALIGN (decl)) @@ -1066,7 +1062,6 @@ update_alignment_for_field (record_layout_info rli, tree field, rli->unpacked_align = MAX (rli->unpacked_align, TYPE_ALIGN (type)); } } -#ifdef PCC_BITFIELD_TYPE_MATTERS else if (is_bitfield && PCC_BITFIELD_TYPE_MATTERS) { /* Named bit-fields cause the entire structure to have the @@ -1109,7 +1104,6 @@ update_alignment_for_field (record_layout_info rli, tree field, user_align |= TYPE_USER_ALIGN (type); } } -#endif else { rli->record_align = MAX (rli->record_align, desired_align); @@ -1147,7 +1141,6 @@ place_union_field (record_layout_info rli, tree field) DECL_SIZE_UNIT (field), rli->offset); } -#if defined (PCC_BITFIELD_TYPE_MATTERS) || defined (BITFIELD_NBYTES_LIMITED) /* A bitfield of SIZE with a required access alignment of ALIGN is allocated at BYTE_OFFSET / BIT_OFFSET. Return nonzero if the field would span more units of alignment than the underlying TYPE. */ @@ -1163,7 +1156,6 @@ excess_unit_span (HOST_WIDE_INT byte_offset, HOST_WIDE_INT bit_offset, return ((offset + size + align - 1) / align > tree_to_uhwi (TYPE_SIZE (type)) / align); } -#endif /* RLI contains information about the layout of a RECORD_TYPE. FIELD is a FIELD_DECL to be added after those fields already present in @@ -1290,7 +1282,6 @@ place_field (record_layout_info rli, tree field) /* Handle compatibility with PCC. Note that if the record has any variable-sized fields, we need not worry about compatibility. */ -#ifdef PCC_BITFIELD_TYPE_MATTERS if (PCC_BITFIELD_TYPE_MATTERS && ! targetm.ms_bitfield_layout_p (rli->t) && TREE_CODE (field) == FIELD_DECL @@ -1335,7 +1326,6 @@ place_field (record_layout_info rli, tree field) if (! DECL_PACKED (field)) TYPE_USER_ALIGN (rli->t) |= TYPE_USER_ALIGN (type); } -#endif #ifdef BITFIELD_NBYTES_LIMITED if (BITFIELD_NBYTES_LIMITED
From: Trevor Saunders <tbsaunde+gcc@tbsaunde.org> gcc/ChangeLog: 2015-04-27 Trevor Saunders <tbsaunde+gcc@tbsaunde.org> * defaults.h (PCC_BITFIELD_TYPE_MATTERS): Add default definition to false. * dwarf2out.c (field_byte_offset): REmove check if PCC_BITFIELD_TYPE_MATTERS is defined. * stor-layout.c (layout_decl): Likewise. (update_alignment_for_field): Likewise. (place_field): Likewise. gcc/cp/ChangeLog: 2015-04-27 Trevor Saunders <tbsaunde+gcc@tbsaunde.org> * class.c (layout_class_type): Remove check if PCC_BITFIELD_TYPE_MATTERS is defined. --- gcc/cp/class.c | 4 ++-- gcc/defaults.h | 4 ++++ gcc/dwarf2out.c | 2 -- gcc/stor-layout.c | 10 ---------- 4 files changed, 6 insertions(+), 14 deletions(-)