From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Booth To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c++/1688: Includes causing extern "C" not to behave correctly (?) Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010118225602.7572.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00459.html List-Id: The following reply was made to PR c++/1688; it has been noted by GNATS. From: Neil Booth To: daniel@ncsu.edu Cc: gcc-gnats@gcc.gnu.org, Zack Weinberg Subject: Re: c++/1688: Includes causing extern "C" not to behave correctly (?) Date: Thu, 18 Jan 2001 18:55:41 +0000 Daniel Henninger wrote:- > > Look at the # LINENO directives created. Are they different? (The > > flag "4" at the end is to do with extern "C"). > > < # 1 "/usr/include/X11/Xlib.h" 1 3 4 > > # 1 "/usr/openwin/include/X11/Xlib.h" 1 > > The second one is where -I/usr/openwin/include was directly specified in > the include path. And of course: > stonecold [12:37pm] ~> ls -ld /usr/include/X11 > lrwxrwxrwx 1 root root 22 Jan 21 2000 /usr/include/X11 -> > ../openwin/include/X11 > > They are one in the same. So the 4 at the end of the first has to do with > the extern "C" directive? How about the 3? What's that for? I think this is your problem. We currently detect systemheader-ness (indicated by the flag "3") by the location the include file was found. But we don't follow symlinks. Once something is recognised as a system header, warnings are suppressed, and maybe other behaviour changes too. Zack, I think this is the first complaint we've had about this :-( I'm not sure whether following symlinks is a good solution or not, though. Neil. >>From bryce@gcc.gnu.org Sun Apr 01 00:00:00 2001 From: bryce@gcc.gnu.org To: bryce@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: libgcj/1572 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010119080601.10367.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00471.html Content-length: 972 The following reply was made to PR libgcj/1572; it has been noted by GNATS. From: bryce@gcc.gnu.org To: bothner@bothner.com, bryce@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: libgcj/1572 Date: 19 Jan 2001 08:00:59 -0000 Synopsis: make boot fails building libgcj due to missing include dir Responsible-Changed-From-To: unassigned->bryce Responsible-Changed-By: bryce Responsible-Changed-When: Fri Jan 19 00:00:59 2001 Responsible-Changed-Why: ... State-Changed-From-To: open->feedback State-Changed-By: bryce State-Changed-When: Fri Jan 19 00:00:59 2001 State-Changed-Why: This appears to be fixed. A java "make bootstrap" now completes without incident, and I can verify that the top-level Makefile passes down libstdc++-v3 include directories as part of the CXX definition even when bootstrap is used. Can you verify? http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1572&database=gcc >>From schmid@mowgli.iap.physik.tu-darmstadt.de Sun Apr 01 00:00:00 2001 From: schmid@mowgli.iap.physik.tu-darmstadt.de To: gcc-gnats@gcc.gnu.org Subject: fortran/2018: Sqrt causes ice in emit_move_insn, at expr.c:2718 Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <200102182346.AAA27416@mowgli.iap.physik.tu-darmstadt.de> X-SW-Source: 2001-q1/msg01469.html Content-length: 2313 >Number: 2018 >Category: fortran >Synopsis: Sqrt causes ice in emit_move_insn, at expr.c:2718 >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: ice-on-legal-code >Submitter-Id: net >Arrival-Date: Sun Feb 18 15:46:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Peter Schmid >Release: 2.97 20010216 (experimental) >Organization: TU Darmstadt >Environment: System: Linux kiste 2.4.1 #33 Thu Feb 15 12:51:39 CET 2001 i686 unknown Architecture: i686 SuSE-7.1 Glibc-2.2 GNU assembler version 2.10.91 (i686-pc-linux-gnu) using BFD version 2.10.1.0.4 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix >Description: The following simple code tbug.f triggers an internal compiler error. The call of the function sqrt causes the error. >How-To-Repeat: source tbug.f function f(c) implicit none real*8 c, f f = sqrt(c) return end Compiling tbug.f g77 -v -c tbug.f -W -Wall -Q g77 version 2.97 20010216 (experimental) (Fortran Frontend version 0.5.26 20010216 (experimental)) Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/specs Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix gcc version 2.97 20010216 (experimental) /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.97/f771 tbug.f -dumpbase tbug.f -W -Wall -version -o /tmp/cciqaby5.s GNU F77 version 2.97 20010216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 2.97 20010216 (experimental). options passed: -W -Wall options enabled: -fmove-all-movables -freduce-all-givs -fpeephole -ffunction-cse -fkeep-static-consts -fpcc-struct-return -fsched-interblock -fsched-spec -fbranch-count-reg -fnew-exceptions -fcommon -fgnu-linker -fargument-noalias-global -fident -m80387 -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 f_tbug.f: In function `f': tbug.f:4: Internal compiler error in emit_move_insn, at expr.c:2718 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. >Fix: >Release-Note: >Audit-Trail: >Unformatted: