Don't define a bare "mips" macro for VxWorks

Don't define a bare "mips" macro for VxWorks

[Richard Sandiford]

The next release of VxWorks includes a system header file that forms an
include filename from a root directory component, an architecture macro,
and a filename.  The architecture macro expands to 'mips' for MIPS
targets, but gcc by default defines 'mips' to 1.  Thus the header file
includes foo/1/bar instead of foo/mips/bar.

This problem doesn't affect users of Wind River's makefiles, since those
makefiles add -ansi to the command line by default.  However, it does
affect users who invoke the compiler directly, and it does affect anyone
wanting to run the gcc testsuites.

Although it's probably not wise of the headers to rely on identifiers
like 'mips' not being macros, I think gcc's definition of 'mips' is even
less sound.  I'd get rid of it for all MIPS targets if I thought it was safe.
I don't think it is safe though, so this patch just stops the definition
for VxWorks.

Tested on mips-wrs-vxworks and mipsisa64-elfoabi.  I can only approve
the mips.h change, so are the generic VxWorks changes OK too?

Richard


gcc/
	* config/vxworks-dummy.h (TARGET_VXWORKS): Define.
	* config/vxworks.h (TARGET_VXWORKS): Override.
	* config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Don't define
	"mips" if TARGET_VXWORKS.

Index: gcc/config/vxworks-dummy.h
===================================================================
--- gcc/config/vxworks-dummy.h	(revision 127336)
+++ gcc/config/vxworks-dummy.h	(working copy)
@@ -17,6 +17,11 @@ Software Foundation; either version 3, o
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
 
+/* True if we're targetting VxWorks.  */
+#ifndef TARGET_VXWORKS
+#define TARGET_VXWORKS 0
+#endif
+
 /* True if generating code for a VxWorks RTP.  */
 #ifndef TARGET_VXWORKS_RTP
 #define TARGET_VXWORKS_RTP false
Index: gcc/config/vxworks.h
===================================================================
--- gcc/config/vxworks.h	(revision 127336)
+++ gcc/config/vxworks.h	(working copy)
@@ -20,6 +20,10 @@ Software Foundation; either version 3, o
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
 
+/* Assert that we are targetting VxWorks.  */
+#undef TARGET_VXWORKS
+#define TARGET_VXWORKS 1
+
 /* In kernel mode, VxWorks provides all the libraries itself, as well as
    the functionality of startup files, etc.  In RTP mode, it behaves more
    like a traditional Unix, with more external files.  Most of our specs
Index: gcc/config/mips/mips.h
===================================================================
--- gcc/config/mips/mips.h	(revision 127336)
+++ gcc/config/mips/mips.h	(working copy)
@@ -357,9 +357,14 @@ #define TARGET_CPU_CPP_BUILTINS()					\
       builtin_define ("__mips__");     					\
       builtin_define ("_mips");						\
 									\
-      /* We do this here because __mips is defined below		\
-	 and so we can't use builtin_define_std.  */			\
-      if (!flag_iso)							\
+      /* We do this here because __mips is defined below and so we	\
+	 can't use builtin_define_std.  We don't ever want to define	\
+	 "mips" for VxWorks because some of the VxWorks headers		\
+	 construct include filenames from a root directory macro,	\
+	 an architecture macro and a filename, where the architecture	\
+	 macro expands to 'mips'.  If we define 'mips' to 1, the	\
+	 architecture macro expands to 1 as well.  */			\
+      if (!flag_iso && !TARGET_VXWORKS)					\
 	builtin_define ("mips");					\
 									\
       if (TARGET_64BIT)							\

Re: Don't define a bare "mips" macro for VxWorks

[Maciej W. Rozycki]

On Fri, 10 Aug 2007, Richard Sandiford wrote:

> Although it's probably not wise of the headers to rely on identifiers
> like 'mips' not being macros, I think gcc's definition of 'mips' is even
> less sound.  I'd get rid of it for all MIPS targets if I thought it was safe.
> I don't think it is safe though, so this patch just stops the definition
> for VxWorks.

 Oh, I have seen clauses like #if defined(mips) in several places (X11 
comes to mind).  Though admittedly they are normally a warning sign of 
somebody assuming MIPS == RISC/os.

  Maciej

Re: Don't define a bare "mips" macro for VxWorks

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 10 Aug 2007, Richard Sandiford wrote:
>> Although it's probably not wise of the headers to rely on identifiers
>> like 'mips' not being macros, I think gcc's definition of 'mips' is even
>> less sound.  I'd get rid of it for all MIPS targets if I thought it was safe.
>> I don't think it is safe though, so this patch just stops the definition
>> for VxWorks.
>
>  Oh, I have seen clauses like #if defined(mips) in several places (X11 
> comes to mind).  Though admittedly they are normally a warning sign of 
> somebody assuming MIPS == RISC/os.

OK, thanks for the pointer; it's useful to have a specific example of
a sourcebase that uses the macro.  That makes me even more convinced
that the patch is doing the right thing.

Richard

Re: Don't define a bare "mips" macro for VxWorks

[Nathan Sidwell]

Richard Sandiford wrote:
> The next release of VxWorks includes a system header file that forms an
> include filename from a root directory component, an architecture macro,
> and a filename.  The architecture macro expands to 'mips' for MIPS
> targets, but gcc by default defines 'mips' to 1.  Thus the header file
> includes foo/1/bar instead of foo/mips/bar.
> 
> This problem doesn't affect users of Wind River's makefiles, since those
> makefiles add -ansi to the command line by default.  However, it does
> affect users who invoke the compiler directly, and it does affect anyone
> wanting to run the gcc testsuites.
> 
> Although it's probably not wise of the headers to rely on identifiers
> like 'mips' not being macros, I think gcc's definition of 'mips' is even
> less sound.  I'd get rid of it for all MIPS targets if I thought it was safe.
> I don't think it is safe though, so this patch just stops the definition
> for VxWorks.
> 
> Tested on mips-wrs-vxworks and mipsisa64-elfoabi.  I can only approve
> the mips.h change, so are the generic VxWorks changes OK too?

ok

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk