new fails on gcc 3.4, i686-unknown-openbsd3.1

new fails on gcc 3.4, i686-unknown-openbsd3.1

[Andrew Pinski]

The new failures on i686-unknown-openbsd3.1 are caused by the new  
parser and/or
the definition of __BEGIN_DECLS/__END_DECLS in openbsd's header,  
sys/cdefs.h:
#define __BEGIN_DECLS   extern "C" {
#define __END_DECLS     };

Note the semicolon after }, that is what is causing it.

Thanks,
Andrew Pinski

On Saturday, Dec 28, 2002, at 07:05 US/Eastern, Andrew Thomas Pinski  
wrote:

> Native configuration is i686-unknown-openbsd3.1
>
> 		=== g++ tests ===
>
>
> Running target unix
> FAIL: g++.dg/abi/bitfield4.C (test for excess errors)
> WARNING: g++.dg/abi/bitfield4.C compilation failed to produce  
> executable
> FAIL: g++.dg/abi/enum1.C (test for excess errors)
> WARNING: g++.dg/abi/enum1.C compilation failed to produce executable
> FAIL: g++.dg/ext/instantiate2.C scan-assembler
> FAIL: g++.dg/init/array4.C (test for excess errors)
> FAIL: g++.dg/init/init-ref1.C (test for excess errors)
> WARNING: g++.dg/init/init-ref1.C compilation failed to produce  
> executable
> FAIL: g++.dg/init/pm1.C (test for excess errors)
> WARNING: g++.dg/init/pm1.C compilation failed to produce executable
> XPASS: g++.dg/other/anon-struct.C  (test for bogus messages, line 8)
> XPASS: g++.dg/parse/angle-bracket.C  (test for bogus messages, line 7)
> FAIL: g++.dg/parse/stack1.C (test for excess errors)
> FAIL: g++.dg/rtti/cv1.C (test for excess errors)
> WARNING: g++.dg/rtti/cv1.C compilation failed to produce executable
> FAIL: g++.dg/template/friend.C (test for excess errors)
> FAIL: g++.dg/template/friend10.C (test for excess errors)
> WARNING: g++.dg/template/friend10.C compilation failed to produce  
> executable
> FAIL: g++.dg/template/pretty1.C (test for excess errors)
> WARNING: g++.dg/template/pretty1.C compilation failed to produce  
> executable
> FAIL: g++.dg/warn/Wunused-2.C  (test for warnings, line 5)
> FAIL: g++.abi/arraynew.C (test for excess errors)
> FAIL: g++.abi/cxa_vec.C (test for excess errors)
> FAIL: g++.abi/vbase1.C (test for excess errors)
> FAIL: g++.abi/vtable3a.C caused compiler crash
> FAIL: g++.abi/vtable3b.C caused compiler crash
> FAIL: g++.abi/vtable3c.C caused compiler crash
> FAIL: g++.abi/vtable3d.C caused compiler crash
> FAIL: g++.abi/vtable3e.C caused compiler crash
> FAIL: g++.abi/vtable3f.C caused compiler crash
> FAIL: g++.abi/vtable3g.C caused compiler crash
> FAIL: g++.abi/vtable3h.C caused compiler crash
> FAIL: g++.abi/vtable3i.C caused compiler crash
> FAIL: g++.abi/vtable3j.C caused compiler crash
> FAIL: g++.benjamin/14687.C (test for excess errors)
> FAIL: g++.benjamin/15071.C (test for excess errors)
> FAIL: g++.benjamin/15822.C (test for excess errors)
> FAIL: g++.benjamin/bool01.C (test for excess errors)
> FAIL: g++.benjamin/bool02.C (test for excess errors)
> FAIL: g++.bob/inherit2.C (test for excess errors)
> FAIL: g++.brendan/copy9.C (test for excess errors)
> FAIL: g++.brendan/crash15.C (test for excess errors)
> FAIL: g++.brendan/crash20.C (test for excess errors)
> FAIL: g++.brendan/crash30.C (test for excess errors)
> FAIL: g++.brendan/crash38.C (test for excess errors)
> FAIL: g++.brendan/crash49.C (test for excess errors)
> FAIL: g++.brendan/crash62.C (test for excess errors)
> FAIL: g++.brendan/cvt1.C (test for excess errors)
> FAIL: g++.brendan/err-msg3.C (test for excess errors)
> FAIL: g++.brendan/nest21.C (test for excess errors)
> FAIL: g++.brendan/new3.C (test for excess errors)
> XPASS: g++.brendan/parse4.C - treated as decl (test for bogus  
> messages, line 22)
> XPASS: g++.brendan/parse4.C - treated as decl (test for bogus  
> messages, line 23)
> XPASS: g++.brendan/parse5.C - (test for bogus messages, line 24)
> XPASS: g++.brendan/parse6.C - (test for bogus messages, line 12)
> FAIL: g++.brendan/ptolemy2.C (test for excess errors)
> FAIL: g++.brendan/template8.C (test for excess errors)
> FAIL: g++.brendan/temporary1.C (test for excess errors)
> XPASS: g++.bugs/900404_04.C , (test for errors, line 15)
> FAIL: g++.eh/catchptr1.C (test for excess errors)
> FAIL: g++.eh/cleanup2.C (test for excess errors)
> FAIL: g++.eh/flow1.C (test for excess errors)
> FAIL: g++.eh/new1.C (test for excess errors)
> FAIL: g++.eh/new2.C (test for excess errors)
> FAIL: g++.eh/rethrow1.C (test for excess errors)
> FAIL: g++.eh/rethrow2.C (test for excess errors)
> FAIL: g++.eh/rethrow3.C (test for excess errors)
> FAIL: g++.eh/rethrow4.C (test for excess errors)
> FAIL: g++.eh/rethrow5.C (test for excess errors)
> FAIL: g++.eh/rethrow6.C (test for excess errors)
> FAIL: g++.eh/spec1.C (test for excess errors)
> FAIL: g++.eh/spec2.C (test for excess errors)
> FAIL: g++.eh/spec3.C (test for excess errors)
> FAIL: g++.eh/spec4.C (test for excess errors)
> FAIL: g++.eh/terminate1.C (test for excess errors)
> FAIL: g++.eh/terminate2.C (test for excess errors)
> FAIL: g++.ext/pretty2.C (test for excess errors)
> FAIL: g++.ext/pretty3.C (test for excess errors)
> FAIL: g++.jason/access23.C (test for excess errors)
> XPASS: g++.jason/access8.C cannot convert to inh (test for errors,  
> line 28)
> XPASS: g++.jason/ambig3.C - late parsing (test for bogus messages,  
> line 12)
> XPASS: g++.jason/ambig3.C - late parsing (test for bogus messages,  
> line 14)
> FAIL: g++.jason/init3.C (test for excess errors)
> FAIL: g++.jason/rfg7.C (test for excess errors)
> FAIL: g++.jason/template24.C (test for excess errors)
> FAIL: g++.jason/template26.C caused compiler crash
> FAIL: g++.jason/template31.C (test for excess errors)
> FAIL: g++.jason/template44.C (test for excess errors)
> FAIL: g++.jason/typeid1.C (test for excess errors)
> FAIL: g++.law/arg1.C (test for excess errors)
> FAIL: g++.law/arg7.C (test for excess errors)
> FAIL: g++.law/arg8.C (test for excess errors)
> FAIL: g++.law/arg9.C (test for excess errors)
> FAIL: g++.law/arm12.C (test for excess errors)
> FAIL: g++.law/arm13.C (test for excess errors)
> FAIL: g++.law/arm15.C (test for excess errors)
> FAIL: g++.law/arm9.C (test for excess errors)
> FAIL: g++.law/array1.C (test for excess errors)
> FAIL: g++.law/bad-error7.C (test for excess errors)
> FAIL: g++.law/bit-fields2.C (test for excess errors)
> FAIL: g++.law/code-gen1.C (test for excess errors)
> FAIL: g++.law/code-gen2.C (test for excess errors)
> FAIL: g++.law/code-gen5.C (test for excess errors)
> FAIL: g++.law/copy1.C (test for excess errors)
> FAIL: g++.law/ctors10.C (test for excess errors)
> FAIL: g++.law/ctors12.C (test for excess errors)
> FAIL: g++.law/ctors13.C (test for excess errors)
> FAIL: g++.law/ctors15.C (test for excess errors)
> FAIL: g++.law/ctors16.C (test for excess errors)
> FAIL: g++.law/ctors17.C (test for excess errors)
> FAIL: g++.law/ctors2.C (test for excess errors)
> FAIL: g++.law/ctors6.C (test for excess errors)
> FAIL: g++.law/ctors8.C (test for excess errors)
> FAIL: g++.law/cvt10.C (test for excess errors)
> FAIL: g++.law/cvt11.C (test for excess errors)
> FAIL: g++.law/cvt12.C (test for excess errors)
> FAIL: g++.law/cvt16.C (test for excess errors)
> FAIL: g++.law/cvt2.C (test for excess errors)
> FAIL: g++.law/cvt7.C (test for excess errors)
> FAIL: g++.law/dtors2.C (test for excess errors)
> FAIL: g++.law/dtors3.C (test for excess errors)
> FAIL: g++.law/dtors4.C (test for excess errors)
> FAIL: g++.law/dtors5.C (test for excess errors)
> FAIL: g++.law/global-init1.C (test for excess errors)
> FAIL: g++.law/init11.C (test for excess errors)
> FAIL: g++.law/init14.C (test for excess errors)
> FAIL: g++.law/missed-error2.C (test for excess errors)
> FAIL: g++.law/nest3.C (test for excess errors)
> FAIL: g++.law/operators16.C (test for excess errors)
> FAIL: g++.law/operators23.C (test for excess errors)
> FAIL: g++.law/operators28.C (test for excess errors)
> FAIL: g++.law/operators30.C (test for excess errors)
> FAIL: g++.law/operators32.C (test for excess errors)
> FAIL: g++.law/operators33.C (test for excess errors)
> FAIL: g++.law/operators4.C (test for excess errors)
> FAIL: g++.law/operators8.C (test for excess errors)
> FAIL: g++.law/profile1.C (test for excess errors)
> FAIL: g++.law/refs1.C (test for excess errors)
> FAIL: g++.law/scope2.C (test for excess errors)
> FAIL: g++.law/temps2.C (test for excess errors)
> FAIL: g++.law/temps3.C (test for excess errors)
> FAIL: g++.law/temps5.C (test for excess errors)
> FAIL: g++.law/temps6.C (test for excess errors)
> FAIL: g++.law/vbase1.C (test for excess errors)
> FAIL: g++.law/virtual2.C (test for excess errors)
> FAIL: g++.law/virtual3.C (test for excess errors)
> FAIL: g++.law/virtual4.C (test for excess errors)
> FAIL: g++.law/visibility1.C (test for excess errors)
> FAIL: g++.law/visibility10.C (test for excess errors)
> FAIL: g++.law/visibility13.C (test for excess errors)
> FAIL: g++.law/visibility15.C (test for excess errors)
> FAIL: g++.law/visibility17.C (test for excess errors)
> FAIL: g++.law/visibility2.C (test for excess errors)
> FAIL: g++.law/visibility22.C (test for excess errors)
> FAIL: g++.law/visibility25.C (test for excess errors)
> FAIL: g++.law/visibility7.C (test for excess errors)
> FAIL: g++.martin/bitset1.C (test for excess errors)
> FAIL: g++.martin/new1.C (test for excess errors)
> FAIL: g++.mike/net40.C (test for excess errors)
> FAIL: g++.mike/net46.C (test for excess errors)
> FAIL: g++.mike/ns15.C (test for excess errors)
> FAIL: g++.mike/p2736.C (test for excess errors)
> FAIL: g++.mike/p658.C (test for excess errors)
> FAIL: g++.mike/p710.C (test for excess errors)
> FAIL: g++.mike/rtti1.C (test for excess errors)
> FAIL: g++.ns/koenig9.C (test for excess errors)
> FAIL: g++.ns/new1.C (test for excess errors)
> FAIL: g++.ns/using4.C (test for excess errors)
> FAIL: g++.ns/using6.C (test for excess errors)
> FAIL: g++.oliva/new1.C (test for excess errors)
> FAIL: g++.oliva/thunk1.C (test for excess errors)
> XPASS: g++.other/access6.C - private - (test for bogus messages, line  
> 9)
> XPASS: g++.other/access6.C - redeclared - (test for bogus messages,  
> line 11)
> XPASS: g++.other/access6.C - private - (test for bogus messages, line  
> 14)
> FAIL: g++.other/align.C (test for excess errors)
> XPASS: g++.other/decl1.C (test for excess errors)
> XPASS: g++.other/decl5.C ::Q not a member of B (test for errors, line  
> 34)
> FAIL: g++.other/defarg6.C (test for excess errors)
> FAIL: g++.other/delete8.C (test for excess errors)
> FAIL: g++.other/dyncast6.C (test for excess errors)
> FAIL: g++.other/headers1.C (test for excess errors)
> FAIL: g++.other/init9.C (test for excess errors)
> FAIL: g++.other/inline14.C (test for excess errors)
> FAIL: g++.other/op2.C (test for excess errors)
> FAIL: g++.other/op3.C (test for excess errors)
> FAIL: g++.other/vaarg1.C (test for excess errors)
> FAIL: g++.other/vtbl2.C (test for excess errors)
> FAIL: g++.pt/crash68.C (test for excess errors)
> FAIL: g++.pt/deduct5.C (test for excess errors)
> FAIL: g++.pt/deduct6.C (test for excess errors)
> FAIL: g++.pt/instantiate10.C (test for excess errors)
> FAIL: g++.pt/ttp19.C (test for excess errors)
> FAIL: g++.pt/ttp40.C (test for excess errors)
> XPASS: g++.pt/typename12.C (test for excess errors)
> XPASS: g++.pt/typename12.C  Execution test
> FAIL: g++.robertl/eb102.C (test for excess errors)
> FAIL: g++.robertl/eb104.C (test for excess errors)
> FAIL: g++.robertl/eb109.C (test for excess errors)
> FAIL: g++.robertl/eb113.C (test for excess errors)
> FAIL: g++.robertl/eb114.C (test for excess errors)
> FAIL: g++.robertl/eb124.C (test for excess errors)
> FAIL: g++.robertl/eb126.C (test for excess errors)
> FAIL: g++.robertl/eb127.C (test for excess errors)
> FAIL: g++.robertl/eb129.C (test for excess errors)
> FAIL: g++.robertl/eb129a.C (test for excess errors)
> FAIL: g++.robertl/eb15.C (test for excess errors)
> FAIL: g++.robertl/eb17.C (test for excess errors)
> FAIL: g++.robertl/eb21.C (test for excess errors)
> FAIL: g++.robertl/eb24.C (test for excess errors)
> FAIL: g++.robertl/eb28.C (test for excess errors)
> FAIL: g++.robertl/eb29.C (test for excess errors)
> FAIL: g++.robertl/eb3.C (test for excess errors)
> FAIL: g++.robertl/eb30.C (test for excess errors)
> FAIL: g++.robertl/eb31.C (test for excess errors)
> FAIL: g++.robertl/eb33.C (test for excess errors)
> FAIL: g++.robertl/eb36.C (test for excess errors)
> FAIL: g++.robertl/eb39.C (test for excess errors)
> FAIL: g++.robertl/eb4.C (test for excess errors)
> FAIL: g++.robertl/eb41.C (test for excess errors)
> FAIL: g++.robertl/eb43.C (test for excess errors)
> FAIL: g++.robertl/eb44.C (test for excess errors)
> FAIL: g++.robertl/eb46.C (test for excess errors)
> FAIL: g++.robertl/eb54.C (test for excess errors)
> FAIL: g++.robertl/eb55.C (test for excess errors)
> FAIL: g++.robertl/eb59.C (test for excess errors)
> FAIL: g++.robertl/eb60.C (test for excess errors)
> FAIL: g++.robertl/eb62.C (test for excess errors)
> FAIL: g++.robertl/eb65.C (test for excess errors)
> FAIL: g++.robertl/eb66.C (test for excess errors)
> FAIL: g++.robertl/eb7.C (test for excess errors)
> FAIL: g++.robertl/eb77.C (test for excess errors)
> FAIL: g++.robertl/eb79.C (test for excess errors)
> FAIL: g++.robertl/eb82.C (test for excess errors)
> FAIL: g++.robertl/eb91.C (test for excess errors)
>
> 		=== g++ Summary ===
>
> # of expected passes		7628
> # of unexpected failures	210
> # of unexpected successes	17
> # of expected failures		181
> # of untested testcases		15
> # of unsupported tests		3
> /export/gates/pinskia/src/gnu/gcc/src/objdir.openbsd/gcc/testsuite/../ 
> g++ version 3.4 20021228 (experimental)

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Marc Espie]

