--- Comment #8 from burnus at gcc dot gnu dot org 2008-11-03 07:21 ---
Subject: Bug 37821
Author: burnus
Date: Mon Nov 3 07:20:24 2008
New Revision: 141544
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141544
Log:
2008-11-03 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2008-11-03 07:35 ---
FIXED on the trunk.
Thanks for the report and sorry that it took that long to commit the fix.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
--- Comment #7 from burnus at gcc dot gnu dot org 2008-10-15 09:29 ---
Patch does not work - the . causes problems as a include (not #include)
does not work anymore: The . is not included. Still there is the issue about
the order . should be searched before the -I paths and it is not
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-14 12:11 ---
Confirm. gcc (the C compiler) has using -I test_directory:
#include ... search starts here:
#include ... search starts here:
test_directory
/usr/local/include
/projects/tob/gcc-trunk/include
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-10-14 12:23 ---
Bugger. How much time do we have left before 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
--- Comment #6 from chris dot walter at duke dot edu 2008-10-14 13:39
---
Sorry, for leaving out the test case, but I see it is confirmed now.
I can't use the conforming INCLUDE since I am dealing with a large legacy code
base and ~150 colleagues who are also using the code with
--- Comment #5 from burnus at gcc dot gnu dot org 2008-10-14 12:31 ---
(In reply to comment #3)
#include ... search starts here:
test_directory
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude
.
That . comes last is also wrong; it should come first for
