On Wed, Jul 31, 2024 at 1:06 AM Uros Bizjak wrote:
>
> On Tue, Jul 30, 2024 at 3:00 PM Richard Biener wrote:
> >
> > On Tue, 30 Jul 2024, Alexander Monakov wrote:
> >
> > >
> > > On Tue, 30 Jul 2024, Richard Biener wrote:
> > >
> > > > > Oh, and please add a small comment why we don't use XFmode
On Wed, Jul 31, 2024 at 9:11 AM Hongtao Liu wrote:
>
> On Wed, Jul 31, 2024 at 1:06 AM Uros Bizjak wrote:
> >
> > On Tue, Jul 30, 2024 at 3:00 PM Richard Biener wrote:
> > >
> > > On Tue, 30 Jul 2024, Alexander Monakov wrote:
> > >
> > > >
> > > > On Tue, 30 Jul 2024, Richard Biener wrote:
> > >
On Tue, Jul 30, 2024 at 5:43 PM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Host systems with only MMX and no SSE2 should be really rare now.
> Let's remove the MMX code path to keep the number of custom
> implementations the same.
>
> The SSE2 code path is also somewhat dubious now (nearly everyt
On Tue, Jul 30, 2024 at 7:05 PM Jakub Jelinek wrote:
>
> Hi!
>
> C23 added in N2956 ( https://open-std.org/JTC1/SC22/WG14/www/docs/n2956.htm )
> two new attributes, which are described as similar to GCC const and pure
> attributes, but they aren't really same and it seems that even the paper
> is
Hi Claudio,
> On 31 Jul 2024, at 08:29, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> This introduces the relevant flags to enable access to the fpmr register and
> fp8 intrinsics, which will be added subsequently.
>
> gcc/ChangeLog:
>
>
Hi Claudio,
> On 31 Jul 2024, at 08:29, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Unlike most system registers, fpmr can be heavily written to in code that
> exercises the fp8 functionality. That is because every fp8 instrinsic call
> can
Hi Claudio,
> On 31 Jul 2024, at 08:29, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> The ACLE declares several helper types and functions to facilitate
> construction
> of `fpm` arguments. These are available when one of the arm_neon.h, arm_
On Wed, Jul 31, 2024 at 3:17 PM Uros Bizjak wrote:
>
> On Wed, Jul 31, 2024 at 9:11 AM Hongtao Liu wrote:
> >
> > On Wed, Jul 31, 2024 at 1:06 AM Uros Bizjak wrote:
> > >
> > > On Tue, Jul 30, 2024 at 3:00 PM Richard Biener wrote:
> > > >
> > > > On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
On Tue, Jul 30, 2024 at 07:51:34PM -0400, Jason Merrill wrote:
> Yeah.
>
> In the paper a fold expanded constraint doesn't have a parameter mapping,
> only atomic constraints do. Within the normal form of (__is_same (T, int)
> && ...) we have a single atomic constraint with parameter mapping T ->
On Wed, Jul 31, 2024 at 10:02 AM Hongtao Liu wrote:
> > > > > > On Tue, 30 Jul 2024, Richard Biener wrote:
> > > > > >
> > > > > > > > Oh, and please add a small comment why we don't use XFmode here.
> > > > > > >
> > > > > > > Will do.
> > > > > > >
> > > > > > > /* Do not enable XFmode,
This patch adds a new compiler pass aimed at identifying naive CRC
implementations,
characterized by the presence of a loop calculating a CRC (polynomial long
division).
Upon detection of a potential CRC, the pass prints an informational
message.
Performs CRC optimization if optimization level
On Wed, Jul 31, 2024 at 09:50:56AM +0200, Richard Biener wrote:
> I wonder if
>
> int foo (uintrptr_t x) { *(int *)x = 1; return 1; }
>
> is considered "noptr" by the standard but then by making a pointer out of
> 'x' invokes UB?
I don't know. The paper claims same behavior as const for functio
Paul Koning writes:
>> On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
>>
>> The following adds a target hook to specify whether regs of MODE can be
>> used to transfer bits. The hook is supposed to be used for value-numbering
>> to decide whether a value loaded in such mode can be punned to
On Tue, Jul 30, 2024 at 1:05 PM Hongyu Wang wrote:
>
> Richard Biener 于2024年7月26日周五 19:45写道：
> >
> > On Fri, Jul 26, 2024 at 10:50 AM Hongyu Wang wrote:
> > >
> > > Hi,
> > >
> > > When introducing munroll-only-small-loops, the option was marked as
> > > Target Save and added to -O2 default whic
On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> OK. Richard, can you please mention the above in the comment why
> XFmode is rejected in the hook?
>
> Later, we can perhaps benchmark XFmode move vs. generic memory copy to
> get some hard data.
My (limited) understanding was that th
On Tue, Jul 30, 2024 at 7:33 PM Tobias Burnus wrote:
>
> Richard Biener wrote:
> > On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
> >> Inside pass_omp_target_link::execute, there is a call to
> >> gimple_regimplify_operands but the value expression is not
> >> expanded.[...]
> >>
> >> Where
On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
>
> On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > OK. Richard, can you please mention the above in the comment why
> > XFmode is rejected in the hook?
> >
> > Later, we can perhaps benchmark XFmode move vs. generic memory cop
On Tue, Jul 30, 2024 at 10:24 PM Jeff Law wrote:
>
>
> This fixes a testsuite regression seen on m68k after some of the recent
> ext-dce changes. Ultimately Richard S and I have concluded the bug was
> a latent issue in subreg simplification.
>
> Essentially when simplifying something like
>
> (s
On Wed, Jul 31, 2024 at 6:32 AM liuhongt wrote:
>
> Ok for trunk?
OK for www.
Richard.
> ---
> htdocs/gcc-14/changes.html| 7 +++
> htdocs/gcc-14/porting_to.html | 9 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> >
> > On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > > OK. Richard, can you please mention the above in the comment why
> > > XFmode is rejected in the hook?
> > >
> > > Later, we c
"Robin Dapp" writes:
>> > IMO, what ought to happen here is that the RA should spill
>> > the inner register to memory and load the V4SI back from there.
>> > (Or vice versa, for an lvalue.) Obviously that's not very efficient,
>> > and so a patch like the above might be useful as an optimisation
On Wed, Jul 31, 2024 at 10:19:06AM +0200, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 09:50:56AM +0200, Richard Biener wrote:
> > I wonder if
> >
> > int foo (uintrptr_t x) { *(int *)x = 1; return 1; }
> >
> > is considered "noptr" by the standard but then by making a pointer out of
> > 'x' in
在 2024/7/29 下午3:58, Xi Ruoyao 写道:
Per a gcc-help thread we are generating sub-optimal code for
__builtin_bswap{32,64}. To fix it:
- Use a single revb.d instruction for bswapdi2.
- Use a single revb.2w instruction for bswapsi2 for TARGET_64BIT,
revb.2h + rotri.w for !TARGET_64BIT.
- Use a s
When we gimplify &MEM[0B + 4] we are re-folding the address in case
types are not canonical which ends up with a constant address that
recompute_tree_invariant_for_addr_expr ICEs on. Properly guard
that call.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/1014
Hi,
Different from p9vector_hw, vmx_hw/vsx_hw/p8vector_hw checks
can still succeed without Altivec/VSX feature support. We
have many runnable test cases only checking for these *_hw
without extra checking for if Altivec/VSX feature enabled or
not. It means they can fail if being tested by explic
Hi,
Checking the existing powerpc_{altivec,vsx}_ok test cases,
I found there are some test cases which don't require the
checks powerpc_{altivec,vsx} even, some of them already
have other effective target check which can cover check
powerpc_{altivec,vsx}, or some of them don't actually
require VSX
Hi,
Following up the previous r15-886, this patch to clean up
the remaining powerpc_vsx_ok which actually should use
powerpc_vsx instead.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this next week if no objections.
BR,
Kewen
--
Hi,
When cleaning up the remaining powerpc_{vsx,altivec}_ok test
cases, I found some dg-do run test cases which should check
for the appropriate {p8vector,vmx}_hw check instead. This
patch is to adjust them accordingly.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linu
Hi,
This is a follow up patch for the previous patch adjusting
powerpc_vsx_ok with powerpc_vsx, focusing on those test cases
which don't really require VSX feature but used powerpc_vsx_ok
before, they actually require some other effective target check,
like some of them just require ALTIVEC featur
Hi,
When cleaning up the remaining powerpc_{vsx,altivec}_ok test
cases, I found some issues are related to pr78056-*.c.
Firstly, the test points of pr78056-[246].c are no longer
available since r9-3164 drops many HAVE_AS_* and the expected
warning are dropped together, so this patch is to remove t
Hi Haochen,
on 2024/7/25 11:34, HAO CHEN GUI wrote:
> Hi,
> This patch add const_vector into any_operand predicate. From my
> understanding, any_operand should include all kinds of operands.
> The const_vector should be included. As emit_move_insn doesn't check
> the predicate, the const_vector
Hi Carl,
on 2024/7/27 06:56, Carl Love wrote:
> GCC maintainers:
>
> Per a report from a user, the existing vec_test_lsbb_all_ones and,
> vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation
> file.
>
> The following patch adds missing documentation for the vec_test_ls
> > Like aarch64 we set REGMODE_NATURAL_SIZE for fixed-size modes to
> > UNITS_PER_WORD. Isn't that part of the problem?
> >
> > In extract_bit_field_as_subreg we check lowpart_bit_field_p (= true because
> > 128 is a multiple of UNITS_PER_WORD). This leads to the subreg expression.
> >
> > If I
On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
>
> On Wed, 31 Jul 2024, Uros Bizjak wrote:
>
> > On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> > >
> > > On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > > > OK. Richard, can you please mention the above in the comm
Hi,
As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
was designed for little-endian, the recent commit r15-2403 made it
be tested with running on BE and PR116148 got exposed.
This patch is to adjust the expected data for members in with_fam_2_v
and with_fam_3_v by considering e
On Tue, 30 Jul 2024, Paul Koning wrote:
>
>
> > On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
> >
> > The following adds a target hook to specify whether regs of MODE can be
> > used to transfer bits. The hook is supposed to be used for value-numbering
> > to decide whether a value loade
Hi Christophe,
Thanks for the comments, attached new version for testcase, see below
new cover letter:
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
This dec_insn is the instruction th
On 31/07/2024 08:57, Kyrylo Tkachov wrote:
> Hi Claudio,
>
>> On 31 Jul 2024, at 08:29, Claudio Bantaloukas
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Unlike most system registers, fpmr can be heavily written to in code that
>> exercises the fp8 functiona
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
> >
> > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> >
> > > On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Jul 31, 2024 at 10:11:44AM +0200, Uros Bizjak wrote:
> > > > >
> On 31 Jul 2024, at 11:31, Claudio Bantaloukas
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 31/07/2024 08:57, Kyrylo Tkachov wrote:
>> Hi Claudio,
>>
>>> On 31 Jul 2024, at 08:29, Claudio Bantaloukas
>>> wrote:
>>>
>>> External email: Use caution openin
32bit x86 CPUs won't natively support the FFS operation on a 64 bit
type. Therefore, the switch-exp-transform-3.c test will always fail
with a 32bit target. I'm fixing my mistake.
gcc/testsuite/ChangeLog:
* gcc.target/i386/switch-exp-transform-3.c: Remove code testing
that the
On Wed, Jul 31, 2024 at 12:02:08PM +0200, Filip Kastl wrote:
> 32bit x86 CPUs won't natively support the FFS operation on a 64 bit
> type. Therefore, the switch-exp-transform-3.c test will always fail
> with a 32bit target. I'm fixing my mistake.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.tar
On Wed, 2024-07-31 at 16:57 +0800, Lulu Cheng wrote:
>
> 在 2024/7/29 下午3:58, Xi Ruoyao 写道:
> > Per a gcc-help thread we are generating sub-optimal code for
> > __builtin_bswap{32,64}. To fix it:
> >
> > - Use a single revb.d instruction for bswapdi2.
> > - Use a single revb.2w instruction for bs
On Wed, Jul 31, 2024 at 11:33 AM Richard Biener wrote:
>
> On Wed, 31 Jul 2024, Uros Bizjak wrote:
>
> > On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
> > >
> > > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> > >
> > > > On Wed, Jul 31, 2024 at 10:24 AM Jakub Jelinek wrote:
> > > > >
> > >
Gives an opportunity to execute the code on bit level,
assigning symbolic values to the variables which don't have initial
values.
Supports only CRC specific operations.
Example:
uint8_t crc;
uint8_t pol = 1;
crc = crc ^ pol;
during symbolic execution crc's value will be
"Kewen.Lin" writes:
> Hi,
>
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r15-2403 made it
> be tested with running on BE and PR116148 got exposed.
>
> This patch is to adjust the expected data for members in with_fam_2_v
Tested on x86_64-pc-linux-gnu. OK for trunk?
TIA, have a lovely day.
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the following:
awaitable g();
template
task f()
{
co_await g();
co_yield 1;
co_return "fo
Hi Richard, hi all,
Richard Biener wrote:
Looking at pass_omp_target_link::execute I wonder iff find_link_var_op
shouldn't simply do the substitution? Aka
This seems to work ...
--- a/gcc/omp-offload.cc
+++ b/gcc/omp-offload.cc
@@ -2893,6 +2893,7 @@ find_link_var_op (tree *tp, int *walk_sub
On Wed 2024-07-31 12:18:34, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 12:02:08PM +0200, Filip Kastl wrote:
> > 32bit x86 CPUs won't natively support the FFS operation on a 64 bit
> > type. Therefore, the switch-exp-transform-3.c test will always fail
> > with a 32bit target. I'm fixing my mi
On Wed, Jul 31, 2024 at 01:32:06PM +0200, Filip Kastl wrote:
> Thanks for the feedback! Here is a second version of the patch. I've tested
> this version with
>
> make check RUNTESTFLAGS="i386.exp=gcc.target/i386/switch-exp-transform-3.c
> --target_board='unix{-m32}'"
>
> and
>
> make check R
On Wed 2024-07-31 13:34:28, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 01:32:06PM +0200, Filip Kastl wrote:
> > Thanks for the feedback! Here is a second version of the patch. I've
> > tested
> > this version with
> >
> > make check RUNTESTFLAGS="i386.exp=gcc.target/i386/switch-exp-transfor
On Tue, Jul 30, 2024 at 5:25 PM Andrew Pinski wrote:
>
> The problem here is that in generic types of comparisons don't need
> to be boolean types (or vector boolean types). And fixes that by making
> sure the types of the conditions match before doing the optimization.
>
> Bootstrapped and tested
On Tue, Jul 30, 2024 at 5:26 PM Andrew Pinski wrote:
>
> When this pattern was converted from being only dealing with 0/-1, we missed
> that if `e == f` is true
> then the optimization is wrong and needs an extra check for that.
>
> This changes the patterns to be:
> /* (a ? x : y) != (b ? x : y)
Andrew Pinski writes:
> When this pattern was converted from being only dealing with 0/-1, we missed
> that if `e == f` is true
> then the optimization is wrong and needs an extra check for that.
>
> This changes the patterns to be:
> /* (a ? x : y) != (b ? x : y) --> (a^b & (x != y)) ? TRUE :
Thanks for the feedback! I updated the patch based on your comments, more
detailed comments inline below. The updated version was bootstrapped and tested
again, no regression.
Best,
Jennifer
0001-AArch64-Fuse-CMP-CSEL-and-CMP-CSET-for-mcpu-neoverse.patch
Description: Binary data
> On 25 Jul 2
On Wed, Jul 31, 2024 at 1:21 PM Tobias Burnus wrote:
>
> Hi Richard, hi all,
>
> Richard Biener wrote:
>
> Looking at pass_omp_target_link::execute I wonder iff find_link_var_op
> shouldn't simply do the substitution? Aka
>
> This seems to work ...
>
> --- a/gcc/omp-offload.cc
> +++ b/gcc/omp-off
I doubt we want the @euro suffix anywhere except Glibc-based targets. We
certainly don't want to append "@euro" on Solaris, where this change
flips some tests from UNSUPPORTED to PASS, e.g.
21_strings/basic_string/numeric_conversions/char/to_string_float.cc
It will probably also cause some to flip
On Wed, 31 Jul 2024 at 13:27, Jonathan Wakely wrote:
>
> I doubt we want the @euro suffix anywhere except Glibc-based targets. We
> certainly don't want to append "@euro" on Solaris, where this change
> flips some tests from UNSUPPORTED to PASS, e.g.
> 21_strings/basic_string/numeric_conversions/c
Hi Jonathan,
> On Wed, 31 Jul 2024 at 13:27, Jonathan Wakely wrote:
>>
>> I doubt we want the @euro suffix anywhere except Glibc-based targets. We
>> certainly don't want to append "@euro" on Solaris, where this change
>> flips some tests from UNSUPPORTED to PASS, e.g.
>> 21_strings/basic_string/
On Wed, 31 Jul 2024, Uros Bizjak wrote:
> On Wed, Jul 31, 2024 at 11:33 AM Richard Biener wrote:
> >
> > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> >
> > > On Wed, Jul 31, 2024 at 10:48 AM Richard Biener wrote:
> > > >
> > > > On Wed, 31 Jul 2024, Uros Bizjak wrote:
> > > >
> > > > > On Wed, Jul
On Wed, Jul 31, 2024 at 02:43:36PM +0200, Richard Biener wrote:
> diff --git a/gcc/config/i386/i386-modes.def
> b/gcc/config/i386/i386-modes.def
> index 6d8f1946f3a..2cc03e30f13 100644
> --- a/gcc/config/i386/i386-modes.def
> +++ b/gcc/config/i386/i386-modes.def
> @@ -21,7 +21,7 @@ along with GCC;
On Wed, 31 Jul 2024 at 13:42, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > On Wed, 31 Jul 2024 at 13:27, Jonathan Wakely wrote:
> >>
> >> I doubt we want the @euro suffix anywhere except Glibc-based targets. We
> >> certainly don't want to append "@euro" on Solaris, where this change
> >> flips some
As discussed a couple of weeks ago, I'm going to push this.
Tested x86_64-linux (where this #else isn't even used, but I checked it
does at least compile when the #if isn't true).
-- >8 --
The linux man page for strerror says that some systems return NULL for
an unknown error number. That violat
On Wed, 31 Jul 2024, Jakub Jelinek wrote:
> On Wed, Jul 31, 2024 at 02:43:36PM +0200, Richard Biener wrote:
> > diff --git a/gcc/config/i386/i386-modes.def
> > b/gcc/config/i386/i386-modes.def
> > index 6d8f1946f3a..2cc03e30f13 100644
> > --- a/gcc/config/i386/i386-modes.def
> > +++ b/gcc/config/
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
The following implements the hook, excluding x87 modes for scalar
and complex float modes.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK this way?
Thanks,
Richard.
* i386.cc (TARGET_MODE_CAN_TRANSFER_BITS): Define.
(ix86_mode_can_transfer_bits): New function.
---
gcc/
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
We can use the new TARGET_MODE_CAN_TRANSFER_BITS hook
Claudio Bantaloukas writes:
> This series introduces initial flags and functionality for the fp8 feature.
>
> Specifically, the following are added:
> - functions that enable constructing valid fpm register values.
> - support for the '+fp8' -march modifier.
> - support for reading and writing the
On Wed, 10 Jul 2024, Richard Biener wrote:
> The loop unrolling code assumes that one third of all volatile accesses
> can be possibly optimized away which is of course not true. This leads
> to excessive unrolling in some cases. The following tracks the number
> of stmts with side-effects as th
Hi Jonathan,
>> agreed: while Solaris 11.4 does have a few *.ISO8859-15@euro locales
>>
>> da_DK.ISO8859-15@euro
>> en_GB.ISO8859-15@euro
>> en_US.ISO8859-15@euro
>> sv_SE.ISO8859-15@euro
>>
>> the majority (17) are not.
>
> Ah interesting, I only saw en_US.ISO8859-15@euro on cfarm216, which is
>
The following improves release_pages when using the madvise path
to sort the freelist to get more page entries contiguous and possibly
release them. This populates the unused prev pointer so the reclaim
can then easily unlink from the freelist without re-ordering it.
The paths not having madvise d
Hi Andre,
On 7/31/24 11:29, Andre Vieira (lists) wrote:
Hi Christophe,
Thanks for the comments, attached new version for testcase, see below
new cover letter:
Thanks for the improved cover letter, it is indeed clearer.
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec
ping for the series?
On Thu, 11 Jul 2024 at 23:43, Christophe Lyon
wrote:
>
> Add a comment about the lack of "n" forms for floating-point nor 8-bit
> integers, to make it clearer why we use build_16_32 for MODE_n.
>
> 2024-07-11 Christophe Lyon
>
> gcc/
> * config/arm/arm-mve
Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
From: Björn Schäpers
This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
I don't know if I picked the right way to do it.
When acceptable I think the declaration should be mov
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Tuesday, July 30, 2024 4:44 PM
> To: Jakub Jelinek ; Richard Biener
>
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEF
> -Original Message-
> From: Tobias Burnus
> Sent: Tuesday, July 30, 2024 6:08 PM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
>
> External email: Use caution opening
'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here
for the test to be executed.
That said, it actually seems to be executed for me anyway, presumably
a default in the directory, but let's fix it to be consistent with
other uses in the tree and in that test directory even.
libgo
We want 'dg-do compile', not 'dg-do-compile'. Fix that.
PR target/69194
PR c++/92024
PR c++/110057
* c-c++-common/Wshadow-1.c: Fix 'dg-do compile' typo.
* g++.dg/tree-ssa/devirt-array-destructor-1.C: Likewise.
* g++.dg/tree-ssa/devirt-array-destructo
We want 'dg-do preprocess', not 'dg-do-preprocess'. Fix that.
PR target/106828
* g++.target/loongarch/pr106828.C: Fix 'dg-do compile' typo.
---
Committed as obvious.
gcc/testsuite/g++.target/loongarch/pr106828.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Per gccint, 'dg-require-effective-target' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aapcs64/func-ret-3.c: Fix
dg-require-effective-target directive order.
* gcc.target/aarch64/aapcs64/func
Per gccint, 'dg-require-*' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
* gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c: Fix
dg-require-profiling
directive order.
* gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c: Likewise.
-
On Wed, Jul 31, 2024 at 02:58:34PM +, Prathamesh Kulkarni wrote:
> There are a couple of issues in the patch:
> (1) The patch streams out NUM_POLY_INT_COEFFS at beginning of mode_table,
> which should work for bp_unpack_poly_value,
> (since AFAIK, it's only called by lto_input_mode_table). How
On Wed, 31 Jul 2024 at 15:42, Björn Schäpers wrote:
>
> Am 30.07.2024 um 11:13 schrieb Jonathan Wakely:
> > On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
> >>
> >> From: Björn Schäpers
> >>
> >> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> >> I don't know if I pick
We haven't been applying our settings to our C++. This patch fixes
that.
Sadly, it seems that the only documented way to apply settings to
multiple modes is to repeat them. I thought that we can provide a list
of modes to apply, but that seems to not be the case (even thought it
happened to work
On Wed, Jul 31, 2024 at 04:02:22PM +0200, Richard Biener wrote:
> The following improves release_pages when using the madvise path
> to sort the freelist to get more page entries contiguous and possibly
> release them. This populates the unused prev pointer so the reclaim
> can then easily unlink
On Tue, 30 Jul 2024, Jason Merrill wrote:
> On 7/29/24 5:32 PM, Patrick Palka wrote:
> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> >
> > > On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
> > > > On Fri, 26 Jul 2024, Jakub Jelinek wrote:
> > > >
> > > > > On Fri, Jul 26, 2024 at
We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
one.
libstdc++-v3/ChangeLog:
* testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do run'.
---
OK? No regressions in the logs but it's a bit weird that it's got a proper
directive with a target specifier so
On Wed, Jul 31, 2024 at 3:40 PM Richard Biener wrote:
>
> The following implements the hook, excluding x87 modes for scalar
> and complex float modes.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK this way?
>
> Thanks,
> Richard.
>
> * i386.cc (TARGET_MODE_CAN_TRANSFER_BI
Hi,
in PR116149 we choose a wrong vector length which causes wrong values in
a reduction. The problem happens in avlprop where we choose the
number of units in the instruction's mode as vector length. For the
non-scalar variants the respective operand has the correct non-widened
mode. For the s
On Wed, Jul 31, 2024 at 11:33 AM Richard Biener wrote:
> > > > > > OK. Richard, can you please mention the above in the comment why
> > > > > > XFmode is rejected in the hook?
> > > > > >
> > > > > > Later, we can perhaps benchmark XFmode move vs. generic memory copy
> > > > > > to
> > > > > > g
On Wed, 31 Jul 2024 at 16:45, Sam James wrote:
>
> We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
> one.
>
> libstdc++-v3/ChangeLog:
> * testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do run'.
> ---
> OK? No regressions in the logs but it's a bit wei
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a
dec_insn
should be, which caused an ICE.
This dec_insn is the instruction that decreases the loop counter
inside a
decrementing loop a
I plan to push this soon to hopefully fix some test breakage on some
architetures. It is simple and obvious. I did not get any feedback on
this and I do not have access to the machines in question.
Regression tested on linux-x86-64.
Regards,
Jerry
commit bc4ee05dc7c60d534ef927ac5e679f67fb99
Jonathan Wakely writes:
> On Wed, 31 Jul 2024 at 16:45, Sam James wrote:
>>
>> We already have a valid 'dg-do run' (- vs _) directive, so drop the bogus
>> one.
>>
>> libstdc++-v3/ChangeLog:
>> * testsuite/28_regex/traits/char/translate.cc: Drop bogus 'dg_do
>> run'.
>> ---
>> OK? No re
On 7/31/24 18:06, Andre Vieira (lists) wrote:
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a
dec_insn
should be, which caused an ICE.
This dec_insn is the instruction that decrease
PRU and other simulator targets do not pass any argv arguments
to main. Instead of erroneously relying on argc==0, use a volatile
variable instead.
I reverted the fix for PR67947 in r6-3891-g8a18fcf4aa1d5c, and made sure
that the updated test case still fails for x86_64:
$ make check-gcc-c RUN
The testcase contains the constant:
arr2 = svreinterpret_u8(svdup_u32(0x0a0d5c3f));
which was initially hoisted by hand, but which gimple optimisers later
propagated to each use (as expected). The constant was then expanded
as a load-and-duplicate from the constant pool. Normally that load
sh
Hi Kyrill,
> > /* True if the vector body contains a store to a decl and if the
> > function is known to have a vld1 from the same decl.
> >
> > @@ -17291,6 +17297,17 @@ aarch64_vector_costs::add_stmt_cost (int count,
> vect_cost_for_stmt kind,
> >stmt_cost = aarch64_detect_vector_s
On 7/31/24 10:39 AM, Dimitar Dimitrov wrote:
PRU and other simulator targets do not pass any argv arguments
to main. Instead of erroneously relying on argc==0, use a volatile
variable instead.
I reverted the fix for PR67947 in r6-3891-g8a18fcf4aa1d5c, and made sure
that the updated test case
Loading an arbitrary constant address in a register is expensive for
PRU. So enable section anchoring by default to utilize the unsigned
byte constant offset operand of load/store instructions.
gcc/ChangeLog:
* common/config/pru/pru-common.cc
(TARGET_OPTION_OPTIMIZATION_TABLE): N
1 - 100 of 159 matches
Mail list logo