On Sat, Dec 28, 2002 at 12:18:00PM -0500, Andrew Pinski wrote:
> The new failures on i686-unknown-openbsd3.1 are caused by the new  
> parser and/or
> the definition of __BEGIN_DECLS/__END_DECLS in openbsd's header,  
> sys/cdefs.h:
> #define __BEGIN_DECLS   extern "C" {
> #define __END_DECLS     };
> 
> Note the semicolon after }, that is what is causing it.

Thanks, this will be fixed shortly.

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Alexandre Oliva]

On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:

> #define __END_DECLS     };

> Note the semicolon after }, that is what is causing it.

Looks like a job for fixheaders...  They headers are obviously in
error.

That said, it would be nice if the new parser would accept such
gratuitous constructs, even if they're not legal C++.  Even though,
grammatically, they seem to be acceptable:

declaration -> block-declaration -> simple-declaration ->
decl-specifier-seqopt init-declarator-listopt;

[dcl.dcl]/3 rules out the empty init-declarator-listopt.
Nevertheless, I think it's a mistake to outright reject programs that
contain such gratuitous semicolons.  Given the number of occurrences
of such constructs in testcases and GCC's libraries, it's obvious that
a lot of code out there will be gratuitously (?) broken by this
change.

Mark, would it be too hard to accept such empty declarations, for the
sake of backward-compatibility, perhaps emitting a warning for this
deprecated extension, and make it an error only in a future release?
Or perhaps we might even want to accept it indefinitely as a GNU
extension.  Any reason not to?  (Not that the extension would solve
OpenBSD's problem, given that the C++ testsuite runs with -ansi)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Marc Espie]

On Sat, Dec 28, 2002 at 03:42:51PM -0200, Alexandre Oliva wrote:
> On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:
> 
> > #define __END_DECLS     };
> 
> > Note the semicolon after }, that is what is causing it.
> 
> Looks like a job for fixheaders...  They headers are obviously in
> error.

