--- 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.g
--- 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.
--- 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::s
--- 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 i
--- 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=19336&action=view)
differences between 32-bit and 64-bit exported symbols
There's a bunch more missing than just
--- 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=19338&action=view)
salient diffs extracted
I removed all the matching +/- line pairs from the raw diff file where a
si
--- 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=gcc&view=rev&rev=155318
Log:
PR target/42377
* config/abi/pre/gnu.ver
--- 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=19339&action=view) [edit]
> updated patch to allow specification of -static-libstdc++ on
--- 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!
>
--- 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
Summary: FAIL: gcc.c-torture/compile/2009-1.c
Product: gcc
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
GC
--- 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=19408&action=view)
Avoid emitting asterisk in assembler section directives.
Several other places in lto-streamer-out.c ta
--- 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=gcc&view=rev&rev=155500
Log:
2009-10-06 Iain Sandoe
PR objective-c
--- 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=gcc&view=rev&rev=155528
Log:
PR lto/42531
* lto-streamer-out.c (pro
--- 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=gcc&view=rev&rev=155534
Log:
2009-12-31 Iain Sandoe
PR targ
--- 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/
--- 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
--- 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 fro
--- 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
--- 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.
--- 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 fi
--- 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.
--- 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
> initializ
--- 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=19517&action=view) [edit]
> diff file i used
I don't like the look of this one:
di
--- 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=19520&action=view) [edit]
> gzipped text
>
> oh my. it counts more than 65535
--- 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 y
--- 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 adjustmen
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=42674
--- 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
--- 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 tr
--- Comment #19 from davek at gcc dot gnu dot org 2010-01-17 15:08 ---
Created an attachment (id=19635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19635&action=view)
lto for cygwin, and probably other coff targets
FTR. Well, that turned out to be quite easy. Nee
--- Comment #12 from davek at gcc dot gnu dot org 2010-01-17 15:28 ---
(In reply to comment #4)
> The patch is not yet in but I think it's the wrong approach. Instead
> uncompression should deal with tail padding.
I think you're right. I just ran into this bug on cyg
Keywords: build, lto
Severity: normal
Priority: P3
Component: lto
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-cygwin
GCC target triplet: i686-pc-cygwin
--- Comment #21 from davek at gcc dot gnu dot org 2010-01-17 16:01 ---
(In reply to comment #20)
> Well. I suppose we can backport stuff for 4.5.1 if it is LTO specific
> but I don't want to have it before 4.5.0.
Thanks, that's how I'll proceed then.
> Plea
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-17 16:07 ---
(In reply to comment #13)
> Maybe. Or simply store the size of the compressed blob at the beginning?
Yep, of course. The padding trick is kinda neat because you can do it on the
fly at the end of writing the d
--- Comment #1 from davek at gcc dot gnu dot org 2010-01-17 16:09 ---
Created an attachment (id=19636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19636&action=view)
work in progress patch
should be good for mingw as well.
needs some binutils support - will attach th
--- Comment #2 from davek at gcc dot gnu dot org 2010-01-17 16:13 ---
Created an attachment (id=19637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19637&action=view)
binutils support
This is needed to extend the .section directive in the pe-coff port of gas so
that we c
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-18 11:05 ---
(In reply to comment #3)
> (In reply to comment #1)
>
> > work in progress patch
>
> This seems to cause "*** No rule to make target `lto/@lto_binary_rea...@.o',
> needed by `lto1'
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-18 12:54 ---
(In reply to comment #5)
> > did you run autoconf?
>
> Forgot to run it, to my disgrace. :) Sorry, false alarm.
>
No need to apologise, thanks for testing on linux for me!
--
http://gcc.g
--- Comment #8 from davek at gcc dot gnu dot org 2010-01-18 16:35 ---
(In reply to comment #7)
> Should we perhaps rename all the lto_elf_ stuff to something else, if all of
> this also Just Works with COFF?
As I said, WIP; I was certainly thinking of renaming it
timization, link-failure
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-cygwin
GCC target triplet: i686-pc-cygwin
BugsThisDependsOn: 41594,41596
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
--- Comment #1 from davek at gcc dot gnu dot org 2010-01-21 03:20 ---
Test results:
clean h...@155967, default test configuration using shared C++ linking:
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01628.html
clean h...@155967, tested using static C++ linking:
http
--- Comment #2 from davek at gcc dot gnu dot org 2010-01-21 03:57 ---
Here's what's going on:
- To implement operator new/delete replacement, we use ld and --wrap to
redirect all references to the operator functions into redirection stubs in the
cygwin dll.
- Each DLL or
--- Comment #3 from davek at gcc dot gnu dot org 2010-01-21 04:00 ---
Created an attachment (id=19670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19670&action=view)
Simple stage-3-safe fix
This is the simple fix that is safe for stage 3. By trivially tweaking the
sp
--- Comment #4 from davek at gcc dot gnu dot org 2010-01-21 04:56 ---
Subject: Bug 42818
Author: davek
Date: Thu Jan 21 04:56:38 2010
New Revision: 156105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156105
Log:
PR target/42818
* config/i386/
--- Comment #5 from davek at gcc dot gnu dot org 2010-01-21 05:00 ---
Fixed for 4.5.0, so setting milestone. Then I'll add a comment about the full
fix and suspend it. BZ maintainers, apologies if this is the wrong thing to
do; should I close it and reopen it? I'm not sure
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-21 05:00 ---
So, the optimal solution would be to avoid using the redirection wrappers when
we're statically linking.
That's still possible: those undefined references without relocs don't cause
problems in and of
--- Comment #9 from davek at gcc dot gnu dot org 2010-01-21 07:10 ---
Created an attachment (id=19672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19672&action=view)
work in progress, revised to use unmodified binutils
D'oh. Turns out p2align will do exactly what I
--- Comment #10 from davek at gcc dot gnu dot org 2010-01-21 07:14 ---
Created an attachment (id=19673)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19673&action=view)
Minor fix of previous attachment.
(In reply to comment #9)
> This is the resulting versio
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-21 19:46 ---
Today's take 2 produces a ton of decompression stream errors. It turns out(*)
that the original approach probably is the correct one after all, and that
p2align will probably not do what we need here, so
--- Comment #13 from davek at gcc dot gnu dot org 2010-01-22 10:46 ---
(In reply to comment #12)
> The patch works for mingw. So you can enable lto for it, too.
>
Thanks for that, I'll update the patch in the next day or three to include
MinGW. (I'll also clean it
--- Comment #3 from davek at gcc dot gnu dot org 2010-01-22 19:25 ---
I haven't tried a whole lot of cross compiler building. There's no reference
to cygwin anywhere in crossconfig.m4, so perhaps we need --with-newlib?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42847
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-27 12:06 ---
I tried building the preprocessed source with my stock 4.3.4 compiler. The
first two error messages are about the undefined wide char types, then there's
a massive cascade of template errors following on from
--- Comment #10 from davek at gcc dot gnu dot org 2010-01-27 12:29 ---
(In reply to comment #8)
> Also note: something is going on with char16_t / char32_t which I do not
> understand at all, at the moment: in that tr1_impl code I did not setup the
> specializations for
--- Comment #11 from davek at gcc dot gnu dot org 2010-01-27 12:30 ---
(In reply to comment #9)
> (In reply to comment #7)
> > Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
>
> My code compiled flawlessly on 4.5.0-20100115,
> othe
--- Comment #14 from davek at gcc dot gnu dot org 2010-01-27 12:36 ---
(In reply to comment #12)
> on all the targets, working fine without including any header. Can you compile
> something as simple as this:
>
> char16_t a;
>
> with -std=c++0x (or -std=gnu++0x)?
T
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-27 12:38 ---
And this is r.155967
$ cat test.cpp
char16_t a;
dkad...@ubik /tmp/boost
$ g++-4 -std=c++0x -c test.cpp ; echo $?
0
dkad...@ubik /tmp/boost
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-27 12:45 ---
(In reply to comment #17)
> So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
Ah, hang on. I may have got some of my revision numbers mixed up there. (I
have a number of objdirs ly
--- Comment #20 from davek at gcc dot gnu dot org 2010-01-27 12:48 ---
(In reply to comment #18)
> (In reply to comment #17)
> > So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
>
> Ah, hang on. I may have got some of my revision numbers mixe
--- Comment #22 from davek at gcc dot gnu dot org 2010-01-27 12:59 ---
(In reply to comment #21)
> Excellent Dave. Thus, we are looking for confirmation of the char16_t /
> char32_t issue, we don't see it on our cygwin and linux machines.
OK, so I'll try updating my m
--- Comment #25 from davek at gcc dot gnu dot org 2010-01-27 13:12 ---
(In reply to comment #24)
> Created an attachment (id=19727)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727&action=view) [edit]
> preprocessed boost 1.39 mpl/size.hpp (20100107)
>
Apart f
--- Comment #27 from davek at gcc dot gnu dot org 2010-01-27 15:17 ---
(In reply to comment #26)
> > Apart from include file paths in # lines, the two files are identical.
>
> I double-checked the compilers used to generate
> them -- the attachments are correct. So the
--- Comment #28 from davek at gcc dot gnu dot org 2010-01-27 15:31 ---
I've just gone back through the older compiler versions I have lying around.
None of them can successfully compile the testcase without -std=c++0x at all,
they all complain about the missing types in the sam
--- Comment #31 from davek at gcc dot gnu dot org 2010-01-27 15:48 ---
(In reply to comment #30)
> If Dave, you have evidence that older versions of GCC always needed -std=c++0x
> in order to compile this boost code, this is a cygwin-specific issue: I just
> tried with a 4.4.x
--- Comment #33 from davek at gcc dot gnu dot org 2010-01-27 16:07 ---
(In reply to comment #32)
> Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really
> honest, personally I'm not interested in cygwin much. My suggestion is just
> making sure the
--- Comment #35 from davek at gcc dot gnu dot org 2010-01-27 17:55 ---
(In reply to comment #34)
> digressing too much in this thread: for sure, if I just take the one-liner
> provided by submitter the errors I get are the same, with and without
> -std=c++0x, and with 4.
--- Comment #40 from davek at gcc dot gnu dot org 2010-01-27 18:17 ---
(In reply to comment #39)
> looks as though the .ii was created using -std=c++0x and then the compiler
> output obtained by compiling it without -std=c++0x
>
> that's never going to work
>
:)
--- Comment #15 from davek at gcc dot gnu dot org 2010-02-03 12:02 ---
(In reply to comment #14)
> There is a portability issue in is_elf_or_coff: fopen should be called with
> "rb" instead of "r". Otherwise, fread fails when a COFF file has 26 sections,
> b
--- Comment #16 from davek at gcc dot gnu dot org 2010-02-03 14:46 ---
Created an attachment (id=19795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19795&action=view)
Latest and updatest.
Updated:
- enable for mingw targets
- open files in binary mode in is_elf_or_coff
--- Comment #17 from davek at gcc dot gnu dot org 2010-02-03 14:48 ---
TO-DO: (additions invited, this is not by any means a complete list!)
- Add autoconfigury to ensure binutils supports .section directive alignment
syntax, and disable LTO if not.
--
davek at gcc dot gnu dot org
--- Comment #18 from davek at gcc dot gnu dot org 2010-02-03 16:09 ---
Created an attachment (id=19797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19797&action=view)
Bugfix of -respin-1
Opps! Forgot to update the lto language hook definitions. All fixed now.
--
d
--- Comment #3 from davek at gcc dot gnu dot org 2010-02-04 03:37 ---
(In reply to comment #2)
> Created an attachment (id=19671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19671&action=view) [edit]
> patch
>
> now it summons gcj-noncore dll and resolves c
--- Comment #19 from davek at gcc dot gnu dot org 2010-02-04 17:12 ---
Created an attachment (id=19805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19805&action=view)
Further bugfix
fixed silly cut'n'pasto in the endianness layer which was truncating 4-byte
--- Comment #5 from davek at gcc dot gnu dot org 2010-02-05 14:06 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00156.html
Patched C++ testsuite results:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00414.html
One new failure observed:
http://gcc.gnu.org/ml/gcc
--- Comment #4 from davek at gcc dot gnu dot org 2010-02-05 17:44 ---
Created an attachment (id=19808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19808&action=view)
proposed fix
I'm going to bootstrap and test this patch, which adds a dummy static
dependency to
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-05 22:39 ---
(In reply to comment #7)
> Fixed.
>
Thanks!
--
davek at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from davek at gcc dot gnu dot org 2010-02-06 00:34 ---
closing old bug after reverifying with latest sources and patch for bug 42776
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-06 00:35 ---
just verified against r.156467
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
* gcc.c (DEFAULT_SWITCH_CURTAILS_COMPILATION): Add -E.
(process_command): Handle -E as done with -c
--- 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 #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 #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 #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...
>
> r16
--- 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 #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 #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 #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 #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 #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 #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
201 - 300 of 329 matches
Mail list logo
