Handling of -specs in cgcc

Handling of -specs in cgcc

[Alexey Zaytsev]

Hi.

Looking at cgcc, it seems that this code does not actually work,

26     if (/^-specs=(.*)$/) {
27         $check .= &add_specs ($1);
28         $has_specs = 1;
29         next;
30     }

because add_specs() never expects to see a file name, and
the option is removed from the argument list and never passed
to gcc. As it seems that this feature never worked, probably
we could simply remove it? Morten?

---

    Pass -specs to gcc without trying (and failing) to decompose it.

    Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>

diff --git a/cgcc b/cgcc
index 4fab530..a1d4f66 100755
--- a/cgcc
+++ b/cgcc
@@ -23,12 +23,6 @@ foreach (@ARGV) {
     $m32 = 1 if /^-m32$/;
     $m64 = 1 if /^-m64$/;

-    if (/^-specs=(.*)$/) {
-       $check .= &add_specs ($1);
-       $has_specs = 1;
-       next;
-    }

Re: Handling of -specs in cgcc

[Alexey Zaytsev]

[Added the new address to the CC]

On Sun, Jul 20, 2008 at 10:28 PM, Alexey Zaytsev
<alexey.zaytsev@gmail.com> wrote:
> Hi.
>
> Looking at cgcc, it seems that this code does not actually work,
>
> 26     if (/^-specs=(.*)$/) {
> 27         $check .= &add_specs ($1);
> 28         $has_specs = 1;
> 29         next;
> 30     }
>
> because add_specs() never expects to see a file name, and
> the option is removed from the argument list and never passed
> to gcc. As it seems that this feature never worked, probably
> we could simply remove it? Morten?
>
> ---
>
>    Pass -specs to gcc without trying (and failing) to decompose it.
>
>    Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
>
> diff --git a/cgcc b/cgcc
> index 4fab530..a1d4f66 100755
> --- a/cgcc
> +++ b/cgcc
> @@ -23,12 +23,6 @@ foreach (@ARGV) {
>     $m32 = 1 if /^-m32$/;
>     $m64 = 1 if /^-m64$/;
>
> -    if (/^-specs=(.*)$/) {
> -       $check .= &add_specs ($1);
> -       $has_specs = 1;
> -       next;
> -    }
> -
>     if ($_ eq '-no-compile') {
>        $do_compile = 0;
>        next;
> @@ -83,6 +77,8 @@ sub cc_only_option {
>     # ones.  Don't include it just because a project wants to pass -Wall to cc.
>     # If you really want cgcc to run sparse with -Wall, use
>     # CHECK="sparse -Wall".
> +
> +    return 1 if $arg =~ /^-specs=.*/;
>     return 1 if $arg =~ /^-Wall$/;
>     return 0;
>  }
>

Re: Handling of -specs in cgcc

[Morten Welinder]

On Tue, Jul 22, 2008 at 1:00 PM, Alexey Zaytsev
<alexey.zaytsev@gmail.com> wrote:
> [Added the new address to the CC]

("troll.com" is a bitkeeper bug.  Use a machine named "troll" and
bitkeeper would
happily add ".com".)

With respect to the substance, I am not sure why you want to remove -specs.
It was never meant to take a filename -- it takes a token like "i86" and adds
options for that.  That is not generally very useful, but has its uses
for cross-
compilation.

Morten

Re: Handling of -specs in cgcc

[Alexey Zaytsev]

On Tue, Jul 22, 2008 at 9:20 PM, Morten Welinder <mwelinder@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 1:00 PM, Alexey Zaytsev
> <alexey.zaytsev@gmail.com> wrote:
>> [Added the new address to the CC]
>
> ("troll.com" is a bitkeeper bug.  Use a machine named "troll" and
> bitkeeper would
> happily add ".com".)
>
> With respect to the substance, I am not sure why you want to remove -specs.
> It was never meant to take a filename -- it takes a token like "i86" and adds
> options for that.  That is not generally very useful, but has its uses
> for cross-
> compilation.

But won't gcc fail in such case? Maybe we should not remove, but replace it
with a unique option to specify for which architecture sparse should check?

>
> Morten
>

Re: Handling of -specs in cgcc

[Morten Welinder]

> But won't gcc fail in such case?

It will not fail, as gcc does not see any of it.  But since the defines might
not match what gcc runs with, you might get interesting effects.

> Maybe we should not remove, but replace it
> with a unique option to specify for which architecture sparse should check?

That's certainly possible, but I would wait for an actual problem showing
up before fixing anything.  Right now, we can use -specs to get an idea
what sparse would find for a different arch without actually having a gcc
around that can cross compile.

Morten

Re: Handling of -specs in cgcc

[Alexey Zaytsev]

On Tue, Jul 22, 2008 at 9:43 PM, Morten Welinder <mwelinder@gmail.com> wrote:
>> But won't gcc fail in such case?
>
> It will not fail, as gcc does not see any of it.  But since the defines might
> not match what gcc runs with, you might get interesting effects.
>

Rright, it is not added to the gcc arguments. But this means that if the
build system actually passes -specs= for some reason, gcc would never
see them... On the other hand, have anyone ever seen the -specs option
used in real life?

>> Maybe we should not remove, but replace it
>> with a unique option to specify for which architecture sparse should check?
>
> That's certainly possible, but I would wait for an actual problem showing
> up before fixing anything.  Right now, we can use -specs to get an idea
> what sparse would find for a different arch without actually having a gcc
> around that can cross compile.
>
> Morten
>

Re: Handling of -specs in cgcc

[Josh Triplett]

On Tue, 2008-07-22 at 13:43 -0400, Morten Welinder wrote:
> > But won't gcc fail in such case?
> 
> It will not fail, as gcc does not see any of it.  But since the defines might
> not match what gcc runs with, you might get interesting effects.
> 
> > Maybe we should not remove, but replace it
> > with a unique option to specify for which architecture sparse should check?
> 
> That's certainly possible, but I would wait for an actual problem showing
> up before fixing anything.  Right now, we can use -specs to get an idea
> what sparse would find for a different arch without actually having a gcc
> around that can cross compile.

In general, it seems questionable to have cgcc handle an option named
identically to one in GCC but have it behave differently than GCC.

That said, I do think Sparse should handle different architectures
without requiring compilation of a "cross-Sparse"; it really just needs
a specs-equivalent for each architecture.

- Josh Triplett

Re: Handling of -specs in cgcc

[Alexey Zaytsev]

On Tue, Jul 22, 2008 at 10:03 PM, Josh Triplett
<josht@linux.vnet.ibm.com> wrote:
> On Tue, 2008-07-22 at 13:43 -0400, Morten Welinder wrote:
>> > But won't gcc fail in such case?
>>
>> It will not fail, as gcc does not see any of it.  But since the defines might
>> not match what gcc runs with, you might get interesting effects.
>>
>> > Maybe we should not remove, but replace it
>> > with a unique option to specify for which architecture sparse should check?
>>
>> That's certainly possible, but I would wait for an actual problem showing
>> up before fixing anything.  Right now, we can use -specs to get an idea
>> what sparse would find for a different arch without actually having a gcc
>> around that can cross compile.
>
> In general, it seems questionable to have cgcc handle an option named
> identically to one in GCC but have it behave differently than GCC.
>
> That said, I do think Sparse should handle different architectures
> without requiring compilation of a "cross-Sparse"; it really just needs
> a specs-equivalent for each architecture.
>
> - Josh Triplett

How about just s/specs/arch/ ?

diff --git a/cgcc b/cgcc
index 4fab530..f4417dc 100755
--- a/cgcc
+++ b/cgcc
@@ -23,7 +23,7 @@ foreach (@ARGV) {
     $m32 = 1 if /^-m32$/;
     $m64 = 1 if /^-m64$/;

-    if (/^-specs=(.*)$/) {
+    if (/^-arch=(.*)$/) {
        $check .= &add_specs ($1);
        $has_specs = 1;
        next;