Not a job for fixheaders. We have control over our headers, and we
fix them as needed, when such issues are discovered.

Note that the problem here is that no-one found out this was a problem
until recently.

In fact, if I had looked more closely at FreeBSD, I would have fixed
this ages ago, since Tendra C++ reported this as incorrect back in 1998.

More generally, whenever you find a problem with OpenBSD's headers, it's
hundreds of times simpler to just fix it on our side.

I'm sick of parsers that generate parsers that generate files (and
basically take forever to fix when they do the wrong thing, because
this is yet another language you have to understand).

I understand where fixheaders come from, and I understand how useful it
is for unresponsive vendors.

But, as far as OpenBSD is concerned, we would be much, much happier with
a check-headers script that diagnoses issues, so that we can fix them
once and for all, and *specifically*, not only for gcc, but for any
compiler that happens to come around. This looks to me to be a much nicer,
more well-rounded approach (of course, it means that gcc extensions are out
of the question, or should be properly protected, but this makes a lot
of engineering sense).
> That said, it would be nice if the new parser would accept such
> gratuitous constructs, even if they're not legal C++.  Even though,
> grammatically, they seem to be acceptable:
Nope, bad idea.  At least, don't accept this for our sake. We will fix
this. It's a very simple mistake. It's much easier to fix than say, std::
conformance.

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Alexandre Oliva]

