Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-11-04 Thread Jeff Law
On 11/3/19 5:12 AM, Oleg Endo wrote: > On Fri, 2019-10-11 at 23:27 +0900, Oleg Endo wrote: >> On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote: >>> >>> So probably the most interesting target for this test is v850-elf >>> as >>> it's got a reasonably well functioning simulator, hard and soft FP >>

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-11-03 Thread Oleg Endo
On Fri, 2019-10-11 at 23:27 +0900, Oleg Endo wrote: > On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote: > > > > So probably the most interesting target for this test is v850-elf > > as > > it's got a reasonably well functioning simulator, hard and soft FP > > targets, little endian, and I'm famil

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-11 Thread Oleg Endo
On Thu, 2019-10-03 at 19:34 -0600, Jeff Law wrote: > > So probably the most interesting target for this test is v850-elf as > it's got a reasonably well functioning simulator, hard and soft FP > targets, little endian, and I'm familiar with its current set of > failures. > > I can confirm that yo

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-11 Thread Oleg Endo
Hi Bernd, On Sun, 2019-09-29 at 08:49 +, Bernd Edlinger wrote: > > But I cannot tell if the bitfield access generates > more efficient code or identical code than the > original variant when no ms bitfields are used. > That needs closer inspection of the generated > assembler code, a simple b

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-03 Thread Jeff Law
On 9/28/19 8:14 PM, Oleg Endo wrote: > Hi, > > I've been dragging this patch along with me for a while. > At the moment, I don't have the resources to fully test it as requested > by Ian in the PR discussion. > > So I would like to ask for general comments on this one and hope that > folks with b

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-02 Thread Jeff Law
On 10/2/19 10:51 AM, Oleg Endo wrote: > On Tue, 2019-10-01 at 14:21 -0600, Jeff Law wrote: >> >> So the ask is to just test this on some LE targets? I can do that :-) >> >> I'll throw it in. Analysis will be slightly more difficult than >> usual >> as we've got some fallout from Richard S's work,

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-02 Thread Oleg Endo
On Tue, 2019-10-01 at 14:21 -0600, Jeff Law wrote: > > So the ask is to just test this on some LE targets? I can do that :-) > > I'll throw it in. Analysis will be slightly more difficult than > usual > as we've got some fallout from Richard S's work, but it's certainly > do-able. Thanks a lot

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-10-01 Thread Jeff Law
On 9/28/19 8:14 PM, Oleg Endo wrote: > Hi, > > I've been dragging this patch along with me for a while. > At the moment, I don't have the resources to fully test it as requested > by Ian in the PR discussion. > > So I would like to ask for general comments on this one and hope that > folks with b

Re: [RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-09-29 Thread Bernd Edlinger
Hi Oleg, I think both variants should fix the issues for us. But I cannot tell if the bitfield access generates more efficient code or identical code than the original variant when no ms bitfields are used. That needs closer inspection of the generated assembler code, a simple bootstrap / regtest

[RFH][libgcc] fp-bit bit ordering (PR 78804)

2019-09-28 Thread Oleg Endo
Hi, I've been dragging this patch along with me for a while. At the moment, I don't have the resources to fully test it as requested by Ian in the PR discussion. So I would like to ask for general comments on this one and hope that folks with bigger automated test setups can run the patch through