ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/09/22/19:31:47

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <20010922233144.72740.qmail@web14507.mail.yahoo.com>
Date: Sun, 23 Sep 2001 09:31:43 +1000 (EST)
From: =?iso-8859-1?q?Danny=20Smith?= <danny_r_smith_2001 AT yahoo DOT co DOT nz>
Subject: Re: [cgf AT redhat DOT com: Re: Fwd: Re: [Refresh]: patch for C++ parser bug with function attributes]
To: cygwin-apps <cygwin-apps AT cygwin DOT com>
In-Reply-To: <20010922120454.C1668@redhat.com>
MIME-Version: 1.0

 --- Christopher Faylor <cgf AT redhat DOT com> wrote: > I don't know if I
should be cc'ing you in my responses or not but I
> forgot to do that this time.
> 
> AFAICT, you aren't subscribed to cygwin-apps, are you?

I am now.

> 
> 
cgf
> 
> On Sat, Sep 22, 2001 at 04:07:33PM +1000, Danny Smith wrote:
> > --- Christopher Faylor <cgf AT redhat DOT com> wrote: > On Fri, Sep 21,
> 2001
> >at 12:49:50PM +1000, Danny Smith wrote:
> >> >Joseph's patch is here:
> >> >http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00774.html
> >> >
> >> >I will start on this. Any interest in backport to 3.0.1, or
> should I
> >> >just target 3.1?  I'm hoping it may solve some of the other
> >> attribute
> >> >problems (stdcall and dllimport) in C++ classes with 3.0.1. 
> >> 
> >> Can you build the trunk version of gcc, Danny?
> >
> >Yes. 3-stage bootstrap with mingw as gcc with cygwin utils. 
> >
> > I have made only a few changes.  One having to do with b**dy
> anonymous
> >unions (again) in w32api (needed for threads)
> >/* "The member specification of anonymous unions shall only
> > define  non-static data members"  saith the Standard */
> >Two anon unions in w32api aren't compliant. I will clean that up and
> >put in w32api cvs
> 
> I've seen the errors but I don't understand why the data members are
> considered "static".  Weren't they just array references?


No GCC is compliant, MS is not.

This is illegal in C++ according to section 9.5 of std.

struct a {
	union /* anon */ {
	struct b_struct {
	  int c;
	};
	int b_int;
	}; 
};

struct b_struct has to be defined outside of anon union namespace (ie
non-static wrt to the union).

The two types in w32api that violate this are PROCESS_HEAP_ENTRY in
winbase.h and REPARSE_DATA_BUFFER in winnt.h


> 
> >Another I sent to Joseph (see below).  
> >
> >The rest were litle bits for libstdc++ (no SIGTRAP) or changes in
> >mingw32.h to override the cygwin directory specs.
> 
> Do you want me to update mingw32.h in the gcc.gnu.org repository?

Yes, I will have some sleep and then look at my changes again first
though.  Also, as before, involves a define in cygwin.h (ifdef
WIN32_BUILD_RELOCATABLE_PACKAGE, as per Mumit's diff to 3.0) to prevent
some undefs of command line macros.
> 
> >I have since put in Donn Terrys native-struct patches and they seem
> to
> >work okay.  
> >Now (take deep breath) to attack the dll stuff .
> 

C dll patches applied and test okay.  Still ICE making C++ dlls with
this syntax: 'class __attribute__(dllexport) foo'.  Mumit's patch
prevents SEGV.


> Do you have these patches available somewhere, by any chance?  I'd
> like
> to try applying them to my sandbox to see if it allows me to compile
> things.  Your changes below didn't do the trick for me,
> unfortunately.
> 
Yes I will get fresh diff after the sleep and assuming I can get decent
connection to server.  

Danny
> cgf 


http://travel.yahoo.com.au - Yahoo! Travel
- Got Itchy feet? Get inspired!

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019