--- Comment #12 from davek at gcc dot gnu dot org 2009-09-30 21:25 ---
Bad news: the patch doesn't work. I edited the generated config.status so
that it would use "bash -x" when reinvoking configure as part of --recheck, and
it seems that although the code goes thr
--- Comment #13 from davek at gcc dot gnu dot org 2009-09-30 21:26 ---
Created an attachment (id=18680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18680&action=view)
"bash -x" log of configure script run
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #26 from davek at gcc dot gnu dot org 2009-10-02 15:35 ---
Thanks Jakub, I'll try and verify that in the next ~24hrs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
--- Comment #2 from davek at gcc dot gnu dot org 2009-10-03 12:23 ---
(In reply to comment #1)
> Wouldn't it be enough to replace ";" by "&&" between the various steps?
>
Hello Sam, the problem with just doing that is that xoscons can fail but s
--- Comment #4 from davek at gcc dot gnu dot org 2009-10-03 13:41 ---
(In reply to comment #0)
> They seem to represent serious breakage of dllexport with cygwin as the latest
> testrun with my libstdc-as-dll patch is showing even more fails on top of
> these, but didn'
--- Comment #7 from davek at gcc dot gnu dot org 2009-10-03 21:55 ---
(In reply to comment #5)
> The breakage can be fixed in target backend i386/winnt-cxx.c
> i386_pe_adjust_class_at_definition, by propagating the dllexport attribute
> there, rather than relying on DECL_CONT
--- Comment #10 from davek at gcc dot gnu dot org 2009-10-07 17:55 ---
(In reply to comment #9)
> Fixed at revision 152511.
>
My tests (r.152512) have now run far enough to confirm that all the new FAILs
are fixed. Thanks Danny!
--
davek at gcc dot gnu dot org c
--- Comment #15 from davek at gcc dot gnu dot org 2009-10-07 20:33 ---
Created an attachment (id=18745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18745&action=view)
global log
(In reply to comment #14)
> Subject: Re: Can't build libgomp without
> --enable
--- Comment #27 from davek at gcc dot gnu dot org 2009-10-08 03:28 ---
Verified that java bootstraps fine at r.152512. Thank you Jakub :)
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from davek at gcc dot gnu dot org 2009-10-08 19:37 ---
(In reply to comment #16)
> Created an attachment (id=18755)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755&action=view) [edit]
> (hopefully) better patch
>
> Gah. Initial white space
--- Comment #19 from davek at gcc dot gnu dot org 2009-10-10 07:35 ---
(In reply to comment #18)
> Created an attachment (id=18756)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18756&action=view) [edit]
> ditto, but without the d'oh factor
>
> That'
--- Comment #20 from davek at gcc dot gnu dot org 2009-10-10 17:46 ---
(In reply to comment #19)
> I'll set a full
> bootstrap going now just for completeness' sake,
Completed and passed check-target-libgomp without incident, by which I mean
it didn't try and
--- Comment #1 from davek at gcc dot gnu dot org 2009-10-13 05:04 ---
It is not appropriate to add a mailing list as a Cc to a bugzilla entry, so
I've removed that from the CC list.
On the other hand, I have some good news for you; this has been fixed in SVN
and will be working i
--- Comment #33 from davek at gcc dot gnu dot org 2009-11-09 11:05 ---
This has been working fine for some time now, so closing. Verified by building
r154011: no debuginfo problems.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from davek at gcc dot gnu dot org 2009-11-09 11:09 ---
Inactive for over a year, and was most likely a system or environment problem
rather than a bug in gcc itself, so closing. HEAD currently builds fine.
--
davek at gcc dot gnu dot org changed:
What
--- Comment #11 from davek at gcc dot gnu dot org 2007-05-02 15:38 ---
From the initial PR:
> There ought to be a way to detect that threading support is disabled so that
> pessimizations like mutex locks can be left out.
From the definition of -mthreads in TFM:
"
--- Comment #12 from davek at gcc dot gnu dot org 2007-05-02 15:41 ---
Sorry for the repeated emails, bugzilla wouldn't let me verify and close this
bug without forcing me to add a comment.
--
davek at gcc dot gnu dot org changed:
What|Re
us: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned 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-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844
--- Comment #1 from davek at gcc dot gnu dot org 2007-05-06 16:10 ---
Created an attachment (id=13516)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13516&action=view)
Testcase as described in summary.
Not preprocessed, but this testcase is not affected by preprocessing
--- Comment #19 from davek at gcc dot gnu dot org 2007-05-31 02:07 ---
Subject: Bug 14331
Author: davek
Date: Thu May 31 02:06:48 2007
New Revision: 125212
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125212
Log:
2007-05-31 Dave Korn <[EMAIL PROTECTED]&g
--- Comment #4 from davek at gcc dot gnu dot org 2010-02-12 17:35 ---
Subject: Bug 42982
Author: davek
Date: Fri Feb 12 17:35:18 2010
New Revision: 156736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156736
Log:
2010-02-12 Dave Korn
Jack
--- Comment #21 from davek at gcc dot gnu dot org 2010-02-13 01:06 ---
(In reply to comment #20)
> What is the plan for this bug, fix it for GCC 4.5.0 or for later?
I don't really think I can argue that this is stage3 material, so the plan is
to fix it when trunk reopens for 4.
--- Comment #7 from davek at gcc dot gnu dot org 2010-02-15 17:30 ---
(In reply to comment #3)
> Confirmed, this is either a cygwin/newlib bug or a libstdc++ bug:
> reduced testcase for the error:
Reduced reduced testcase:
static const char print = 0x97;
--
davek at gcc d
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-15 17:31 ---
Oops, that was slightly premature. I meant to add that the error (from the
original testcase) doesn't happen with the 4.3.4 system compiler nor with 4.5.0
head, and that I'm afraid there aren't going
--- Comment #9 from davek at gcc dot gnu dot org 2010-02-15 17:32 ---
(In reply to comment #5)
> Is the print member really already overflowed? It has a value of 0200 which
> is
> 0x80: so if char is signed (it is on cygwin) then it's setting the sign bit,
> which sho
--- Comment #10 from davek at gcc dot gnu dot org 2010-02-15 17:35 ---
(still here - only de-cc'd one of my two addresses)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
--- Comment #2 from davek at gcc dot gnu dot org 2010-02-17 15:10 ---
(In reply to comment #1)
> This sounds more like a cygwin problem, not a GCC one.
It's a problem with the cygwin target-dependent linker spec.
The -mno-cygwin option is deprecated and scheduled to be withdra
--- Comment #2 from davek at gcc dot gnu dot org 2010-02-17 15:15 ---
I can confirm that 4.3 series builds working ecj1 when you use the configure
option, since that's how I build the distro release compiler.
--
davek at gcc dot gnu dot org changed:
What|Re
--- Comment #10 from davek at gcc dot gnu dot org 2010-02-17 15:24 ---
This bug was originally caused by the fact that libjava was disabled in
noconfigdirs for cygwin at the time the report was filed. This has long since
been fixed.
The last four comments are incorrect in assuming
--- Comment #4 from davek at gcc dot gnu dot org 2010-02-17 15:33 ---
The ln invocation has long since been using -f, so i'm closing this old bug
fixed.
--
davek at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from davek at gcc dot gnu dot org 2010-02-17 15:29 ---
Just reconfirmed with recent pre-4.5.0 HEAD:
$ /gnu/gcc/install-pr42811-3/opt/gcc-tools/bin/g++-4.exe -S vis.cpp -o vis.asm
vis.cpp:30:47: warning: visibility attribute not supported in this
configuration; ignored
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-17 15:39 ---
Hello James, are you still experiencing this problem?
It looks to me like the xgcc driver program that you debugged was working ok,
but something failed when it launched the separate cc1 process. You might need
to
--- Comment #11 from davek at gcc dot gnu dot org 2010-02-18 12:54 ---
(In reply to comment #9)
> Dave, what do you recommend about this issue? Does it affect cygwin too?
>
This particular problem doesn't occur on cygwin, but we've had similar issues
in the past with
--- Comment #5 from davek at gcc dot gnu dot org 2010-02-20 00:40 ---
Created an attachment (id=19928)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19928&action=view)
patch respin
So, after much single-stepping in the debugger, and some discussion on the
mailing list
--- Comment #1 from davek at gcc dot gnu dot org 2010-02-21 22:27 ---
just ran into this myself!
--
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
--- 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
fi
--- 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 #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 #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 #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 #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 #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 #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 #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 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 enabl
--- 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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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.
Mi
--- 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 #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 #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 #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, tha
--- 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
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
--
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=20487&action=view)
Simple fix.
Maybe a bit verbose; I only made it a separate if clause so it could have its
own comme
--- 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 #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 #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 #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 #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 #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
nt: target
AssignedTo: unassigned 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-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
--- Comment #1 from davek at gcc dot gnu dot org 2009-11-20 16:11 ---
Created an attachment (id=19068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19068&action=view)
work-in-progress
This patch is a bit overly keen in how far it propagates dllimport, leading to
the reg
--
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 #4 from davek at gcc dot gnu dot org 2009-12-04 17:30 ---
Just got awake in my $TZ, will look at this straight away and fix or revert in
the next couple of hours. Sorry for the inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-04 17:58 ---
Created an attachment (id=19225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19225&action=view)
Simple fix
The comment in the patch should explain. Namespace macros are defined at the
top of c++c
--- Comment #6 from davek at gcc dot gnu dot org 2009-12-04 18:00 ---
I didn't anticipate any of the os-specific config headers trying to use the
namespace macros, since all the necessary defines and stuff are only half-way
through being set up, but I didn't imagine the poss
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-04 18:23 ---
(In reply to comment #7)
> I'll test tonight.
Thanks. So sorry for the aggro :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-05 02:27 ---
(In reply to comment #9)
> The patch fixes the build error. It's ok to install with a ChangeLog
> entry.
Great, thanks for checking and sorry for the inconvience. I'll get it
committed in the
101 - 200 of 329 matches
Mail list logo
