On Wed, Apr 15, 2009 at 1:07 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Apr 15, 2009 at 11:51 AM, Tom Tromey <tro...@redhat.com> wrote: >>>>>>> "H.J." == H J Lu <hjl.to...@gmail.com> writes: >> >> H.J.> Can you take a look at my patch: >> H.J.> http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01829.html >> >> I looked at this today. I don't understand why the check is not done >> in the loop. Also I don't understand whether this patch can change >> the directory search order in cases like #include_next. Can you >> comment on this issue? > > gcc.dg/cpp/pr20356.c checks the expected behavior for #include_next. > My patch works with it. > >> And more generally, could you try to provide some explanation for how >> these patches are supposed to function? FWIW the reason it takes me >> so long to look at them is that I have to reverse engineer the logic, >> usually by applying the patch and stepping through with the >> debugger... which is an awful lot of work for a bug which is >> essentially cosmetic. >> > > There is only one patch: > > http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01829.html > > search_cache checks if the file can be found when starting > searching at START_DIR with a trailing '/'. If the start_dir field of > head of hash entry isn't NULL, it is the start search directory for > the cached file. If START_DIR + name is the same as > pathname for head and START_DIR is the directory which > contains the file, > > (!strncmp (start_dir->name, file->path, start_dir->len) > && !strcmp (file->name, file->path + start_dir->len))) > > that means the cached head is a perfect match. > We don't need to add START_DIR to start search at > START_DIR (with trailing '/') and then START_DIR (without > trailing '/') >
This is very old. I also forgot about it. OK for trunk? Thanks. -- H.J.
