Re: [PATCH] Optimize n + 1 for automatic n array (PR c++/71537)
On 01/10/2017 11:40 PM, Jakub Jelinek wrote:
+constexpr bool
+foo ()
+{
+ constexpr int n[42] = { 1 };
+ constexpr int o = n ? 1 : 0;
+ constexpr int p = n + 1 ? 1 : 0;
+ constexpr int q = "abc" + 1 ? 1 : 0;
+ return p + p + q == 3;
+}
Not o + p + q ?
John.
Re: [PATCH, libgcc, ARM] __gnu_f2h_internal inaccuracy
Ping ? Paul, seen that you've contributed fp16.c together with Sandra
Loosemore, perhaps you can review this patch please ?
John.
In message
John Tytgat wrote:
> __gnu_f2h_internal in libgcc converts single-precision floating-point value
> to half-precision value for ARM. I noticed there is a slight inaccuracy
> for floating-point values 2^-25 + epsilon (with epsilon > 0 and < 2^-26).
> Those should all be converted to 2^-24 in half-precision.
>
> And this because the mask used to implement the even-odd rounding for
> aexp = -25 is wrong. Currently we have:
>
> /* Decimal point between bits 22 and 23. */
> mantissa |= 0x0080;
> if (aexp < -14)
> {
> mask = 0x007f;
> if (aexp < -25)
> aexp = -26;
> else if (aexp != -25)
> mask >>= 24 + aexp;
> }
> else
> mask = 0x1fff;
>
> But when aexp is 25 the mask should be 0xff instead of 0x7f as the
> decimal dot in half-precision will be between bit 24 and 23 of the
> above mentioned mantissa. Cfr. the even-odd rounding done:
>
> /* Round. */
> if (mantissa & mask)
> {
> increment = (mask + 1) >> 1;
> if ((mantissa & mask) == increment)
> increment = mantissa & (increment << 1);
> mantissa += increment;
> if (mantissa >= 0x0100)
> {
> mantissa >>= 1;
> aexp++;
> }
> }
>
> Attached patch solves this problem. I've left out the clamping of
> aexp to -26 for values less than -25 as this it not necessary. After
> the even-odd rounding all aexp values less than -24 will result in +0. or
> -0. anyway.
>
> John Tytgat
>
> * config/arm/fp16.c (__gnu_f2h_internal): Fix inaccuracy.
>
> I've got a copyright assignment but no write access.
>
> John Tytgat.
--
John Tytgat BASS
j...@bass-software.comIndex: libgcc/config/arm/fp16.c
===
--- libgcc/config/arm/fp16.c(revision 193830)
+++ libgcc/config/arm/fp16.c(working copy)
@@ -47,11 +47,9 @@
mantissa |= 0x0080;
if (aexp < -14)
{
- mask = 0x007f;
- if (aexp < -25)
- aexp = -26;
- else if (aexp != -25)
- mask >>= 24 + aexp;
+ mask = 0x00ff;
+ if (aexp >= -25)
+mask >>= 25 + aexp;
}
else
mask = 0x1fff;
Re: [PATCH, libgcc, ARM] __gnu_f2h_internal inaccuracy
In message
John Tytgat wrote:
> [...] Attached patch solves this problem. [...]
This time for real.
John Tytgat.
--
John Tytgat, in his comfy chair at home
john.tyt...@aaug.net
Index: libgcc/config/arm/fp16.c
===
--- libgcc/config/arm/fp16.c(revision 193830)
+++ libgcc/config/arm/fp16.c(working copy)
@@ -47,11 +47,9 @@
mantissa |= 0x0080;
if (aexp < -14)
{
- mask = 0x007f;
- if (aexp < -25)
- aexp = -26;
- else if (aexp != -25)
- mask >>= 24 + aexp;
+ mask = 0x00ff;
+ if (aexp >= -25)
+mask >>= 25 + aexp;
}
else
mask = 0x1fff;
[PATCH, libgcc, ARM] __gnu_f2h_internal inaccuracy
__gnu_f2h_internal in libgcc converts single-precision floating-point value
to half-precision value for ARM. I noticed there is a slight inaccuracy
for floating-point values 2^-25 + epsilon (with epsilon > 0 and < 2^-26).
Those should all be converted to 2^-24 in half-precision.
And this because the mask used to implement the even-odd rounding for
aexp = -25 is wrong. Currently we have:
/* Decimal point between bits 22 and 23. */
mantissa |= 0x0080;
if (aexp < -14)
{
mask = 0x007f;
if (aexp < -25)
aexp = -26;
else if (aexp != -25)
mask >>= 24 + aexp;
}
else
mask = 0x1fff;
But when aexp is 25 the mask should be 0xff instead of 0x7f as the
decimal dot in half-precision will be between bit 24 and 23 of the
above mentioned mantissa. Cfr. the even-odd rounding done:
/* Round. */
if (mantissa & mask)
{
increment = (mask + 1) >> 1;
if ((mantissa & mask) == increment)
increment = mantissa & (increment << 1);
mantissa += increment;
if (mantissa >= 0x0100)
{
mantissa >>= 1;
aexp++;
}
}
Attached patch solves this problem. I've left out the clamping of
aexp to -26 for values less than -25 as this it not necessary. After
the even-odd rounding all aexp values less than -24 will result in +0. or
-0. anyway.
John Tytgat
* config/arm/fp16.c (__gnu_f2h_internal): Fix inaccuracy.
I've got a copyright assignment but no write access.
John Tytgat.
--
John Tytgat BASS
j...@bass-software.com
Re: [RFC, PATCH] ARM related deprecations
In message <4f4d0e64.1020...@arm.com> Richard Earnshaw wrote: > On 28/02/12 17:10, Joseph S. Myers wrote: > > On Tue, 28 Feb 2012, Richard Earnshaw wrote: > > > >> Here's an updated patch and a suggested web-page patch: > > > > uClinux targets do not have -gnu in their target triplets. > > > > You missed the WinCE port from the list in the webpage patch of ports > > being deprecated for using FPA floating-point format and lacking a modern > > alternative using VFP format. (The config.gcc patch also got the triplet > > for WinCE wrong - it's arm*-wince-pe* not arm*-*-wince*. Though ISTR the > > more functional port that hasn't been contributed to FSF GCC uses some > > other triplet.) > > > > Have I ever said how much I hate triplets? > > Here's an updated version, plus some updates to install.texi to avoid > references to the obsolete ports. > > OK? As mentioned/asked in http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00744.html our GCC/ARM port for RISC OS which is using for one of its multilib variants FPA (to interface with the SharedCLibrary used in RISC OS). Other multilib variants are soft-float and VPF. I would like to keep the FPA support in gcc 4.8. I'm wondering if the removal of FPA is really necessary. Does FPA support prevent future ARM improvements in GCC ? John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven
Re: [RFC, PATCH] ARM related deprecations
In message <4ee2285b.3060...@arm.com> Richard Earnshaw wrote: > I think we've reached the point where the following target > configurations should be End-of-Life'd. As such, I'd like to mark them > as deprecated in gcc-4.7, prior to removal after the branch. > > I'd also like to remove at that time support for some now obsolete > co-processor units, namely the FPA and Maverick. Would it really be necessary to remove the FPA support ? Does it hinder any future ARM support in gcc ? The reason for thse questions is that for many years our RISC OS gcc port (currently following the gcc developments on the 4.6 branch and trunk) can make use of hard-float FPA output for one of its multilib flavours (see http://gccsdk.riscos.info/) and I would like to keep on supporting this in gcc 4.8. John. -- John Tytgat, in his comfy chair at home BASS john.tyt...@aaug.net ARM powered, RISC OS driven
[PATCH libcpp]: S_ISREG non-zero value does not always fit in a bool
In libcpp/files.c the value of S_ISREG() is assigned to a bool variable.
AFAIK a non-zero value of S_ISREG does not necessary fit into a bool
(unsigned char) so on some systems the file reading is a bit less efficient
wrt its buffer size determination.
Please commit after positive review (I don't have commit write rights).
John.
2011-05-29 John Tytgat
* files.c (read_file_guts): Add test on non-zero value of S_ISREG.
--
John Tytgat, in his comfy chair at home
john.tyt...@aaug.net
Index: libcpp/files.c
===
--- libcpp/files.c (revision 174393)
+++ libcpp/files.c (working copy)
@@ -595,7 +595,7 @@
return false;
}
- regular = S_ISREG (file->st.st_mode);
+ regular = S_ISREG (file->st.st_mode) != 0;
if (regular)
{
/* off_t might have a wider range than ssize_t - in other words,
