[Bug driver/47236] New: Spaces introduced in option processing

[Bug driver/47236] New: Spaces introduced in option processing

[bigotp at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47236

           Summary: Spaces introduced in option processing
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bigotp@acm.org


The fix to #44076 causes options passed to language drivers to be split into
two arguments, a feature not present in previous versions.  

cat >xspecs <<EOSpec
.nc: @nesc

@nesc:
echo INVOKE: %{D*&U*&A*} 
EOSpec

echo "This is TEST" > foo.nc

gcc -specs=xspecs -DTEST foo.nc

With versions prior to revision 163770, this would produce output including:

INVOKE: -DTEST

As of that version, it now produces:

INVOKE: -D TEST

This breaks the nesC component-based compiler used for TinyOS, and possibly
other similar languages that leverage the gcc driver.  The space does not
appear to be introduced for built-in languages (viz., the parameter remains
-DTEST when passed to cpp for a C language file).

If this is intentional and to be fixed in the per-language driver, please
update the description of the specs language to describe the conditions under
which such canonicalization can occur.

[Bug driver/47236] Spaces introduced in option processing

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47236

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jsm28 at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #1 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-01-10 00:32:29 UTC ---
This has nothing to do with the specs language.  Rather, the canonical form of
an option accepting both joined and separate arguments is the form with a
separate argument, all option processing in both the driver and the core
compilers now uses common logic to process options into logical
cl_decoded_option structures, and all subsequent processing now uses those
structures - and if it needs to regenerate an option for specs processing, uses
the canonical form of the option (meaning specs no longer need to handle
noncanonical options if they are noncanonical in a way indicated in the .opt
files, e.g. through being aliases or through using joined arguments where
separate arguments are also accepted).  -D options certainly appear to be
passed in canonical (separate) form to subprocesses (e.g. by gcc -E) to me.

If an option accepts a separate argument and it is passed down to subprocesses
by specs, those subprocesses must accept the form with the separate argument.