On Dec 28, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> Mark, would it be too hard to accept such empty declarations, for the
> sake of backward-compatibility, perhaps emitting a warning for this
> deprecated extension, and make it an error only in a future release?

Doh, I meant to check the sources before hitting send, but my fingers
slipped.  Sorry.  I realize now that we just pedwarn if we're in
pedantic mode (which the testsuite enables).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Mark Mitchell]

This may be a duplicate reply; some mail weirdness here.

> Nevertheless, I think it's a mistake to outright reject programs that
> contain such gratuitous semicolons.  Given the number of occurrences
> of such constructs in testcases and GCC's libraries, it's obvious that
> a lot of code out there will be gratuitously (?) broken by this
> change.

I agree, and the new parser (I think) accepts this construct when not
pedantic.  There may be more places where we need to add the leniency
for this; it's certainly something we should accept when not being
pedantic.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Alexandre Oliva]

On Dec 28, 2002, Marc Espie <espie@nerim.net> wrote:

> On Sat, Dec 28, 2002 at 03:42:51PM -0200, Alexandre Oliva wrote:
>> On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:
>> 
>> > #define __END_DECLS     };
>> 
>> > Note the semicolon after }, that is what is causing it.
>> 
>> Looks like a job for fixheaders...  They headers are obviously in
>> error.

