--- 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=gcc&view=rev&rev=143472
Log:
PR bootstrap/38862
* Makefile.in (BAC
--- 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=gcc&view=rev&rev=143552
Log:
PR bootstrap/37660
* config/i386/
--- 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=gcc&view=rev&rev=143829
Log:
PR target/38904
* mkmap-flat.awk (EN
--- Comment #60 from davek at gcc dot gnu dot org 2009-05-28 10:48 ---
Subject: Bug 37216
Author: davek
Date: Thu May 28 10:48:35 2009
New Revision: 147950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147950
Log:
gcc/ChangeLog:
2009-05-28 Dave Korn
P
--- 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=18229&action=view)
proposed fix
This patch fixes all the significant FAILs currently extant in the libffi
te
--- 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=18230&action=view)
Updated patch
Now with a trivial tweak to fix a missing-prototype warning.
--
davek at gcc dot gnu
--- 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=18231&action=view)
final spin
Turns out that '#' makes a bad choice of comment introducer if the next word i
--- 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=gcc&view=rev&rev=150042
Log:
PR libffi/40807
* src/x
--- 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
UNCONFIRMED
Severity: 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
--- 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=18253&action=view)
Rename macros with GNAT_ prefix
Now testing this (respun) version of the fix I originally suggested to bu
--- 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 the
--- 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=gcc&view=rev&rev=150098
Log:
PR bootstrap/40578
* adaint.h (FOP
--- 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, s
--- 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 no
--- 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=gcc&view=rev&rev=150209
Log:
PR bootstrap/38903: Backport fix f
--- 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
./xoscons ; \
$(RM) ../../s-oscons.ads ; \
$(CP) s-oscons.ads s-oscons.h ../../)
should be changed something along the lines (untested):
$(ADA_GEN_SUBDIR)/s-oscons.ads : $(ADA_GEN_SUBDIR)/s-oscons-tmplt.c
$(ADA_GEN_SUBDIR)/gsocket.h $(ADA_GEN_SUBDIR)/xosco
t: 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 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=41020
--- 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/
--- 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:
--- 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 sta
--- 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
--
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
in
--- 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!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
gcj
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=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 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 definit
--- 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=revision&revision=146627
http://gcc.gnu.org/viewcvs?view=revision&revision=146869
These days libjav
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-21 02:26 ---
Was fixed in
http://gcc.gnu.org/viewcvs?view=revision&revision=147641
--
davek at gcc dot gnu dot org changed:
What|Removed |A
--- 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
--- 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
--- 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:
<1>: Abbrev Number: 49 (DW_TAG_variabl
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-15 13:40 ---
This looks a little tricky.
Knowledge of the "__emutls_v." prefix is entirely private to varasm.c. The
actual prefixed object itself escapes publicly with that name, but only
varasm.c knows that
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-15 14:07 ---
(In reply to comment #6)
> (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 examp
--- Comment #10 from davek at gcc dot gnu dot org 2009-09-15 14:24 ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > (In reply to comment #1)
> > > > The cause is that DW_TAG_variable refer
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-15 14:53 ---
The bogus const info is added in at the end of this call chain, when generating
the var die:
#0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
at /gnu/gcc/gcc/gcc/tree.h:182
#1
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-15 16:16 ---
(In reply to comment #11)
> The bogus const info is added in at the end of this call chain, when
> generating
> the var die:
>
> #0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-15 17:08 ---
Created an attachment (id=18586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-15 17:16 ---
(In reply to comment #14)
> Created an attachment (id=18586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view) [edit]
> reduced testcase
>
Ok, this is really interesting.
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-15 17:25 ---
(In reply to comment #16)
> Please read what I wrote.
I did, but I'm a few steps behind, and haven't figured out whether to blame
encode_section_info() for being naive, or to look at where the SYM_REF
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-15 17:36 ---
Created an attachment (id=18587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18587&action=view)
patch based on jakub's suggestion
this fixes the testcase, so I may as well take it for a full boo
--- Comment #22 from davek at gcc dot gnu dot org 2009-09-15 17:57 ---
Created an attachment (id=18588)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18588&action=view)
slightly reworked patch
slightly reworked per hj's suggestion
--
davek at gcc dot gnu dot
--- Comment #21 from davek at gcc dot gnu dot org 2009-09-15 17:51 ---
(In reply to comment #19)
> Index: varasm.c
> ===
> --- varasm.c(revision 151703)
> +++ varasm.c(working copy)
> @@
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-16 10:19 ---
Created an attachment (id=18595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595&action=view)
simplified fix
After discussion on the -patches list, it seemed sensible to try preserving the
precise v
--- Comment #25 from davek at gcc dot gnu dot org 2009-09-16 10:51 ---
(In reply to comment #24)
> As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
> their SYMBOL_REFs start using that TLS model. But, unlike the user vars,
> these
> occur nor
--- Comment #26 from davek at gcc dot gnu dot org 2009-09-16 10:54 ---
Created an attachment (id=18596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596&action=view)
YA respin
don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values.
--
--- Comment #27 from davek at gcc dot gnu dot org 2009-09-16 21:10 ---
This is not really specific to debug info after all, and since tls doesn't have
its own category, I think middle-end is the best description of this bug.
Just about to post test results from final respin, only
--- Comment #28 from davek at gcc dot gnu dot org 2009-09-16 21:29 ---
Subject: Bug 41357
Author: davek
Date: Wed Sep 16 21:29:17 2009
New Revision: 151773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151773
Log:
PR middle-end/41357
*
in/as.exe'
'AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe' '--disable-win32-registry'
'--disable-libgcj-debug' '--enable-languages=c,c++,java,objc,obj-c++' 2>&1 |
tee conf.log
--
Summary: expr.c undefined reference while linking jc1
Prod
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:20 ---
Unsurprisingly, adding -g0 to the build line results in an expr.o without the
undefined reference.
/gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/
-B/opt/gcc-tools/i686-pc-cygwin/bin/ -B
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-19 09:21 ---
(In reply to comment #2)
> Unsurprisingly,
Oops, sorry, wrong PR! I was on the wrong browser tab. Apologies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-19 09:21 ---
Unsurprisingly, adding -g0 to the build line results in an expr.o without the
undefined reference.
/gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/
-B/opt/gcc-tools/i686-pc-cygwin/bin/ -B
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:33 ---
This is where the subsequently-undefined reference is being generated:
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: {} 14169456
Old value = 73
New value = 74
0x004c5fe2 in
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-19 09:44 ---
Fortunately it even happens when using the stage1 compiler, which has usable
debug info:
(gdb) c 73
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: dw2_string_counter
Old value
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-19 09:49 ---
Created an attachment (id=18606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18606&action=view)
unreduced preprocessed source.
compile this with:
/gnu/gcc/obj.no.pr41357/./stage1-gcc/cc1.exe -fprepr
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-19 09:56 ---
heh, it's my old friend add_location_or_const_value_attribute() from pr41357
(gdb) up
#5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58,
decl=0x7f004bc0, attr=DW_AT_location)
at /gn
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-19 10:44 ---
Was off-by-one on the rtx, it's actually "ret" not "goto".
The refcount of the indirect_string_node goes to zero here, in
prune_unused_types_walk_attribs():
(gdb) c
Continuing.
Hardwa
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-19 10:56 ---
(In reply to comment #8)
> The "ret" string is shared between some attribute and a value from
> CONST_STRING.
Sorry, as I just figured out I was off by one on that:
(gdb) fin
Run t
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-19 11:17 ---
(In reply to comment #10)
> Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm
> afraid we can't do anything for it, unless we can find such string in the
> ro
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-19 11:34 ---
(In reply to comment #10)
> we can't do anything for it, unless we can find such string in the
> rodata section of the compilation unit.
> .LASF74 is a label in .debug_str section, which isn'
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-19 12:32 ---
(In reply to comment #13)
Thanks for taking the time to explain that.
I think the implication of what you're saying is that we can in fact handle
strings and just giving up on them is too severe, but we ne
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-19 13:13 ---
(In reply to comment #14)
> (In reply to comment #13)
>
> Thanks for taking the time to explain that.
>
> I think the implication of what you're saying is that we can in fact handle
> string
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-19 16:25 ---
(In reply to comment #16)
> Patch I sent to improve tree_loc code also has code to lookup constants
> in constant pool. For strings in particular this has pretty good chance
> of success.
I see
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-19 17:59 ---
(In reply to comment #17)
> (In reply to comment #16)
>
> > Patch I sent to improve tree_loc code also has code to lookup constants
> > in constant pool. For strings in particular this has pretty
--- Comment #20 from davek at gcc dot gnu dot org 2009-09-19 21:20 ---
(In reply to comment #19)
> Subject: Re: expr.c undefined reference while linking jc1
>
> > :-( There must be one more latent bug in the code; after applying both the
> > patches you sent to
Component: libgomp
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=41418
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-20 14:57 ---
Created an attachment (id=18616)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18616&action=view)
diffs in generated libtool files
This looks like it might be informative.
--
http://gcc.gnu.org/b
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-20 14:59 ---
Perhaps the two single most salient points from that diff:
# Is the compiler the GNU compiler?
-with_gcc=no
+with_gcc=yes
# Whether we are building with GNU ld or not.
-with_gnu_ld="no"
+with_gnu_ld=&quo
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-21 07:53 ---
(In reply to comment #3)
> First off, do you happen to know whether this is a regression?
'fraid not, I never thought to try this before.
> Then, please show more of the build output of the fa
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18624&action=view)
good rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625&action=view)
bad rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18626)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18626&action=view)
good config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18627)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18627&action=view)
bad config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-22 01:17 ---
Subject: Bug 41404
Author: davek
Date: Tue Sep 22 01:17:24 2009
New Revision: 151958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151958
Log:
PR bootstrap/41404
* dwa
--- Comment #29 from davek at gcc dot gnu dot org 2009-09-22 01:34 ---
Subject: Bug 41357
Author: davek
Date: Tue Sep 22 01:33:53 2009
New Revision: 151959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151959
Log:
PR middle-end/41357
*
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-22 11:54 ---
I'll try and get to testing it today, but it'll be late tonight before I can
start, I've got to spend the day doing some binutils stuff. Will be back in
touch when I know something, thank
--- Comment #31 from davek at gcc dot gnu dot org 2009-09-28 05:48 ---
(In reply to comment #30)
> I still get
>
> /bin/sh ./libtool --tag CC --mode=link
> /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwi
Component: 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=41512
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:28 ---
Hi John,
What kind of TLS do you have on your platform? Also, does reverting the patch
help you any, or do you just end up with the failures that were showing in bug
41357?
That PR is still open because the fix
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-30 03:32 ---
Created an attachment (id=18669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18669&action=view)
testcase source compiled by gcc HEAD
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:33 ---
Created an attachment (id=18670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18670&action=view)
same testcase compiled with gcc 4.3.4
Note the differences in the "-export: " directives in the
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-30 03:40 ---
Switching to c++ as I suggested initially, there were changes to the handling
of vague linkage and global declarations within the same period, and as I
mentioned nothing that seemed relevant in the backend
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-30 13:50 ---
Comment 32 in bug 41357 says that that bug has now gone away again as of
r.152325; I haven't had time to verify that myself yet but perhaps that one
will work for you also?
--
http://gcc.gnu.org/bug
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-30 14:10 ---
(In reply to comment #4)
> It uses GCC's emulated TLS support (don't support HP's TLS implementation).
> There were no libgomp failures prior to the change:
> http://gcc.gnu.org/ml/gcc-test
1 - 100 of 329 matches
Mail list logo
