--- 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-inl
--- 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
--- 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 a
--- 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)
--- 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...
>
> r16
--- 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 #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'
--- 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 J
--- 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 o
--- 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
* gcc.c (DEFAULT_SWITCH_CURTAILS_COMPILATION): Add -E.
(process_command): Handle -E as done with -c
--- 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 #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 -O
--- 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 (TR
--- 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=gcc&view=rev&rev=161982
Log:
2010-07-09 Dave Korn
Backport from
--- 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=gcc&view=rev&rev=160722
Log:
ChangeLog:
Backport from mainline:
2010-04-27 D
--- 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=20771&action=view)
testcase as per initial comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44321
y: P3
Component: middle-end
AssignedTo: 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 #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 #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 #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'
--- 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
--
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 #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
--- 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
--- 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 #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
--- 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=20668&action=view)
testcase: makefile
--
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=20667&action=view)
testcase: dll header
--
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=20666&action=view)
testcase: dll source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- 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=20665&action=view)
testcase: main executable source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- 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
>
--- 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
--- 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
--- 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/le
--- 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.
--- 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 #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=gcc&view=rev&rev=159115
Log:
PR target/42811
* tests/staticrootstes
--- 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=gcc&view=rev&rev=159111
Log:
PR target/43888
* config/i386
--- 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 #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 #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 #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=20512&action=view)
Extends GNU LD to parse archives for LTO.
(In reply to comment #3)
> Ow. I think we need to get LD
--- 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
> wi
--- 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
--- 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 #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 #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=gcc&view=rev&rev=158764
Log:
Missing changelog from last commit!
ChangeLog:
20
--- 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=gcc&view=rev&rev=158763
Log:
Missing file from last commit!
ChangeLog:
2010-04-
--- 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=gcc&view=rev&rev=158762
Log:
ChangeLog:
PR lto/42776
* conf
--- 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
--- 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=20487&action=view)
Simple fix.
Maybe a bit verbose; I only made it a separate if clause so it could have its
own comme
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
else if (code == NE_EXPR)
> return omit_two_operands_loc (loc, type, boolean_true_node,
> arg0, arg1);
> }
it seems that i386_pe_binds_local_p is incorrectly returning true even for the
weak symbol. I have a patch.
--
Summary: FAIL
--- 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 incompati
--- 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, tha
--- 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 #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&#x
--- 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:
--- 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
--- 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.
Mi
--- 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 #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 #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 #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
--- 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 jus
--- 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
--- 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
--- 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/l
--- 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 g
--- 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=gcc&view=rev&rev=157931
Log:
PR target/42609
* config/i386/
--- 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 wher
--- 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 #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 t
--- 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?
--
dav
--- 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
> (ident
--- 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 |
--- 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=gcc&view=rev&rev=157662
Log:
PR libobjc/30445
* conf
--- 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 n
--- 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 ABI
--- 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 gn
--- 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
--- 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 ju
--- 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=20166&action=view)
Use libtool to build win32 shared library
This code is now simply obsoleted by libtool functionality, w
--- 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 enabl
--
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
--
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=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=42271
--- 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.
--
--- 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
--- 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 #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=gcc&view=rev&rev=157606
Log:
PR target/42811
* libjava/configure.ac
--- 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=gcc&view=rev&rev=157605
Log:
PR target/42811 (prerequisite)
*
--- 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=gcc&view=rev&rev=157604
Log:
PR target/42811 (prerequisite)
*
--- 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:
--- 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 #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 #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
fi
--- 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 #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=19977&action=view)
Alternative approach
This alternative approach attempts to place a circular dependency between the
two ge
1 - 100 of 329 matches
Mail list logo