> Not a job for fixheaders. We have control over our headers, and we
> fix them as needed, when such issues are discovered.

Even for headers that have already been deployed? :-)  GCC might help
with those, should Joe R. User decide to install GCC on his older
OpenBSD box that has this header still broken.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Marc Espie]

On Sat, Dec 28, 2002 at 07:49:29PM -0200, Alexandre Oliva wrote:
> On Dec 28, 2002, Marc Espie <espie@nerim.net> wrote:
> 
> > On Sat, Dec 28, 2002 at 03:42:51PM -0200, Alexandre Oliva wrote:
> >> On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:

> >> > #define __END_DECLS     };

> >> > Note the semicolon after }, that is what is causing it.

> >> Looks like a job for fixheaders...  They headers are obviously in
> >> error.

> > Not a job for fixheaders. We have control over our headers, and we
> > fix them as needed, when such issues are discovered.

> Even for headers that have already been deployed? :-)  GCC might help
> with those, should Joe R. User decide to install GCC on his older
> OpenBSD box that has this header still broken.

Define `older'. We churn out new releases every six months, consistently.
It's a really bad idea to not update an OpenBSD box, especially since a
large proportion of the changes are security fixes, and we almost never
deploy incompatible changes...

There are loads of reasons why you may not want to use a newer gcc on
an older OpenBSD box, especially as there have been fixes all over the
place, including the assembler, the linker, and header files... 

I believe that trying to do a correct job in fix-headers for OpenBSD is a
pointless exercise.  There are lots of other reasons why a newer gcc won't
do much good on an older OpenBSD box. There's a good reason the OpenBSD
project doesn't maintain more than two releases back, and only for critical
fixes: we don't have the manpower to do so. Instead, we concentrate on
making each new release obviously better than the last.
(by obviously, I mean that there are no incompatible changes or slow-downs
that would make one person question the suitability of the upgrade).

And I don't think there's anybody around there who is actually testing
newer gcc releases on older OpenBSD releases, to ensure the level of
quality we try to achieve with new releases, so really, it's pointless.

Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Mark Mitchell]

--On Saturday, December 28, 2002 03:42:51 PM -0200 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:
>
>> #define __END_DECLS     };
>
>> Note the semicolon after }, that is what is causing it.
>
> Looks like a job for fixheaders...  They headers are obviously in
> error.

> Nevertheless, I think it's a mistake to outright reject programs that
> contain such gratuitous semicolons.  Given the number of occurrences
> of such constructs in testcases and GCC's libraries, it's obvious that
> a lot of code out there will be gratuitously (?) broken by this
> change.

There's already some code in the new parser to accept this when not
pedantic; we pedwarn when pedantic.  It may be that we need additional
compensating code in other places; right now it's only
cp_parser_declaration_seq_opt.

I certainly agree that we should accept stray semicolons unless we're
being pedantic -- but when we are asked to be pedantic, then this is
the sort of thing a pedantic cares about. :-)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com