diff mbox

[i386] : Remove some default defines

Message ID AANLkTimd+7nfAtZ6jj6zKK=Wya6OtPdvU4EK6cvzBrSB@mail.gmail.com
State New
Headers show

Commit Message

Uros Bizjak Aug. 12, 2010, 10:16 a.m. UTC 
Hello!

In addition to LONG_TYPE_SIZE, this patch removes EMPTY_FIELD_BOUNDARY
define which is overridden by PCC_BITFIELD_TYPE_MATTERS. The later is
the default for all i386 targets.

2010-08-12  Uros Bizjak  <ubizjak@gmail.com>

	* config/i386/i386.c (LONG_TYPE_SIZE): Remove.
	(EMPTY_FIELD_BOUNDARY): Remove.
	* config/i386/i386-interix.h (PCC_BITFIELD_TYPE_MATTERS): Remove.

Tested on x86_64-pc-linux-gnu, committed to mainline SVN.

Uros.
diff mbox

Patch

Index: config/i386/i386.h
===================================================================
--- config/i386/i386.h	(revision 163187)
+++ config/i386/i386.h	(working copy)
@@ -661,10 +661,9 @@ 
 
 #define SHORT_TYPE_SIZE 16
 #define INT_TYPE_SIZE 32
+#define LONG_LONG_TYPE_SIZE 64
 #define FLOAT_TYPE_SIZE 32
-#define LONG_TYPE_SIZE BITS_PER_WORD
 #define DOUBLE_TYPE_SIZE 64
-#define LONG_LONG_TYPE_SIZE 64
 #define LONG_DOUBLE_TYPE_SIZE 80
 
 #define WIDEST_HARDWARE_FP_SIZE LONG_DOUBLE_TYPE_SIZE
@@ -740,10 +739,6 @@ 
 /* C++ stores the virtual bit in the lowest bit of function pointers.  */
 #define TARGET_PTRMEMFUNC_VBIT_LOCATION ptrmemfunc_vbit_in_pfn
 
-/* Alignment of field after `int : 0' in a structure.  */
-
-#define EMPTY_FIELD_BOUNDARY BITS_PER_WORD
-
 /* Minimum size in bits of the largest boundary to which any
    and all fundamental data types supported by the hardware
    might need to be aligned. No data type wants to be aligned
Index: config/i386/i386-interix.h
===================================================================
--- config/i386/i386-interix.h	(revision 163187)
+++ config/i386/i386-interix.h	(working copy)
@@ -287,8 +287,6 @@ 
 
 #define HOST_PTR_AS_INT unsigned long
 
-#define PCC_BITFIELD_TYPE_MATTERS 1
-
 /* The following two flags are usually "off" for i386, because some non-gnu
    tools (for the i386) don't handle them.  However, we don't have that
    problem, so....  */