--- 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 #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 #25 from jakub at gcc dot gnu dot org 2009-10-02 15:03 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #24 from jakub at gcc dot gnu dot org 2009-10-02 15:01 ---
Subject: Bug 41404
Author: jakub
Date: Fri Oct 2 15:01:22 2009
New Revision: 152403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152403
Log:
PR debug/41404
PR debug/41353
* cfgexpan
--- 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
* dwarf2out.c (mem_loc_descri
--- Comment #22 from jakub at gcc dot gnu dot org 2009-09-21 08:40 ---
Created an attachment (id=18620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18620&action=view)
gcc45-pr41404.patch
This fixes the bug, unfortunately doesn't do any good with CONST_STRINGs.
CONST_STRING as em
--- Comment #21 from hubicka at ucw dot cz 2009-09-19 22:15 ---
Subject: Re: expr.c undefined reference while linking jc1
> What's your timescale for this if you were to do it? If it's likely to take
> a few days, should we maybe commit something roughly like the patch from
> commen
--- 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 today and rebuilding dwarf2
--- Comment #19 from hubicka at ucw dot cz 2009-09-19 18:24 ---
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 today and rebuilding dwarf2out.o and cc1.exe, no difference
> in
>
--- 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 good chance
> > of
--- 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 you wrote:
" Th
--- Comment #16 from hubicka at ucw dot cz 2009-09-19 16:10 ---
Subject: Re: expr.c undefined reference while linking jc1
> 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
> rodat
--- 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
> strings and just giving up on t
--- 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 need to deci
--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-19 12:12 ---
Consider:
__attribute__((noinline))
int bar (void)
{
const char *foo = "foo";
asm volatile ("nop" : : : "memory");
foo = "bar";
asm volatile ("nop" : : : "memory");
return 16;
}
int main (void)
{
bar ();
--- 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't
> allocated, so I wond
--- 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
> rodata section of the compilatio
--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-19 11:04 ---
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
rodata section of the compilation unit.
.byte 0x3
--- 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 till exit from #0 gen_label_for_in
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-19 10:50 ---
The "ret" string is shared between some attribute and a value from
CONST_STRING.
But prune_unused_types_walk_attribs resets the count to 0:
/* Set the string's refcount to 0 so that prune_unused_types_mark
--- 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.
Hardware watchpoint 5: ((struct indirec
--- 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 /gnu/gcc/
--- 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 -fpreprocessed ex
--- 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 = 73
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-19 09:43 ---
Please attach preprocessed source.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- 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 mem_l
--- 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/
27 matches
Mail list logo
