gmane.comp.parsers.sparse

Handling of -specs in cgcc

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 <at> 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=(.*)$/) {

(Continue reading)

headers

Alexey Zaytsev | 22 Jul 19:00

Re: Handling of -specs in cgcc

[Added the new address to the CC]

On Sun, Jul 20, 2008 at 10:28 PM, Alexey Zaytsev
<alexey.zaytsev <at> 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 <at> gmail.com>
>
> diff --git a/cgcc b/cgcc
> index 4fab530..a1d4f66 100755
> --- a/cgcc
> +++ b/cgcc
> @@ -23,12 +23,6 @@ foreach (@ARGV) {

(Continue reading)

headers

Morten Welinder | 22 Jul 19:20

Re: Handling of -specs in cgcc

On Tue, Jul 22, 2008 at 1:00 PM, Alexey Zaytsev
<alexey.zaytsev <at> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Alexey Zaytsev | 22 Jul 19:28

Re: Handling of -specs in cgcc

On Tue, Jul 22, 2008 at 9:20 PM, Morten Welinder <mwelinder <at> gmail.com> wrote:
> On Tue, Jul 22, 2008 at 1:00 PM, Alexey Zaytsev
> <alexey.zaytsev <at> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Morten Welinder | 22 Jul 19:43

Re: Handling of -specs in cgcc

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Alexey Zaytsev | 22 Jul 19:59

Re: Handling of -specs in cgcc

On Tue, Jul 22, 2008 at 9:43 PM, Morten Welinder <mwelinder <at> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Josh Triplett | 22 Jul 20:03

Re: Handling of -specs in cgcc

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

--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Alexey Zaytsev | 22 Jul 20:11

Re: Handling of -specs in cgcc

On Tue, Jul 22, 2008 at 10:03 PM, Josh Triplett
<josht <at> 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

(Continue reading)