[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#121282: On i386, gcc-3.0 allows $ in indentifiers but not the asm



On Tue, 27 Nov 2001, Martin v. Loewis wrote:

> According to the GCC documentation, the rationale for this feature is
> that traditional C allows it, but ISO C and ISO C++ disallow it.
> 
> So I'd say that, if all Debian packages either build fine without it,
> or enable it when needed, turning it off on all platforms may be
> reasonable.

Daniel just pointed out the case that I expected to see such code (the
kernel).  I hate to say it, but the x86 kernel code seems to be a frequent
spot to see such funky code in the wild (why is that anyway?).  Ugh.  And,
of course, getting any of that fixed is like pulling teeth from a hippo.

Hmmm....I'm wondering if this would be feasible:

Step 1: Make a case with the kernel folks to at least modify the Makefiles
        to add the --dollars-in-identifiers flag for x86.  Since this is
        the norm anyway, doing the modification shouldn't hurt anything.
Step 2: When that is done, disable it by default in our gcc on x86 only.
Step 3: Start making the case upstream with the gcc SC, or at least try.
        As you've pointed out, it takes forever to get rid of an option
        or change it in gcc, which is understandable in a way, so why not
        start sooner than later, right? :-)

In any case, I'm coming to the conclusion that the two bugs in question
probably won't get "fixed" for woody anyway, so we have time on this.  The
above is only one track of action that we could take.  Of course, the
better course is probably to investigate making the "$b" case distinct
from "c$b" and working from there.  The latter is ugly code, IMO, but at
least gas won't have a problem with it on x86 and could be considered
acceptable by some people's definitions (regarding the $b case,
though...if gas won't let it through on linux, I see no redeeming value
for making that case a warning only situation...at least as far as we are
concerned...upstream is another matter altogether).

C



Reply to: