On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> Currently, make_extraction() identifies where we can emit an ASHIFT of
> an extend in place of an extraction, but fails to make the corresponding
> canonicalization/simplification when presented with a MULT by a power of
> two. Such a r
On Thu, 22 Oct 2020, Jakub Jelinek via Gcc-patches wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
> - PR97164 - reject forming arrays with elt sizes not divisible by elt
> alignment
OK.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html
> - f
The C parts are OK.
--
Joseph S. Myers
jos...@codesourcery.com
This is OK.
--
Joseph S. Myers
jos...@codesourcery.com
On 10/22/20 3:16 PM, Andrew MacLeod via Gcc-patches wrote:
On 10/22/20 12:53 PM, Eric Botcazou wrote:
There are a few places in the ranger where we sanity check the types of
the ranges. We were using types_compatible_p() but thats not really
acccurate as gimple allows types which are useless_ty
On 10/15/20 6:18 PM, Marek Polacek wrote:
The code added in r10-6437 caused us to create a CONSTRUCTOR when we're
{}-initializing an aggregate. Then we pass this new CONSTRUCTOR down to
cxx_eval_constant_expression which, if the CONSTRUCTOR isn't TREE_CONSTANT
or reduced_constant_expression_p, c
PowerPC: Map IEEE 128-bit long double built-in functions
This patch is revised from the first and second versions of the patch posted.
It now uses the names that are not in the user's namespace (i.e. __sinieee128
instead of sinf128) that Joseph Myers suggested.
In addition, I added the changes su
PowerPC: Add -mno-gnu-attributes to ibm-ldouble.o.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch is split off from the patch adding __float128 <-> Decimal
conversions. This patch is needed to prevent the linker from issuing a
warning when
PowerPC: Add __float128 conversions to/from Decimal.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch adds the various decimal to/from IEEE 128-bit conversions. I
had to make some changes to the infrastructure, since that infrastructure
assu
PowerPC: Update long double IEEE 128-bit tests.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch fixes 3 tests in the testsuite that fail if long double is set
to IEEE 128-bit.
I have tested this patch with bootstrap builds on a little endia
PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
I have split all of these patches into separate patches to hopefully get them
into the tree.
If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support. This
> Sorry for missing the regression.. it was there, it just snuck by me in
> the noise :-P
>
> THis seems to resolve the issue on my end, and its the right thing.
>
> Bootstrapped on x86_64-pc-linux-gnu, no regressions, for SURE this time,
> pushed.
No problem, thanks for the quick turnaround!
-
PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
instead of __builtin_pack_longdouble if long double is IEEE 128-b
PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch adds long double variants of the power10 __float128 built-in
functions. This is needed when long double uses IEEE 128-bi
PowerPC: Update __float128 and __ibm128 error messages.
I have split all of these patches into separate patches to hopefully get them
into the tree.
This patch attempts to make the error messages for intermixing IEEE 128-bit
floating point with IBM 128-bit extended double types to be clearer if t
PowerPC: Use __float128 instead of __ieee128 in tests.
I have split all of these patches into separate patches to hopefully get them
into the tree.
Two of the tests used the __ieee128 keyword instead of __float128. This
patch changes those cases to use the official keyword.
I have tested this p
PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.
This is a new patch. It turns off the warning about switching the long double
type via compile line if the GLIBC is 2.32 or newer. It only does this if the
languages are C or C++, since those language libraries support switching the
This test fails in C++20 mode because std::is_clock is false for the
test clock, because it doesn't define a duration member.
libstdc++-v3/ChangeLog:
* testsuite/30_threads/condition_variable/members/68519.cc:
Define recent_epoch_float_clock::duration to meet the Cpp17Clock
On Linux/x86_64,
f5d9bc8ae81abe46640477bc9e655aa093947f5f is the first bad commit
commit f5d9bc8ae81abe46640477bc9e655aa093947f5f
Author: Jonathan Wakely
Date: Thu Oct 22 18:42:03 2020 +0100
libstdc++: Only include in if needed
caused
FAIL: 20_util/polymorphic_allocator/construct_pair.
On Wed, 21 Oct 2020, Iain Sandoe wrote:
> Arnaud Charlet wrote:
>
> > > This patch breaks bootstrap on Darwin platforms.
> > >
> > > Pierre-Marie de Rodat wrote:
> > >
> > > > The modification file time precision now defined by OS.
> > > >
> > > > Tested on x86_64-pc-linux-gnu, committed on trun
On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > OK, looks like VSX_MM_SUFFIX doesn't exist anymore. Don't know what
> > happed to it. Thanks.
>
> It never existed on trunk. Please always regstrap patches on tru
On Thu, Oct 22, 2020 at 09:08:58AM -0700, Carl Love wrote:
> I see the error print statement you changed so that it would not wrap.
> I have always been told it is best not to break the print statement
> across two lines. The argument is it makes it harder to find it in the
> code when using grep
On 22/10/20 18:59 +0100, Jonathan Wakely wrote:
By moving std::make_obj_using_allocator and the related "utility
functions for uses-allocator construction" to a new header, we can avoid
including the whole of in and
.
In order to simplify the implementation of those utility functions they
now
On 10/22/20 11:30 AM, Alexandre Oliva wrote:
On Oct 22, 2020, Jonathan Yong wrote:
No objections for mingw-w64 since it has been tested, but I'm not
certain if the original mingw.org version has it.
Prompted by you, I looked into the original mingw32, and found it does
NOT have sincos, so I w
On Thu, Oct 22, 2020 at 11:25:09PM +1030, Alan Modra wrote:
> Some of these are wrong, sorry. I need to go over and check them
> thoroughly. Please consider the patch withdrawn.
Revised patch, removing changes to
gcc.target/powerpc/fold-vec-st-double.c,
gcc.target/powerpc/fold-vec-st-longlong.c,
gcc.target/powerpc/fold-vec-st-pixel.c and other testcases fail on
power10, generating
addi 9,5,12
rldicr 9,9,0,59
stxv 34,0(9)
rather than
addi 5,5,12
stvx 2,0,5
for an altivec lvx/stvx style address.
The problem starts with fwprop creating
(insn 9 4 0 2 (s
101 - 126 of 126 matches
Mail list logo
