Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
* Michael Meissner via Gcc-patches:
> On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
>> This change appears to have broken builds for powerpc in a configuration
>> that bootstraps a cross toolchain starting with a GCC build with no libc
>> available.
>>
>> Specifically, such a bootstrap build uses --disable-decimal-float among
>> other options (in the first GCC build before libc has been built), to
>> disable GCC target library code that has any dependence on libc or libc
>> headers - dfp-bit.c uses libc headers, without an inhibit_libc
>> conditional, so cannot be used in such a bootstrap configuration. Most of
>> the DFP code in libgcc is disabled by --disable-decimal-float, but it
>> seems the new conversions are not. This results in errors of the form:
>>
>> In file included from
>> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/rs6000/_kf_to_sd.c:37:
>> /scratch/jmyers/glibc-bot/src/gcc/libgcc/dfp-bit.c:32:10: fatal error:
>> stdio.h: No such file or directory
>>32 | #include
>> | ^
>> compilation terminated.
>>
>> The appropriate fix is not to build any of these new conversions in the
>> --disable-decimal-float case. (That clearly makes sense anyway, even in
>> the absence of the bootstrap issue.)
>>
>> https://sourceware.org/pipermail/libc-testresults/2021q1/007576.html
>
> Thanks. I agree if --disable-decimal-float is used we should not build the
> conversions. And we want to eliminate the stdio.h dependency. I will look at
> it unless somebody has already fixed it.
This issue is still present.
What about the patch below?
Thanks,
Florian
rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
between _Float128 and Decimal.).
libgcc/
* config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
point functions for $(decimal_float) only.
diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 6fb1a3d871b..b1f00accdf1 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -37,8 +37,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
# New functions for software emulation
fp128_ppc_funcs= floattikf floatuntikf fixkfti fixunskfti \
extendkftf2-sw trunctfkf2-sw \
- sfp-exceptions _mulkc3 _divkc3 _powikf2 \
- $(fp128_dec_funcs) $(fp128_decstr_funcs)
+ sfp-exceptions _mulkc3 _divkc3 _powikf2
+
+ifeq ($(decimal_float),yes)
+fp128_ppc_funcs+= $(fp128_dec_funcs) $(fp128_decstr_funcs)
+endif
fp128_ppc_src = $(addprefix $(srcdir)/config/rs6000/,$(addsuffix \
.c,$(fp128_ppc_funcs)))
Re: [PATCH] rs6000: Enable 32bit variable vec_insert [PR99718]
On Fri, Mar 26, 2021 at 11:27 PM Xionghu Luo wrote:
>
> From: "luo...@cn.ibm.com"
>
> 32bit and P7 VSX could also benefit a lot from the variable vec_insert
> implementation with shift/insert/shift back method.
>
> Tested pass on P7BE/P8BE/P8LE{-m32,m64} and P9LE{m64}.
I successfully bootstrapped and tested on AIX 7.2.3.0.
Thanks, David
Re: improve future::poll calibration loop
On 26/03/21 02:50 -0300, Alexandre Oliva wrote:
The calibration loop I've recently added to the libstdc++
future/members/poll.cc tests could still select iteration counts that
might yield zero-time measurements for the wait_for when ready loop.
Waiting for a future that has already had a value set is presumably
uniformly faster than a zero-timed wait for a result,
On trunk and gcc-10 branch yes, but not in any released version.
so I've changed
the calibration loop to use the former.
We might still be unlucky and get nonzero from the initial loop, so
that the calibration is skipped altogether, but then get zero from the
later when-ready loop. I'm not dealing with this case in this patch.
In gcc-10 testing, I also had to bump up some multipliers from 100 to
150, but IIUC there have been changes for GCC 11 that will hopefully
render those unnecessary, so I'm leaving them out.
Yes, the relative performance of different future ops are quite
different on trunk.
Regstrapped on x86_64-linux-gnu and cross-tested for x86_64-vx7r2 along
with other patches, mostly for the testsuite. Ok to install?
OK, thanks.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/future/members/poll.cc: Use faster
after-ready call in the calibration loop.
---
.../testsuite/30_threads/future/members/poll.cc|8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
index 133dae15ac471..4c846d0b7baf5 100644
--- a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
+++ b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
@@ -55,6 +55,12 @@ int main()
Attempt to calibrate it. */
if (start == stop)
{
+ /* After set_value, wait_for is faster, so use that for the
+calibration to avoid zero at low clock resultions. */
+ promise pc;
+ future fc = pc.get_future();
+ pc.set_value(1);
+
/* Loop until the clock advances, so that start is right after a
time increment. */
do
@@ -65,7 +71,7 @@ int main()
after another time increment. */
do
{
- f.wait_for(chrono::seconds(0));
+ fc.wait_for(chrono::seconds(0));
stop = chrono::high_resolution_clock::now();
i++;
}
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
[PATCH] fold-const: Fix ICE in extract_muldiv_1 [PR99777]
Hi!
extract_muldiv{,_1} is apparently only prepared to handle scalar integer
operations, the callers ensure it by only calling it if the divisor or
one of the multiplicands is INTEGER_CST and because neither multiplication
nor division nor modulo are really supported e.g. for pointer types, nullptr
type etc. But the CASE_CONVERT handling doesn't really check if it isn't
a cast from some other type kind, so on the testcase we end up trying to
build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
TYPE_PRECISION which means something completely different for vector types,
etc.
So IMNSHO we should just punt on conversions from non-integrals or
non-scalar integrals.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2021-03-26 Jakub Jelinek
PR tree-optimization/99777
* fold-const.c (extract_muldiv_1): For conversions, punt on casts from
types other than scalar integral types.
* g++.dg/torture/pr99777.C: New test.
--- gcc/fold-const.c.jj 2021-03-25 13:41:55.0 +0100
+++ gcc/fold-const.c2021-03-26 11:51:57.901091895 +0100
@@ -6713,6 +6713,8 @@ extract_muldiv_1 (tree t, tree c, enum t
break;
CASE_CONVERT: case NON_LVALUE_EXPR:
+ if (!INTEGRAL_TYPE_P (TREE_TYPE (op0)))
+ break;
/* If op0 is an expression ... */
if ((COMPARISON_CLASS_P (op0)
|| UNARY_CLASS_P (op0)
@@ -6721,8 +6723,7 @@ extract_muldiv_1 (tree t, tree c, enum t
|| EXPRESSION_CLASS_P (op0))
/* ... and has wrapping overflow, and its type is smaller
than ctype, then we cannot pass through as widening. */
- && (((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
- && TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0)))
+ && ((TYPE_OVERFLOW_WRAPS (TREE_TYPE (op0))
&& (TYPE_PRECISION (ctype)
> TYPE_PRECISION (TREE_TYPE (op0
/* ... or this is a truncation (t is narrower than op0),
@@ -6737,8 +6738,7 @@ extract_muldiv_1 (tree t, tree c, enum t
/* ... or has undefined overflow while the converted to
type has not, we cannot do the operation in the inner type
as that would introduce undefined overflow. */
- || ((ANY_INTEGRAL_TYPE_P (TREE_TYPE (op0))
- && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0)))
+ || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0))
&& !TYPE_OVERFLOW_UNDEFINED (type
break;
--- gcc/testsuite/g++.dg/torture/pr99777.C.jj 2021-03-26 12:22:49.833560450
+0100
+++ gcc/testsuite/g++.dg/torture/pr99777.C 2021-03-26 12:22:37.927692142
+0100
@@ -0,0 +1,44 @@
+// PR tree-optimization/99777
+
+template
+inline const T &
+min (const T &a, const T &b)
+{
+ if (b < a)
+return b;
+ return a;
+}
+
+template
+inline const T &
+max (const T &a, const T &b)
+{
+ if (a < b)
+return b;
+ return a;
+}
+
+extern int o, a, c;
+long h;
+unsigned long long e;
+signed char d;
+extern short p[][7][5][30];
+
+void
+test (long long b, short f[][17][25][22][20])
+{
+ for (char i = 0; i < 7; i += 3)
+for (unsigned char l = e; l < 5; l += 2)
+ {
+ if (max (0LL, min (7LL, b)))
+ for (bool j = 0; j < 1; j = b)
+ {
+ for (unsigned k = d; k < 20; k++)
+ h = f[0][i][l][b][k];
+ for (int m = 0; m < 5; m++)
+ p[c][i][l][m] = 0;
+ }
+ for (int n = 0; n < 4; n += a)
+ o = n;
+ }
+}
Jakub
Re: [PATCH] Fix _GLIBCXX_DEBUG container allocator aware move constructors
On 26/03/21 21:41 +0100, François Dumont via Libstdc++ wrote: I review the allocator aware move constructors of _GLIBCXX_DEBUG containers. I think the recently added __gnu_debug basic_string one is also missing the rvalue reference, no ? You mean is_nothrow_constructible instead of is_nothrow_constructible? No, it's not missing. They mean the exact same thing: Base is an rvalue, Base&& is an rvalue, and Base& is an lvalue. Writing Base&& instead of Base is just extra noise that adds no value. libstdc++: _GLIBCXX_DEBUG Fix allocator aware move constructor The correct term is "allocator-extended move constructor". And is it really a "fix"? The standard doesn't require a noexcept-specifier on those constructors, so what we have now is not incorrect, just suboptimal. Fix several allocator aware move construtor in _GLIBCXX_DEBUG containers. libstdc++-v3/ChangeLog: * include/debug/forward_list (forward_list(forward_list&&, const allocator_type&)): Add noexcept qualification. * include/debug/list (list(list&&, const allocator_type&)): Likewise and add call to safe container allocator aware move constructor. * include/debug/string (basic_string(basic_string&&, const _Allocator&)): Check base type allocator aware more constructor. * include/debug/vector (vector(vector&&, const allocator_type&)): Fix noexcept qualification. * testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc: Add allocator aware move constructor noexceot qualification check. * testsuite/23_containers/list/cons/noexcept_move_construct.cc: Likewise. Tested under linux x86_64. Ok to commit ? OK, thanks.
Re: off-by-one buffer overflow patch
Pushed: To git+ssh://gcc.gnu.org/git/gcc.git 651684b462f..01685676a93 master -> master Author: Steve Kargl Date: Sat Mar 27 15:02:16 2021 -0700 fortran: Fix off-by-one in buffer sizes. gcc/fortran/ChangeLog: * misc.c (gfc_typename): Fix off-by-one in buffer sizes. Regards, Jerry On 3/27/21 6:28 AM, dhumieres.domini...@free.fr wrote: Le 2021-03-27 06:36, Jerry DeLisle a écrit : On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998. Do you need help to do a commit? Jerry I was too quick and did not realize that I did not post the actual patch I have in my working tree, but the Steve's one does the trick. And yes I need help to do a commit. Thanks Dominique
Re: [PATCH v9] Practical improvement to libgcc complex divide
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 respect to adding spaces around operations and removing > excess () in #define macro definitions. Did you gather cycle counter diffs for current against new for the normal and some edge cases? Can you please share data for -Os between current and your proposed new? TIA,
Re: off-by-one buffer overflow patch
On Sat, Mar 27, 2021 at 03:11:05PM -0700, Jerry DeLisle wrote: > Pushed: > > To git+ssh://gcc.gnu.org/git/gcc.git > 651684b462f..01685676a93 master -> master > > Author: Steve Kargl > Date: Sat Mar 27 15:02:16 2021 -0700 > > fortran: Fix off-by-one in buffer sizes. > > gcc/fortran/ChangeLog: > > * misc.c (gfc_typename): Fix off-by-one in buffer sizes. > > Regards, > > Jerry Thanks for committing the patch. -- steve
