This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR target/6077: Tweak meaning of %{.s:...}

The following patch is my proposed solution to PR target/6077.  This is
not a regression, and therefore I'm proposing this possibly controversial
change for gcc 4.1.  However it does affect several platforms including
Solaris 2, in addition to Tru64 problem mentioned in the bugzilla PR.

The issue concerns the interaction between GCC's -x command line option
and the driver's SPECs processing.  Particularly, the %{.foo:bar} idiom,
that expands "bar" if the current input file has the file extension .foo.
The discrepancy is that the majority (all?) uses of this construct, don't
actually care about the input filename, but are attempting to infer the
input file's format from it's suffix.  Normally, this works as intended,
but the "-x blah" (a.k.a. "--language blah") command line option allows
a file to processed with an arbitrary file extension.  This can
unexpectedly confuse target SPECs that construct different command
sequences depending upon the presence of .s or .S files on the command

The proposed solution is to subtly change the semantics of the
%{.s:...}, %{!.s:...}, %{.S:...} and %{!.S:...} to actually test
whether the input file is processed by the compiler as assembler
or preprocessed assembler (or not) as appropriate.  This only
requires a minimal tweak to input_suffix_matches that is only used
to process the relevant SPEC construct.  In theory, we could limit
the set of suffixes that this routine handles, but for the time
being the proof of concept is to only intercept/tweak .s and .S.
This change has absolutely no affect unless the user specifies
"-x" to explicitly change the meaning of a .s, .S or assembler
input file.

Does this seem like a reasonable strategy?

The following patch has been tested by a complete bootstrap, all
default languages, on both i686-pc-linux-gnu and alphaev67-dec-osf5.1,
with a top-level "make -k check" with no new failures.  I've also
confirmed by hand that this change resolves PR target/6077.

Ok to attach this patch to the bugzilla PR for 4.1?

2004-12-27  Roger Sayle  <>

	PR target/6077
	* gcc.c (input_suffix_matches): Tweak the semantics of %{.s:...}
	and %{.S:...} (and their negative variants) to test whether the
	input file is assembler or pre-processed-assembler independent of
	the actual filename extension.

Index: gcc.c
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.442
diff -c -3 -p -r1.442 gcc.c
*** gcc.c	15 Dec 2004 23:50:26 -0000	1.442
--- gcc.c	27 Dec 2004 22:17:55 -0000
*************** handle_spec_function (const char *p)
*** 5459,5464 ****
--- 5459,5480 ----
  static inline bool
  input_suffix_matches (const char *atom, const char *end_atom)
+   /* We special case the semantics of {.s:...} and {.S:...} and their
+      negative variants.  Instead of testing the input filename suffix,
+      we test whether the input source file is an assembler file or an
+      assembler-with-cpp file respectively.  This allows us to correctly
+      handle the -x command line option.  */
+   if (atom + 1 == end_atom
+       && input_file_compiler
+       && input_file_compiler->suffix)
+     {
+       if (*atom == 's')
+ 	return !strcmp (input_file_compiler->suffix, "@assembler");
+       if (*atom == 'S')
+ 	return !strcmp (input_file_compiler->suffix, "@assembler-with-cpp");
+     }
    return (input_suffix
  	  && !strncmp (input_suffix, atom, end_atom - atom)
  	  && input_suffix[end_atom - atom] == '\0');

Roger Sayle,                         E-mail:
OpenEye Scientific Software,         WWW:
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]