--- Comment #14 from davek at gcc dot gnu dot org 2007-04-10 15:11 ---
Patch posted for review at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--- Comment #16 from davek at gcc dot gnu dot org 2007-04-17 18:47 ---
Oh, BTW, congratulations Tom on being appointed a libcpp maintainer!
grin-grin-hint-hint-nudge-nudge-wink-wink
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
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=31662
--- Comment #2 from davek at gcc dot gnu dot org 2007-04-25 01:23 ---
It determines the calling convention used, and is therefore surely the
territory of the system headers/libs. Do take a look at the upstream source:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/include
--- 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:
`-mthreads
--- 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|Removed
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=13516action=view)
Testcase as described in summary.
Not preprocessed, but this testcase is not affected by preprocessing anyway
--- Comment #2 from davek at gcc dot gnu dot org 2009-01-17 21:06 ---
Subject: Bug 38862
Author: davek
Date: Sat Jan 17 21:06:17 2009
New Revision: 143472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143472
Log:
PR bootstrap/38862
* Makefile.in (BACKENDLIBS
--- Comment #12 from davek at gcc dot gnu dot org 2009-01-21 19:20 ---
Subject: Bug 37660
Author: davek
Date: Wed Jan 21 19:20:08 2009
New Revision: 143552
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143552
Log:
PR bootstrap/37660
* config/i386/cygwin.h
--- Comment #3 from davek at gcc dot gnu dot org 2009-01-31 18:52 ---
Subject: Bug 38904
Author: davek
Date: Sat Jan 31 18:52:00 2009
New Revision: 143829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143829
Log:
PR target/38904
* mkmap-flat.awk (END): Use
--- 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=gccview=revrev=125212
Log:
2007-05-31 Dave Korn [EMAIL PROTECTED]
PR preprocessor
--- 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
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=19068action=view)
work-in-progress
This patch is a bit overly keen in how far it propagates dllimport, leading to
the regression
--
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=19225action=view)
Simple fix
The comment in the patch should explain. Namespace macros are defined at the
top of c++config.h before
--- 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 possibility
--- 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 next hour or two
--- Comment #11 from davek at gcc dot gnu dot org 2009-12-05 06:14 ---
Committed revision 155008.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from davek at gcc dot gnu dot org 2009-12-05 06:16 ---
boh! Forgot to reference the pr in the changelog. I'll fix it if anyone asks
me to but not otherwise, I don't think it's likely to be critical for such a
transient bug.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from davek at gcc dot gnu dot org 2009-12-15 11:49 ---
Hi Rainer, it'll take a little time but I'll set myself up a build environment
and see if I can reproduce this.
The libtool dependency libs stuff is a known problem in libtool IIRC. Details
to follow.
--
http
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-17 09:04 ---
This is starting to look like an LD bug. The function is there in the objects
fed into the final link:
$ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve
t .text$_ZNSs7reserveEy
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 10:07 ---
Ok, it's not an LD bug. LD is doing the right thing, which in this case turns
out to be filtering it out of the list of exports due to the version script.
In the 32-bit multilib, we have this version of std::string
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-17 10:20 ---
Starting to think that actually this is just how the ABI should be for w64 and
the version script for libstdc++ just has a weakness. If I'm guessing right,
it's because w64 is the only LLP64 target that is why
--- Comment #7 from davek at gcc dot gnu dot org 2009-12-17 11:27 ---
Created an attachment (id=19336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19336action=view)
differences between 32-bit and 64-bit exported symbols
There's a bunch more missing than just std::string::reserve
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-17 11:52 ---
Created an attachment (id=19338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19338action=view)
salient diffs extracted
I removed all the matching +/- line pairs from the raw diff file where a
signature changed
--- Comment #9 from davek at gcc dot gnu dot org 2009-12-17 15:25 ---
Subject: Bug 42377
Author: davek
Date: Thu Dec 17 15:25:36 2009
New Revision: 155318
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155318
Log:
PR target/42377
* config/abi/pre/gnu.ver: Adjust
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-17 15:27 ---
Should be fixed in SVN now. Rainer, please verify when you get a chance.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 19:58 ---
(In reply to comment #2)
Created an attachment (id=19339)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339action=view) [edit]
updated patch to allow specification of -static-libstdc++ on the CL while
--- Comment #13 from davek at gcc dot gnu dot org 2009-12-20 19:59 ---
(In reply to comment #12)
(In reply to comment #11)
(In reply to comment #10)
Should be fixed in SVN now. Rainer, please verify when you get a chance.
Seems to work now!
Rainer
That counts
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-21 05:11 ---
This problem will be resolved in the next few days when I release an official
cygwin distro package for libelf, which will have this issue fixed. HTH :)
--
davek at gcc dot gnu dot org changed:
What
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
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
--- Comment #1 from davek at gcc dot gnu dot org 2009-12-29 02:53 ---
Created an attachment (id=19408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19408action=view)
Avoid emitting asterisk in assembler section directives.
Several other places in lto-streamer-out.c take this same
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-29 04:13 ---
Subject: Bug 41595
Author: davek
Date: Tue Dec 29 04:13:09 2009
New Revision: 155500
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155500
Log:
2009-10-06 Iain Sandoe iain.san...@sandoe-acoustics.co.uk
--- Comment #2 from davek at gcc dot gnu dot org 2009-12-30 16:37 ---
Test runs all finished.
Before: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02081.html
After: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02582.html
No new fails. Sending patch.
--
http
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-30 23:21 ---
Subject: Bug 42531
Author: davek
Date: Wed Dec 30 23:20:55 2009
New Revision: 155528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155528
Log:
PR lto/42531
* lto-streamer-out.c (produce_asm
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-31 01:35 ---
Subject: Bug 41605
Author: davek
Date: Thu Dec 31 01:35:24 2009
New Revision: 155534
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155534
Log:
2009-12-31 Iain Sandoe iain.san...@sandoe-acoustics.co.uk
--- Comment #9 from davek at gcc dot gnu dot org 2010-01-02 13:25 ---
(In reply to comment #7)
(In reply to comment #6)
I have a hard way thinking of a way this is a regression.
Well it is partly a regression as if you have libelf installed in /usr/local
or
/usr, configure
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-02 13:51 ---
(In reply to comment #10)
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O3 -fwhopr
this means you do not get any LTO optimization (it's really the only test
that tests
--- Comment #13 from davek at gcc dot gnu dot org 2010-01-02 13:59 ---
(In reply to comment #12)
The collect2 stuff should in principle work with non-ELF targets
as well if you circumvent that first problem somehow (for
example by not producing regular object code from cc1 but only
--- Comment #16 from davek at gcc dot gnu dot org 2010-01-02 14:33 ---
JFTR: I'll be working on this later in January. I'll do it on the
cygwin-improvements branch for visibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-02 15:20 ---
(In reply to comment #17)
I don't really see the point of the ELF container if you also have code to
parse a native object format. Either add a separate COFF etc. (or
BFD-using if you so wish) implementation
--- Comment #12 from davek at gcc dot gnu dot org 2010-01-04 15:42 ---
COMMON symbols don't cause members to be pulled in from library archives. You
can omit -L. -lex from the final link altogether and get the same result:
it's unused. So the reference from bug.o to _jindx2 doesn't
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-04 16:36 ---
(In reply to comment #14)
(In reply to comment #12)
COMMON symbols don't cause members to be pulled in from library archives.
You
can omit -L. -lex from the final link altogether and get the same result
--- Comment #17 from davek at gcc dot gnu dot org 2010-01-04 18:05 ---
(In reply to comment #16)
You made an unmerited assertion that COMMON symbols don't cause
members to be pulled in from library archives. I've shown the
counter example.
On what platform?
This appears
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-04 18:06 ---
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1811 also looks pertinent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
--- Comment #3 from davek at gcc dot gnu dot org 2010-01-09 07:12 ---
[ Replying to your post on binutils list ]
jojelino wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42658
it is critical when linking libgcj library hence it uses .jcr section to
initialize java class CTORs
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-09 07:49 ---
(In reply to comment #4)
Created an attachment (id=19517)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19517action=view) [edit]
diff file i used
I don't like the look of this one:
diff --git a/libjava
--- Comment #8 from davek at gcc dot gnu dot org 2010-01-09 08:43 ---
(In reply to comment #7)
Created an attachment (id=19520)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19520action=view) [edit]
gzipped text
oh my. it counts more than 65535.. [167929]
!LOL! That's
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-09 09:38 ---
Ah. It's probably caused by --enable-java-awt. AWT isn't yet supported on
cygwin yet; looks like it will need some adjustment to the way .o files are
divided between the two dlls, most likely.
Can you confirm
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-09 10:12 ---
(In reply to comment #12)
(In reply to comment #11)
Ah. It's probably caused by --enable-java-awt. AWT isn't yet supported on
cygwin yet; looks like it will need some adjustment to the way .o files
in function returning non-
void warning
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek
--- Comment #2 from davek at gcc dot gnu dot org 2010-01-11 00:23 ---
(In reply to comment #1)
We should probably warn instead function returning non-void declared with
attribute noreturn.
I think not; I don't see why you should be obliged to change the prototype of a
function
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-11 08:16 ---
just waiting to see if this can be reproduced with clean sources.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from davek at gcc dot gnu dot org 2010-01-11 17:39 ---
Confirmed that it was just a glitch of some kind.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-11 19:07 ---
(In reply to comment #3)
(even without the __noreturn__?)
Yes, even without.
I think this may be actually two bugs, one is the noreturn which should set
current_function_returns_abnormally to true, so
--- Comment #3 from davek at gcc dot gnu dot org 2009-07-20 01:25 ---
Long since fixed.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from davek at gcc dot gnu dot org 2009-07-20 01:27 ---
Taking assignment.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from davek at gcc dot gnu dot org 2009-07-20 14:11 ---
Created an attachment (id=18229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18229action=view)
proposed fix
This patch fixes all the significant FAILs currently extant in the libffi
testsuite
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-20 14:31 ---
Created an attachment (id=18230)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18230action=view)
Updated patch
Now with a trivial tweak to fix a missing-prototype warning.
--
davek at gcc dot gnu dot org
--- Comment #5 from davek at gcc dot gnu dot org 2009-07-20 14:43 ---
Created an attachment (id=18231)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18231action=view)
final spin
Turns out that '#' makes a bad choice of comment introducer if the next word is
if and you're running
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-24 10:12 ---
Subject: Bug 40807
Author: davek
Date: Fri Jul 24 10:12:16 2009
New Revision: 150042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150042
Log:
PR libffi/40807
* src/x86/ffi.c
--- Comment #7 from davek at gcc dot gnu dot org 2009-07-24 10:22 ---
Fixed at r.150042.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status
: normal
Priority: P3
Component: ada
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
--- Comment #1 from davek at gcc dot gnu dot org 2009-07-25 15:09 ---
This is how adaint.h uses the FOPEN, etc. macros to conceal the 32/64 file i/o
selection:
#if defined (__GLIBC__) || defined (sun) || defined (__sgi)
#define FOPEN fopen64
#define STAT stat64
#define FSTAT fstat64
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-25 16:06 ---
*** Bug 40857 has been marked as a duplicate of this bug. ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davek at gcc dot gnu dot org 2009-07-25 16:06 ---
*** This bug has been marked as a duplicate of 40578 ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #7 from davek at gcc dot gnu dot org 2009-07-25 16:14 ---
Created an attachment (id=18253)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18253action=view)
Rename macros with GNAT_ prefix
Now testing this (respun) version of the fix I originally suggested to bug
40857
--- Comment #13 from davek at gcc dot gnu dot org 2009-07-26 14:26 ---
Broken again on HEAD :-(
Configured with --program-suffix=-4, bootstrapped, and installed into a new
$prefix that I then placed at the front of $PATH.
None of the newly built gnat* executables had
--- Comment #8 from davek at gcc dot gnu dot org 2009-07-26 15:09 ---
Subject: Bug 40578
Author: davek
Date: Sun Jul 26 15:09:10 2009
New Revision: 150098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150098
Log:
PR bootstrap/40578
* adaint.h (FOPEN, STAT, FSTAT
--- Comment #9 from davek at gcc dot gnu dot org 2009-07-26 15:13 ---
All done now.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #17 from davek at gcc dot gnu dot org 2009-07-26 20:39 ---
(In reply to comment #15)
Right, my change fixed gnatmake so that it would call the proper gcc (based on
the
previous comments on this PR), but Makefiles have never supported
--program-suffix, so that's not even
--- Comment #19 from davek at gcc dot gnu dot org 2009-07-26 20:57 ---
(In reply to comment #18)
No, the support that was implemented is that the suffix of gnatmake
is the one that gcc gets suffixed with.
Ah ok, I see. Then it's working as designed. Sorry for the noise in your
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-29 09:23 ---
Reopening against 4.3.4 RC 20090727.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #5 from davek at gcc dot gnu dot org 2009-07-29 11:45 ---
Subject: Bug 38903
Author: davek
Date: Wed Jul 29 11:45:30 2009
New Revision: 150209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150209
Log:
PR bootstrap/38903: Backport fix from HEAD
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-29 12:08 ---
Fixed on gcc-4_3-branch.
Not present on gcc-4_4-branch, fix was applied to HEAD before branching.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
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=40984
: Can't declare an extern C friend.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-09 21:31 ---
(In reply to comment #0)
$ g++-4 -v
Yuck, that got horribly wrapped. Here it is again, hopefully formatted a
little better this time:
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /gnu/gcc/gcc
--- Comment #2 from davek at gcc dot gnu dot org 2009-08-09 22:03 ---
Still present, although the location has slipped slightly for the warnings on
the function declarations with no body.
$ g++ -S vis.cpp -o vis.asm
vis.cpp: In function 'int foo(int)':
vis.cpp:11: warning: visibility
--- Comment #3 from davek at gcc dot gnu dot org 2009-08-10 16:17 ---
(In reply to comment #2)
Apart from the semi-colon after the extern C block the code is valid and
this
is a recent regression on trunk.
I am fairly sure that a semi-colon after a block statement like
--- Comment #5 from davek at gcc dot gnu dot org 2009-08-10 17:16 ---
(In reply to comment #4)
It's irrelevant to this bug and is just me being more pedantic than -pedantic,
however ... even with -pedantic GCC has always accepted stray semi-colons at
namespace scope, but it's
--
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 #1 from davek at gcc dot gnu dot org 2009-08-12 22:57 ---
Even the target-specific i686-mingw32/bin directory contains host applications,
i.e. the non-$target-prefixed versions of the binutils.
So since these DLLs are never going to be used on the host, we could put them
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-18 13:36 ---
(In reply to comment #10)
Does the fix mean that GNAT does not support large files on any platform?
No need to worry, that was reason why I mentioned it would be necessary to
change the 64-bit definition as well
--- Comment #10 from davek at gcc dot gnu dot org 2009-08-21 02:20 ---
*** Bug 30570 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
--- Comment #9 from davek at gcc dot gnu dot org 2009-08-21 02:20 ---
*** This bug has been marked as a duplicate of 38892 ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-21 02:23 ---
This has been fixed now since these two revisions were applied:
http://gcc.gnu.org/viewcvs?view=revisionrevision=146627
http://gcc.gnu.org/viewcvs?view=revisionrevision=146869
These days libjava builds fine
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-21 02:26 ---
Was fixed in
http://gcc.gnu.org/viewcvs?view=revisionrevision=147641
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-15 12:47 ---
This bug is also present on i686-pc-cygwin at r.151703, so given Jie's
diagnosis in comment 2, let's switch the component from 'target' to 'debug'.
libtool: link: /gnu/gcc/obj.libstdc.enabled/./gcc/xgcc
-B/gnu/gcc
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
(In reply to comment #2)
I think it's the same issue for PR41357.
*This* is PR41357; you must mean PR41308. Yes, I think so, I'll mark it as a
dup of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
*** Bug 41308 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
*** This bug has been marked as a duplicate of 41357 ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-15 13:29 ---
(In reply to comment #1)
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.
Here's an example:
1f51: Abbrev Number: 49 (DW_TAG_variable)
f52 DW_AT_name
1 - 100 of 328 matches
Mail list logo
