Hi,
I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and
GCC12 (on the same X86 machine)
For gcc11:
wide int max elts =3
For gcc12:
wide int max elts =9
Does anyone know what’s the reason for this difference?
Thanks a lot for any help.
Qing
For posterity: This was discussed briefly on IRC, and Segher approved with
some
simplifications and a request to implement a fail/retry check.
Thanks,
Bill
On 11/3/21 10:02 AM, Jonathan Wakely wrote:
> On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER
> maintainers a
For at least one target (Darwin) the platform convention is to
register static destructors (i.e. __attribute__((destructor)))
with __cxa_atexit rather than placing them into a list that is
run by some other mechanism.
This patch provides a target hook that allows a target to opt
into this and hand
On Wed, 3 Nov 2021 at 00:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> These functions have been deprecated since C++11, and were removed in
> C++17. The proposal P0323 wants to reuse the name std::unexpected for a
> class template, so we will need to stop defining the curren
On Thu, 4 Nov 2021, Jeff Law wrote:
> On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
> > Correct a `vax-netbsdelf' target regression ultimately caused by commit
> > c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> > LRA) and as of commit 4a960d548b7d ("Avoid invalid loop tr
On Linux/x86_64,
d70720c2382e687e192a9d666e80acb41bfda856 is the first bad commit
commit d70720c2382e687e192a9d666e80acb41bfda856
Author: Tamar Christina
Date: Thu Nov 4 17:32:09 2021 +
middle-end: convert negate + right shift into compare greater.
caused
FAIL: gcc.dg/signbit-2.c sca
Tested x86_64-linux, committed to trunk. Backport to gcc-11 to follow,
and maybe to other branches too.
Since std::tuple started using [[no_unique_address]] the tuple
member of std::unique_ptr has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:
This patch aims to fix PR 55227; two underlying bugs that have caused:
(1) Rejection of valid designated initialization of char array fields by
string literals (a) when enclosed in optional braces or (b) unbraced
when the string literal is shorter than the target char array field.
(2) Acceptance
On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely wrote:
>
>
> On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> From: yfeldblum
>>
>> The stdout stream is reserved for output intentionally produced by the
>> application. Assertion failures and other form
On 11/4/2021 3:04 PM, Maciej W. Rozycki wrote:
On Thu, 4 Nov 2021, Jeff Law wrote:
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of com
On Thu, 4 Nov 2021, Jeff Law wrote:
> Sometimes the language we're using in email is not as crisp as it should be.
> So
> just to be clear, the canonicalization I'm referring to is only in effect
> within
> a MEM. It does not apply to address calculations that happen outside a MEM.
> I
> thi
On 10/31/21 8:13 AM, Daniil Stas wrote:
On Sun, 10 Oct 2021 23:10:20 +
Daniil Stas wrote:
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-int-precision to disable emitting
warnings when passing an argument of an incompatible integer type to
On 2021/11/4 09:59, David Edelsohn wrote:
> On Wed, Nov 3, 2021 at 9:46 PM Xionghu Luo wrote:
>>
>> On 2021/11/3 23:13, David Edelsohn wrote:
>>> Did you manually change fusion.md or did you regenerate it after
>>> fixing genfusion.pl?
>>>
>>> If you regenerated it, the ChangeLog entry should b
On Thu, Nov 4, 2021 at 8:50 PM Xionghu Luo wrote:
> [PATCH] rs6000: Fix incorrect fusion constraint [PR102991]
>
> gcc/ChangeLog:
>
> * config/rs6000/fusion.md: Regenerate.
> * config/rs6000/genfusion.pl: Fix incorrect clobber constraint.
Okay.
Thanks, David
Hi Qing,
on 2021/11/5 上午4:37, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know what
> Note that this is not safe with -fsignaling-nans, so needs to be disabled
> for that option (if there isn't already logic somewhere with that effect),
> because the extend will convert a signaling NaN to quiet (raising
> "invalid"), but copysign won't, so this transformation could result in a
> s
This is an expanded version of the patch for PR 101337 that Bernhard
sent out a few days ago with a request for me to finish it. Bernhard
did the part for operands and I added the pieces for procedure arguments
and intrinsics, along with fixing up the test cases that were previously
full of xf
These patches are a refinement of the patches to add XXSPLTIDP support on
September 13th. These patches generate instructions that load up a VSX
register with certain constants instead of using PLXV to load the constant.
On the Power10:
* XXSPLTIDP is a prefixed instruction that takes a value e
Add new constant data structure.
This patch provides the data structure and function to convert a
CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a constant) to
an array of bytes, half-words, words, and double words that can be loaded
into a 128-bit vector register.
The next patches w
Add LXVKQ support.
This patch adds support to generate the LXVKQ instruction to load specific
IEEE-128 floating point constants.
Compared to the last time I submitted this patch, I modified it so that it
uses the bit pattern of the vector to see if it can generate the LXVKQ
instruction. This mea
Generate XXSPLTIW on power10.
This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
instruction for V8HImode, V4SImode, and V4SFmode vectors. It does this by
adding support for vector constants that can be used, and adding a
VEC_DUPLICATE pattern to generate the actual XXSPLTIW i
Generate XXSPLTIDP for vectors on power10.
This patch implements XXSPLTIDP support for all vector constants. The
XXSPLTIDP instruction is given a 32-bit immediate that is converted to a vector
of two DFmode constants. The immediate is in SFmode format, so only constants
that fit as SFmode values
Generate XXSPLTIDP for scalars on power10.
This patch implements XXSPLTIDP support for SF, and DF scalar constants.
The previous patch added support for vector constants. This patch adds
the support for SFmode and DFmode scalar constants.
I added 2 new tests to test loading up SF and DF scalar c
a and b are same type as trunc type and has less precision than
extend type, the transformation is guarded by flag_finite_math_only.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify (trunc)fmax/fmin((ex
a, b, c are same type as truncation type and has less precision than
extend type, the optimization is guarded under
flag_unsafe_math_optimizations.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
On Thu, Nov 4, 2021 at 1:38 PM Qing Zhao via Gcc-patches
wrote:
>
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know what’s
On 2021/11/5 08:58, David Edelsohn wrote:
> On Thu, Nov 4, 2021 at 8:50 PM Xionghu Luo wrote:
>
>> [PATCH] rs6000: Fix incorrect fusion constraint [PR102991]
>>
>> gcc/ChangeLog:
>>
>> * config/rs6000/fusion.md: Regenerate.
>> * config/rs6000/genfusion.pl: Fix incorrect clobber
On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches wrote:
> > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> > and GCC12 (on the same X86 machine)
> >
> > For gcc11:
> >
> > wide int max elts =3
> >
> > For gcc12:
> >
> > wide int max elts =9
> >
On Thu, 4 Nov 2021, Martin Jambor wrote:
> Hi,
>
> On Wed, Nov 03 2021, Richard Biener wrote:
> > On Mon, 1 Nov 2021, Martin Jambor wrote:
> >
> >> Hello,
> >>
> >> I'd like to ping this patch.
> >>
> >> Thanks,
> >>
> >> Martin
> >>
> >>
> >> On Wed, Oct 13 2021, Martin Jambor wrote:
> >> >
101 - 129 of 129 matches
Mail list logo
