This is the mail archive of the gcc-patches@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: Fix for "" vs <> inclusion bug


On Sat, Jun 24, 2000 at 09:34:09PM +0200, Laurynas Biveinis wrote:
> Zack Weinberg wrote:
> > On Sat, Jun 24, 2000 at 04:21:06PM +0200, Laurynas Biveinis wrote:
> > > I'll try to make a patch, which would close older files before opening
> > > new ones, if cpp starts hiting this limit.
> > 
> > Thanks, that would be great.  
> 
> OK, before I start coding, a question - is it worth keeping include
> file access counter in struct include_file and then browse the
> splay tree to determine the header which was earliest accessed to
> close it? It could be a little perfomance win. Or is it OK to close
> any suitable file? If yes, what's the best way to choose it
> from the splay tree?

As a first pass, I would just walk over the splay tree and close *all*
the open files.  That's simple, guaranteed to work, and should get
performance no worse than if the optimization didn't exist in the
first place.  Files are still read all at once, so you needn't worry
about closing a file under the reader.

In a second pass, you could add a counter to each include_file saying
how many times it has been read, and just close the files for which
n==1.

> > I wonder how many files it winds up
> > holding open in a typical build - a lot of GCC's internal headers
> > don't have reinclude guards, bleah.
> 
> Maybe I'll add some debugging code to see it.
> BTW, are there any reasons not to provide reinclude guards for other
> headers? I could do it someday.

As far as I know, it should be safe to add reinclude guards to all the
.h files.  There are some files that are intentionally read more than
once, but I think they all have the .def extension.

> > What's signal 33?
> 
> Cpp's exit code FATAL_EXIT_CODE

Huh - why does Make think it was a signal, then?

zw

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