PING: PATCH: PR preprocessor/39533: -MM may list a header file twice

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Apr 15, 2009 at 1:07 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Apr 15, 2009 at 11:51 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "H.J." == H J Lu <hjl.tools@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.