* Re: egcs-1.2 stuff @ 1999-03-28 6:12 Kaveh R. Ghazi 1999-03-28 6:24 ` David Miller ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Kaveh R. Ghazi @ 1999-03-28 6:12 UTC (permalink / raw) To: law; +Cc: davem, egcs > From: Jeffrey A Law <law@hurl.cygnus.com> > > OK. Now that egcs-1.1.2 is done, we need to start discussing the major > stuff that needs to be resolved for egcs-1.2. My quick list: > > 7. Various bugs effecting glibc, the linux kernel, mips large frames, > etc etc. Basically some major bug hunting sessions. I think we should address the -fpic/-fPIC failures on the sparc. This would affect glibc or really any shared library. IIRC, Dave had a preliminary fix early last fall around the time we split the 1.1.x branch. For some reason it never went in. (?) > Mon Sep 7 22:04:51 1998 David S. Miller <davem@pierdol.cobaltmicro.com> > > * config/sparc/sparc.c (legitimize_pic_address): If during or > after reload, and no PIC references existed before reload, emit > get_pc sequence to setup pic base register for all such > references. Of course maybe this is completely unrelated to the failures I'm seeing today. :-) For an example of the recent -fpic/-fPIC failures (and beyond above what normally occurs) see: http://egcs.cygnus.com/ml/egcs-testresults/1999-03/msg00353.html --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 6:12 egcs-1.2 stuff Kaveh R. Ghazi @ 1999-03-28 6:24 ` David Miller 1999-03-31 23:46 ` David Miller 1999-03-28 13:09 ` Jeffrey A Law 1999-03-31 23:46 ` egcs-1.2 stuff Kaveh R. Ghazi 2 siblings, 1 reply; 22+ messages in thread From: David Miller @ 1999-03-28 6:24 UTC (permalink / raw) To: ghazi; +Cc: law, egcs Date: Sun, 28 Mar 1999 09:12:45 -0500 (EST) From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> I think we should address the -fpic/-fPIC failures on the sparc. This would affect glibc or really any shared library. IIRC, Dave had a preliminary fix early last fall around the time we split the 1.1.x branch. For some reason it never went in. (?) ... Of course maybe this is completely unrelated to the failures I'm seeing today. :-) For an example of the recent -fpic/-fPIC failures (and beyond above what normally occurs) see: I think they are probably related, and in any event the bug I fixed in that change should still exist in the mainline cvs sources. At the time I came up with that fix, Jeff and I had decided that the correct fix was to check for and emit the get_pc sequences in a completely different place so that all possible cases were handled (this meant doing the checks after reload) The bug would trigger in cases where there were no PIC references in a function, but usage of a float constant in float regs would trigger a PIC reference to the data section during reload. At this point the sparc backend would be stymied because it checked before reload whether the "get_pc" sequence needed to be emitted. So it never was, and the PIC register contained garbage and obviously caused the resulting code to crash. Later, David S. Miller davem@redhat.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 6:24 ` David Miller @ 1999-03-31 23:46 ` David Miller 0 siblings, 0 replies; 22+ messages in thread From: David Miller @ 1999-03-31 23:46 UTC (permalink / raw) To: ghazi; +Cc: law, egcs Date: Sun, 28 Mar 1999 09:12:45 -0500 (EST) From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> I think we should address the -fpic/-fPIC failures on the sparc. This would affect glibc or really any shared library. IIRC, Dave had a preliminary fix early last fall around the time we split the 1.1.x branch. For some reason it never went in. (?) ... Of course maybe this is completely unrelated to the failures I'm seeing today. :-) For an example of the recent -fpic/-fPIC failures (and beyond above what normally occurs) see: I think they are probably related, and in any event the bug I fixed in that change should still exist in the mainline cvs sources. At the time I came up with that fix, Jeff and I had decided that the correct fix was to check for and emit the get_pc sequences in a completely different place so that all possible cases were handled (this meant doing the checks after reload) The bug would trigger in cases where there were no PIC references in a function, but usage of a float constant in float regs would trigger a PIC reference to the data section during reload. At this point the sparc backend would be stymied because it checked before reload whether the "get_pc" sequence needed to be emitted. So it never was, and the PIC register contained garbage and obviously caused the resulting code to crash. Later, David S. Miller davem@redhat.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 6:12 egcs-1.2 stuff Kaveh R. Ghazi 1999-03-28 6:24 ` David Miller @ 1999-03-28 13:09 ` Jeffrey A Law 1999-03-28 16:06 ` David Miller ` (2 more replies) 1999-03-31 23:46 ` egcs-1.2 stuff Kaveh R. Ghazi 2 siblings, 3 replies; 22+ messages in thread From: Jeffrey A Law @ 1999-03-28 13:09 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: davem, egcs In message < 199903281412.JAA02308@caip.rutgers.edu >you write: > I think we should address the -fpic/-fPIC failures on the sparc. > This would affect glibc or really any shared library. IIRC, Dave had a > preliminary fix early last fall around the time we split the 1.1.x > branch. For some reason it never went in. (?) If it's the problem I think it is then it's unlikely we'll have a general solution in time for egcs-1.2. Lazy allocation of the PIC register is a bad bad idea right now. It's going to consistently lose. If we want this to work 100% reliably for egcs-1.2, then the backend is going to need to pre-allocate the register early and take the performance hit. This effects multiple ports that have tried to do lazy allocation of the PIC register (for example the ppc). Then someone will need to block out some significant time post egcs-1.2 to fix the problem correctly. It's not a simple problem to fix. jeff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 13:09 ` Jeffrey A Law @ 1999-03-28 16:06 ` David Miller 1999-03-31 23:46 ` David Miller 1999-03-31 23:46 ` Jeffrey A Law 1999-04-30 10:46 ` PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Joern Rennecke 2 siblings, 1 reply; 22+ messages in thread From: David Miller @ 1999-03-28 16:06 UTC (permalink / raw) To: law; +Cc: ghazi, egcs Date: Sun, 28 Mar 1999 13:58:05 -0700 From: Jeffrey A Law <law@upchuck.cygnus.com> If it's the problem I think it is then it's unlikely we'll have a general solution in time for egcs-1.2. And if so, the solution is just to mark %l7 as fixed on Sparc when PIC is enabled just like was done in egcs-1.1.x But this won't solve the other issue I mention with float constants. Later, David S. Miller davem@redhat.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 16:06 ` David Miller @ 1999-03-31 23:46 ` David Miller 0 siblings, 0 replies; 22+ messages in thread From: David Miller @ 1999-03-31 23:46 UTC (permalink / raw) To: law; +Cc: ghazi, egcs Date: Sun, 28 Mar 1999 13:58:05 -0700 From: Jeffrey A Law <law@upchuck.cygnus.com> If it's the problem I think it is then it's unlikely we'll have a general solution in time for egcs-1.2. And if so, the solution is just to mark %l7 as fixed on Sparc when PIC is enabled just like was done in egcs-1.1.x But this won't solve the other issue I mention with float constants. Later, David S. Miller davem@redhat.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 13:09 ` Jeffrey A Law 1999-03-28 16:06 ` David Miller @ 1999-03-31 23:46 ` Jeffrey A Law 1999-04-30 10:46 ` PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Joern Rennecke 2 siblings, 0 replies; 22+ messages in thread From: Jeffrey A Law @ 1999-03-31 23:46 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: davem, egcs In message < 199903281412.JAA02308@caip.rutgers.edu >you write: > I think we should address the -fpic/-fPIC failures on the sparc. > This would affect glibc or really any shared library. IIRC, Dave had a > preliminary fix early last fall around the time we split the 1.1.x > branch. For some reason it never went in. (?) If it's the problem I think it is then it's unlikely we'll have a general solution in time for egcs-1.2. Lazy allocation of the PIC register is a bad bad idea right now. It's going to consistently lose. If we want this to work 100% reliably for egcs-1.2, then the backend is going to need to pre-allocate the register early and take the performance hit. This effects multiple ports that have tried to do lazy allocation of the PIC register (for example the ppc). Then someone will need to block out some significant time post egcs-1.2 to fix the problem correctly. It's not a simple problem to fix. jeff ^ permalink raw reply [flat|nested] 22+ messages in thread
* PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-03-28 13:09 ` Jeffrey A Law 1999-03-28 16:06 ` David Miller 1999-03-31 23:46 ` Jeffrey A Law @ 1999-04-30 10:46 ` Joern Rennecke 1999-04-30 23:15 ` Joern Rennecke 1999-05-06 13:36 ` Franz Sirl 2 siblings, 2 replies; 22+ messages in thread From: Joern Rennecke @ 1999-04-30 10:46 UTC (permalink / raw) To: law; +Cc: ghazi, davem, egcs > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > I think we should address the -fpic/-fPIC failures on the sparc. > > This would affect glibc or really any shared library. IIRC, Dave had a > > preliminary fix early last fall around the time we split the 1.1.x > > branch. For some reason it never went in. (?) > If it's the problem I think it is then it's unlikely we'll have a general > solution in time for egcs-1.2. > > Lazy allocation of the PIC register is a bad bad idea right now. It's going > to consistently lose. If we want this to work 100% reliably for egcs-1.2, then > the backend is going to need to pre-allocate the register early and take the > performance hit. This effects multiple ports that have tried to do lazy > allocation of the PIC register (for example the ppc). > > Then someone will need to block out some significant time post egcs-1.2 to fix > the problem correctly. It's not a simple problem to fix. I think that, if no PIC register is preallocated and we find during reload that we need one after all, we should just load it with a secondary reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i appropriately). We should check that reload inheritance works for the temporarily allocated PIC register. Then we should get actually better code than if we allocated the PIC register for the entire function. ^ permalink raw reply [flat|nested] 22+ messages in thread
* PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-04-30 10:46 ` PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Joern Rennecke @ 1999-04-30 23:15 ` Joern Rennecke 1999-05-06 13:36 ` Franz Sirl 1 sibling, 0 replies; 22+ messages in thread From: Joern Rennecke @ 1999-04-30 23:15 UTC (permalink / raw) To: law; +Cc: ghazi, davem, egcs > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > I think we should address the -fpic/-fPIC failures on the sparc. > > This would affect glibc or really any shared library. IIRC, Dave had a > > preliminary fix early last fall around the time we split the 1.1.x > > branch. For some reason it never went in. (?) > If it's the problem I think it is then it's unlikely we'll have a general > solution in time for egcs-1.2. > > Lazy allocation of the PIC register is a bad bad idea right now. It's going > to consistently lose. If we want this to work 100% reliably for egcs-1.2, then > the backend is going to need to pre-allocate the register early and take the > performance hit. This effects multiple ports that have tried to do lazy > allocation of the PIC register (for example the ppc). > > Then someone will need to block out some significant time post egcs-1.2 to fix > the problem correctly. It's not a simple problem to fix. I think that, if no PIC register is preallocated and we find during reload that we need one after all, we should just load it with a secondary reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i appropriately). We should check that reload inheritance works for the temporarily allocated PIC register. Then we should get actually better code than if we allocated the PIC register for the entire function. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-04-30 10:46 ` PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Joern Rennecke 1999-04-30 23:15 ` Joern Rennecke @ 1999-05-06 13:36 ` Franz Sirl 1999-05-06 14:16 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 1 sibling, 2 replies; 22+ messages in thread From: Franz Sirl @ 1999-05-06 13:36 UTC (permalink / raw) To: Joern Rennecke; +Cc: law, ghazi, davem, egcs, geoffk At 19:46 30.04.99 , Joern Rennecke wrote: > > > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > > I think we should address the -fpic/-fPIC failures on the sparc. > > > This would affect glibc or really any shared library. IIRC, Dave had a > > > preliminary fix early last fall around the time we split the 1.1.x > > > branch. For some reason it never went in. (?) > > If it's the problem I think it is then it's unlikely we'll have a general > > solution in time for egcs-1.2. > > > > Lazy allocation of the PIC register is a bad bad idea right now. It's > going > > to consistently lose. If we want this to work 100% reliably for > egcs-1.2, then > > the backend is going to need to pre-allocate the register early and > take the > > performance hit. This effects multiple ports that have tried to do lazy > > allocation of the PIC register (for example the ppc). > > > > Then someone will need to block out some significant time post egcs-1.2 > to fix > > the problem correctly. It's not a simple problem to fix. > >I think that, if no PIC register is preallocated and we find during >reload that we need one after all, we should just load it with a secondary >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i >appropriately). >We should check that reload inheritance works for the temporarily >allocated PIC register. Then we should get actually better code than if >we allocated the PIC register for the entire function. Hmm, would this solution possibly be OK for 1.2? It really would be great if this was solved once and forever, so if you have some code to try I'm willing to test it on PPC. Franz. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 13:36 ` Franz Sirl @ 1999-05-06 14:16 ` Geoff Keating 1999-05-06 14:45 ` Franz Sirl 1999-05-31 21:36 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 1 sibling, 2 replies; 22+ messages in thread From: Geoff Keating @ 1999-05-06 14:16 UTC (permalink / raw) To: Franz.Sirl-kernel; +Cc: amylaar, law, ghazi, davem, egcs > Date: Thu, 06 May 1999 22:36:17 +0200 > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> > Cc: law@cygnus.com, ghazi@snafu.Rutgers.EDU, davem@cobaltmicro.com, > egcs@egcs.cygnus.com, geoffk@ozemail.com.au > > At 19:46 30.04.99 , Joern Rennecke wrote: > > > > > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > > > I think we should address the -fpic/-fPIC failures on the sparc. > > > > This would affect glibc or really any shared library. IIRC, Dave had a > > > > preliminary fix early last fall around the time we split the 1.1.x > > > > branch. For some reason it never went in. (?) > > > If it's the problem I think it is then it's unlikely we'll have a general > > > solution in time for egcs-1.2. > > > > > > Lazy allocation of the PIC register is a bad bad idea right now. It's > > going > > > to consistently lose. If we want this to work 100% reliably for > > egcs-1.2, then > > > the backend is going to need to pre-allocate the register early and > > take the > > > performance hit. This effects multiple ports that have tried to do lazy > > > allocation of the PIC register (for example the ppc). Yes. > > > Then someone will need to block out some significant time post egcs-1.2 > > to fix > > > the problem correctly. It's not a simple problem to fix. Yes. > >I think that, if no PIC register is preallocated and we find during > >reload that we need one after all, we should just load it with a secondary > >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i > >appropriately). > >We should check that reload inheritance works for the temporarily > >allocated PIC register. Then we should get actually better code than if > >we allocated the PIC register for the entire function. Regrettably, it's more complex than that. It's not just the case of suddenly discovering that a routine, which previously didn't have a PIC register, needs one. It's also the case when a routine which already has a PIC register finds that it needs to access it in more and/or different places than before. The example I have of this is attached below. Look at register 26; it is the PIC register, yet it gets stomped just after label '.L5'; and there's a flow of control from there to just after label '.L13' where the PIC register is used. Compile under 1.1.1, targetting powerpc-linux with '-O -fpic'. The problem here is triggered by reload deciding to do some constant rearrangement because of a REG_EQUIV note: it sees this (insn 264 261 266 (set (reg:SI 117) (unspec[ (symbol_ref:SI ("@h_malloc")) (reg:SI 128) ] 8)) 398 {*movsi_got_internal} (nil) (expr_list:REG_EQUIV (symbol_ref:SI ("@h_malloc")) (nil))) and decides that it can then simplify this insn: (insn 160 158 162 (set (reg:SI 120) (mem:SI (reg:SI 117))) 402 {movsi+1} (nil) (nil)) by rewriting it as (insn 160 158 162 (set (reg:SI 120) (symbol_ref:SI ("@h_malloc"))) (nil) (nil)) because register 117 is equivalent to the symbol_ref; but it actually ends up as (insn 160 158 162 (set (reg:SI 120) (unspec[ (symbol_ref:SI ("@h_malloc")) (reg:SI 128) ] 8)) 398 {*movsi_got_internal} (nil) (nil)) and suddenly there's a new use of register 128 that wasn't there before, and this causes global alloc to fail. Similar problems happen with floating-point constants. Is this testcase already in the test suite? It's stripped-down code from kaffe's implementation of GNU zip. If you want a temporary fix, I've previously posted a solution which ensures that reload will never ask for a new occurrence of the PIC register. It should be in the egcs-patches archive. If you use this, then there is no need to do anything else. It would need to be ported to sparc if it is needed there (the port consists of defining two preprocessor variables in sparc.h). The patch operates by forcing reload to never spill constants to memory (only when -fpic, of course). It works OK on powerpc, but on sparc it might need some more code in the machine description to make life easier for the crippled reload---I would be glad to help here. On powerpc, I'm not sure that you can use reload in the way suggested. I suspect there are cases in which it won't be able to reload the link register, for instance when folding switch statements. > Hmm, would this solution possibly be OK for 1.2? It really would be great > if this was solved once and forever, so if you have some code to try I'm > willing to test it on PPC. Certainly, if there's code already written I'm happy to run it against my test suite. -- Geoffrey Keating <geoffk@ozemail.com.au> ===File ~/gcc-bugs/test11.s================================= .file "test11.c" gcc2_compiled.: .globl memset .section ".text" .align 2 .type doit,@function doit: stwu 1,-176(1) mflr 0 stw 14,104(1) stw 15,108(1) stw 16,112(1) stw 17,116(1) stw 18,120(1) stw 19,124(1) stw 20,128(1) stw 21,132(1) stw 22,136(1) stw 23,140(1) stw 24,144(1) stw 25,148(1) stw 26,152(1) stw 27,156(1) stw 28,160(1) stw 29,164(1) stw 30,168(1) stw 31,172(1) stw 0,180(1) bl _GLOBAL_OFFSET_TABLE_@local-4 mflr 26 mr 18,3 mr 16,4 mr 17,5 mr 22,6 addi 3,1,72 li 4,0 li 5,16 crxor 6,6,6 bl memset@plt addi 3,1,8 li 4,0 li 5,60 crxor 6,6,6 bl memset@plt li 31,0 li 3,0 li 27,0 addi 25,1,12 li 30,1 addi 19,1,72 li 14,1 li 15,0 addi 20,1,88 .L5: li 26,0 slwi 21,30,2 .L9: cmplw 0,30,31 bc 4,1,.L11 addi 23,26,1 addi 0,30,-1 slwi 24,0,2 .L12: slwi 0,27,2 lwzx 31,25,0 addi 27,27,1 mr 9,31 cmplw 0,31,23 bc 4,1,.L13 add 11,19,21 cmplwi 0,31,1 bc 12,1,.L13 .L18: slwi 0,9,2 lwzx 0,11,0 cmplw 0,31,0 bc 12,1,.L13 addi 9,9,1 cmplwi 0,9,1 bc 4,1,.L18 .L13: slwi 0,27,2 stwx 9,25,0 lwz 10,h_malloc@got(26) lwz 0,0(10) slw 3,14,18 mtlr 0 blrl stw 3,0(22) addi 22,3,4 stw 15,4(3) stwx 3,24,20 cmplw 0,30,31 bc 12,1,.L12 .L11: mr 28,16 mr 29,17 stw 28,0(3) stw 29,4(3) addi 26,26,1 cmplwi 0,26,6 bc 4,1,.L9 addi 30,30,1 cmplwi 0,30,2 bc 4,1,.L5 lwz 0,180(1) mtlr 0 lwz 14,104(1) lwz 15,108(1) lwz 16,112(1) lwz 17,116(1) lwz 18,120(1) lwz 19,124(1) lwz 20,128(1) lwz 21,132(1) lwz 22,136(1) lwz 23,140(1) lwz 24,144(1) lwz 25,148(1) lwz 26,152(1) lwz 27,156(1) lwz 28,160(1) lwz 29,164(1) lwz 30,168(1) lwz 31,172(1) la 1,176(1) blr .Lfe1: .size doit,.Lfe1-doit .align 2 .globl is_ok .type is_ok,@function is_ok: stwu 1,-16(1) mflr 0 stw 0,20(1) li 3,0 crxor 6,6,6 bl exit@plt .Lfe2: .size is_ok,.Lfe2-is_ok .align 2 .globl main .type main,@function main: stwu 1,-16(1) mflr 0 stw 0,20(1) bl _GLOBAL_OFFSET_TABLE_@local-4 mflr 9 lwz 11,h_malloc@got(9) lwz 9,is_ok@got(9) stw 9,0(11) li 3,0 li 4,0 li 5,0 li 6,0 bl doit@local bl abort@plt .Lfe3: .size main,.Lfe3-main .comm h_malloc,4,4 .ident "GCC: (GNU) egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)" ============================================================ ===File ~/gcc-bugs/test11.c================================= typedef struct _huft { unsigned e; struct _huft* t; } huft; huft* (*h_malloc)(unsigned); static void doit( unsigned p2, unsigned p3, huft *p4, huft** t) { unsigned a, h, j, k, w; unsigned *xp, *l; unsigned lx[2*7+1], v[2*2]; huft *q; huft r; huft *u[2]; memset(v, 0, sizeof(v)); memset(lx, 0, sizeof(lx)); w = 0; q = 0; h = 0; l = lx+1; for (k=1; k <= 2; k++) for (a=0; a < 7; a++) { while (k > w) { w = l[h++]; j = w; if (w > a + 1) { xp = v + k; while (j < 2 && w <= xp[j]) ++j; } l[h] = j; q = h_malloc(1<<p2); *t = q; t = &(q->t); *t = 0; u[k-1] = q; } r.e = p3; r.t = p4; q[0] = r; } } huft *is_ok(unsigned x) { exit(0); } int main() { h_malloc = is_ok; doit(0, 0, 0, 0); abort(); } ============================================================ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 14:16 ` Geoff Keating @ 1999-05-06 14:45 ` Franz Sirl 1999-05-13 1:12 ` Jeffrey A Law ` (2 more replies) 1999-05-31 21:36 ` Geoff Keating 1 sibling, 3 replies; 22+ messages in thread From: Franz Sirl @ 1999-05-06 14:45 UTC (permalink / raw) To: Geoff Keating; +Cc: amylaar, law, ghazi, davem, egcs At 23:15 06.05.99 , Geoff Keating wrote: >Is this testcase already in the test suite? It's stripped-down code >from kaffe's implementation of GNU zip. Geoff, this testcase is not in the testsuite, but it also no longer FAILs with the current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's one testcase in the testsuite which still shows this problem with -fpic on PPC, attached below. Franz. PS. Geoff, if you want to play with the egcs-mainline a bit, login into the LinuxPPC developers machine, you'll find everything under ~fsirl/egcsm (source) and ~fsirl/obj/cvsm (build from today), you should have full access there. gcc/testsuite/gcc.dg/980523-1.c: /* { dg-do run { target rs6000-*-linux* powerpc-*-linux*} } */ /* { dg-options "-O2 -fpic" } */ void foo1(int a, char *b, int c) { c =a+c+234; } int foo2(int d) { return d*d; } int bar1, bar2, bar3; char * bar4; int main(void) { int h; bar1 = foo2(1); bar2 = foo2(1); h = foo2(1); foo1(1, "a", foo2(1)); foo1(bar1, "a", foo2(1)); foo2(1); h = foo2(1); bar3 = 1; bar4 = "a"; foo1(1, "n", foo2(1)); foo1(1, "o", foo2(1)); foo1(1, "p", foo2(1)); foo1(bar1, "a", foo2(1)); bar3 = h; bar4 = "b"; foo1(bar1, "b", foo2(1)); foo1(1, "q", foo2(1)); bar4 = "c"; foo1(1, "c", foo2(1)); bar4 = "d"; foo1(1, "d", foo2(1)); bar4 = "e"; foo1(1, "e", foo2(1)); bar4 = "f"; foo1(1, "f", foo2(1)); bar4 = "g"; foo1(1, "g", foo2(1)); bar4 = "h"; foo1(1, "h", foo2(1)); bar4 = "i"; foo1(1, "i", foo2(1)); bar4 = "j"; foo1(1, "j", foo2(1)); bar4 = "k"; foo1(1, "k", foo2(1)); bar4 = "l"; foo1(1, "l", foo2(1)); bar4 = "m"; foo1(bar2, "m", foo2(1)); exit(0); } ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 14:45 ` Franz Sirl @ 1999-05-13 1:12 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-18 21:33 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 2 siblings, 1 reply; 22+ messages in thread From: Jeffrey A Law @ 1999-05-13 1:12 UTC (permalink / raw) To: Franz Sirl; +Cc: Geoff Keating, amylaar, ghazi, davem, egcs In message < 4.2.0.37.19990506233202.036d7400@mail.lauterbach.com >you write: > At 23:15 06.05.99 , Geoff Keating wrote: > >Is this testcase already in the test suite? It's stripped-down code > >from kaffe's implementation of GNU zip. > > Geoff, > > this testcase is not in the testsuite, but it also no longer FAILs with the > > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's > one testcase in the testsuite which still shows this problem with -fpic on > PPC, attached below. I've added this test to the testsuite. Thanks! Jeff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-13 1:12 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 22+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Franz Sirl; +Cc: Geoff Keating, amylaar, ghazi, davem, egcs In message < 4.2.0.37.19990506233202.036d7400@mail.lauterbach.com >you write: > At 23:15 06.05.99 , Geoff Keating wrote: > >Is this testcase already in the test suite? It's stripped-down code > >from kaffe's implementation of GNU zip. > > Geoff, > > this testcase is not in the testsuite, but it also no longer FAILs with the > > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's > one testcase in the testsuite which still shows this problem with -fpic on > PPC, attached below. I've added this test to the testsuite. Thanks! Jeff ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 14:45 ` Franz Sirl 1999-05-13 1:12 ` Jeffrey A Law @ 1999-05-18 21:33 ` Geoff Keating 1999-05-31 21:36 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 2 siblings, 1 reply; 22+ messages in thread From: Geoff Keating @ 1999-05-18 21:33 UTC (permalink / raw) To: Franz.Sirl-kernel; +Cc: amylaar, law, ghazi, davem, egcs > Date: Thu, 06 May 1999 23:44:47 +0200 > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> > Cc: amylaar@cygnus.co.uk, law@cygnus.com, ghazi@snafu.Rutgers.EDU, > davem@cobaltmicro.com, egcs@egcs.cygnus.com > > At 23:15 06.05.99 , Geoff Keating wrote: > >Is this testcase already in the test suite? It's stripped-down code > >from kaffe's implementation of GNU zip. > > Geoff, > > this testcase is not in the testsuite, but it also no longer FAILs with the > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's > one testcase in the testsuite which still shows this problem with -fpic on > PPC, attached below. ... The canonical example of this sort of thing is this: extern int v; void f(void) { asm ("" : : "r"(&v)); } because until it actually parses the asm, reload can't tell that it's not extern int v; void f(void) { asm ("" : : "i"(&v)); } which does not need the GOT register---this is not a hypothetical example, the first one happens in glibc somewhere, and you use the second one to override -fpic on a section of code which you know will be in writable memory, like (on ppc): static const double real_params[] = { 1, 2, 3.141 }; const double * params(void) __attribute__((section(".wcode"), const)); const double * params(void) { const double *result; /* Just like `return real_params', except that it is not PIC and so will be faster under these circumstances (it saves building a stack frame, for instance). */ asm ("lis %0,%1@ha ; addi %0,%0,%1@lo" : "=b"(result) : "i"(real_params)); return result; } -- Geoffrey Keating <geoffk@ozemail.com.au> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-18 21:33 ` Geoff Keating @ 1999-05-31 21:36 ` Geoff Keating 0 siblings, 0 replies; 22+ messages in thread From: Geoff Keating @ 1999-05-31 21:36 UTC (permalink / raw) To: Franz.Sirl-kernel; +Cc: amylaar, law, ghazi, davem, egcs > Date: Thu, 06 May 1999 23:44:47 +0200 > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> > Cc: amylaar@cygnus.co.uk, law@cygnus.com, ghazi@snafu.Rutgers.EDU, > davem@cobaltmicro.com, egcs@egcs.cygnus.com > > At 23:15 06.05.99 , Geoff Keating wrote: > >Is this testcase already in the test suite? It's stripped-down code > >from kaffe's implementation of GNU zip. > > Geoff, > > this testcase is not in the testsuite, but it also no longer FAILs with the > current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's > one testcase in the testsuite which still shows this problem with -fpic on > PPC, attached below. ... The canonical example of this sort of thing is this: extern int v; void f(void) { asm ("" : : "r"(&v)); } because until it actually parses the asm, reload can't tell that it's not extern int v; void f(void) { asm ("" : : "i"(&v)); } which does not need the GOT register---this is not a hypothetical example, the first one happens in glibc somewhere, and you use the second one to override -fpic on a section of code which you know will be in writable memory, like (on ppc): static const double real_params[] = { 1, 2, 3.141 }; const double * params(void) __attribute__((section(".wcode"), const)); const double * params(void) { const double *result; /* Just like `return real_params', except that it is not PIC and so will be faster under these circumstances (it saves building a stack frame, for instance). */ asm ("lis %0,%1@ha ; addi %0,%0,%1@lo" : "=b"(result) : "i"(real_params)); return result; } -- Geoffrey Keating <geoffk@ozemail.com.au> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 14:45 ` Franz Sirl 1999-05-13 1:12 ` Jeffrey A Law 1999-05-18 21:33 ` Geoff Keating @ 1999-05-31 21:36 ` Franz Sirl 2 siblings, 0 replies; 22+ messages in thread From: Franz Sirl @ 1999-05-31 21:36 UTC (permalink / raw) To: Geoff Keating; +Cc: amylaar, law, ghazi, davem, egcs At 23:15 06.05.99 , Geoff Keating wrote: >Is this testcase already in the test suite? It's stripped-down code >from kaffe's implementation of GNU zip. Geoff, this testcase is not in the testsuite, but it also no longer FAILs with the current cvs-egcs, reload got a _lot_ smarter since egcs-1.1. But there's one testcase in the testsuite which still shows this problem with -fpic on PPC, attached below. Franz. PS. Geoff, if you want to play with the egcs-mainline a bit, login into the LinuxPPC developers machine, you'll find everything under ~fsirl/egcsm (source) and ~fsirl/obj/cvsm (build from today), you should have full access there. gcc/testsuite/gcc.dg/980523-1.c: /* { dg-do run { target rs6000-*-linux* powerpc-*-linux*} } */ /* { dg-options "-O2 -fpic" } */ void foo1(int a, char *b, int c) { c =a+c+234; } int foo2(int d) { return d*d; } int bar1, bar2, bar3; char * bar4; int main(void) { int h; bar1 = foo2(1); bar2 = foo2(1); h = foo2(1); foo1(1, "a", foo2(1)); foo1(bar1, "a", foo2(1)); foo2(1); h = foo2(1); bar3 = 1; bar4 = "a"; foo1(1, "n", foo2(1)); foo1(1, "o", foo2(1)); foo1(1, "p", foo2(1)); foo1(bar1, "a", foo2(1)); bar3 = h; bar4 = "b"; foo1(bar1, "b", foo2(1)); foo1(1, "q", foo2(1)); bar4 = "c"; foo1(1, "c", foo2(1)); bar4 = "d"; foo1(1, "d", foo2(1)); bar4 = "e"; foo1(1, "e", foo2(1)); bar4 = "f"; foo1(1, "f", foo2(1)); bar4 = "g"; foo1(1, "g", foo2(1)); bar4 = "h"; foo1(1, "h", foo2(1)); bar4 = "i"; foo1(1, "i", foo2(1)); bar4 = "j"; foo1(1, "j", foo2(1)); bar4 = "k"; foo1(1, "k", foo2(1)); bar4 = "l"; foo1(1, "l", foo2(1)); bar4 = "m"; foo1(bar2, "m", foo2(1)); exit(0); } ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 14:16 ` Geoff Keating 1999-05-06 14:45 ` Franz Sirl @ 1999-05-31 21:36 ` Geoff Keating 1 sibling, 0 replies; 22+ messages in thread From: Geoff Keating @ 1999-05-31 21:36 UTC (permalink / raw) To: Franz.Sirl-kernel; +Cc: amylaar, law, ghazi, davem, egcs > Date: Thu, 06 May 1999 22:36:17 +0200 > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> > Cc: law@cygnus.com, ghazi@snafu.Rutgers.EDU, davem@cobaltmicro.com, > egcs@egcs.cygnus.com, geoffk@ozemail.com.au > > At 19:46 30.04.99 , Joern Rennecke wrote: > > > > > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > > > I think we should address the -fpic/-fPIC failures on the sparc. > > > > This would affect glibc or really any shared library. IIRC, Dave had a > > > > preliminary fix early last fall around the time we split the 1.1.x > > > > branch. For some reason it never went in. (?) > > > If it's the problem I think it is then it's unlikely we'll have a general > > > solution in time for egcs-1.2. > > > > > > Lazy allocation of the PIC register is a bad bad idea right now. It's > > going > > > to consistently lose. If we want this to work 100% reliably for > > egcs-1.2, then > > > the backend is going to need to pre-allocate the register early and > > take the > > > performance hit. This effects multiple ports that have tried to do lazy > > > allocation of the PIC register (for example the ppc). Yes. > > > Then someone will need to block out some significant time post egcs-1.2 > > to fix > > > the problem correctly. It's not a simple problem to fix. Yes. > >I think that, if no PIC register is preallocated and we find during > >reload that we need one after all, we should just load it with a secondary > >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i > >appropriately). > >We should check that reload inheritance works for the temporarily > >allocated PIC register. Then we should get actually better code than if > >we allocated the PIC register for the entire function. Regrettably, it's more complex than that. It's not just the case of suddenly discovering that a routine, which previously didn't have a PIC register, needs one. It's also the case when a routine which already has a PIC register finds that it needs to access it in more and/or different places than before. The example I have of this is attached below. Look at register 26; it is the PIC register, yet it gets stomped just after label '.L5'; and there's a flow of control from there to just after label '.L13' where the PIC register is used. Compile under 1.1.1, targetting powerpc-linux with '-O -fpic'. The problem here is triggered by reload deciding to do some constant rearrangement because of a REG_EQUIV note: it sees this (insn 264 261 266 (set (reg:SI 117) (unspec[ (symbol_ref:SI ("@h_malloc")) (reg:SI 128) ] 8)) 398 {*movsi_got_internal} (nil) (expr_list:REG_EQUIV (symbol_ref:SI ("@h_malloc")) (nil))) and decides that it can then simplify this insn: (insn 160 158 162 (set (reg:SI 120) (mem:SI (reg:SI 117))) 402 {movsi+1} (nil) (nil)) by rewriting it as (insn 160 158 162 (set (reg:SI 120) (symbol_ref:SI ("@h_malloc"))) (nil) (nil)) because register 117 is equivalent to the symbol_ref; but it actually ends up as (insn 160 158 162 (set (reg:SI 120) (unspec[ (symbol_ref:SI ("@h_malloc")) (reg:SI 128) ] 8)) 398 {*movsi_got_internal} (nil) (nil)) and suddenly there's a new use of register 128 that wasn't there before, and this causes global alloc to fail. Similar problems happen with floating-point constants. Is this testcase already in the test suite? It's stripped-down code from kaffe's implementation of GNU zip. If you want a temporary fix, I've previously posted a solution which ensures that reload will never ask for a new occurrence of the PIC register. It should be in the egcs-patches archive. If you use this, then there is no need to do anything else. It would need to be ported to sparc if it is needed there (the port consists of defining two preprocessor variables in sparc.h). The patch operates by forcing reload to never spill constants to memory (only when -fpic, of course). It works OK on powerpc, but on sparc it might need some more code in the machine description to make life easier for the crippled reload---I would be glad to help here. On powerpc, I'm not sure that you can use reload in the way suggested. I suspect there are cases in which it won't be able to reload the link register, for instance when folding switch statements. > Hmm, would this solution possibly be OK for 1.2? It really would be great > if this was solved once and forever, so if you have some code to try I'm > willing to test it on PPC. Certainly, if there's code already written I'm happy to run it against my test suite. -- Geoffrey Keating <geoffk@ozemail.com.au> ===File ~/gcc-bugs/test11.s================================= .file "test11.c" gcc2_compiled.: .globl memset .section ".text" .align 2 .type doit,@function doit: stwu 1,-176(1) mflr 0 stw 14,104(1) stw 15,108(1) stw 16,112(1) stw 17,116(1) stw 18,120(1) stw 19,124(1) stw 20,128(1) stw 21,132(1) stw 22,136(1) stw 23,140(1) stw 24,144(1) stw 25,148(1) stw 26,152(1) stw 27,156(1) stw 28,160(1) stw 29,164(1) stw 30,168(1) stw 31,172(1) stw 0,180(1) bl _GLOBAL_OFFSET_TABLE_@local-4 mflr 26 mr 18,3 mr 16,4 mr 17,5 mr 22,6 addi 3,1,72 li 4,0 li 5,16 crxor 6,6,6 bl memset@plt addi 3,1,8 li 4,0 li 5,60 crxor 6,6,6 bl memset@plt li 31,0 li 3,0 li 27,0 addi 25,1,12 li 30,1 addi 19,1,72 li 14,1 li 15,0 addi 20,1,88 .L5: li 26,0 slwi 21,30,2 .L9: cmplw 0,30,31 bc 4,1,.L11 addi 23,26,1 addi 0,30,-1 slwi 24,0,2 .L12: slwi 0,27,2 lwzx 31,25,0 addi 27,27,1 mr 9,31 cmplw 0,31,23 bc 4,1,.L13 add 11,19,21 cmplwi 0,31,1 bc 12,1,.L13 .L18: slwi 0,9,2 lwzx 0,11,0 cmplw 0,31,0 bc 12,1,.L13 addi 9,9,1 cmplwi 0,9,1 bc 4,1,.L18 .L13: slwi 0,27,2 stwx 9,25,0 lwz 10,h_malloc@got(26) lwz 0,0(10) slw 3,14,18 mtlr 0 blrl stw 3,0(22) addi 22,3,4 stw 15,4(3) stwx 3,24,20 cmplw 0,30,31 bc 12,1,.L12 .L11: mr 28,16 mr 29,17 stw 28,0(3) stw 29,4(3) addi 26,26,1 cmplwi 0,26,6 bc 4,1,.L9 addi 30,30,1 cmplwi 0,30,2 bc 4,1,.L5 lwz 0,180(1) mtlr 0 lwz 14,104(1) lwz 15,108(1) lwz 16,112(1) lwz 17,116(1) lwz 18,120(1) lwz 19,124(1) lwz 20,128(1) lwz 21,132(1) lwz 22,136(1) lwz 23,140(1) lwz 24,144(1) lwz 25,148(1) lwz 26,152(1) lwz 27,156(1) lwz 28,160(1) lwz 29,164(1) lwz 30,168(1) lwz 31,172(1) la 1,176(1) blr .Lfe1: .size doit,.Lfe1-doit .align 2 .globl is_ok .type is_ok,@function is_ok: stwu 1,-16(1) mflr 0 stw 0,20(1) li 3,0 crxor 6,6,6 bl exit@plt .Lfe2: .size is_ok,.Lfe2-is_ok .align 2 .globl main .type main,@function main: stwu 1,-16(1) mflr 0 stw 0,20(1) bl _GLOBAL_OFFSET_TABLE_@local-4 mflr 9 lwz 11,h_malloc@got(9) lwz 9,is_ok@got(9) stw 9,0(11) li 3,0 li 4,0 li 5,0 li 6,0 bl doit@local bl abort@plt .Lfe3: .size main,.Lfe3-main .comm h_malloc,4,4 .ident "GCC: (GNU) egcs-2.91.54 19980816 (gcc2 ss-980609 experimental)" ============================================================ ===File ~/gcc-bugs/test11.c================================= typedef struct _huft { unsigned e; struct _huft* t; } huft; huft* (*h_malloc)(unsigned); static void doit( unsigned p2, unsigned p3, huft *p4, huft** t) { unsigned a, h, j, k, w; unsigned *xp, *l; unsigned lx[2*7+1], v[2*2]; huft *q; huft r; huft *u[2]; memset(v, 0, sizeof(v)); memset(lx, 0, sizeof(lx)); w = 0; q = 0; h = 0; l = lx+1; for (k=1; k <= 2; k++) for (a=0; a < 7; a++) { while (k > w) { w = l[h++]; j = w; if (w > a + 1) { xp = v + k; while (j < 2 && w <= xp[j]) ++j; } l[h] = j; q = h_malloc(1<<p2); *t = q; t = &(q->t); *t = 0; u[k-1] = q; } r.e = p3; r.t = p4; q[0] = r; } } huft *is_ok(unsigned x) { exit(0); } int main() { h_malloc = is_ok; doit(0, 0, 0, 0); abort(); } ============================================================ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 13:36 ` Franz Sirl 1999-05-06 14:16 ` Geoff Keating @ 1999-05-31 21:36 ` Franz Sirl 1 sibling, 0 replies; 22+ messages in thread From: Franz Sirl @ 1999-05-31 21:36 UTC (permalink / raw) To: Joern Rennecke; +Cc: law, ghazi, davem, egcs, geoffk At 19:46 30.04.99 , Joern Rennecke wrote: > > > > In message <199903281412.JAA02308@caip.rutgers.edu>you write: > > > I think we should address the -fpic/-fPIC failures on the sparc. > > > This would affect glibc or really any shared library. IIRC, Dave had a > > > preliminary fix early last fall around the time we split the 1.1.x > > > branch. For some reason it never went in. (?) > > If it's the problem I think it is then it's unlikely we'll have a general > > solution in time for egcs-1.2. > > > > Lazy allocation of the PIC register is a bad bad idea right now. It's > going > > to consistently lose. If we want this to work 100% reliably for > egcs-1.2, then > > the backend is going to need to pre-allocate the register early and > take the > > performance hit. This effects multiple ports that have tried to do lazy > > allocation of the PIC register (for example the ppc). > > > > Then someone will need to block out some significant time post egcs-1.2 > to fix > > the problem correctly. It's not a simple problem to fix. > >I think that, if no PIC register is preallocated and we find during >reload that we need one after all, we should just load it with a secondary >reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i >appropriately). >We should check that reload inheritance works for the temporarily >allocated PIC register. Then we should get actually better code than if >we allocated the PIC register for the entire function. Hmm, would this solution possibly be OK for 1.2? It really would be great if this was solved once and forever, so if you have some code to try I'm willing to test it on PPC. Franz. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: egcs-1.2 stuff 1999-03-28 6:12 egcs-1.2 stuff Kaveh R. Ghazi 1999-03-28 6:24 ` David Miller 1999-03-28 13:09 ` Jeffrey A Law @ 1999-03-31 23:46 ` Kaveh R. Ghazi 2 siblings, 0 replies; 22+ messages in thread From: Kaveh R. Ghazi @ 1999-03-31 23:46 UTC (permalink / raw) To: law; +Cc: davem, egcs > From: Jeffrey A Law <law@hurl.cygnus.com> > > OK. Now that egcs-1.1.2 is done, we need to start discussing the major > stuff that needs to be resolved for egcs-1.2. My quick list: > > 7. Various bugs effecting glibc, the linux kernel, mips large frames, > etc etc. Basically some major bug hunting sessions. I think we should address the -fpic/-fPIC failures on the sparc. This would affect glibc or really any shared library. IIRC, Dave had a preliminary fix early last fall around the time we split the 1.1.x branch. For some reason it never went in. (?) > Mon Sep 7 22:04:51 1998 David S. Miller <davem@pierdol.cobaltmicro.com> > > * config/sparc/sparc.c (legitimize_pic_address): If during or > after reload, and no PIC references existed before reload, emit > get_pc sequence to setup pic base register for all such > references. Of course maybe this is completely unrelated to the failures I'm seeing today. :-) For an example of the recent -fpic/-fPIC failures (and beyond above what normally occurs) see: http://egcs.cygnus.com/ml/egcs-testresults/1999-03/msg00353.html --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) @ 1999-05-06 18:53 Kaveh R. Ghazi 1999-05-31 21:36 ` Kaveh R. Ghazi 0 siblings, 1 reply; 22+ messages in thread From: Kaveh R. Ghazi @ 1999-05-06 18:53 UTC (permalink / raw) To: Franz.Sirl-kernel, geoffk; +Cc: amylaar, davem, egcs, law > From: Geoff Keating <geoffk@ozemail.com.au> > > [...] > > Similar problems happen with floating-point constants. > > Is this testcase already in the test suite? It's stripped-down code > from kaffe's implementation of GNU zip. If you're looking for testcases, I regularly run the entire testsuite with -fpic/-fPIC on solaris2 and get several extra failures. See: http://egcs.cygnus.com/ml/egcs-testresults/1999-05/msg00049.html These extra failures may not fail on your system with -fpic/-fPIC, but they're a good place to start. Or you can do a full -fpic/-fPIC run yourself. It takes a while, but I'm sure something extra will pop up as a new failure. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PIC register allocation by reload (Was: Re: egcs-1.2 stuff) 1999-05-06 18:53 PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Kaveh R. Ghazi @ 1999-05-31 21:36 ` Kaveh R. Ghazi 0 siblings, 0 replies; 22+ messages in thread From: Kaveh R. Ghazi @ 1999-05-31 21:36 UTC (permalink / raw) To: Franz.Sirl-kernel, geoffk; +Cc: amylaar, davem, egcs, law > From: Geoff Keating <geoffk@ozemail.com.au> > > [...] > > Similar problems happen with floating-point constants. > > Is this testcase already in the test suite? It's stripped-down code > from kaffe's implementation of GNU zip. If you're looking for testcases, I regularly run the entire testsuite with -fpic/-fPIC on solaris2 and get several extra failures. See: http://egcs.cygnus.com/ml/egcs-testresults/1999-05/msg00049.html These extra failures may not fail on your system with -fpic/-fPIC, but they're a good place to start. Or you can do a full -fpic/-fPIC run yourself. It takes a while, but I'm sure something extra will pop up as a new failure. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~1999-05-31 21:36 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-03-28 6:12 egcs-1.2 stuff Kaveh R. Ghazi 1999-03-28 6:24 ` David Miller 1999-03-31 23:46 ` David Miller 1999-03-28 13:09 ` Jeffrey A Law 1999-03-28 16:06 ` David Miller 1999-03-31 23:46 ` David Miller 1999-03-31 23:46 ` Jeffrey A Law 1999-04-30 10:46 ` PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Joern Rennecke 1999-04-30 23:15 ` Joern Rennecke 1999-05-06 13:36 ` Franz Sirl 1999-05-06 14:16 ` Geoff Keating 1999-05-06 14:45 ` Franz Sirl 1999-05-13 1:12 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-18 21:33 ` Geoff Keating 1999-05-31 21:36 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 1999-05-31 21:36 ` Geoff Keating 1999-05-31 21:36 ` Franz Sirl 1999-03-31 23:46 ` egcs-1.2 stuff Kaveh R. Ghazi 1999-05-06 18:53 PIC register allocation by reload (Was: Re: egcs-1.2 stuff) Kaveh R. Ghazi 1999-05-31 21:36 ` Kaveh R. Ghazi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).