Bug 47236 - Spaces introduced in option processing
Summary: Spaces introduced in option processing
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-09 16:59 UTC by Peter A. Bigot
Modified: 2011-01-10 00:32 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter A. Bigot 2011-01-09 16:59:40 UTC
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.
Comment 1 Joseph S. Myers 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.