On 27/07/18 17:45, Nicolas Pitre wrote:
> On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
>
>> Nicolas Pitre wrote:
>>
However if r4 is non-zero, the carry will be set, and the tsths will be
executed. This
clears the carry and sets the Z flag based on bit 20.
>>>
>>> No, not at all.
On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
> Nicolas Pitre wrote:
>
> >> However if r4 is non-zero, the carry will be set, and the tsths will be
> >> executed. This
> >> clears the carry and sets the Z flag based on bit 20.
> >
> > No, not at all. The carry is not affected. And that's the point
Nicolas Pitre wrote:
>> However if r4 is non-zero, the carry will be set, and the tsths will be
>> executed. This
>> clears the carry and sets the Z flag based on bit 20.
>
> No, not at all. The carry is not affected. And that's the point of the
> tst instruction here rather than a cmp: it sets
On Fri, 27 Jul 2018, Nicolas Pitre wrote:
> On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
>
> > Hi Nicolas,
> >
> > I think your patch doesn't quite work as expected:
> >
> > @@ -238,9 +238,10 @@ LSYM(Lad_a):
> > movsip, ip, lsl #1
> > adcsxl, xl, xl
> > adc xh, xh, xh
> >
On Fri, 27 Jul 2018, Wilco Dijkstra wrote:
> Hi Nicolas,
>
> I think your patch doesn't quite work as expected:
>
> @@ -238,9 +238,10 @@ LSYM(Lad_a):
> movsip, ip, lsl #1
> adcsxl, xl, xl
> adc xh, xh, xh
> - tst xh, #0x0010
> - sub r4, r4, #1
>
Hi Nicolas,
I think your patch doesn't quite work as expected:
@@ -238,9 +238,10 @@ LSYM(Lad_a):
movsip, ip, lsl #1
adcsxl, xl, xl
adc xh, xh, xh
- tst xh, #0x0010
- sub r4, r4, #1
- bne LSYM(Lad_e)
+ subsr4, r4, #1
Umesh Kalappa wrote:
> Any more suggestions or comments on the patch ?
The patch is suboptimal as it introduces 2 additional instructions in a
fairly common path for a branch that is very unlikely to be taken in
practice.
I'm therefore proposing this alternative patch to fix the issue in an
Hi,
Any more suggestions or comments on the patch ?
Thank you
~Umesh
On Tue, Jul 24, 2018, 2:08 PM Umesh Kalappa
wrote:
> Thank you All for the suggestions and we tried runing the GCC
> testsuite and found that no regression with the fix and also ran the
> our regressions base for
Thank you All for the suggestions and we tried runing the GCC
testsuite and found that no regression with the fix and also ran the
our regressions base for conformance with no regress.
Is ok for commit with below Changelog ?
+++ libgcc/ChangeLog(working copy)
@@ -1,3 +1,9 @@
+2018-07-18
Umesh Kalappa wrote:
> We tested on the SP and yes the problem persist on the SP too and
> attached patch will fix the both SP and DP issues for the denormal
> resultant.
The patch now looks correct to me (but I can't approve).
> We bootstrapped the compiler ,look ok to us with minimal testing
On Mon, Jul 23, 2018 at 12:09 PM, Umesh Kalappa
wrote:
> Hi Richard,
>
> We tested on the SP and yes the problem persist on the SP too and
> attached patch will fix the both SP and DP issues for the denormal
> resultant.
> We bootstrapped the compiler ,look ok to us with minimal testing ,
Have
Hi Richard,
We tested on the SP and yes the problem persist on the SP too and
attached patch will fix the both SP and DP issues for the denormal
resultant.
We bootstrapped the compiler ,look ok to us with minimal testing ,
Any floating point test-suite to test for the attached patch ? any
So why is this only changing the double-precision implementation?
Surely, a problem like this will normally be common to both SP and DP
floating-point computations.
R.
On 23/07/18 08:46, Umesh Kalappa wrote:
> Thank you Wilco for the inputs and we agree that the fix break down
> for the case.
>
Thank you Wilco for the inputs and we agree that the fix break down
for the case.
Meanwhile ,attached patch will take care the inputs and we are testing
the patch vigorously ,would you recommended any test-suite out there
for the same ?
Thank you
~Umesh
On Fri, Jul 20, 2018 at 10:04 PM, Wilco
Umesh Kalappa wrote:
> We tried some of the normalisation numbers and the fix works and please
> could you help us with the input ,where if you see that fix breaks down.
Well try any set of inputs which require normalisation. You'll find these no
longer get normalised and so will get incorrect
Thank you all for your comments .
Wilco,
We tried some of the normalisation numbers and the fix works and please
could you help us with the input ,where if you see that fix breaks down.
Thank you again
~Umesh
On Fri, Jul 20, 2018, 7:07 PM Wilco Dijkstra wrote:
> Hi Umesh,
>
> Looking at your
Hi Umesh,
Looking at your patch, this would break all results which need to be normalized.
Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S (revision 262850)
+++ libgcc/config/arm/ieee754-df.S
On 18/07/18 13:31, Umesh Kalappa wrote:
Hi Nagy/Ramana,
Please help us to review the attached patch and do let me know your comments .
No regress in the gcc.target suite for arm target.
have you submitted a copyright assignment form yet?
https://gcc.gnu.org/contribute.html
Index:
Reminder !!!
~Umesh
On Wed, Jul 18, 2018 at 6:01 PM, Umesh Kalappa wrote:
> Hi Nagy/Ramana,
>
> Please help us to review the attached patch and do let me know your comments .
>
> No regress in the gcc.target suite for arm target.
>
> Thank you
> ~Umesh
>
> On Tue, Jul 17, 2018 at 4:01 PM,
Hi Nagy/Ramana,
Please help us to review the attached patch and do let me know your comments .
No regress in the gcc.target suite for arm target.
Thank you
~Umesh
On Tue, Jul 17, 2018 at 4:01 PM, Umesh Kalappa wrote:
> Will do, thanks.
> Thanks
>
> On Tue, Jul 17, 2018, 3:24 PM Ramana
20 matches
Mail list logo
