Recent changes to attribute handling in GCC fix some *really important*
problems with handling of attributes in C++, particulary with dllimport of
class definitions.
cp/Changelog
2002-01-31 Jason Merrill [EMAIL PROTECTED]
PR c++/3395
* decl.c (xref_tag): Remember early
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Thu, Mar 21, 2002 at
06:36:33PM +1100, Danny Smith wrote:
I just stumbled across this is gcc 3.1 changelog:
2002-02-05 Alexandre Oliva [EMAIL PROTECTED]
* target.h (struct gcc_target): Added ms_bitfield_layout_p.
* target
I've noticed this thread on cywgin. I actually have been discussing this
with ReactOS team recently. The ReactOs patchset for fastcall support in
GCC and binutils has been in my local sandbox for 3.1 and causes no
regressions with GCC/binutils testsuites. It has been in a mingw gcc
2.95.3
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Apr 08, 2002 at
08:29:29AM +1000, Danny Smith wrote:
maintainer. There are currently bugs in binutils with respect to ld
--shared (or at least there was two weeks ago and has been since 17
[UTC]
December).
URL? I don't see
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Apr 08, 2002 at
08:54:00AM +1000, Robert Collins wrote:
Chris asked the question a while ago: Wanna be a binutils maintainer.
Are you asking if someone here can step up? I'd love to, but I suspect
I don't have the time to do a good
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Apr 08, 2002 at
11:28:20AM +1000, Danny Smith wrote:
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Apr 08, 2002
at
08:29:29AM +1000, Danny Smith wrote:
If so, I am happy checking in windres patches. The checksum
patch
I think that this (return 8 byte structures in registers) should also go in
mingw32.h config file for GCC. I'm not sure about cygwin.h ldiv() returns
an 8-byte structure. I can't think of any others, but if we're serious
about compatability with MS object files, this would seema good thing.
--- Ralf Habacker [EMAIL PROTECTED] wrote: Hi,
this patch fixes an cygwin ld issue (GNU ld version 2.11.92 20011001) I've
encountered while analysing the runtime linking performance for kde.
Background:
The ld-auto-import stuff introduces additional symbols (_nm_...) in the
import
--- Ralf Habacker [EMAIL PROTECTED] wrote:
Can anybody tell me which cvs version is the last stable ? I have tried to
checkout binutils with date 2001/12/31, but got compiling errors.
Compiling errors are fixed (was an overseen cvs conflict, but the problem
still
remains).
So it
--- Ralf Habacker [EMAIL PROTECTED] wrote: (*) tentative because
I can't actually test it myself against HEAD,
given the pre-existing problem with binutils HEAD on pe386.
I have tried,it works, Danny Smith seems to have fixed the bugs located in
bfd.
Alan Modra fixed it, not me.
http
--- Charles Wilson [EMAIL PROTECTED] wrote: Robert Collins wrote:
Yes, and at that point we had two issues:
1) We couldn't use libstdc++, let alone the STL. The STL still isn't
available - beyond whats in libg++-3.
2) I think that Jason's design needed some tweaking.
Well,
--- Charles Wilson [EMAIL PROTECTED] wrote:
Christopher Faylor wrote:
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote:
1) Ralf's removing unused _nm_ symbol exports fix
2) Danny's (or Ralf's?) export-list fix (where whole static
archives can
be marked for
on MinGW with GCC 3.1 and GCC 2.95.3 and current CVS binutils.
2002-05-21 Danny Smith [EMAIL PROTECTED]
* pe-dll.c (autofilter_liblist): Add more system libs excluded
by default.
(autofilter_objlist): Add crtbegin.o, crtend.o
.
Listing of symbol names in a .def file forces those specific symbols
to be included even if they are contained in excluded libs.
Can this be reviewed?
The diff updated to current CVS is attached.
2002-05-21 Danny Smith [EMAIL PROTECTED]
* emultempl/pe.em (OPTION_EXCLUDE_LIBS): Add
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Mon, Jun 10, 2002 at
10:00:14AM +1000, Billinghurst, David (CRTS) wrote:
I didn't even notice the ChangeLog.cygwin-mingw files, as I was
working elsewhere. I would prefer to use them and will make the
appropriate changes.
I don't think
Can the __GXX_MERGED_TYPEINFO_NAMES patch (alternative #2) proposed by
Jason Merrill at
http://gcc.gnu.org/ml/gcc/2002-05/msg01970.html
be revisited?
The following 3.1 bug was reported by Colin Peters to Mingw list. It
is also a bug on Cygwin GCC 3.1
When attempting to use dynamic_cast in an
--- Christopher Faylor [EMAIL PROTECTED] wrote: I'm in the process of
checking in some stuff to the cygwin gcc branch.
I've checked in my most recent set of changes (mainly for -mno-cygwin)
and am currently in the process of checking in the merged changes from
the main 3.1.1 branch. It's
--- Christopher Faylor [EMAIL PROTECTED] wrote: I'll be creating a new
cygwin-mingw-gcc-3_2-branch as soon as
the main gcc 3.2 branch, which has just been created, has the
ABI patchset applied.
Then I'll create a new gcc 3.2 for cygwin within a few days.
I won't probably won't take
I would like to get this into cygwin ASAP, too, Danny. If you add it to
the existing 3.1 branch, it will be copied over to the 3.2 branch
automatically.
I haven't missed a message wrt the ABI compatibility merge have I?
We're still waiting for that, right?
The merge has happened.
The merge has happened.
http://gcc.gnu.org/ml/gcc/2002-07/msg01277.html
umm - that says the branch is opened, for abi changes.
It doesnt mention anything about a merge...
Am I missing something?
Sorry, that was misleading. Soon after that, a swag of CVS check-ins hit the cp
and
--- Danny Smith [EMAIL PROTECTED] wrote: I have modified the
Adriano dos Santos Fernandes patchset somewhat so that
it
can be used with both cygwin and mingw
In absence of feedback on this patch from cygwin developers I will modify so
that it only applies to mingw and -mno-cygwin
I'd like to provide feedback, but am short of cycles myself. Can you
describe what it does? I can likely tell any (obvious) collisions with
cygwin from that.
Rob
For mingw (without a special EH dll):
The patch uses the win32api FindAtom/AddAtom functions to create/find a local
ATOM
Lastly, wouldn't SEH be a feasible alternative (if the ReactOS work is
usable).
my concern with ReactOS SEH is that is has Borland license uncertainties.
Danny
http://digital.yahoo.com.au - Yahoo! Digital How To
- Get the best out of your PC!
Diff of my local tree with cygwin-mingw branch shows missing fastcall and
ms-bitfield stuff in i386.c.
Index: gcc/gcc/config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.368.2.19.2.2
diff -u
I have committed Adianos' patch to gcc-3_2-cygwin-mingw branch:
Danny
gcc/ChangeLog
2002-08-16 Danny Smith [EMAIL PROTECTED]
crtstuff.c (__do_frame_init): Call __w32_sharedptr_initialize.
config/i386/t-cygming (LIB2FUNCS_EXTRA): Add
__w32_sharedptr_initialize.c
--- egor duda [EMAIL PROTECTED] wrote: Hi!
Maybe i'm running slightly ahead of the train, but it looks like
w32-shared-ptr.c haven't been actually added to repository. Neither
trying to check it out nor looking for it via cvsweb interface helps.
Is it unintentional omission during
Oscar Fuentes has discovered a serious problem with DWARF2 exception
handling in GCC in context of windows messages, reported below and discussed
in
several posts to mingw users.
This will also affect Cygwin apps that use C++ exceptions in
combination with windows callbacks.
The immediate
The __RUNTIME_PSEUDO_RELOC_LIST__ addition to ldscripts causes problems
with ld -r -o foo.o bar.o baz.o because of multiple definitions. This
change fixes that problem, but how will it affect intended usage of the
-auto-import extension?
--- pe.sc.orig Sun Sep 29 05:26:05 2002
+++ pe.sc
--- egor duda [EMAIL PROTECTED] wrote: Hi!
Tuesday, 19 November, 2002 Christopher Faylor [EMAIL PROTECTED] wrote:
CF I've made a new version of binutils available for download. This is
CF just a refresh from sources.redhat.com. A notable change is the
CF addition of Egor Duda's
I have merged in cygwin-mingw-gcc-3_2-branch plus updated dll/exe shared_ptr
patch to cygwin-mingw-v2-branch of FSF CVS.
The changes are in gcc/ChangeLog.cygwin-mingw, gcc/ada/ChangeLog.cygwin-mingw
libf2c/ChangeLog.cygwin-mingw, libstdc++-v3/ChangeLog.cygwin-mingw
I have tested on cygwin with:
I've been expecting a bug report for mingw-runtime and ini.cc in setup for
awhile, but haven't seen one, so I'll ask if the CVS mingw runtime is getting
any testing with setup anymore.
The problem is in the default usage of _CRTIMP ( = __attribute__((dllimport)) )
macro on all mingw runtime
--- Robert Collins [EMAIL PROTECTED] wrote: On Mon, 2003-03-31 at
10:17, Danny Smith wrote:
I'll make the _CRTIMP macro a no-op by default if someone will confirm
that
there is a problem with setup.
So, is that CVS mingw-runtime only?
src/winsup/mingw
And is there a setup.exe
Ergo, this will be a problem when the next mingw-runtime comes out.
Danny, if you have a patch for either mingw or setup, that'd be great.
Does what you are suggesting impose any limitations on setup ?
Probably simplest (for per-file override of _CRTIMP) is just to add
#define _CRTIMP
--- Christopher Faylor [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2003 at
04:41:47PM +0200, Gerrit
P. Haase wrote:
Christopher schrieb:
On Wed, Oct 22, 2003 at 01:13:28PM +0200, Gerrit P. Haase wrote:
Hallo,
I would like to rename this package to mingw-gcc. Probably it would be
no bad
I'm going to create a 3.3.2 branch for gcc, ok?
Danny could you do your magic to the branch? Or would it
make better sense to just merge the changes from 3.3.1 - 3.3.2
into the current branch?
I think the latter might be safer. My local version has some
mingw-specific anon-mmap stuff
Danny Smith [EMAIL PROTECTED]
* mingwex/getopt.c: Define IS_POSIXLY_CORRECT as per
NetBSD getopt_long.c
retrieving revision 1.2
diff -c -3 -p -r1.2 getopt.c
*** mingwex/getopt.c3 Mar 2003 10:27:57 - 1.2
--- mingwex/getopt.c1 Feb 2004 03:00:07 -
From: Nicholas Wourms
The recent directx reorganization in the winsup/w32api dir has
allowed
some mingw-only code to slip into the general build
(lib/directx/dxerr.c). This causes a compile failure when building a
cygwin target. Please have the author of the new code rectify this by
not
Charles Wilson wrote:
The other question is, how is the .rdata is read only, you can't
change
anything there enforced? By whom? Is this something about the pei-x86
format that is enforced by the Windows Runtime Loader, or is it simply
a
convention enforced by our startup objects (crt0.o etc)?
Wouldn't this patch to ld/pe.em solve the e-a-i-b problem?
*** pe.em.orig Sun Jul 10 12:33:54 2005
--- pe.em Sun Jul 10 12:33:29 2005
*** static unsigned long
*** 666,672
compute_dll_image_base (const char *ofile)
{
unsigned long hash = strhash (ofile);
! return
cgf wrote
Am I reading this right, though? auto-image-base puts everything
above 0x6000. That doesn't seem quite right.
I apologise for breaking thread but I'm on someone else's machine and have to
use the mail clinet available.
As I understand it, memory address space is usually
RE: http://cygwin.com/ml/cygwin-patches/2006-q2/msg00051.html
I am not subscribed to cygwin-patches so I'm posting here. Forgive me
if I've transgressed boundares, but I've always considered mingw as a
cygwin-dependent app.
Applying the above patch, running aclocal and then autoconf-2.5x, then
Dave Korn wrote:
Corinna Vinschen wrote:
So why does it do that at all: previous dllimport ignored?
It shouldn't do that. The dllimport should have precedence, IMHO.
I don't know why it does that, it's just the behaviour of
vanilla upstream
GCC. I think it might be important, and
Charles Wilson
Dave Korn wrote:
Corinna Vinschen wrote:
#2)
It's already on by default. The variable
link_info.pei386_auto_import
is currently initialized to -1, which means Do it, but complain.
The only thing changing that initialization to 1 would do,
would be to
stop
43 matches
Mail list logo
