On 1/21/2021 5:04 PM, Joseph Myers wrote:
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided i
l the
.tar file to them directly (500Kbytes).
- patrick mcgehearty
On 1/25/2021 2:48 PM, Joseph Myers wrote:
On Mon, 25 Jan 2021, Patrick McGehearty wrote:
On 1/21/2021 5:04 PM, Joseph Myers wrote:
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
TEST Data
I'd still like
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided in the commit message).
+ if ((mo
Changes in this version from Version 6:
Updated copyrights for following three files to -2021.
gcc/c-family/c-cppbuiltin.c
Moved code for setting LIBGCC modename to FUNC_EXT section.
Added code to set modename for any additional modes such as
FLT128 or FLT64X
Changes in this version from Version 6:
Updated copyrights for following three files to -2021.
gcc/c-family/c-cppbuiltin.c
Moved code for setting LIBGCC modename to FUNC_EXT section.
Added code to set modename for any additional modes such as
FLT128 or FLT64X
-0001.bin
I'll resubmit the patch with the corrected link.
- patrick
On 2/1/2021 5:49 PM, Joseph Myers wrote:
On Mon, 1 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
The message which contains the attached gzipped tarball of the
development test programs is:
https://www
Ping - Submitted Feb 2, 2021
I believe this version fixes all issues raised
in previous submissions.
- Patrick McGehearty
On 2/2/2021 4:25 PM, Patrick McGehearty via Gcc-patches wrote:
Changes in this version from Version 6:
Updated copyrights for following three files to -2021
Comments inline
On 2/19/2021 3:27 PM, Joseph Myers wrote:
On Tue, 2 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
if (mode == TYPE_MODE (double_type_node))
- ; /* Empty suffix correct. */
+ {
+ ; /* Empty suffix correct
:
On Fri, 19 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
Here you're properly computing the mapping from mode to float.h macro
prefix (though I think "modename" is a confusing name for the variable
used for float.h macro prefixes; to me, "modename" suggests the name
Changes in this version from Version 7:
gcc/c-family/c-cppbuiltin.c
Changed modename to float_h_prefix
Removed (mode == TYPE_MODE...) code left over from earlier approach.
libgcc/libgcc2.c
Removed conditional use of XF constants in TF case.
Also left over fro
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
The new code uses the following macros which are intended to be mapped
to appropriate values according to the underlying hardwa
IBM128 modes.
- patrick
On 8/12/2021 11:19 AM, Joseph Myers wrote:
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc compl
oseph Myers wrote:
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
This file includes quad-float128.h, which does some remapping from TF to
KF depending on __LONG_DOUBLE_IEEE128__.
I think you probably need to have a similar __LONG_DOUBLE_IEEE128__
conditional here
re how else to approach this issue for a short term solution.
- Patrick McGehearty (patrick.mcgehea...@oracle.com)
On 8/13/2021 12:12 PM, Joseph Myers wrote:
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
If _divkc3.c is not intended to provide a version of complex divide
The v4 revision adds a test in libgcc/libgcc2.c for when
"__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
of __LIBGCC_TF_EPSILON__. That is specific to IBM 128-bit format long
doubles where EPSILON is very, very small and 1/EPSILON oveflows to
infinity. This change avoids the ov
I will prepare a patch without the changes to .../rs6000/_divkc3.c
but I have no way of testing it to confirm it fixes the original
complaint.
On 8/26/2021 5:09 PM, Joseph Myers wrote:
On Thu, 26 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
The revision retains the use of __LIBGCC_DF_
This revision (v5) adds a test in libgcc/libgcc2.c for when
"__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
of __LIBGCC_TF_EPSILON__. That is specific to IBM 128-bit format long
doubles where EPSILON is very, very small and 1/EPSILON oveflows to
infinity. This change avoids the
rick McGehearty
patrick.mcgehea...@oracle.com
On 10/13/2020 9:54 AM, Patrick McGehearty via Gcc-patches wrote:
Ping - still need review of version 4 of this patch.
It has been over a month since the last comment.
- patrick
On 9/9/2020 2:13 AM, Richard Biener wrote:
On Tue, Sep 8, 2020 at
Ping
Note: I don't have commit privileges for gcc.
On 8/27/2021 2:59 PM, Patrick McGehearty via Gcc-patches wrote:
This revision (v5) adds a test in libgcc/libgcc2.c for when
"__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
of __LIBGCC_TF_EPSILON__. That is
- - - -
New in version 6: Due to an oversight (i.e. coding error), version 5
changed the use of __LIBGCC_TF_EPSILON__ to __LIBGCC_DF_EPSILON__ but
not the other LIBGCC_TF values. For correct execution of the long
double test case it is necessary to also switch to using
__LIBGCC_DF_MIN__. For consi
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
The new code uses the following macros which are intended to be mapped
Ping...
The fix is minimal (four lines changed).
I recognize that those familiar with IBM 128-bit floating
point precision is a select set of people.
On the plus side, tests fail without the patch and pass with the patch.
- patrick
On 7/8/2021 4:24 PM, Patrick McGehearty via Gcc-patches wrote
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
The new code uses the following macros which are intended to be mapped
to appropriate values according to the underlying hardwa
decisions
might prevent me from having time for rapid response.
- Patrick McGehearty (patrick.mcgehea...@oracle.com)
On 7/21/2020 12:19 PM, Patrick McGehearty via Gcc-patches wrote:
Ping
On 7/1/2020 11:30 AM, Patrick McGehearty via Gcc-patches wrote:
(Version 3)
(Added in version 3)
Support
My understanding is this feature/flag is not intended to be "default on".
It is intended to be used in security sensitive environments such
as the Linux kernel where it was requested by kernel security experts.
I'm not understanding the objection here if the feature is requested
by security teams
(Version 4)
(Added in version 4)
Fixed Changelog entry to include __divsc3, __divdc3, __divxc3, __divtc3.
Revised description to avoid incorrect use of "ulp (units last place)".
Modified float precison case to use double precision when double
precision hardware is available. Otherwise float uses t
On 9/9/2020 2:13 AM, Richard Biener wrote:
Thanks for working on this. Speaking about performance and
accuracy I spot a few opportunities to use FMAs [and eventually
vectorization] - do FMAs change anything on the accuracy analysis
(is there the chance they'd make it worse?). We might want t
Ping
On 7/1/2020 11:30 AM, Patrick McGehearty via Gcc-patches wrote:
(Version 3)
(Added in version 3)
Support for half, float, extended, and long double precision has
been added to the prior work for double precision. Since half precision
is computed with float precision as per current
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements to the quality of answers
for the default double precision complex divide routine when dealing
with very large or very small exponents.
The current code correctly implements Smith's method (1962
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements to the quality of answers
for the default double precision complex divide routine when dealing
with very large or very small exponents.
The current code correctly implements Smith's method (1962
not need to be concerned with special treatment of nulls.
I'll change the strncpy to memcpy.
- patrick
On 12/8/2020 5:31 PM, Jakub Jelinek wrote:
On Tue, Dec 08, 2020 at 10:32:33PM +, Patrick McGehearty via Gcc-patches
wrote:
2020-12-08 Patrick McGehearty
* gcc/c-family/c-cppbuilti
On 12/10/2020 5:35 PM, Jakub Jelinek wrote:
On Thu, Dec 10, 2020 at 10:27:46AM -0600, Patrick McGehearty via Gcc-patches
wrote:
Thank you for your rapid feedback.
I'll fix the various formatting issues (spaces in the wrong places
and such as well as revise the Changelog magic) in the
Changes in this version from Version 5:
Commit message change:
Information for Changelogs put in proper format. Thanks go to
Jakub Jelinek for enlightening me how to do that and providing
an excellent example.
c-cppbuiltin.c - Fixed various formatting issues regard
. :-)
- Patrick McGehearty (patrick.mcgehea...@oracle.com)
On 12/17/2020 9:43 PM, Patrick McGehearty via Gcc-patches wrote:
Changes in this version from Version 5:
Commit message change:
Information for Changelogs put in proper format. Thanks go to
Jakub Jelinek for enlightening me
I see your point about other floating point formats.
According to the C standard, DOUBLE precision must
have a DBL_MAX of at least 1E+37. That is (slightly)
greater than 0x1.0p+63.
Would
#define RMIN2 (0x1.0p-53)
#define RMINSCAL (0x1.0p+51)
be acceptable?
Those will be in range for any architect
s the new algorithm changes the order of
operations which does not involve the use of fused mul-add.
- Patrick McGehearty
On 6/4/2020 6:38 PM, Patrick McGehearty via Gcc-patches wrote:
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements t
Joseph,
Thank you again for your prompt and insightful response.
It's now clear that I was engaged in wishful thinking that I only needed
to handle double precision in my proposed change. I understand now that
the text above the routine:
- - - - -
#if defined(L_divhc3) || defined(L_divsc3) || def
I will study real.c carefully along with the C99 std
to determine if I can find useful values for RMIN2 and RMINSCAL
for each format which are within range for all instances
of that format. A quick skim of real.c shows we have ieee half precision
and two arm half precision formats, for example.
I
(Version 3)
(Added in version 3)
Support for half, float, extended, and long double precision has
been added to the prior work for double precision. Since half precision
is computed with float precision as per current libgcc practice,
the enhanced underflow/overflow tests provide no benefit for ha
Joseph, thank you for your detailed review and comments.
I will get to work on the necessary revisions as well
as find for a suitable place for sharing my random number
generating tests.
- patrick
On 11/16/2020 8:34 PM, Joseph Myers wrote:
On Tue, 8 Sep 2020, Patrick McGehearty via Gcc
It took some work, but I think I've responded to all the issues raised here.
Patch V5 coming right after this mail.
On 11/16/2020 8:34 PM, Joseph Myers wrote:
On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches wrote:
This project started with an investigation related to
Summary of Purpose
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements to the quality of answers
for the default complex divide routine (half, float, double, extended,
long double precisions) when dealing with very large or very small exponents.
Ping - still need review of version 4 of this patch.
It has been over a month since the last comment.
- patrick
On 9/9/2020 2:13 AM, Richard Biener wrote:
On Tue, Sep 8, 2020 at 8:50 PM Patrick McGehearty via Gcc-patches
wrote:
(Version 4)
(Added in version 4)
Fixed Changelog entry to
Ping...
On 2/22/2021 5:08 PM, Patrick McGehearty via Gcc-patches wrote:
Changes in this version from Version 7:
gcc/c-family/c-cppbuiltin.c
Changed modename to float_h_prefix
Removed (mode == TYPE_MODE...) code left over from earlier approach.
libgcc/libgcc2.c
Changes in Version 9 since Version 8:
Revised code to meet gcc coding standards in all files, especially
with respect to adding spaces around operations and removing
excess () in #define macro definitions.
Major revision to gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.c
Prior co
Thank you for your interest in this project.
On 3/27/2021 6:18 PM, Bernhard Reutner-Fischer wrote:
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
Changes in Version 9 since Version 8:
Revised code to meet gcc coding standards in all files, especially
with
s that can..."
Will make the change.
On 3/31/2021 12:03 PM, Bernhard Reutner-Fischer wrote:
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 9f993c4..c0d9e57 100644
--- a/gcc/c-
Changes in this version from Version 9:
Replaced all uses of alloca with XALLOCAVEC in
c_cpp_builtins() in c-cppbuiltin.c
Did not replace alloca elsewhere in the same file.
Fixed type of name_len.
Fixed prototypes for abort & exit in new test programs.
Fixed spelling errors and omitted words in c
coverage to most precisions, improving the computation
for accuracy and speed, and from improving the code maintainability.
- Patrick McGehearty]
On 4/7/2021 3:21 PM, Patrick McGehearty via Gcc-patches wrote:
Changes in this version from Version 9:
Replaced all uses of alloca with XALLOCAVEC in
Changes in this version from Version 10:
(thanks to Joseph Myers for catching these issues)
In gcc/c-family/c-cppbuiltin.c
Fixed three cases where XALLOCAVEC argument contained ...LIBGCC_...
but should have contained ...LIBGCC__...
These off by one errors managed to not fail previously due to the
50 matches
Mail list logo
