- - - -
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
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 speci
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
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_
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
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
that handles IBM-128 format, then where
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
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
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
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
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".
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
The new code uses the following macros which are intended to be mapped
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
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
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
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-family/c-cppbuiltin.c
+++
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
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
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 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
:
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 names suc
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
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
-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.mail
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
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
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 ((mode == TYPE_MODE
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 to see
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
. :-)
- 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
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
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 next
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-cppbuiltin.c - Add supporting macros for new
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.
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
https
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
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 8:50
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
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
(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
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
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 for half, float
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
(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
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.
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) ||
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
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
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
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
50 matches
Mail list logo
