_Pragma within macros is improperly expanded

2002-11-11 Thread Matthias Klose 

>Submitter-Id:  net
>Originator:Matthias Klose
>Organization:  
>Confidential:  no
>Synopsis:  _Pragma within macros is improperly expanded
>Severity:  serious
>Priority:  medium
>Category:  preprocessor
>Class: sw-bug
>Release:   3.2.1 2002-11-03
>Environment:
System: Linux smile 2.4.18-xfs #1 Tue Mar 12 22:42:02 CET 2002 i686 unknown
Architecture: i686


host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
>Description:
The original report from the Debian BTS, fix applied to head and branch:

[EMAIL PROTECTED]:~$ cat foo.c
_Pragma("foo"); int y;
#define FOO _Pragma("foo"); int x;
FOO
[EMAIL PROTECTED]:~$ cpp-3.2 foo.c
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"

# 1 "foo.c"
#pragma foo 
# 1 "foo.c"
 ; int y;


# 3 "foo.c"
#pragma ; int x;foo 

The first line is expanded correctly; the third is not (rendering
_Pragma almost completely useless).


Fixed by Neil:
* cpphash.h (FIRST, LAST, CUR, RLIMIT): Fix definitions.
* cpplib.c (destringize_and_run): Kludge around getting
tokens from in-progress macros.
(_cpp_do__Pragma): Simplify. testsuite:
* gcc.dg/cpp/_Pragma4.c: New test.

Bug submitter claims:

Nope, still not right. Here's a new case where it breaks:

[EMAIL PROTECTED]:~/tmp$ cat foo.c
#define ALPHA(A) alpha_ ## A
#define BETA(B) beta_ ## B
#define GAMMA(C) _Pragma("moose") ALPHA(C) BETA(C)
GAMMA(baz);
[EMAIL PROTECTED]:~/tmp$ cpp-3.2 foo.c
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"




# 4 "foo.c"
#pragma moose=20
# 4 "foo.c"
alpha_baz beta_alpha_baz;
[EMAIL PROTECTED]:~/tmp$ cpp-2.95 foo.c
# 1 "foo.c"



_Pragma("moose") alpha_bazbeta_baz;
=3D=3D

Note how beta_baz has become beta_alpha_baz in 3.2. This only happens
when the _Pragma is present, so I presume it's the same bug in another
form.

But wait! It gets better:

[EMAIL PROTECTED]:~/tmp$ cat foo.c
#define ALPHA
#define BETA(B) beta_ ## B
#define GAMMA(C) _Pragma("moose") ALPHA BETA(C)
GAMMA(baz);
[EMAIL PROTECTED]:~/tmp$ cpp-3.2 foo.c
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"




# 4 "foo.c"
#pragma moose=20
# 4 "foo.c"
cpp-3.2: Internal error: Aborted (program cpp0)
Please submit a full bug report.

>How-To-Repeat:

>Fix:

Bug#157416: preprocessor/8524: _Pragma within macros is improperly expanded

2002-11-11 Thread gcc-gnats 
Thank you very much for your problem report.
It has the internal identification `preprocessor/8524'.
The individual assigned to look at your
report is: unassigned. 

>Category:   preprocessor
>Responsible:unassigned
>Synopsis:   _Pragma within macros is improperly expanded
>Arrival-Date:   Sun Nov 10 22:36:00 PST 2002

Bug#157416: preprocessor/8524: _Pragma within macros is improperly expanded

2002-11-11 Thread neil 
Synopsis: _Pragma within macros is improperly expanded

Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: neil
Responsible-Changed-When: Sun Nov 10 22:44:07 2002
Responsible-Changed-Why:
Mine.
State-Changed-From-To: open->analyzed
State-Changed-By: neil
State-Changed-When: Sun Nov 10 22:44:07 2002
State-Changed-Why:
Yah, I'm not entirely surprised; the code in question is not pretty.  I'll 
take another look.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8524

Bug#168706: g++-3.0: Bad syntax error on nested classes' member functions.

2002-11-11 Thread Ian Turner 
Package: g++-3.0
Version: 1:3.0.4-7
Severity: normal

The source below makes G++-3.0 report a syntax error where none exists.

Basically it doesn't wait before giving up on the typename.

// Comment out to make it work.
#define BREAK

struct a {
  struct b {
typedef unsigned int foo_t;
foo_t frobnicate();
  };
};


#ifndef BREAK
a::b::foo_t a::b::frobnicate() {

}
#else
foo_t a::b::frobnicate() {
  return 0;
}
#endif


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux crafter 2.4.19 #1 Fri Sep 27 18:25:53 PDT 2002 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages g++-3.0 depends on:
ii  gcc-3.0   1:3.0.4-7  The GNU C compiler.
ii  gcc-3.0-base  1:3.0.4-7  The GNU Compiler Collection (base 
ii  libc6 2.2.5-14.3 GNU C Library: Shared libraries an
ii  libstdc++3-dev1:3.0.4-7  The GNU stdc++ library version 3 (

Re: libstdc++/8516 (broken links in libstdc++ html documentation)

2002-11-11 Thread Phil Edwards 
On Mon, Nov 11, 2002 at 10:27:16AM +, Jonathan Wakely wrote:
> On Sun, Nov 10, 2002 at 04:06:27PM +0100, Matthias Klose wrote:
> 
> > >Description:
> > running htdig on the installed set of html docs shows some
> > broken/non-existing links:
> 
> The files lwg-active.html and lwg-defects.html are copied verbatim from
> the standard committee site. As most of the links in those pages are
> relative links to other pages on that site, which aren't included in
> libstdc++, they don't work.

And in fact this is documented in ext/howto.html, which is the entry point
to the LWG files.

> The other broken links all appear to be for .txt files, which are included
> with the sources. They should be ok, but it looks like they've not been
> included with the HTML files.

I checked the libstdc++5-doc package just now.  They have been included,
but (in too-stringent accordance with Debian policy regarding /usr/share/doc
files) they've been gzipped.  Not Our Problem.  :-)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
 - Edsger Dijkstra, 1930-2002