--- Comment #22 from davek at gcc dot gnu dot org 2010-09-23 03:56 ---
(In reply to comment #20)
Indeed, the explanation page
http://gcc.gnu.org/wiki/Visibility
[ ... ]
this means to use these options, you should alter your header files first, but
wxwidgets source code apparently
--- Comment #23 from davek at gcc dot gnu dot org 2010-09-23 04:08 ---
(In reply to comment #21)
I see that the main problem is dllexported *inline* functions.
That is my understanding of it too.
Can Nathan's change be modified
to only emit dllexported *non-inline* functions? I
--- Comment #15 from davek at gcc dot gnu dot org 2010-09-13 14:41 ---
(In reply to comment #14)
Well, scans definitely pass on x86_64 AND i686 linux without -fpic.
Why it fails for the -fpic targets should be clear from the assembly dumps.
The fix you are referring to added
--- Comment #11 from davek at gcc dot gnu dot org 2010-09-12 15:05 ---
Still FAILing on i686-pc-cygwin (and presumably any other nonpic ix86 targets):
FAIL: gcc.target/i386/volatile-2.c scan-assembler movl[ \\t][^,]+,
obj_0((%rip))?
FAIL: gcc.target/i386/volatile-2.c scan
--- Comment #13 from davek at gcc dot gnu dot org 2010-09-12 19:55 ---
(In reply to comment #12)
(In reply to comment #11)
Still FAILing on i686-pc-cygwin (and presumably any other nonpic ix86
targets):
This was fixed at...
r163685 | uros | 2010-08-31 13:32:23 -0400 (Tue
--- Comment #6 from davek at gcc dot gnu dot org 2010-09-12 23:45 ---
This is also present on i686-pc-cygwin:
FAIL: gcc.target/i386/pr38240.c (internal compiler error)
ICE happens here:
(gdb) bt
#0 0x006065e0 in convert_move (to=0x7fcc26c0, from=0x7fcc26d0, unsignedp=0)
at /gnu
--- Comment #19 from davek at gcc dot gnu dot org 2010-09-04 11:54 ---
(In reply to comment #18)
See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
non-darwin platform.
Yep, it's all the same kind of undefined symbol problems as in Jack's
original
--- Comment #20 from davek at gcc dot gnu dot org 2010-09-04 11:57 ---
(In reply to comment #19)
(In reply to comment #18)
See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
non-darwin platform.
Yep, it's all the same kind of undefined symbol
--- Comment #6 from davek at gcc dot gnu dot org 2010-08-20 01:06 ---
Has this target had the support added for JSM's built-in stdint patch? (Sorry,
reference not to hand right now; will dig it up if nobody knows what i'm
talking about.)
--
davek at gcc dot gnu dot org changed
--- Comment #1 from davek at gcc dot gnu dot org 2010-07-23 14:47 ---
My first WAG is that this is actually a mishandling of TARGET_EXECUTABLE_SUFFIX
vs. -o in gcc.c/convert_filename()...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45041
--- Comment #2 from davek at gcc dot gnu dot org 2010-07-23 15:05 ---
Ah. This appears to be fixed on HEAD. I suspect this patch did the job:
2009-10-14 Pascal Obry o...@adacore.com
* gcc.c (DEFAULT_SWITCH_CURTAILS_COMPILATION): Add -E.
(process_command): Handle -E
--- Comment #6 from davek at gcc dot gnu dot org 2010-07-11 12:56 ---
(In reply to comment #5)
Program received signal SIGSEGV, Segmentation fault.
0x006f25bd in lvalue_p_1 (ref=0x70c4fb98) at
../../gcc-4.x/gcc/cp/tree.c:71
71if (TREE_CODE (TREE_TYPE (ref
--- Comment #11 from davek at gcc dot gnu dot org 2010-07-12 00:14 ---
(In reply to comment #10)
(In reply to comment #2)
I can't reproduce it with r161865. (on x86_64-linux with -m32)
please confirm that this error introduces from -O1? surely, it would not be
reproducible
--- Comment #5 from davek at gcc dot gnu dot org 2010-07-09 00:21 ---
Subject: Bug 43888
Author: davek
Date: Fri Jul 9 00:20:58 2010
New Revision: 161982
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161982
Log:
2010-07-09 Dave Korn dave.korn.cyg...@gmail.com
--- Comment #50 from davek at gcc dot gnu dot org 2010-06-14 10:38 ---
Subject: Bug 42776
Author: davek
Date: Mon Jun 14 10:38:18 2010
New Revision: 160722
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160722
Log:
ChangeLog:
Backport from mainline:
2010-04-27 Dave Korn
: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-29 11:33 ---
Created an attachment (id=20771)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20771action=view)
testcase as per initial comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 ---
(In reply to comment #11)
I have doubts about the approach in winnt.c, but well maybe I am wrong here. I
investigated for this issue and see the real issue in declaration cloning in
varasm.c's emutls_decl
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 ---
(In reply to comment #12)
TARGET_EMUTLS_VAR_INIT
Nah, scratch that, it's not really sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 ---
(In reply to comment #14)
Hi Dave,
following patch solves the issue for me pretty well.
That looks good to me to, although doing it in the middle-end makes me worry
that some other target might
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-17 17:02 ---
Yes, it certainly does, in fact it omits to compile any definition for 'foo'
whatsoever!
But isn't this the expected behaviour of using '-fwhole-program' on something
that is not the whole program? I'm not sure
--- Comment #10 from davek at gcc dot gnu dot org 2010-05-17 18:25 ---
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but as auto-export gets disabled
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-17 18:28 ---
Consensus seems to be that this is indeed how it's meant to work, but that
figuring out which are the externally visible functions and marking them
automatically would be a nice enhancement that would make the -fwhole
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-15 09:06 ---
(In reply to comment #0)
Windows targets that use emutls add a . character as a separator from the
_emutls_{t,v} and the true symbol name. However, exporting these symbol names
from a DLL is problematic (i.e
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-15 09:34 ---
(In reply to comment #1)
In other words, I don't think the runtime loader actually keys off the
presence
of a dot in the exported symbol, but where the EAT entry points to. If we can
persuade ld that sometimes
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20665action=view)
testcase: main executable source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20666action=view)
testcase: dll source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #5 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20667action=view)
testcase: dll header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #6 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20668action=view)
testcase: makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #7 from davek at gcc dot gnu dot org 2010-05-15 09:45 ---
So... I think now we just need to figure out how to tell LD that some export
directives contain dots because they're exporting a symbol containing a dot.
Actually, that's probably all we need to do: when we find
--- Comment #9 from davek at gcc dot gnu dot org 2010-05-15 13:48 ---
FTR: Patch posted at http://sourceware.org/ml/binutils/2010-05/msg00171.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #19 from davek at gcc dot gnu dot org 2010-05-12 16:48 ---
(In reply to comment #18)
FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
reason:
Leaked composite object at 0x2b5d6f749ef0
(../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz
--- Comment #23 from davek at gcc dot gnu dot org 2010-05-12 22:20 ---
(In reply to comment #22)
Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using make
-k check, so otherwise deadly trivial patch can't be fully tested.
Well I can't approve it but I think it's
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-10 20:54 ---
(In reply to comment #16)
On alphaev68-pc-linux-gnu, I'm getting:
FAIL: leaktest
1 of 4 tests failed
Is this failure something to worry about?
The honest answer is: I can't tell you. These are test cases
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-09 21:00 ---
Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-06 16:06 ---
Subject: Bug 43888
Author: davek
Date: Thu May 6 16:06:18 2010
New Revision: 159111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159111
Log:
PR target/43888
* config/i386/winnt.c
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-06 16:21 ---
Subject: Bug 42811
Author: davek
Date: Thu May 6 16:20:53 2010
New Revision: 159115
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159115
Log:
PR target/42811
* tests/staticrootstest.c: New
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-02 23:56 ---
Applied to trunk at r.158983.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-03 00:18 ---
Ow. Still present on mainline. This really needs a C++ F/E expert to look at
it.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davek at gcc dot gnu dot org 2010-04-30 15:30 ---
Posted: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01899.html
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davek at gcc dot gnu dot org 2010-04-28 13:38 ---
Quoting RG from the gcc list:
[ ... ] Or you fix collect2 to do processing of archives and hand
lto1 the required information (it expects archive components
with LTO bytecode like archiv...@offset with offset being
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-28 23:49 ---
(In reply to comment #2)
Quoting RG from the gcc list:
[ ... ] Or you fix collect2 to do processing of archives and hand
lto1 the required information (it expects archive components
with LTO bytecode like archiv
--- Comment #4 from davek at gcc dot gnu dot org 2010-04-29 05:28 ---
Created an attachment (id=20512)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20512action=view)
Extends GNU LD to parse archives for LTO.
(In reply to comment #3)
Ow. I think we need to get LD to help us
--- Comment #10 from davek at gcc dot gnu dot org 2010-04-26 18:39 ---
(In reply to comment #1)
I don't speak Mach-O, but yes, the approach should work. You'd start by
saying lto_binary_reader=lto-mach-o in config.gcc and adding a new
lto/lto-mach-o.c with the same handful
--- Comment #45 from davek at gcc dot gnu dot org 2010-04-27 02:23 ---
Subject: Bug 42776
Author: davek
Date: Tue Apr 27 02:22:40 2010
New Revision: 158762
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158762
Log:
ChangeLog:
PR lto/42776
* configure.ac (--enable
--- Comment #46 from davek at gcc dot gnu dot org 2010-04-27 02:24 ---
Subject: Bug 42776
Author: davek
Date: Tue Apr 27 02:23:56 2010
New Revision: 158763
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158763
Log:
Missing file from last commit!
ChangeLog:
2010-04-27 Dave Korn
--- Comment #47 from davek at gcc dot gnu dot org 2010-04-27 02:25 ---
Subject: Bug 42776
Author: davek
Date: Tue Apr 27 02:24:51 2010
New Revision: 158764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158764
Log:
Missing changelog from last commit!
ChangeLog:
2010-04-27 Dave
--- Comment #48 from davek at gcc dot gnu dot org 2010-04-27 02:26 ---
Sorry, missed a couple of files the first time round and had to check them in
subsequently. Oops. *sheepish grin*
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from davek at gcc dot gnu dot org 2010-04-27 02:35 ---
I noticed the dependency was the wrong way round when I saw that this open bug
was blocking a freshly-closed one :)
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from davek at gcc dot gnu dot org 2010-04-25 12:14 ---
P:\gcc4\bin\cyggcc_s-sjlj-1.dll
This is the source of all your problems. Sorry, I should have been able to
work this out just from seeing your configure line earlier.
The SJLJ and DW2 EH models are incompatible
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: davek at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #1 from davek at gcc dot gnu dot org 2010-04-25 18:36 ---
Created an attachment (id=20487)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20487action=view)
Simple fix.
Maybe a bit verbose; I only made it a separate if clause so it could have its
own comment, but should
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-24 23:33 ---
(In reply to comment #2)
Totally crazy. Dave can you reproduce this?
I have a theory. Will report back in ten minutes or so...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877
--- Comment #4 from davek at gcc dot gnu dot org 2010-04-24 23:44 ---
(In reply to comment #3)
(In reply to comment #2)
Totally crazy. Dave can you reproduce this?
I have a theory. Will report back in ten minutes or so...
Uh, well, nope, that didn't work. I was wondering
--- Comment #43 from davek at gcc dot gnu dot org 2010-04-23 16:13 ---
(In reply to comment #42)
Fixed?
Still awaiting build system maintainer approval as per your request. Ten days
is just on the lower margin of the range that I let a patch wait before pinging
it; I'll do so
--- Comment #11 from davek at gcc dot gnu dot org 2010-04-21 02:17 ---
(In reply to comment #10)
Dave, can I assign this to you?
Probably not now I beat you to it! Will take me a day or three to get round
to.
--
davek at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from davek at gcc dot gnu dot org 2010-04-15 10:13 ---
Mid-air collision!
Mid-air collision detected!
:)
(In reply to comment #5)
I remember correctly), I wonder whether we should simply special case mingw32
and conditional to the macro being defined
Yeah
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-15 01:03 ---
Is this a combined-tree build? Sounds like:
http://www.mail-archive.com/g...@gcc.gnu.org/msg27284.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #4 from davek at gcc dot gnu dot org 2010-04-15 01:17 ---
So the ideal fix would be to change #ifdef FIONREAD to something more like
#if HAVE_IOCTL defined (FIONREAD). But that runs into the need-link-test
vs. cross-configure problem.
MinGW doesn't have sys/ioctl.h; could
--- Comment #41 from davek at gcc dot gnu dot org 2010-04-13 06:01 ---
Thanks everyone for all the help with testing and validation :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #36 from davek at gcc dot gnu dot org 2010-04-12 13:30 ---
(In reply to comment #35)
http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf
Thanks for the link, not just because it's full of intersting information,
but also because I now have a new candidate for
most
--- Comment #40 from davek at gcc dot gnu dot org 2010-04-13 05:58 ---
Submitted to -patches list at:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from davek at gcc dot gnu dot org 2010-04-10 16:20 ---
(In reply to comment #30)
there is something odd.
with lto:
Time: 674.484 sec (11 m 14 s)
without:
Time: 419.938 sec (6 m 59 s)
a lot slower using lto?
Is it possible you're just seeing the effects of file
--- Comment #25 from davek at gcc dot gnu dot org 2010-04-09 03:57 ---
(In reply to comment #24)
Updated for current trunk, just compiled a cross gcc for mingw
I'll test if works
Thank you! Now that 4.6 is open I'll finish the work on this (the
autoconfery needs tightening up
--- Comment #28 from davek at gcc dot gnu dot org 2010-04-09 04:10 ---
(In reply to comment #27)
these functions are static
Hmm, some kind of inlining problem maybe? There's a thread on the main GCC
list at the moment about problems with WHOPR, so I don't know to what extent
it's
--- Comment #5 from davek at gcc dot gnu dot org 2010-04-01 20:22 ---
bootstrapped, manual testing, and g++ testing now got far enough to verify the
critical testcases g++.old-deja/g++.abi/cxa_vec.C and
g++.old-deja/g++.brendan/new3.C aren't affected, which would be the place where
any
--- Comment #6 from davek at gcc dot gnu dot org 2010-04-01 20:24 ---
Subject: Bug 42609
Author: davek
Date: Thu Apr 1 20:24:35 2010
New Revision: 157931
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157931
Log:
PR target/42609
* config/i386/cygwin.h
--- Comment #7 from davek at gcc dot gnu dot org 2010-04-01 20:27 ---
Comment Required
You have to specify a comment on this change. Please explain your change.
I fixed it, so I set the resolution to 'FIXED'. Silly bugzilla!
--
davek at gcc dot gnu dot org changed
--- Comment #10 from davek at gcc dot gnu dot org 2010-04-02 01:03 ---
(In reply to comment #8)
cygcheck shows a reference to a sjlj dll,
Woah, deja vu!
although --disable-sjlj-exceptions is specified:
So, you must still have the related .dll.a file in /usr/local/lib, so
--- Comment #3 from davek at gcc dot gnu dot org 2010-04-01 01:11 ---
I figure this is worth fixing in the ~22-hour window remaining before 2nd
April. The option although deprecated should not for preference be released in
a broken state, and since it worked in all previous versions
--- Comment #2 from davek at gcc dot gnu dot org 2010-03-25 14:37 ---
(In reply to comment #0)
The manner is which Java is being checked _seems_ completely different. I'm
not
a Java expert, in fact I only know a little about it - shouldn't Java be
(identical) _independant_
--- Comment #2 from davek at gcc dot gnu dot org 2010-03-25 14:43 ---
James, you reported this against 4.3.0. I've just tried your testcase against
both 4.3.4 and HEAD, neither of which had any problem; can you see if you still
get it at all, or if we can close this PR?
--
davek
--- Comment #16 from davek at gcc dot gnu dot org 2010-03-25 14:53 ---
(In reply to comment #15)
(In reply to comment #14)
So I guess that the build and install recreates those rogue dlls.
My project compiles and links, but cannot run because the DLL is missing. So
the DLL
--- Comment #11 from davek at gcc dot gnu dot org 2010-03-23 00:22 ---
(In reply to comment #10)
Hsre's the cygcheck, which doesn't complain:
Indeed.
I can try to debug cc1.exe next, I guess.
That's the next thing to try. I'm just testing a build of HEAD using your
formula
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 00:36 ---
Cygwin no longer uses install-sh any more, it uses /usr/bin/install; also the
.exe magic has been substantially reworked. Everything works on head and
series 3 is obsolete, so I'm closing this old bug.
--
davek
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
--- Comment #3 from davek at gcc dot gnu dot org 2010-03-23 02:09 ---
Good grief, I've managed to totally overlook objc during the dll-ification
frenzy from late last summer. Confirmed that this bug still exists on HEAD.
There is fortunately a very simple and safe solution enabled
--- Comment #4 from davek at gcc dot gnu dot org 2010-03-23 02:11 ---
Created an attachment (id=20166)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20166action=view)
Use libtool to build win32 shared library
This code is now simply obsoleted by libtool functionality, which we
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 02:14 ---
(In reply to comment #5)
And this is ok if you post it with a changelog :).
Good evening Andrew! I was just looking in MAINTAINERS to see who takes care
of objc these days!
Yep, it built ok. I'm just checking
--- Comment #7 from davek at gcc dot gnu dot org 2010-03-23 02:45 ---
(In reply to comment #6)
(In reply to comment #5)
And this is ok if you post it with a changelog :).
Good evening Andrew! I was just looking in MAINTAINERS to see who takes care
of objc these days!
Yep
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 03:37 ---
This is mostly a HOWTO rather than a bug report. And 4.2 branch is retired
now, and cygwin has released 1.7, and pretty much everything's changed, so
closing it to tidy up BZ a bit.
--
davek at gcc dot gnu dot
--- Comment #4 from davek at gcc dot gnu dot org 2010-03-23 03:52 ---
(In reply to comment #3)
There is a bug in gcc-4_2 in that it won't let you make a new ABI (with a
three
stage build). So how can you switch ABIs?
No, there is/was not a bug. Switching ABIs isn't just
--- Comment #12 from davek at gcc dot gnu dot org 2010-03-23 04:03 ---
(In reply to comment #11)
That's the next thing to try. I'm just testing a build of HEAD using your
formula to see if it reproduces.
Well, nope, that's gone way past stage 1 by now and no sign of any problems
--- Comment #8 from davek at gcc dot gnu dot org 2010-03-23 05:05 ---
Subject: Bug 30445
Author: davek
Date: Tue Mar 23 05:05:35 2010
New Revision: 157662
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157662
Log:
PR libobjc/30445
* configure.ac
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-23 05:09 ---
I don't think you have any bug. Enjoy your DLL!
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from davek at gcc dot gnu dot org 2010-03-21 19:25 ---
Recategorising; target narrowly wins out over libjava. Patch was approved
at http://gcc.gnu.org/ml/java-patches/2010-q1/msg00062.html
--
davek at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from davek at gcc dot gnu dot org 2010-03-21 19:34 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:34:19 2010
New Revision: 157604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157604
Log:
PR target/42811 (prerequisite)
* include/private
--- Comment #12 from davek at gcc dot gnu dot org 2010-03-21 19:37 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:36:49 2010
New Revision: 157605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157605
Log:
PR target/42811 (prerequisite)
* jvmti.cc
--- Comment #13 from davek at gcc dot gnu dot org 2010-03-21 19:41 ---
Subject: Bug 42811
Author: davek
Date: Sun Mar 21 19:41:37 2010
New Revision: 157606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157606
Log:
PR target/42811
* libjava/configure.ac (DLLTOOL
--- Comment #14 from davek at gcc dot gnu dot org 2010-03-21 19:42 ---
And another one bites the dust.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from davek at gcc dot gnu dot org 2010-03-20 19:46 ---
This was fixed on 2009-11-30 by r.154853, which enabled libstdc++ as a DLL on
windows platforms.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from davek at gcc dot gnu dot org 2010-03-20 20:02 ---
Raising priority P4 - P3 and Cc'ing RM.
I didn't want to ask to block the release for a bug in a long-neglected
language on a secondary target before I was sure I'd be able to come up with a
fix in time, but now
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-20 20:33 ---
Right you are. I'll just have to hope it gets approved quickly while those
remaining P1s gradually tick away... :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-21 00:04 ---
No activity since the start of the year, no response to request for information
in a month. Probably was just a glitch; suspending in the absence of any
further information.
--
davek at gcc dot gnu dot org
--- Comment #6 from davek at gcc dot gnu dot org 2010-02-27 17:50 ---
Created an attachment (id=19977)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19977action=view)
Alternative approach
This alternative approach attempts to place a circular dependency between the
two generated
1 - 100 of 328 matches
Mail list logo
