On Thu, May 9, 2024 at 11:12 AM Levy Hsu wrote:
>
> Hi All
>
> We've introduced a new subroutine in ix86_expand_vec_perm_const_1
> to optimize vector shifting for the V16QI type on x86.
> This patch uses a three-instruction sequence psrlw, psllw, and por
> to handle specific vector shuffle operati
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove vector set and vector init built-ins.
>
> The vector init built-ins:
>
> __builtin_vec_init_v16qi, __builtin_vec_init_v8hi,
> __builtin_vec_init_v4si, __builtin_vec_init_v4sf,
> __builtin_vec_init_v2di, __builtin_vec_init_v2df,
>
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvcmpeqsp built-in
>
> The built-in __builtin_vsx_xvcmpeqsp is a duplicate of the overloaded
> vec_cmpeq built-in. The built-in is undocumented. The built-in and
> the test cases are removed.
>
> gcc/ChangeLog:
> * c
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, extend vec_xxpermdi built-in for __int128 args
>
> Add a new overloaded instance for vec_xxpermdi
>
>__int128 vec_xxpermdi (__int128, __int128, const int);
>
> Update the documentation to include a reference to the new built-in
> instance.
On 5/13/24 6:54 PM, Patrick O'Neill wrote:
On 5/13/24 13:28, Jeff Law wrote:
On 5/13/24 12:49 PM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added
Hi,
"Kewen.Lin" writes:
> Hi,
>
> on 2024/5/14 11:00, Jiufu Guo wrote:
>> Hi,
>>
>> Thanks a lot for your helpful review!
>>
>> "Kewen.Lin" writes:
>>
>>> Hi,
>>>
>>> on 2024/5/13 10:57, Jiufu Guo wrote:
Hi,
For PR96866, when gcc print asm code for modifier "%a" which requires
Hi,
on 2024/5/14 11:00, Jiufu Guo wrote:
> Hi,
>
> Thanks a lot for your helpful review!
>
> "Kewen.Lin" writes:
>
>> Hi,
>>
>> on 2024/5/13 10:57, Jiufu Guo wrote:
>>> Hi,
>>>
>>> For PR96866, when gcc print asm code for modifier "%a" which requires
>>> an address operand, while the operand i
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp built-ins
>
> The undocumented __builtin_vsx_xvnegdp and __builtin_vsx_xvnegsp are
> redundant. The overloaded vec_neg built-in provides the same
> functionality. The two buit-ins are not d
Hi,
Thanks a lot for your helpful review!
"Kewen.Lin" writes:
> Hi,
>
> on 2024/5/13 10:57, Jiufu Guo wrote:
>> Hi,
>>
>> For PR96866, when gcc print asm code for modifier "%a" which requires
>> an address operand, while the operand is with the constraint "X" which
>> allow non-address form.
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove __builtin_vsx_vperm_* built-ins
>
> The undocumented built-ins:
> __builtin_vsx_vperm_16qi_uns,
> __builtin_vsx_vperm_1ti,
> __builtin_vsx_vperm_1ti_uns,
> __builtin_vsx_vperm_2df,
> __builtin_vsx_vperm_2di,
> __builtin_vsx_vpe
Hi,
on 2024/4/20 05:18, Carl Love wrote:
> rs6000, remove the vec_xxsel built-ins, they are duplicates
>
> The following undocumented built-ins are covered by the existing overloaded
> vec_sel built-in definitions.
>
> const vsc __builtin_vsx_xxsel_16qi (vsc, vsc, vsc);
> same as vsc __builtin
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, add overloaded vec_sel with int128 arguments
>
> Extend the vec_sel built-in to take three signed/unsigned int128 arguments
> and return a signed/unsigned int128 result.
>
> Extending the vec_sel built-in makes the existing buit-ins
> __builtin_
Hi,
Thanks for your helpful comments!
Segher Boessenkool writes:
> Hi!
>
> On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote:
>> For PR96866, when gcc print asm code for modifier "%a" which requires
>> an address operand,
>
> It requires a *memory* operand, and it outputs its address.
Do you have any advice?
BRs,
Lin
-Original Message-
From: Hu, Lin1
Sent: Wednesday, May 8, 2024 9:38 AM
To: gcc-patches@gcc.gnu.org
Cc: Liu, Hongtao ; ubiz...@gmail.com
Subject: [PATCH] vect: generate suitable convert insn for int -> int, float ->
float and int <-> float.
Hi, all
Thi
Hi Aldy,
Thanks for your review comments.
在 2024/5/13 19:18, Aldy Hernandez 写道:
> On Thu, May 9, 2024 at 10:05 AM Mikael Morin wrote:
>>
>> Hello,
>>
>> Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
>>> Hi,
>>>The former patch adds isfinite optab for __builtin_isfinite.
>>> https://gcc.gnu.
Hi,
on 2024/4/20 05:17, Carl Love wrote:
> rs6000, remove duplicated built-ins of vecmergl and vec_mergeh
>
> The following undocumented built-ins are same as existing documented
> overloaded builtins.
>
> const vf __builtin_vsx_xxmrghw (vf, vf);
> same as vf __builtin_vec_mergeh (vf, vf);
> That's just a matter of matching the overflow as an additional case no?
> i.e. you can add an overload for unsigned_integer_sat_add matching the
> IFN_ ADD_OVERFLOW and using the realpart and imagpart helpers.
> I think that would be better as it avoid visiting all the statements twice
> but
From: Pan Li
This patch would like to fix below format issue of trailing operator.
=== ERROR type #1: trailing operator (4 error(s)) ===
gcc/config/riscv/riscv-vector-builtins.cc:4641:39: if ((exts &
RVV_REQUIRE_ELEN_FP_16) &&
gcc/config/riscv/riscv-vector-builtins.cc:4651:39: if ((exts &
RVV_
Ack, thanks Jeff and will fix it ASAP.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, May 14, 2024 2:10 AM
To: Li, Pan2 ; Kito Cheng ;
juzhe.zh...@rivai.ai
Cc: gcc-patches
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16
scalar
On 5/13/24 9:00 AM,
This patch folds vget_low_* intrinsics to BIT_FILED_REF to open up more
optimization opportunities for gimple optimizers.
While we are here, we also remove the vget_low_* definitions from arm_neon.h and
use the new intrinsics framework.
PR target/102171
gcc/ChangeLog:
* config/a
On 5/13/24 13:28, Jeff Law wrote:
On 5/13/24 12:49 PM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
On Tue, May 14, 2024 at 01:38:49AM +0200, Andrew Pinski wrote:
> On Mon, May 13, 2024, 11:41 PM Kees Cook wrote:
> > But it makes no sense to warn about:
> >
> > void sparx5_set (int * ptr, struct nums * sg, int index)
> > {
> >if (index >= 4)
> > warn ();
> >*ptr = 0;
> >*val = s
On Mon, May 13, 2024, 11:41 PM Kees Cook wrote:
> On Mon, May 13, 2024 at 02:46:32PM -0600, Jeff Law wrote:
> >
> >
> > On 5/13/24 1:48 PM, Qing Zhao wrote:
> > > -Warray-bounds is an important option to enable linux kernal to keep
> > > the array out-of-bound errors out of the source tree.
> > >
On 12/19/23 10:28 PM, Jeff Law wrote:
On 12/19/23 02:53, Sergei Lewis wrote:
gcc/ChangeLog
* config/riscv/riscv.md (movmem): Use
riscv_vector::expand_block_move,
if and only if we know the entire operation can be performed
using one vector
load followed by one vector stor
On 5/13/24 15:47, Jeff Law wrote:
>> On 5/13/24 11:49, Vineet Gupta wrote:
>>> 500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
>>> 500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
>>> 500.perlbench_r-2 |692,074,638,817 | 691,118,734,547 |
>>> 502.gcc_r-0
On 5/13/24 3:13 PM, Vineet Gupta wrote:
On 5/13/24 11:49, Vineet Gupta wrote:
500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
500.perlbench_r-2 |692,074,638,817 | 691,118,734,547 |
502.gcc_r-0 |1
On Mon, May 13, 2024 at 02:46:32PM -0600, Jeff Law wrote:
>
>
> On 5/13/24 1:48 PM, Qing Zhao wrote:
> > -Warray-bounds is an important option to enable linux kernal to keep
> > the array out-of-bound errors out of the source tree.
> >
> > However, due to the false positive warnings reported in
LGTM
juzhe.zh...@rivai.ai
The validator warns about as deprecated; use instead.
Pushed.
Gerald
---
htdocs/projects/cxx-dr-status.html | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index c70cdf21..e29d2407 100644
>> Seems a bit odd on first sight. If all we want to do is to
>> select between two masks why do we need a large Pmode mode?
Since we are lowering final mask = vcond_mask_len (mask, 1s, 0s, len, bias),
into:
vid.v v1
vcmp v2
vmsltu.vx v2, v1, len, TUMU
Then len is Pmode, so we only allow to low
Hi, Robin.
I saw vwadd/vwsub.wx have same issue. Could you change them and add test too ?
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-14 04:15
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Do not allow v0 as dest
On Mon, Mar 4, 2024 at 12:13 AM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> f
Hi Pan,
thanks for working on this.
In general the patch looks reasonable to me but I'd rather
have some more comments about the high-level idea.
E.g. cbranch is implemented like aarch64 by xor'ing the
bitmasks and comparing the result against zero (so we branch
based on mask equality).
> +;; vc
On 5/13/24 11:49, Vineet Gupta wrote:
> 500.perlbench_r-0 | 1,214,534,029,025 | 1,212,887,959,387 |
> 500.perlbench_r-1 |740,383,419,739 | 739,280,308,163 |
> 500.perlbench_r-2 |692,074,638,817 | 691,118,734,547 |
> 502.gcc_r-0 |190,820,141,435 | 190,857,065,988 |
> 50
On 5/13/24 1:48 PM, Qing Zhao wrote:
-Warray-bounds is an important option to enable linux kernal to keep
the array out-of-bound errors out of the source tree.
However, due to the false positive warnings reported in PR109071
(-Warray-bounds false positive warnings due to code duplication from
On 2/27/24 07:25, Jeff Law wrote:
> On 2/25/24 21:53, Greg McGary wrote:
>> Add option -m(no-)autovec-segment to enable/disable autovectorizer
>> from emitting vector segment load/store instructions. This is useful for
>> performance experiments.
>>
>> gcc/ChangeLog:
>> * config/riscv/autove
On 5/13/24 12:49 PM, Vineet Gupta wrote:
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
This avoids burning a register and m
Dear all,
the attached patch does two things:
- it fixes a bogus array bounds check when deep-copying a class component
of a derived type and the class component has rank > 1, the reason being
that the previous code compared the full size of one side with the size
of the first dimension of
On 5/13/24 12:49 PM, Vineet Gupta wrote:
Apologies for the delay in getting this out. Needed to fix one ICE
with glibc build and fresh round of testing: both testsuite and SPEC
runs (which are similar to v1 in terms of Cactu gains, but some more minor
regressions elsewhere gcc). Again those se
Hi,
this patch splits the vfw...wf pattern so we do not emit
e.g. vfwadd.wf v0,v8,fa5,v0.t anymore.
Regtested on rv64gcv_zvfh.
Regards
Robin
gcc/ChangeLog:
PR target/115068
* config/riscv/vector.md: Split vfw.wf pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/
Pushed.
commit 06c46c88cc02e0dff5f65b41754178fb25fb939e
Author: Marek Polacek
Date: Mon May 13 16:09:05 2024 -0400
cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 114
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index a5f45359..2a6
-Warray-bounds is an important option to enable linux kernal to keep
the array out-of-bound errors out of the source tree.
However, due to the false positive warnings reported in PR109071
(-Warray-bounds false positive warnings due to code duplication from
jump threading), -Warray-bounds=1 cannot
If we have an AND with a constant operand and the constant operand
requires synthesis, then we may be able to generate more efficient code
than we do now.
Essentially the need for constant synthesis gives us a budget for
alternative ways to clear bits, which zext.w can do for bits 32..63
tr
Apologies for the delay in getting this out. Needed to fix one ICE
with glibc build and fresh round of testing: both testsuite and SPEC
runs (which are similar to v1 in terms of Cactu gains, but some more minor
regressions elsewhere gcc). Again those seem so small that IMHO this
should still go in.
If the constant used for stack offset can be expressed as sum of two S12
values, the constant need not be materialized (in a reg) and instead the
two S12 bits can be added to instructions involved with frame pointer.
This avoids burning a register and more importantly can often get down
to be 2 ins
Hi,
This set of patches help improve stack/array accesses by improving
constant materialization. Details are in respective patches.
The first patch is the main change which improves SPEC cactu by 10%.
As discussed/agreed for v1 [1], I've dropped the splitter variant for
stack accesses.
I also h
Hi,
on 2024/5/9 15:35, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks for your comments.
>
> 在 2024/5/9 13:44, Kewen.Lin 写道:
>> Hi,
>>
>> on 2024/5/8 14:47, HAO CHEN GUI wrote:
>>> Hi,
>>> This patch enables overlapped by-piece operations. On rs6000, default
>>> move/set/clear ratio is 2. So the ov
On Mon, 2024-05-13 20:19:42 +0200, Jan-Benedict Glaw wrote:
> On Tue, 2024-04-30 17:24:15 -0400, Andrew MacLeod wrote:
> > Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
>
> Starting with this patch (upstream as
> e8ae56a7dc46e39a48017bb5159e4dc672ec7fad, can still be reproduc
On Tue, 2024-04-30 17:24:15 -0400, Andrew MacLeod wrote:
> Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Starting with this patch (upstream as
e8ae56a7dc46e39a48017bb5159e4dc672ec7fad, can still be reproduced with
0c585c8d0dd85601a8d116ada99126a48c8ce9fd as of May 13th), my CI
On 5/13/24 9:00 AM, Li, Pan2 wrote:
Committed, thanks Juzhe and Kito. Let's wait for a while before backport to 14.
Could you fix the formatting nits caught by the CI linter?
=== ERROR type #1: trailing operator (4 error(s)) ===
gcc/config/riscv/riscv-vector-builtins.cc:4641:39: if ((exts &
Same patch for gcc12.
bootstraps and passes all tests on x86_64-pc-linux-gnu
On 5/9/24 10:32, Andrew MacLeod wrote:
As requested, backported the patch for 111009 to resolve incorrect
ranges from addr_expr and committed to GCC 13 branch.
bootstraps and passes all tests on x86_64-pc-linux-gnu
Pushed as obvious.
-- >8 --
This patch fixes a compilation error when building GCC using Clang.
Since __array_rank is used as a built-in trait name, use rank instead.
PR c++/115061
gcc/cp/ChangeLog:
* semantics.cc (finish_trait_expr): Use rank instead of
__array_rank.
On Mon, May 13, 2024 at 8:19 AM Marek Polacek wrote:
>
> On Sun, May 12, 2024 at 11:48:07PM -0700, Ken Matsui wrote:
> > This patch fixes a compilation error when building GCC using Clang.
> > Since __array_rank is used as a built-in trait name, use rank instead.
>
> I think you can go ahead and p
On Linux/x86_64,
fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9 is the first bad commit
commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9
Author: Matthias Kretz
Date: Mon May 6 12:13:55 2024 +0200
libstdc++: Use __builtin_shufflevector for simd split and concat
caused
FAIL: experimental/simd/pr1
Hi Pan,
>
> @@ -4114,6 +4115,7 @@ proc check_effective_target_vect_early_break_hw { } {
> || [check_effective_target_arm_v8_neon_hw]
> || [check_sse4_hw_available]
> || [istarget amdgcn-*-*]
> + || [check_effective_target_riscv_v]
> }}]
> }
I believe this should be
This is an expansion of the optimize `a == CST & a`
to handle more than just casts. It adds optimization
for unary.
The patch for binary operators will come later.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/111487
gcc/ChangeLog:
* match.
Hi Ajit,
Why did you send three mails for this revision of the patch? If you're
going to send a new revision of the patch you should increment the
version number and outline the changes / reasons for the new revision.
Mostly the comments below are just style nits and things you missed from
the l
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013
Successfully tested and bootstrapped on x86-64.
commit 44430ef3d8ba75692efff5f6969d5610134566d3
Author: Vladimir N. Makarov
Date: Mon May 13 10:12:11 2024 -0400
[PR115013][LRA]: Modify register starvation recog
On Sun, May 12, 2024 at 11:48:07PM -0700, Ken Matsui wrote:
> This patch fixes a compilation error when building GCC using Clang.
> Since __array_rank is used as a built-in trait name, use rank instead.
I think you can go ahead and push this patch as obvious, thanks.
> PR c++/115061
>
> g
> -Original Message-
> From: pan2...@intel.com
> Sent: Monday, May 13, 2024 3:54 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> Tamar Christina ; Richard Sandiford
> ; Pan Li
> Subject: [PATCH v1 1/3] Vect: Support loop len
>
> Thanks Tamer for comments.
>
> > I think OPTIMIZE_FOR_BOTH is better here, since this is a win also when
> optimizing for size.
>
> Sure thing, let me update it in v5.
>
> > Hmm why do you iterate independently over the statements? The block below
> already visits
> > Every statement doesn'
Committed, thanks Juzhe and Kito. Let's wait for a while before backport to 14.
Pan
-Original Message-
From: Kito Cheng
Sent: Monday, May 13, 2024 10:11 PM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16
From: Pan Li
This patch depends on below 2 patches.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651459.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651460.html
After we supported vectorizable early exit in RISC-V, we would like to
enable the gcc vect test for vectorizable ear
From: Pan Li
This patch depends on below middle-end implementation.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651459.html
After we support the loop lens for the vectorizable, we would like to
implement the feature for the RISC-V target. Given below example:
unsigned vect_a[1923];
un
From: Pan Li
This patch adds early break auto-vectorization support for target which
use length on partial vectorization. Consider this following example:
unsigned vect_a[802];
unsigned vect_b[802];
void test (unsigned x, int n)
{
for (int i = 0; i < n; i++)
{
vect_b[i] = x + i;
i
13 May 2024 1:30:28 pm NightStrike :
On Thu, May 9, 2024 at 1:03 PM Peter Damianov
wrote:
Windows terminal and mintty both have support for link escape
sequences, and so
auto_enable_urls shouldn't be hardcoded to false. For older versions
of the
windows console, mingw_ansi_fputs's console A
On Mon, May 13, 2024 at 4:14 PM Robin Dapp wrote:
>
> > What happens if we simply remove all of the force_reg here?
>
> On x86 I bootstrapped and tested the attached without fallout
> (gcc188, so it's no avx512-native machine and therefore limited
> coverage). riscv regtest is unchanged.
> For aa
> What happens if we simply remove all of the force_reg here?
On x86 I bootstrapped and tested the attached without fallout
(gcc188, so it's no avx512-native machine and therefore limited
coverage). riscv regtest is unchanged.
For aarch64 I would to rely on the pre-commit CI to pick it
up (does t
LGTM as well :)
On Sat, May 11, 2024 at 3:58 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM from my side. Wait for kito chime in.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2024-05-11 15:54
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; Pan Li
> Subject: [P
On Mon, 2024-05-13 at 09:42 -0400, David Malcolm wrote:
> On Mon, 2024-05-13 at 11:14 +0200, Mark Wielaard wrote:
> > Hi Evgeny,
> >
> > Adding David to the CC, who might know the details.
> >
> > On Mon, May 13, 2024 at 08:44:12AM +, Evgeny Karpov wrote:
> > > Sunday, May 12, 2024
> > >
> >
On Mon, 2024-05-13 at 11:14 +0200, Mark Wielaard wrote:
> Hi Evgeny,
>
> Adding David to the CC, who might know the details.
>
> On Mon, May 13, 2024 at 08:44:12AM +, Evgeny Karpov wrote:
> > Sunday, May 12, 2024
> >
> > Thank you for reviewing our changes related to the refactoring of
> > e
Thanks Tamer for comments.
> I think OPTIMIZE_FOR_BOTH is better here, since this is a win also when
> optimizing for size.
Sure thing, let me update it in v5.
> Hmm why do you iterate independently over the statements? The block below
> already visits
> Every statement doesn't it?
Because it
On Mon, 13 May 2024, Kewen.Lin wrote:
> > In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile
> > though this removes the "convenient" defaulting, requiring each target to
> > enumerate all standard C ABI type modes. But that might be also a good
> > thing.
> >
>
> I gu
When enabling single-lane SLP and not splitting groups the fix for
PR60276 is no longer effective since it for unknown reason exempted
pure SLP. The following removes this exemption, making
gcc.dg/vect/pr60276.c PASS even with --param vect-single-lane-slp=1
Bootstrapped and tested on x86_64-unkno
13 May 2024 1:30:28 pm NightStrike :
On Thu, May 9, 2024 at 1:03 PM Peter Damianov
wrote:
Windows terminal and mintty both have support for link escape
sequences, and so
auto_enable_urls shouldn't be hardcoded to false. For older versions
of the
windows console, mingw_ansi_fputs's console A
On Thu, May 9, 2024 at 1:03 PM Peter Damianov wrote:
>
> Windows terminal and mintty both have support for link escape sequences, and
> so
> auto_enable_urls shouldn't be hardcoded to false. For older versions of the
> windows console, mingw_ansi_fputs's console API translation logic does mangle
Hi Nathaniel,
>> > There are a couple of other tests that appear to potentially have a
>> > similar issue:
>> >
>> > global-2_a.C
>> > 21:// { dg-final { scan-lang-dump-not {Reachable GMF '::printf[^\n']*'
>> > added} module } }
>> >
>> > global-3_a.C
>> > 15:// { dg-final { scan-lang-dump-not {Re
Hi,
on 2024/5/13 10:57, Jiufu Guo wrote:
> Hi,
>
> For PR96866, when gcc print asm code for modifier "%a" which requires
> an address operand, while the operand is with the constraint "X" which
> allow non-address form. An error message would be reported to indicate
> the invalid asm operands.
>
On Mon, May 13, 2024 at 01:59:51PM +0200, Rainer Orth wrote:
> Hi Nathaniel,
>
> > On Mon, May 13, 2024 at 10:40:30AM +0200, Rainer Orth wrote:
> >> g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:
> >>
> >> FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module
> >> "Depset:0
Hi Nathaniel,
> On Mon, May 13, 2024 at 10:40:30AM +0200, Rainer Orth wrote:
>> g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:
>>
>> FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module "Depset:0
>> decl entity:[0-9]* function_decl:'::printf'"
>> FAIL: g++.dg/modules/stdio-
> > @@ -11751,9 +11767,16 @@ tsubst_friend_class (tree friend_tmpl, tree args)
> > if (tmpl != error_mark_node)
> > {
> > /* The new TMPL is not an instantiation of anything, so we
> > -forget its origins. We don't reset CLASSTYPE_TI_TEMPLATE
> > +forget its origi
On Mon, May 13, 2024 at 10:40:30AM +0200, Rainer Orth wrote:
> g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:
>
> FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module "Depset:0
> decl entity:[0-9]* function_decl:'::printf'"
> FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a scan
On Thu, May 9, 2024 at 10:05 AM Mikael Morin wrote:
>
> Hello,
>
> Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
> > Hi,
> >The former patch adds isfinite optab for __builtin_isfinite.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
> >
> >Thus the builtin might not be
Hi!
On Mon, May 13, 2024 at 10:57:12AM +0800, Jiufu Guo wrote:
> For PR96866, when gcc print asm code for modifier "%a" which requires
> an address operand,
It requires a *memory* operand, and it outputs its address. This is a
generic modifier btw (not rs6000).
> while the operand is with the c
On Tue, 7 May 2024 at 14:42, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu and aarch64-linux-gnu and with Clang 18 on x86_64-
> linux-gnu.
>
> OK for trunk and backport(s)?
OK for all.
>
> -- 8<
>
> Signed-off-by: Matthias Kretz
>
> libst
The following refactors a bit how we perform SLP reduction group
discovery possibly making it easier to have multiple reduction
groups later, esp. with single-lane SLP.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_analyze_slp_instance): Remove
On Mon, 13 May 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, May 10, 2024 2:07 PM
> > To: Richard Biener
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] Allow patterns in SLP reductions
> >
> > On Fri, Mar 1, 2024 at 10:21 AM Ric
On Fri, May 10, 2024 at 03:59:25PM -0400, Jason Merrill wrote:
> > 2024-05-09 Jakub Jelinek
> > Jason Merrill
> >
> > PR lto/113208
> > * cp-tree.h (maybe_optimize_cdtor): Remove.
> > * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only
> > for implicit instan
> -Original Message-
> From: Richard Biener
> Sent: Friday, May 10, 2024 2:07 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Allow patterns in SLP reductions
>
> On Fri, Mar 1, 2024 at 10:21 AM Richard Biener wrote:
> >
> > The following removes the over-br
Hi Evgeny,
Adding David to the CC, who might know the details.
On Mon, May 13, 2024 at 08:44:12AM +, Evgeny Karpov wrote:
> Sunday, May 12, 2024
>
> Thank you for reviewing our changes related to the refactoring of
> extracting the MinGW implementation from ix64.
>
> It was expected to move t
Hi Pan,
> -Original Message-
> From: pan2...@intel.com
> Sent: Monday, May 6, 2024 3:49 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Tamar Christina
> ; richard.guent...@gmail.com;
> hongtao@intel.com; Pan Li
> Subject: [PATCH v4 2/3] VECT: Suppo
Hi Pan,
> -Original Message-
> From: pan2...@intel.com
> Sent: Monday, May 6, 2024 3:48 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Tamar Christina
> ; richard.guent...@gmail.com;
> hongtao@intel.com; Pan Li
> Subject: [PATCH v4 1/3] Internal-fn
On Thu, May 09, 2024 at 01:42:15PM -0400, David Malcolm wrote:
> I've pushed the following changes to releases/gcc-13
> as r13-8741-g89feb3557a0188 through r13-8761-gb7a2697733d19a.
Unfortunately many of the commits contained git commit message wording
that update_git_version can't cope with.
Word
Sunday, May 12, 2024
Mark Wielaard wrote:
> The new cygming.opt.urls and mingw.opt.urls in the
> gcc/config/mingw/cygming.opt.urls directory need to generated by make
> regenerate-opt-urls in the gcc subdirectory. They still contained references
> to
> the gcc/config/i386 directory from which th
g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:
FAIL: g++.dg/modules/stdio-1_a.H -std=c++17 scan-lang-dump module "Depset:0
decl entity:[0-9]* function_decl:'::printf'"
FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a scan-lang-dump module "Depset:0
decl entity:[0-9]* function_decl:'::printf
From: Piotr Trojanek
Recognize references to attributes Put_Image and Object_Size as
language-defined in Ada 2022 and implementation-defined in earlier
versions of Ada. Other attributes listed in Ada 2022 RM, K.2 and
currently implemented in GNAT are correctly categorized.
This change only affec
From: Bob Duff
If a pragma Compile_Time_Warning triggers, and the pragma
is later removed because it is dead code, then the compiler
can return a bad exit code. This causes gprbuild to report
"*** compilation phase failed".
This is because Total_Errors_Detected, which is declared as Nat,
goes ne
From: Piotr Trojanek
Code cleanup; semantics is unaffected.
gcc/ada/
* sem_util.adb (Has_No_Output): Iteration with
First_Formal/Next_Formal involves Entity_Ids.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_util.adb | 2 +-
1 file changed, 1 insertion(+
On Mon, 13 May 2024, Jakub Jelinek wrote:
> Hi!
>
> We pattern recognize already many different patterns, and closest to the
> requested one also
>yc = (type) y;
>zc = (type) z;
>x = yc + zc;
>w = (typeof_y) x;
>if (x > max)
> where y/z has the same unsigned type and type is a
From: Piotr Trojanek
The removed code is no longer needed (and causes assertion failures).
Most likely it should have been using the Split_PPC flag.
gcc/ada/
* sem_util.adb (Is_Potentially_Unevaluated): Remove code for
recovering the original structure of expressions with AND TH
1 - 100 of 132 matches
Mail list logo
