[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #28 from ddaney at avtrex dot com 2008-05-07 17:59 --- Subject: Re: We should to use StringBuilder instead of StringBuffer where appropriate. gnu_andrew at member dot fsf dot org wrote: > --- Comment #25 from gnu_andrew at member dot fsf dot org 2008-05-07 > 17:57 --- > Created an attachment (id=15598) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view) > Move towards a CPStringBuilder-using code base > > I don't think it is strictly speaking necessary to attach all of these patches. David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS
--- Comment #4 from ddaney at avtrex dot com 2008-01-17 21:48 --- Subject: Re: [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS rguenth at gcc dot gnu dot org wrote: > --- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-17 21:40 > --- > Yes, I can read. It says > > FAIL: gcc.dg/pr34233.c (internal compiler error) > FAIL: gcc.dg/pr34233.c (test for excess errors) > > so, what is the ICE message? Unknown at this time. I was merely noting the failure in hopes that Richard Sandiford would fix it. Failing that, I will try to post more details and/or fix it myself in the next few days. David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #10 from ddaney at avtrex dot com 2007-10-14 02:02 --- Subject: Re: Gcc 4.2.2 broken for mips linux kernel builds rsandifo at gcc dot gnu dot org wrote: > --- Comment #9 from rsandifo at gcc dot gnu dot org 2007-10-13 10:47 > --- > The problem comes from dbr_schedule, although it's not really a bug there. > We have: > > bne $5,$0,L1# A > ...stuff... > L1: > bne $5,$0,L2# B > ...printk call... > L2: > > and nothing before dbr_schedule has managed to thread A to L2. > dbr_schedule first fills B's delay slot with an lui from the printk > block, then steal_delay_list_from_target realises that A can steal B's > delay slot and branch directly to L2. There is no other path to L1, > so the rest of the printk call is now dead. > > For most targets, this is at worst a missed optimisation; we should have > threaded A to L2 much earlier than dbr_schedule, and deleted the whole > printk block as dead. I don't think the MIPS port can rely on that > happening for correctness. So (alas!) I think the upshot is simply > that we need to add some special code to mips_reorg to delete high-part > relocations that have no matching lows. > > I'll have a poke. > > That makes sense, however it is a bit strange because... IIRC when I compiled the .i file with a fairly recent 4.3 build, the printk in question was not optimized away. So if 4.2.2 can validly optimize away the printk, then we have an optimization regression in 4.3 David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #17 from ddaney at avtrex dot com 2007-09-05 21:36 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 richard at codesourcery dot com wrote: > --- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22 > --- > Subject: Re: internal compiler error: in print_operand_reloc, at > config/mips/mips.c:5579 > > "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes: >> My concern was that the bug only occurs for me with -EB, so running the >> test case with -EL would be pointless. I understand that you do most of >> your testing on the simulator, but for someone doing testing on little >> endian hardware there is no coverage without the -EB. > > OK. As I said before, I didn't think it would be pointless, because > we do want to make sure this continues to work for -EL too. The only time loading the low order bits of a word is done at an offset from the base of the word is in big endian. So I don't think it will ever fail on a little endian system, but I may be missing something. > (There's > generally very little coverage of -mabi=64 -msym32; the only user I know > of is linux.) However, I'll yield and make mips.exp skip the test when > running explicitly-EL multilibs. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #15 from ddaney at avtrex dot com 2007-09-05 21:15 ---
Subject: Re: internal compiler error: in print_operand_reloc,
at config/mips/mips.c:5579
richard at codesourcery dot com wrote:
> --- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08
> ---
> Subject: Re: internal compiler error: in print_operand_reloc, at
> config/mips/mips.c:5579
>
> "ddaney at avtrex dot com" <[EMAIL PROTECTED]> writes:
>>> I've not forced -EB because that fails for -EL
>>> multilibs, and we want this test to work for both anyway.)
>>>
>> Are you sure? On the trunk I tested on mipsel-linux with -EB and it
>> seems to work. For a compile only test it should work on little-endian
>> system.
>
> I mean that it fails if you explicitly test -EL multilibs. E.g. on
> mipsisa64-elf, I normally test "mips-sim{,-msoft-float}{-EB,-EL}", and
> the compiler will complain at having both -EL and -EB on the command line.
> We could make mips.exp skip the test when -EL is forced, but it seems
> more useful to run it regardless. Or we could use target selectors to
> select between two dg-mips-options lines depending on whether -EL has
> been added to the multilib flags. However, it seems odd to test
> big-endian (only) on little-endian systems when -EL is not explicitly
> given, but test little-endian when -EL _is_ explicitly (and redundantly)
> given.
>
My concern was that the bug only occurs for me with -EB, so running the
test case with -EL would be pointless. I understand that you do most of
your testing on the simulator, but for someone doing testing on little
endian hardware there is no coverage without the -EB.
David Daney
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #13 from ddaney at avtrex dot com 2007-09-05 20:57 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 rsandifo at gcc dot gnu dot org wrote: > I've not forced -EB because that fails for -EL > multilibs, and we want this test to work for both anyway.) > Are you sure? On the trunk I tested on mipsel-linux with -EB and it seems to work. For a compile only test it should work on little-endian system. David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug java/30591] Cross build fails because native gcj needed to build ecjx
--- Comment #4 from ddaney at avtrex dot com 2007-04-25 01:16 --- Subject: Re: Cross build fails because native gcj needed to build ecjx tromey at gcc dot gnu dot org wrote: > --- Comment #3 from tromey at gcc dot gnu dot org 2007-04-25 01:12 > --- > Is this still a problem? > I thought it was ironed out a while ago. > > I have not tested it recently. I will try to test again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug libgcj/29604] Race condition in ServerSocket.accept()
--- Comment #4 from ddaney at avtrex dot com 2006-10-26 18:03 --- Subject: Re: Race condition in ServerSocket.accept() tromey at gcc dot gnu dot org wrote: > --- Comment #3 from tromey at gcc dot gnu dot org 2006-10-26 17:58 > --- > Instead of directly calling accept we could select or poll on the fd. > This would let us have a timeout or an interrupt or something. > For all I know poll would react more gracefully to another thread > closing the fd -- but I haven't tried that. > The essence of the problem is that you can not temporarily drop a lock (as Object.wait() does) in a race free manner while entering the accept() system call. Sticking a poll before the accept may in some cases narrow the window of the race, but it does not close it. I was going to fix the problem in 15 Minutes, but now I think I need a day to mull it over. This is the type of problem that keeps us sharp... David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29604
[Bug debug/29132] [4.1/4.2 Regression] Mips exception handling broken.
--- Comment #4 from ddaney at avtrex dot com 2006-09-18 21:59 --- Subject: Re: [4.2 Regression] Mips exception handling broken. roger at eyesopen dot com wrote: > --- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 --- > Hi David, > > I was wondering if you have a MIPS tree handy, whether you could easily > test the following single line patch: > > Index: dwarf2out.c > === > *** dwarf2out.c (revision 117035) > --- dwarf2out.c (working copy) > *** dwarf2out_begin_prologue (unsigned int l > *** 2572,2578 > fde = &fde_table[fde_table_in_use++]; > fde->decl = current_function_decl; > fde->dw_fde_begin = dup_label; > ! fde->dw_fde_current_label = NULL; > fde->dw_fde_hot_section_label = NULL; > fde->dw_fde_hot_section_end_label = NULL; > fde->dw_fde_unlikely_section_label = NULL; > --- 2572,2578 > fde = &fde_table[fde_table_in_use++]; > fde->decl = current_function_decl; > fde->dw_fde_begin = dup_label; > ! fde->dw_fde_current_label = dup_label; > fde->dw_fde_hot_section_label = NULL; > fde->dw_fde_hot_section_end_label = NULL; > fde->dw_fde_unlikely_section_label = NULL; > > Due to all the abstraction with debugging formats, its difficult to tell the > order in which things get executed, and whether this initial value for > dw_fde_current_label survives long enough to avoid use of a set_loc. > > Many thanks in advance, > Preliminary results using: readelf --debug-dump=frames libstdc++.so show that this patch is working. I now get: 0064 0024 0068 FDE cie= pc=0003ed40..0003eed4 Augmentation data: 00 00 00 00 DW_CFA_advance_loc: 16 to 0003ed50 DW_CFA_def_cfa_offset: 48 DW_CFA_advance_loc: 24 to 0003ed68 DW_CFA_offset: r16 at cfa-24 DW_CFA_offset: r17 at cfa-20 DW_CFA_offset: r18 at cfa-16 DW_CFA_offset: r19 at cfa-12 DW_CFA_offset: r20 at cfa-8 Both addresses shown for DW_CFA_advance_loc are within the range of PC for the FDE. It will take (a lot) more time to see if the code actually works on my test platform, but it looks good to me so far. David Daney. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug debug/29132] [4.1/4.2 Regression] Mips exception handling broken.
--- Comment #3 from ddaney at avtrex dot com 2006-09-18 21:32 --- Subject: Re: [4.2 Regression] Mips exception handling broken. roger at eyesopen dot com wrote: > --- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 --- > Hi David, > > I was wondering if you have a MIPS tree handy, whether you could easily > test the following single line patch: > > Index: dwarf2out.c > === > *** dwarf2out.c (revision 117035) > --- dwarf2out.c (working copy) > *** dwarf2out_begin_prologue (unsigned int l > *** 2572,2578 > fde = &fde_table[fde_table_in_use++]; > fde->decl = current_function_decl; > fde->dw_fde_begin = dup_label; > ! fde->dw_fde_current_label = NULL; > fde->dw_fde_hot_section_label = NULL; > fde->dw_fde_hot_section_end_label = NULL; > fde->dw_fde_unlikely_section_label = NULL; > --- 2572,2578 > fde = &fde_table[fde_table_in_use++]; > fde->decl = current_function_decl; > fde->dw_fde_begin = dup_label; > ! fde->dw_fde_current_label = dup_label; > fde->dw_fde_hot_section_label = NULL; > fde->dw_fde_hot_section_end_label = NULL; > fde->dw_fde_unlikely_section_label = NULL; > > Due to all the abstraction with debugging formats, its difficult to tell the > order in which things get executed, and whether this initial value for > dw_fde_current_label survives long enough to avoid use of a set_loc. > I will try the patch now. A full build with libgcj will take me several hours to build and test. David Daney. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #4 from ddaney at avtrex dot com 2006-03-27 18:42 --- Subject: Re: NullPointerException not generated for large classes... mckinlay at redhat dot com wrote: > --- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 --- > GCJ could be made to generate explicit null checks when large offsets are > used. > It is probably relatively rare to have a normal object that is larger than a > page, so performance for most apps shouldn't be effected. > > Note that array accesses should not need this as the "length" field will be > dereferenced first, triggering NullPointerException, assuming bounds checks > are > used. I would also expect Strings should not have a problem. > > Do we know who's heap exactly is mapped at such a low address? If its mapped > by > Java/Boehm GC, then we can probably just fix the GC to not map things at such > low addresses (or to insert guard pages there instead). It is libgcj's (Boehm GC) heap in my tests that is at 0x1000. This message: http://gcc.gnu.org/ml/java/2006-03/msg00206.html Has more thoughts on the subject. David Daney. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26487] Weird handling of HTTP Headers
--- Comment #10 from ddaney at avtrex dot com 2006-03-01 17:10 --- Subject: Re: Weird handling of HTTP Headers ifoox at redhat dot com wrote: > --- Comment #9 from ifoox at redhat dot com 2006-03-01 16:11 --- > Hi David, > > I tried to get classpath and try out applying the patch to test it out, but I > had some problems with it. I'll try again in a bit but I have some general > comments in the meanwhile. > > It seems more appropriate to keep the headers in a Map than a List, especially > since getHeaderFields() has to return a map, and most opeartions are just a > simple getHeaderField(sometype). It seems that a LinkedHashMap (which Headers > extends) should be able to handle same-name headers, because it will just > chain > them together. In theory :) > > If this doesn't work out, it might be possible to store it in a Map in a > structure like: String -> [String, String, ...] where [] is a List. So we > would > always have a String to List mapping and the List may contain 1 or more values > for that header. > > Does that make any sense? :) You should be able to check-out the classpath HEAD and apply the patch to that. Then copy the entire gnu/java/net/protocol/http directory contents directly into the corresponding place in the classpath directory of libgcj and rebuild. My first attempt at fixing was to do as you suggested. The problem is that you lose the order of the headers in the case where there were more than one header of the same name. Enumerating the headers in the manner of your test program becomes quite complicated. In the general case, the ability to delete some headers complicates things further. I gave up and went down the road of a somewhat simpler implementation at the expense of lookup overhead. In most cases there are fewer than about a dozen headers, so linear searching an ArrayList should not be too bad. I think I will get a second opinion from Tromey et al. ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26487
