This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: zack's todo list


On Mon, Nov 13, 2000 at 07:10:49PM +0000, Joseph S. Myers wrote:
> On Mon, 13 Nov 2000, Zack Weinberg wrote:
> 
> >   - Make __FUNCTION__ et al allocate the string only when used.
> >     (Avoids pointless allocation of strings and decl structures for
> >     every function.  May mean we don't need prune_unused_decls
> >     anymore.)
> 
> If you're looking at __FUNCTION__ and related stuff, you might wish to
> look at the outstanding __func__ bugs (c99-func-[234].c and PR c/460).

Hrm.  The key bit is not taking part in string concatenation, which I
know about and will try to fix.  I can certainly get the type right.

I'm not convinced that c99-func-3 is correct.  6.4.2.2 says simply

    The identifier __func__ shall be implicitly declared by the
    translator as if, immediately following the opening brace of each
    function definition, the declaration

	static const char __func__[] = "function-name";

    appeared, where function-name is the name of the lexically-enclosing
    function.

Now where is it written that this requires that __func__ be separate
from other objects?  Can a s.c. program tell the difference?  On a
quick skim through 6.2.2-6.2.5, I see nothing prohibiting us from
merging identical static read-only objects, and the rules for pointer
equality say only that the test c99-func-3 does must pass iff __func__
and "main" are two separate objects...

Hm, I bet this is equivalent:

static const char a[] = "blah";
static const char b[] = "blah";

- must a and b be different?  The embedded people would surely like
  them to be merged.

> >   - Do installation in separate shell script?
> 
> More details?

I was primarily thinking that installation is currently done by an
incomprehensible shell script embedded in the makefile, and perhaps it
would be less incomprehensible if it was on its own and didn't have to
be backslashed to hell and back.  Also that it could be told the value
of $(LANGUAGES) at install time, and not have to do the icky dances we
do now to figure out what it is without actually using it.

> I know one problem with installation: installed headers are
> owned by the user who did the build rather than root (if installing as
> root but building as a user);

That should be fixed, agreed.

> and a desirable feature would be DESTDIR support;

I don't know what this is.

> and I was thinking of also installing under version-numbered
> names (gcc-3.0, etc.) to encourage keeping old drivers around rather than
> trying to use -V and complaining when it doesn't work

Probably a good idea.  Should we do this for all the drivers or just
gcc itself?  Maybe we should get rid of -V and -b while we're at it?

[I forgot to mention that I want to add language tagging for object
files, and make collect2 figure out which libraries to add.  This'd be
a big step toward not needing separate drivers for each language.  I
doubt it can happen in 3.0 though.]

zw

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]