Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

[Neil Booth]

The following reply was made to PR preprocessor/3243; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: aoliva@gcc.gnu.org
Cc: carlo@alinoe.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory
Date: Tue, 19 Jun 2001 21:11:10 +0100

 aoliva@gcc.gnu.org wrote:-
 
 > State-Changed-Why:
 
 > Seems to be a preprocessor bug.  #include "file.h" should look for
 > file.h in the directory containing the file being processed first,
 > regardless of the header search path or -I-.
 
 No, that is not what is implemented, nor is it what is documented.
 So, either the bug lies elsewhere, or we need a good reason to change
 the documented behaviour.
 
 Neil.

Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

[Alexandre Oliva]

The following reply was made to PR libstdc++/3243; it has been noted by GNATS.

From: Alexandre Oliva <aoliva@redhat.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>, libstdc++@gcc.gnu.org
Cc: carlo@alinoe.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory
Date: 20 Jun 2001 17:15:53 -0300

 On Jun 19, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:
 
 > aoliva@gcc.gnu.org wrote:-
 >> State-Changed-Why:
 
 >> Seems to be a preprocessor bug.  #include "file.h" should look for
 >> file.h in the directory containing the file being processed first,
 >> regardless of the header search path or -I-.
 
 > No, that is not what is implemented, nor is it what is documented.
 > So, either the bug lies elsewhere, or we need a good reason to change
 > the documented behaviour.
 
 I stand corrected.  I didn't know about this detail in the
 documentation and implementation of -I-.  This means gthr.h must
 indeed be fixed to take this possibility into account.  Unfortunately,
 Carlo's patch isn't enough, since it breaks bootstrap.
 
 -- 
 Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
 Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
 CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
 Free Software Evangelist    *Please* write to mailing lists, not to me

Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

[Carlo Wood]

The following reply was made to PR libstdc++/3243; it has been noted by GNATS.

From: Carlo Wood <carlo@alinoe.com>
To: Zack Weinberg <zackw@stanford.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory
Date: Wed, 20 Jun 2001 17:23:11 +0200

 On Tue, Jun 19, 2001 at 06:13:47PM -0700, Zack Weinberg wrote:
 > -I- can indeed break system headers that expect the 'directory of the
 > current file' to be searched.  That may not be a good enough reason to
 > change a feature with that length of tenure.  I am all for separating
 > the two effects, if we can agree on the interface and the degree of
 > backward compatibility.
 
 Then no matter the decision about -I-'s effect, gthr.h should be changed
 to #include "bits/whatever" rather than #include "whatever".
 
 If that breaks bootstrapping then that is problem two.
 
 -- 
 Carlo Wood <carlo@alinoe.com>

Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

[Zack Weinberg]

The following reply was made to PR preprocessor/3243; it has been noted by GNATS.

From: "Zack Weinberg" <zackw@stanford.edu>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   carlo@alinoe.com
Cc:  
Subject: Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory
Date: Tue, 19 Jun 2001 18:13:47 -0700

 To clarify what Neil said:  -I- has had the documented effect of
 separating "" and <> search paths, *and* inhibiting the search of the
 'directory of the current file', since at least 2.7.2.
 
 -I- can indeed break system headers that expect the 'directory of the
 current file' to be searched.  That may not be a good enough reason to
 change a feature with that length of tenure.  I am all for separating
 the two effects, if we can agree on the interface and the degree of
 backward compatibility.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3243&database=gcc
 
 -- 
 zw     Well, there's another triumph for clean hands, a pure heart, a good
        soul...and vastly superior technology.
        	-- _Undocumented Features: Out in the Cold_

Re: preprocessor/3243: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

[aoliva]

Synopsis: /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory

State-Changed-From-To: open->analyzed
State-Changed-By: aoliva
State-Changed-When: Tue Jun 19 06:27:32 2001
State-Changed-Why:
    Seems to be a preprocessor bug.  #include "file.h" should look for file.h in the directory containing the file being processed first, regardless of the header search path or -I-.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3243&database=gcc