Hi Jerry,
looks fine to me. The change is so small that I see no harm, ok to merge.
Thanks for the patch.
- Andre
On Wed, 31 Jul 2024 09:08:54 -0700
Jerry D wrote:
> I plan to push this soon to hopefully fix some test breakage on some
> architetures. It is simple and obvious. I did not get an
On Tue, Jul 30, 2024 at 11:04 AM liuhongt wrote:
>
> (insn 98 94 387 2 (parallel [
> (set (reg:TI 337 [ _32 ])
> (ashift:TI (reg:TI 329)
> (reg:QI 521)))
> (clobber (reg:CC 17 flags))
> ]) "test.c":11:13 953 {ashlti3_doubleword}
>
Do you want me to take care of those 2 tests ?
You seem to have started something on the review of dg-error patterns in
use.
Here I kept the test variable because I fear to potentially have a
diagnostic about unused returned value.
François
On 31/07/2024 23:12, Jonathan Wakely wrote:
On W
On Thu, Aug 1, 2024 at 10:03 AM Kong, Lingling wrote:
>
>
>
> > -Original Message-
> > From: Liu, Hongtao
> > Sent: Thursday, August 1, 2024 9:35 AM
> > To: Kong, Lingling ; gcc-patches@gcc.gnu.org
> > Cc: Wang, Hongyu
> > Subject: RE: [PATCH] i386: Fix memory constraint for APX NF
> >
>
On Mon, Jul 29, 2024 at 10:11 AM Andrew Pinski wrote:
>
> On Mon, Jul 29, 2024 at 12:57 AM Kugan Vivekanandarajah
> wrote:
> >
> > On Thu, Jul 25, 2024 at 10:19 PM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 25, 2024 at 4:42 AM Kugan Vivekanandarajah
> > > wrote:
> > > >
> > > > On Tue,
on 2024/8/1 01:52, Carl Love wrote:
> Kewen:
>
> On 7/31/24 2:12 AM, Kewen.Lin wrote:
>> 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
2024-08-01 09:53 Jeff Law wrote:
>
>
>
>On 7/30/24 7:05 PM, Xiao Zeng wrote:
>> 2024-07-31 03:10 Jeff Law wrote:
>>>
>>>
>>>
>>> On 7/28/24 7:58 PM, Xiao Zeng wrote:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105314-rtl.c: Skip zicond.
* gcc.target/r
> -Original Message-
> From: Liu, Hongtao
> Sent: Thursday, August 1, 2024 9:35 AM
> To: Kong, Lingling ; gcc-patches@gcc.gnu.org
> Cc: Wang, Hongyu
> Subject: RE: [PATCH] i386: Fix memory constraint for APX NF
>
>
>
> > -Original Message-
> > From: Kong, Lingling
> > Sent:
On 7/30/24 7:05 PM, Xiao Zeng wrote:
2024-07-31 03:10 Jeff Law wrote:
On 7/28/24 7:58 PM, Xiao Zeng wrote:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105314-rtl.c: Skip zicond.
* gcc.target/riscv/pr105314-rtl32.c: Dotto.
* gcc.target/riscv/pr105314.c
> -Original Message-
> From: Kong, Lingling
> Sent: Thursday, August 1, 2024 9:30 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; Wang, Hongyu
>
> Subject: [PATCH] i386: Fix memory constraint for APX NF
>
> The je constraint should be used for APX NDD ADD with register source
>
The je constraint should be used for APX NDD ADD with register source
operand. The jM is for APX NDD patterns with immediate operand.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.md (nf_mem_constraint): Fixed the constraint
在 2024/7/31 下午6:25, Xi Ruoyao 写道:
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 ins
I wrote this support file to help me debug Tcl issues in the
testsuite.
Adding a call to:
print_stack_backtrace
somewhere in a .exp file (along with "load_lib print-stack.exp") leads
to the interpreter printing a backtrace in a form that e.g. Emacs can
consume, with filename:linenum: lines, an
I want to reuse some of the support for valgrind in jit.exp
in my upcoming testsuite for https://gcc.gnu.org/wiki/libdiagnostics
so this patch splits that out into a valgrind.exp.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-2467-g55982d1682921f.
gcc/ChangeLog:
* diagnostic-path.cc
(thread_event_printer::print_swimlane_for_event_range): Gracefully
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pused to trunk as r15-2466-g5cb7adeaf5420c.
gcc/testsuite/ChangeLog:
* gcc.dg/sarif-output/sarif.py: Drop unused import of gzip.
Signed-off-by: David Malcolm
---
gcc/testsuite/gcc.dg/sarif-ou
This patch extends
* the work done in r15-2291-gd7a688fc960f78 to capture labels
on location ranges in rich_locations in SARIF form as
"annotations" (§3.28.6)
* the work done in r15-2354-g4d1f71d49e396c to support
related locations (§3.27.22 and §3.34)
so that all location ranges in a rich_l
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-2464-gc990667996ff79.
gcc/ChangeLog:
* diagnostic-format-sarif.cc (sarif_builder::sarif_builder): Asser
Pushed to trunk as r15-2463-gf829e627f40c95.
gcc/ChangeLog:
* diagnostic-format-sarif.cc: Tweak ASCII art in comment
to show edges for both directions in the digraph.
Signed-off-by: David Malcolm
---
gcc/diagnostic-format-sarif.cc | 12 ++--
1 file changed, 6 insertions(
> Sorry for the slow review.
>
> Pengxuan Zheng writes:
> > This patch improves the Advanced SIMD popcount expansion by using SVE
> > if available.
> >
> > For example, GCC currently generates the following code sequence for V2DI:
> > cnt v31.16b, v31.16b
> > uaddlp v31.8h, v31.16b
> >
This patch improves the Advanced SIMD popcount expansion by using SVE if
available.
For example, GCC currently generates the following code sequence for V2DI:
cnt v31.16b, v31.16b
uaddlp v31.8h, v31.16b
uaddlp v31.4s, v31.8h
uaddlp v31.2d, v31.4s
However, by using SVE, we can gener
This patch improves the Advanced SIMD popcount expansion by using SVE if
available.
For example, GCC currently generates the following code sequence for V2DI:
cnt v31.16b, v31.16b
uaddlp v31.8h, v31.16b
uaddlp v31.4s, v31.8h
uaddlp v31.2d, v31.4s
However, by using SVE, we can gener
This has been approved and will be committed if there's no other comments in a
day.
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 : FALSE */
/* (a ? x : y) == (b ? x :
On Mon, 22 Jul 2024, Xi Ruoyao wrote:
> On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> > the build is configured --enable-default-pie. Let's fix them.
> >
> > Tested on x86_64-linux-gnu. Ok for trunk and releases/gc
On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
>
> The template `future.wait_until` will expand to
> `_M_load_and_test_until_impl` where it will call
> `_M_load_and_test_until*` with given time_point casted into second and
> nanosecond. The callee expects the caller to provide the values
> corr
On 7/31/24 3:56 PM, Arsen Arsenović wrote:
Okay, I've reworked it, and it built and passed coroutine tests.
Regstrapping overnight. Is the following OK with you?
OK.
-- >8 --
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the foll
On Wed, 31 Jul 2024 at 21:59, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 21:44, François Dumont wrote:
> >
> > Committed as trivial.
> >
> > Fix a compilation error that is not expected by the tests preserving
> > the expected ones.
> >
> > The 'test' variable declaration is missing since
On Wed, 31 Jul 2024 at 21:44, François Dumont wrote:
>
> Committed as trivial.
>
> Fix a compilation error that is not expected by the tests preserving
> the expected ones.
>
> The 'test' variable declaration is missing since commit
> a9260b7eb688df43a724e25421ba40f35a89fee9 that removed the test
Kewen:
On 7/29/24 3:21 AM, Kewen.Lin wrote:
+@smallexample
+@exdent vector signed __int128 vec_sld (vector signed __int128,
+vector signed __int128, const unsigned int);
+@exdent vector unsigned __int128 vec_sld (vector unsigned __int128,
+vector unsigned __int128, const unsigned int);
+@exden
On Sat, 13 Jul 2024, Martin Uecker wrote:
> This marks structures which include a byte array
> as typeless storage for all C language modes.
>
>
> Bootstrapped and regression tested on x86_64.
>
>
>
>
> c: Add support for byte arrays in C2Y
>
> To get correct aliasing behavior r
Committed as trivial.
Fix a compilation error that is not expected by the tests preserving
the expected ones.
The 'test' variable declaration is missing since commit
a9260b7eb688df43a724e25421ba40f35a89fee9 that removed the test global
variable in testsuite files.
libstdc++-v3/ChangeLog:
*
On Wed, Jul 31, 2024 at 3:42 AM Mariam Arutunian
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 =
On Wed, 31 Jul 2024 at 19:18, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 19:17, Dimitar Dimitrov wrote:
> >
> > On Wed, Jul 31, 2024 at 05:09:52PM +0100, Jonathan Wakely wrote:
> > > It took a while, but I was finally happy with this v4 patch, so I pushed
> > > it to trunk. Then I noticed
From: Mikael Morin
Tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Add the tests covering the various cases for which we are about to implement
inline expansion of MINLOC and MAXLOC. Those are cases where the DIM
argument is not present.
PR fortran/90608
gcc/testsuite/ChangeLo
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY
is of integral type, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined before).
Sca
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was introd
From: Mikael Morin
The next patch will need reindenting of the array bound check generation
code. This outlines it to its own function beforehand, reducing the churn
in the next patch.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-ar
From: Mikael Morin
This series of patches enable the generation of inline code for the MINLOC
and MAXLOC intrinsics, when the DIM argument is not present. The
generated code is based on the inline implementation already generated in
the scalar case, that is when ARRAY has rank 1 and DIM is prese
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the
DIM argument is not present and ARRAY has rank 1. This case is similar to
the case where the result is scalar (DIM present and rank 1 A
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline code for the MINLOC and MAXLOC intrinsic,
if the ARRAY argument is of integral type and of any rank (only the rank 1
case was previously inlined), and neither DIM nor MASK arguments
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support inlining
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Disable rewriting of MINLOC/MAXLOC expressions for which inline code
generation is supported. Update the gfc_inline_intrinsic_function_p
predicate (already existing) for that, with the current state of
MINLOC/
Okay, I've reworked it, and it built and passed coroutine tests.
Regstrapping overnight. Is the following OK with you?
-- >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()
{
On Wed, Jul 31, 2024 at 5:05 AM Richard Biener
wrote:
>
> 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
Jennifer Schmitz writes:
> 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
>
> From 89936b7bc2de7a1e4bc55c3a1e8d5e6ac0de579d Mon Sep 17 00:00:00
Hi Tamar,
> On 31 Jul 2024, at 18:46, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
> 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
Jason Merrill writes:
> On 7/31/24 6:54 AM, Arsen Arsenović wrote:
>> 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:
>>awaita
Hi, Kewen,
Thanks a lot for fixing this testing case issue.
Yes, the change LGTM though I can’t approve it.
Qing
> On Jul 31, 2024, at 05:22, Kewen.Lin wrote:
>
> Hi,
>
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r
On Sun, 7 Jul 2024, Gerald Pfeifer wrote:
> However, wouldn't it be so much better if we could import (or "import")
> BUGURL from gcc/ where it is also set?
Yes, it would seem reasonable to parse the ACX_BUGURL line in
gcc/configure.ac. (It's not obvious that the URL should change more
frequen
On Wed, 31 Jul 2024 at 19:17, Dimitar Dimitrov wrote:
>
> On Wed, Jul 31, 2024 at 05:09:52PM +0100, Jonathan Wakely wrote:
> > It took a while, but I was finally happy with this v4 patch, so I pushed
> > it to trunk. Then I noticed silly mistake in the new test, which I'll
> > fix shortly.
> >
> .
Tamar Christina writes:
> @@ -289,6 +293,12 @@ struct sve_vec_cost : simd_vec_cost
>const int gather_load_x32_cost;
>const int gather_load_x64_cost;
>
> + /* Additional loop initialization cost of using a gather load instruction.
> The x32
Sorry for the trivia, but: long line.
> +
On Wed, Jul 31, 2024 at 05:09:52PM +0100, Jonathan Wakely wrote:
> It took a while, but I was finally happy with this v4 patch, so I pushed
> it to trunk. Then I noticed silly mistake in the new test, which I'll
> fix shortly.
>
...
> +#if defined _GLIBCXX_HAVE_ICONV
> + ::iconv_t _M_cd = (::icon
On 7/31/24 6:54 AM, Arsen Arsenović wrote:
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()
{
Arsen Arsenović writes:
> 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 ca
Kewen:
On 7/31/24 2:12 AM, Kewen.Lin wrote:
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
More enable-rtl-checking fixes for ext-dce. Very similar to the one
recently posted, this time covering more of the shift ops.
I checked all instances of CONSTANT_P guarding [U]INTVAL and fixed all
that looked wrong. I also created a dummy assembler/linker so that I
could run the GCC testsui
It took a while, but I was finally happy with this v4 patch, so I pushed
it to trunk. Then I noticed silly mistake in the new test, which I'll
fix shortly.
Compared to v3 sent two weeks ago, the main change here is the addition
of a mutex to the __encoding facet, so that two formatters using the
s
On 7/31/24 9:55 AM, Robin Dapp wrote:
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 h
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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, 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
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
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.
-
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
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/
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
'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
> -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
> -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
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
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
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
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 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
>
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
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
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
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 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
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/
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 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
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, 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
1 - 100 of 159 matches
Mail list logo
