Re: preprocessor/1565 (fwd)

Re: preprocessor/1565 (fwd)

[Richard B. Kreckel]

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

From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Bruno Haible <haible@ilog.fr>, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Fri, 19 Jan 2001 21:14:12 +0100 (CET)

 On Mon, 8 Jan 2001, Neil Booth wrote:
 > Indeed, but the expansion of (Y) is special - it is not a nested
 > replacement as the phrasing of the standard [attempts to] make clear.
 > It's a shame the standard doesn't have an example like PR/1565.
 
 Indeed, it is.  Neil, maybe you already know, since Martin Sebor seems to
 have been in touch with you, but let me forward a piece of email I just
 got to you anyways.  I hope this can be fixed now that the question has
 been clarified.
 
 best wishes
         -richy.
 -- 
 Richard Kreckel
 <Richard.Kreckel@Uni-Mainz.DE>
 < http://wwwthep.physik.uni-mainz.de/~kreckel/ >
 
 
 
 From: bs@research.att.com Fri Jan 19 21:01:20 2001
 Date: Fri, 19 Jan 2001 13:07:24 -0500 (EST)
 From: Bjarne Stroustrup <bs@research.att.com>
 To: kreckel@thep.physik.uni-mainz.de
 Subject: Re: macro magic
 
 Here is feedback. Dave Prosser (who was AT&T's representative to the C 
 committee for years and its editor) is as authoratative as an individual can 
 be on this subject.
 
 	- Bjarne
 	
 	
 ------------- Begin Forwarded Message -------------
 
 From: Dave Prosser <dfp@sco.com>
 Delivered-To: c++std-core@research.att.com
 Date: Fri, 19 Jan 2001 11:04:39 -0500
 MIME-Version: 1.0
 Subject: Re: macro magic
 Content-Transfer-Encoding: 7bit
 
 To: C++ core language mailing list
 Message c++std-core-9035
 
 I don't usually feel the need to add my comments to this list.  Please
 forgive the length of this reply, but you need to be careful what you
 ask for since you might get an answer.
 
 Martin Sebor wrote:
 > Bjarne Stroustrup wrote:
 > > I have received a question about macro substitution prompted by a discussion
 > > about GCC3.
 > >
 > > The question is, Given
 > >
 > >         #define NIL(xxx)  xxx
 > >         #define G_0(arg) NIL(G_1) (arg)
 > >         #define G_1(arg) NIL(arg)
 > >         G_0(42)
 > >
 > > Should this result in 'NIL(42)' or rather in plain '42'? I did not find the
 > > answer obvious from the standards text.
 > 
 > Since this issue affects some of our code I have discussed it in some detail
 > with the implementor of gcc's new preprocessor (and some compiler writers). As
 > is apparent from the issue, Neil's position is that this example represents a
 > potential recursive expansion(*) and thus stops at NIL(42).
 > 
 > gcc expands the macro call like so:
 > 
 > 0.    G_0(42)
 > 1.      NIL(G_1) (42)
 > 2.        G_1 (42)
 > 3.          NIL(42)   <--- NIL not expanded again
 > 
 > The preprocessor stops at step 3 since recursive expansion is not performed.
 > 
 > All other compilers apparently consider the expansion started at step 1 complete
 > at step 3 and perform another step, yielding 42.
 > 
 > 0.    G_0(42)
 > 1.      NIL(G_1) (42)
 > 2.        G_1 (42)   <--- expansion of NIL complete
 > 3.      NIL(42)
 > 4.      42
 > 
 > I personally think the text could be interpreted both ways and could stand
 > clarification. But that's an issue for WG14.
 > 
 > Martin
 > 
 > (*) 6.10.3.4, p2 of C99: If the name of the macro being replaced is found during
 > this scan of the replacement list (not including the rest of the source file^Rs
 > preprocessing tokens), it is not replaced. Furthermore, if any nested
 > replacements encounter the name of the macro being replaced, it is not replaced.
 > These nonreplaced macro name preprocessing tokens are no longer available for
 > further replacement even if they are later (re)examined in contexts in which
 > that macro name preprocessing token would otherwise have been replaced.
 
 Having been the author of the compromise preprocessing algorithm
 specified in the first C standard, I assert that the intent of
 the specification is that the result is "42".  Whether the text
 of the standard can justify such is a different question.  If
 this question were passed to the C committee for an interpretation,
 the committee documents would presumbly be used as necessary to
 make the intent clear.
 
 It's good to hear that almost all implementation get this one
 "right".
 
 When we were wrestling with the different worlds of preprocessing
 behavior back in the mid 80's on the C committee, we decided that
 "the right" thing to do was first to specify an algorithm and
 then try to describe it in standardese after we had agreed with
 the algorithm's behavior.
 
 I've got a yellowed copy of the algorithm paper dated 4 Dec 1986
 (X3J11/86-196) that used a C-like pseudo functional programming
 language to describe the preprocessing behavior:
 
 expand(TS) /* recur, substitute, pushback, rescan */
 {
     if TS is {} then
 	return {};
 
     else if TS is T<HS> * TS' and T is in HS then
 	return T<HS> * expand(TS');
 
     else if TS is T<HS> * TS' and T is a "()-less macro" then
 	return expand(subst(ts(T),{},{},HS|{T},{}) * TS');
 
     else if TS is T<HS> * ( * TS' and T is a "()'d macro" then
       check TS' is actuals * )<HS'> * TS'' and actuals are "correct for T"
 	return expand(subst(ts(T),fp(T),actuals,(HS&HS')|{T},{}) * TS'');
 
     note TS must be T<HS> * TS'
     return T<HS> * expand(TS');
 }
 
 The *'s above a list concatenation "operators", the notation T<HS>
 means a token T with "hide set" HS, a {} represents an empty set
 or list, | is used for set union, and a & means a set intersection.
 (The typeset version of the paper is easier to read.)
 
 The paper goes on to specify subst() and two other support routines.
 The remaining four routines two of which are used above (ts and fp)
 are just described.
 
 subst() does the replacement of formals with actuals, usually doing
 a recursive expand() on the actuals as they are being inserted in
 the resulting token sequence.  The final step of subst() is to
 add (union) in the hide set given in its invocation across the
 entire resulting token sequence.
 
 What determines the result of Bjarne's example is the hide set
 passed to subst() for the "()'d macro" case above.  The hide set
 is the named macro added to the *intersection* of the hide sets
 for the first and last tokens in the function-like invocation.
 This was a deliberate choice intended to allow the most reasonable
 macro replacement while still preventing infinite recursions.
 
 So, in particular, when we do the subst() step on "G_0(42)"
 we produce a token sequence
 	NIL<G_0> * (<G_0> * G_1<G_0> * )<G_0) * (<G_0> * 42<G_0> * )<G_0>
 which is handed back to expand().  It passes the invocation
 "NIL(G_1)" to subst() resulting in the following sequence handed
 back to expand():
 	G_1<G_0,NIL> * (<G_0> * 42<G_0> * )<G_0>
 
 Note that the hide sets for the first token of the invocation
 "G_1(42)" differ.  The intersection of the two results in just
 <G_0> which means that NIL is *not* hidden in the resulting
 sequence handed back to expand():
 	NIL<G_0,G_1> * (<G_0,G_1> * 42<G_0,G_1> * )<G_0,G_1>
 
 Thus the invocation "NIL(42)" will be substituted, resulting
 in the single token
 	42<G_0,G_1,NIL>
 
 -- 
 Dave Prosser dfp@sco.com (908)790-2358 Rm A332, SCO, Murray Hill, NJ
 
 ------------- End Forwarded Message -------------
 
 
 	- Bjarne
 Bjarne Stroustrup, http://www.research.att.com/~bs 
 
>From apbianco@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: apbianco@gcc.gnu.org
To: apbianco@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: java/1204
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010209005600.11555.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01088.html
Content-length: 587

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

From: apbianco@gcc.gnu.org
To: apbianco@gcc.gnu.org, gcc-gnats@gcc.gnu.org, green@cygnus.com
Cc:  
Subject: Re: java/1204
Date: 9 Feb 2001 00:53:27 -0000

 Synopsis: Definite assignment problem
 
 State-Changed-From-To: open->closed
 State-Changed-By: apbianco
 State-Changed-When: Thu Feb  8 16:53:27 2001
 State-Changed-Why:
     Per checked in a patch for that recently.  I can't reproduce 
     the problem. I'm closing this PR.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=1204&database=gcc
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1700
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010314232605.3486.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02359.html
Content-length: 530

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

From: neil@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, vakopian@usc.edu
Cc:  
Subject: Re: c++/1700
Date: 14 Mar 2001 23:25:10 -0000

 Synopsis: g++ 2.97 20010110 does not compile correct code.
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: neil
 State-Changed-When: Wed Mar 14 15:25:04 2001
 State-Changed-Why:
     No preprocessed source forthcoming.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1700&database=gcc

Re: preprocessor/1565 (fwd)

[Bruno Haible]

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

From: Bruno Haible <haible@ilog.fr>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: gcc-gnats@gcc.gnu.org, kreckel@zino.physik.Uni-Mainz.DE,
        nobody@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Mon, 8 Jan 2001 21:13:46 +0100 (CET)

 Neil Booth writes:
 
 > So you still fall under
 > 
 > "Furthermore, if any nested replacements encounter the name of the
 > macro being replaced, it is not replaced"
 
 The question is whether "nested replacements" means only those which
 are done without the rest of the source file's preprocessing tokens,
 or whether it on the contrary means all those which start with a macro
 token that results from the rescanning. It's not clear.
 
 Bruno
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/2150
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010314113601.16317.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02316.html
Content-length: 511

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

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, treaves@silverfields.com
Cc:  
Subject: Re: c++/2150
Date: 14 Mar 2001 11:27:12 -0000

 Synopsis: Internal compiler error.
 
 State-Changed-From-To: open->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Wed Mar 14 03:27:11 2001
 State-Changed-Why:
     Fixed in the CVS branch 3.0.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2150&database=gcc

Re: preprocessor/1565 (fwd)

[Bruno Haible]

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

From: Bruno Haible <haible@ilog.fr>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: neil@gcc.gnu.org, gcc-gnats@gcc.gnu.org, kreckel@zino.physik.Uni-Mainz.DE,
        nobody@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Mon, 8 Jan 2001 20:07:50 +0100 (CET)

 Neil Booth writes:
 
 > >      GEN_LF_OP2_AUX1
 > > 
 > > Here the "this scan" must stop because it needs more tokens. With the
 > > next tokens from the file we get
 > 
 > Yes.  But if I understand what you're trying to imply, I think you're
 > misreading this.  Indeed, one of the examples in the standard refutes
 > what you're saying.  Check out the example that reads
 > 
 > #define t(a) a
 > 
 > f(y+1) + f(f(z)) % t(t(g)(0) + t)(1);
 >                                ^^^^^
 
 There is a crucial difference between this example and
 preprocessor/1565. Namely, in the example, after expansion of
 
          t(t(g)(0) + t)
 
          t(g)(0) + t
 
          g(0) + t
 
          f(0) + t
 
          f(2 * (0)) + t
 
 the 't' is already already in the list of tokens before any other
 tokens from the file are looked at. This is what 6.10.3.4.2 points at:
   "These nonreplaced macro name preprocessing tokens are no longer
    available for further replacement ..."
 
 Whereas in preprocessor/1565, we have the expansion
 
          GEN_F_OP2
 
          CONCAT(GEN_LF_OP2_AUX,1)
 
          CONCAT_(GEN_LF_OP2_AUX,1)
 
          GEN_LF_OP2_AUX1
 
 and the result of the rescan does _not_ contain the token CONCAT.
 
 > You seem to be saying that that the t(1) that will result here should
 > expand, because the (1) is coming from the rest of the file, after the
 > scan of the outer t() has been exhausted.
 
 No, I'm not saying that. The two cases are different.
 
 > The words "(not including the rest of the source file's preprocessing
 > tokens)" are referring to the second 'X' in examples like this:-
 > 
 > #define e(n) 4 + n
 > #define X e
 > 
 > X(X)
 > 
 > which expands to "4 + e", since we read the "(X)" from the rest of the
 > source file and expand it, even though we are still expanding the
 > original X.
 
 How do you handle
 
    #define e(n) 4 + n
    #define Y X
    #define X e
 
    X(Y)
 
 ? I hope it returns "4 + e" as well. Then compare it with my case
 (substitute CONCAT for X)...
 
 > I have no intention of reverting this behaviour.  The standard is
 > quite clear; the new CPP is correct.  A fix for the end-user software
 > is trivial, too: simply redefine a duplicate of the CONCAT macro with
 > a different name, e.g. CONCAT2 or CONCAT_NESTED.
 
 No, it's not as simple. Essentially every macro which calls CONCAT
 needs to have its own private version of CONCAT, each with a different
 name.
 
 Bruno
 
>From dje@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: dje@gcc.gnu.org
To: dje@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/812
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010319202603.29121.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02461.html
Content-length: 704

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

From: dje@gcc.gnu.org
To: dje@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  nparpand@perinfo.com
Cc:  
Subject: Re: c++/812
Date: 19 Mar 2001 20:17:04 -0000

 Synopsis: C++ doesnt work with threads on AIX
 
 Responsible-Changed-From-To: unassigned->dje
 Responsible-Changed-By: dje
 Responsible-Changed-When: Mon Mar 19 12:17:01 2001
 Responsible-Changed-Why:
     AIx issue
 State-Changed-From-To: open->closed
 State-Changed-By: dje
 State-Changed-When: Mon Mar 19 12:17:01 2001
 State-Changed-Why:
     addressed in forthcoming gcc-3.0 release
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=812&database=gcc

Re: preprocessor/1565 (fwd)

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: Bruno Haible <haible@ilog.fr>, gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Fri, 19 Jan 2001 20:35:32 +0000

 Richard B. Kreckel wrote:-
 
 > Indeed, it is.  Neil, maybe you already know, since Martin Sebor seems to
 > have been in touch with you, but let me forward a piece of email I just
 > got to you anyways.  I hope this can be fixed now that the question has
 > been clarified.
 > 
 > best wishes
 >         -richy.
 
 Hi Richard,
 
 Where is this e-mail conversation taking place?  Is it in public?
 
 I guess I should find out a way to revert this behaviour.  I think
 it's not too hard, but I'm not sure.
 
 Cheers,
 
 Neil.
>From tromey@redhat.com Sun Apr 01 00:00:00 2001
From: tromey@redhat.com
To: gcc-gnats@gcc.gnu.org
Subject: libgcj/2441: RegisterNatives fails without interpreter
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010331000445.20867.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02684.html
Content-length: 723

>Number:         2441
>Category:       libgcj
>Synopsis:       RegisterNatives fails without interpreter
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 30 16:06:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Tom Tromey
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
The JNI RegisterNatives function always fails
unless the interpreter is enabled.  This is wrong.
RegisterNatives should always work.  One way to do
this would be to maintain a hash table holding the
mapping.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: preprocessor/1565 (fwd)

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Bruno Haible <haible@ilog.fr>
Cc: gcc-gnats@gcc.gnu.org, kreckel@zino.physik.Uni-Mainz.DE,
	nobody@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Mon, 8 Jan 2001 19:25:53 +0000

 Bruno Haible wrote:-
 
 > There is a crucial difference between this example and
 > preprocessor/1565. Namely, in the example, after expansion of
 > 
 >          t(t(g)(0) + t)
 > 
 >          t(g)(0) + t
 > 
 >          g(0) + t
 > 
 >          f(0) + t
 > 
 >          f(2 * (0)) + t
 > 
 > the 't' is already already in the list of tokens before any other
 > tokens from the file are looked at. This is what 6.10.3.4.2 points at:
 
 True [though the argument is expanded first].
 
 >   "These nonreplaced macro name preprocessing tokens are no longer
 >    available for further replacement ..."
 > 
 > Whereas in preprocessor/1565, we have the expansion
 > 
 >          GEN_F_OP2
 > 
 >          CONCAT(GEN_LF_OP2_AUX,1)
 > 
 >          CONCAT_(GEN_LF_OP2_AUX,1)
 > 
 >          GEN_LF_OP2_AUX1
 > 
 > and the result of the rescan does _not_ contain the token CONCAT.
 
 OK, I see what you're getting at [apologies I see now I got the
 reference wrong in my previous mail].  But you're still nested within
 the original CONCAT expansion - it has not yet completely finished,
 otherwise you cannot explain your desire to scan again - even though
 you pull in extra tokens from the source file for GEN_LF_OP2_AUX1.
 Maybe that is where we disagree.
 
 So you still fall under
 
 "Furthermore, if any nested replacements encounter the name of the
 macro being replaced, it is not replaced"
 
 in my opinion, and do not expand.
 
 > How do you handle
 > 
 >    #define e(n) 4 + n
 >    #define Y X
 >    #define X e
 > 
 >    X(Y)
 
 Indeed, but the expansion of (Y) is special - it is not a nested
 replacement as the phrasing of the standard [attempts to] make clear.
 It's a shame the standard doesn't have an example like PR/1565.
 
 Neil.
>From rodrigc@mediaone.net Sun Apr 01 00:00:00 2001
From: Craig Rodrigues <rodrigc@mediaone.net>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1519
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010218004602.26118.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01419.html
Content-length: 1127

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

From: Craig Rodrigues <rodrigc@mediaone.net>
To: gcc-gnats@gcc.gnu.org, johnspooner@earthlink.net, nobody@gcc.gnu.org,
   rodrigc@mediaone.net
Cc:  
Subject: Re: c++/1519
Date: Sat, 17 Feb 2001 19:42:05 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1519&database=gcc
 
 Tested with:
 gcc version 2.97 20010211 (experimental)
 from http://www.codesourcery.com/gcc-snapshots/
 
 Compiling the attached testcase yielded the following compiler
 errors:
 In file included from slots.moc:18,
                  from slots.cpp:3:
 slots.h:8: redefinition of `class myclass'
 slots.h:8: previous definition of `class myclass'
 slots.h:8: confused by earlier errors, bailing out
 
 No internal compiler errors occurred.
 
 Should this bug report be closed?
 
 Note, bug reports for Redhat's distribution of gcc should
 be directed to http://bugzilla.redhat.com/bugzilla .
 
 You may wish to obtain a new version of Redhat's
 gcc package from:
 ftp://rawhide.redhat.com/
 
 --
 Craig Rodrigues
 http://www.gis.net/~craigr
 rodrigc@mediaone.net
 
 
 

Re: preprocessor/1565 (fwd)

[Richard B. Kreckel]

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

From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Richard.Kreckel@uni-mainz.de, Bruno Haible <haible@ilog.fr>,
        gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/1565 (fwd)
Date: Fri, 19 Jan 2001 21:45:09 +0100 (CET)

 On Fri, 19 Jan 2001, Neil Booth wrote:
 > Where is this e-mail conversation taking place?  Is it in public?
 
 Sorry, I don't know whether "C++ core language mailing list"
 <c++std-core@research.att.com> is public or archived somewhere.  Google
 produces no results. :(   I have simply asked Bjarne if he knew some
 authority on this topic and he came up with this conversation.  There was
 no further expanation.
 
 > I guess I should find out a way to revert this behaviour.  I think
 > it's not too hard, but I'm not sure.
 
 Luck,
   -richy.
 -- 
 Richard Kreckel
 <Richard.Kreckel@Uni-Mainz.DE>
 < http://wwwthep.physik.uni-mainz.de/~kreckel/ >
 
 
>From gcc-bug@vogtnerdo Sun Apr 01 00:00:00 2001
From: gcc-bug@vogtner do
To: gcc-gnats@gcc.gnu.org
Subject: g++ runs out of memory if reference parameter is initialized with 0
Date: Sun, 01 Apr 2001 00:00:00 -0000
X-SW-Source: 2001-q1/msg01664.html
Content-length: 11

>Number:  
>From green@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: green@gcc.gnu.org
To: green@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: java/1380
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010217200600.1885.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01363.html
Content-length: 546

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

From: green@gcc.gnu.org
To: Heinz@chanet.de, gcc-gnats@gcc.gnu.org, green@gcc.gnu.org
Cc:  
Subject: Re: java/1380
Date: 17 Feb 2001 20:01:39 -0000

 Synopsis: Compiling Gnu's regexp for Java
 
 State-Changed-From-To: open->feedback
 State-Changed-By: green
 State-Changed-When: Sat Feb 17 12:01:39 2001
 State-Changed-Why:
     This was fixed recently.  Try the GCC v3 branch or recent snapshots.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1380&database=gcc