On Fri, May 24, 2024 at 10:46 AM Mariam Arutunian
wrote:
>
> 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 inf
On Tue, May 28, 2024 at 8:36 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will im
On Tue, May 28, 2024 at 8:37 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch adds an optab for __builtin_isnormal. The normal check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will im
On Mon, May 27, 2024 at 9:48 AM Jiawei wrote:
>
> Return NULL_TREE when genop3 equal EXACT_DIV_EXPR.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652641.html
>
> version log v3: remove additional POLY_INT_CST check.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652795.html
OK.
Tha
Hi,
on 2024/5/27 20:54, Richard Biener wrote:
> On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
>>
>> Hi,
>> This patch adds an optab for __builtin_isfinite. The finite check can be
>> implemented on rs6000 by a single instruction. It needs an optab to be
>> expanded to the certain sequenc
Hi PA, hi all,
two remarks while quickly browsing the code:
Paul-Antoine Arras:
+ if (n->sym->ts.type != BT_DERIVED
+ || !n->sym->ts.u.derived->ts.is_iso_c)
+ {
+ gfc_error ("argument list item %qs in "
+
On Wed, May 15, 2024 at 12:59 PM Alexander Monakov wrote:
>
>
> Hello,
>
> I'd like to ask if anyone has any new thoughts on this patch.
>
> Let me also point out that valgrind/memcheck.h is permissively
> licensed (BSD-style, rest of Valgrind is GPLv2), with the intention
> to allow importing int
On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>
> Including the following changes:
> * The definition of the new internal function .ACCESS_WITH_SIZE
> in internal-fn.def.
> * C FE converts every reference to a FAM with a "counted_by" attribute
> to a call to the internal function .ACCESS_WI
On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>
I have no comments here, if Siddesh is OK with this I approve.
> gcc/ChangeLog:
>
> * tree-object-size.cc (access_with_size_object_size): New function.
> (call_object_size): Call the new function.
>
> gcc/testsuite/ChangeLog:
>
>
On Fri, Apr 12, 2024 at 3:55 PM Qing Zhao wrote:
>
> to carry the TYPE of the flexible array.
>
> Such information is needed during tree-object-size.cc.
>
> We cannot use the result type or the type of the 1st argument
> of the routine .ACCESS_WITH_SIZE to decide the element type
> of the original
Hi all,
This patch aims to acheive EQ/NE comparison between avx512 kmask and -1
by using kxortest with checking CF.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,-m64}. Ok for trunk?
BRs,
Lin
gcc/ChangeLog:
PR target/113609
* config/i386/sse.md
(*kortest_cmp_se
When the neutral op is the initial value we might need to convert
it from pointer to integer.
Bootstrapped and tested no x86_64-unknown-linux-gnu, pushed.
This shows with the SLP single-lane reduction discovery.
* tree-vect-loop.cc (get_initial_defs_for_reduction): Convert
neutra
From: Pan Li
This patch would like to add the middle-end presentation for the
saturation sub. Aka set the result of add to the min when downflow.
It will take the pattern similar as below.
SAT_SUB (x, y) => (x - y) & (-(TYPE)(x >= y));
For example for uint8_t, we have
* SAT_SUB (255, 0) =>
On Mon, May 13, 2024 at 5:25 PM Andrew Pinski wrote:
>
> 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.
>
On Mon, 27 May 2024 at 09:26, Jakub Jelinek wrote:
>
> Hi!
>
> The r13-8207-g17acf9fbeb10d7adad commit changed some tests to use
> -lstdc++exp instead of -lstdc++_libbacktrace, but it didn't change
> the 19_diagnostics/stacktrace/hash.cc test, presumably because
> when it was added on the trunk, i
Not sure why these all are popping up recently...
Anyway: pushed.
Gerald
---
htdocs/news.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index ca3e7dc5..b7a6f479 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -512,7 +512,7 @@
On Mon, 10 Jul 2023, Kyrylo Tkachov via Gcc-patches wrote:
> I know the GCC source is inconsistent on this but the proper branding
> these days is "ARM" -> "Arm" and "ARMv8.1-M" -> "Armv8.1-M".
Arm, Red Hat, and SUSE - those three are spelt incorrectly by third
parties more often than not, it se
On Fri, May 24, 2024 at 11:27 AM Feng Xue OS
wrote:
>
> Hi,
>
> The patch was updated with the newest trunk, and also contained some minor
> changes.
>
> I am working on another new feature which is meant to support pattern
> recognition
> of lane-reducing operations in affine closure originated
On Sat, May 25, 2024 at 4:45 PM Feng Xue OS wrote:
>
> Some utility functions (such as vect_look_through_possible_promotion) that are
> to find out certain kind of direct or indirect definition SSA for a value, may
> return the original one of the SSA, not its pattern representative SSA, even
> pa
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, May 22, 2024 10:29 AM
> To: Richard Sandiford
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: RE: [PATCH 2/4]AArch64: add new tuning param and attribute for
> enab
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, May 22, 2024 12:24 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 3/4]AArch64: add new alternative with early clobber to
>
On Sat, May 25, 2024 at 4:54 PM Feng Xue OS wrote:
>
> Both derived classes ( loop_vec_info/bb_vec_info) have their own "bbs"
> field, which have exactly same purpose of recording all basic blocks
> inside the corresponding vect region, while the fields are composed by
> different data type, one i
On Tue, 28 May 2024, Richard Biener wrote:
> On Wed, May 15, 2024 at 12:59 PM Alexander Monakov wrote:
> >
> >
> > Hello,
> >
> > I'd like to ask if anyone has any new thoughts on this patch.
> >
> > Let me also point out that valgrind/memcheck.h is permissively
> > licensed (BSD-style, rest of
The following avoids accounting single-lane SLP to the discovery
limit. As the two testcases show this makes discovery fail,
unfortunately even not the same across targets. The following
should fix two FAILs for GCN as a side-effect.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
On 27/05/24 22:07 +0200, François Dumont wrote:
In C++98 this test fails with:
Excess errors:
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned
int)' writing between 2 and 92233720368
On Mon, 27 May 2024 at 05:37, François Dumont wrote:
>
> Here is a new version working also in C++98.
Can we use a different solution that doesn't involve an explicit
template argument list for that __uninitialized_fill_n_a call?
-+this->_M_impl._M_finish = std::__uninitialized_fill_n_a
> IMO, there is no need for CONST_INT_P condition, we should also allow
> symbol_ref, label_ref and const (all allowed by
> x86_64_immediate_operand predicate), these all decay to an immediate
> value.
Changed.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk.
For MEM, rtx_
Let's make https://gcc.gnu.org/gcc-15/changes.html a bit more useful …
While there were several useful Fortran commits already, only one seems
to be about a new feature.
Thus, document selected_logical_kind and the ISO_FORTRAN_ENV additions.
Comments or suggestions before I commit it?
Tobias
On Tue, May 28, 2024 at 11:46 AM Alexander Monakov wrote:
>
>
> On Tue, 28 May 2024, Richard Biener wrote:
>
> > On Wed, May 15, 2024 at 12:59 PM Alexander Monakov
> > wrote:
> > >
> > >
> > > Hello,
> > >
> > > I'd like to ask if anyone has any new thoughts on this patch.
> > >
> > > Let me als
On Tue, 28 May 2024, Richard Biener wrote:
> > I am a bit confused what you mean by "cheaper". Could it be that we are not
> > on the same page regarding the machine code behind client requests?
>
> Probably "cheaper" in register usage.
But it doesn't matter considering that execution under Va
On Tue, May 28, 2024 at 12:48 PM liuhongt wrote:
>
> > IMO, there is no need for CONST_INT_P condition, we should also allow
> > symbol_ref, label_ref and const (all allowed by
> > x86_64_immediate_operand predicate), these all decay to an immediate
> > value.
>
> Changed.
>
> Bootstrapped and reg
On Tue, May 28, 2024 at 1:38 PM Alexander Monakov wrote:
>
>
> On Tue, 28 May 2024, Richard Biener wrote:
>
> > > I am a bit confused what you mean by "cheaper". Could it be that we are
> > > not
> > > on the same page regarding the machine code behind client requests?
> >
> > Probably "cheaper"
On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote:
>
> Hi,
>
> on 2024/5/27 20:54, Richard Biener wrote:
> > On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
> >>
> >> Hi,
> >> This patch adds an optab for __builtin_isfinite. The finite check can be
> >> implemented on rs6000 by a single inst
Hi all,
the attached patch fixes a memory leak with unlimited polymorphic return types.
The leak occurred, because an expression with side-effects was evaluated twice.
I have substituted the check for non-variable expressions followed by creating a
SAVE_EXPR with checking for trees with side effec
We process asm memory input/outputs with constraints to ESCAPED
but for this temporarily build an ADDR_EXPR. The issue is that
the used build_fold_addr_expr ends up wrapping the ADDR_EXPR in
a conversion which ends up producing &ANYTHING constraints which
is quite bad. The following uses get_cons
Code generation for contiguous load vectorization can already deal
with generalized avoidance of loading from a gap. The following
extends detection of peeling for gaps requirement with that,
gets rid of the old special casing of a half load and makes sure
when we do access the gap we have peeling
Seems good, thanks Tobias!
FX
The stored-to ANYTHING handling has more holes, uncovered by treating
volatile accesses as ANYTHING. We fail to properly build the
pred and succ graphs, in particular we may not elide direct nodes
from receiving from STOREDANYTHING.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Hi Maciej (Hi David, added to CC),
On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> As reported in PR target/79646 and fixed by a change proposed by Abe we
> have a couple of issues with the descriptions of the VAX floating-point
> format options in the option definition file. Add
On Wed, 15 May 2024 at 20:50, Matthias Kretz wrote:
>
> Tested on aarch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu,
> x86_64-linux-gnu (-m64, -m32, -mx32), and arm-linux-gnueabi
>
> OK for trunk?
OK
> And when backporting, should I squash it with the commit that
> introduced the reg
The dump scanning is supposed to check that we do not merge two
sligtly different gathers into one SLP node but since we now
SLP the store scanning for "ectorizing stmts using SLP" is no
longer good. Instead the following makes us look for
"stmt 1 .* = .MASK" which would be how the second lane of
Changed as the comments.
Thanks,
Feng
From: Richard Biener
Sent: Tuesday, May 28, 2024 5:34 PM
To: Feng Xue OS
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] vect: Use vect representative statement instead of
original in patch recog [PR115060]
On Sat,
Several of the 19_diagnostics/stacktrace tests FAIL on Solaris/SPARC (32
and 64-bit), Solaris/x86 (32-bit only), and several other targets:
FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test
FAIL: 19_diagn
On Tue, 28 May 2024 at 15:25, Rainer Orth wrote:
>
> Several of the 19_diagnostics/stacktrace tests FAIL on Solaris/SPARC (32
> and 64-bit), Solaris/x86 (32-bit only), and several other targets:
>
> FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
> FAIL: 19_diagnostics/stac
> On Tue, 2024-05-28 at 15:03 +0200, Mark Wielaard wrote:
> Hi Maciej (Hi David, added to CC),
>On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> > As reported in PR target/79646 and fixed by a change proposed by
> > Abe we
> > have a couple of issues with the descriptions of the VAX
commit 05daf617ea22e1d818295ed2d037456937e23530
Author: Jeff Law
Date: Sat May 25 12:39:05 2024 -0600
[committed] [v2] More logical op simplifications in simplify-rtx.cc
does some simplifications, and then `bseli.b $w1,$w0,255` is found that
it is same with `or.v $w1,$w0,$w1`. So there wil
Because bbs of loop_vec_info need to be allocated via old-fashion
XCNEWVEC, in order to receive result from dfs_enumerate_from(),
so have to make bb_vec_info align with loop_vec_info, use
basic_block * instead of vec. Another reason is that
some loop vect related codes assume that bbs is a pointer,
Andrew Carlotti writes:
> The existing implementation of this function was convoluted, and had
> multiple control flow errors that became apparent to me while reading
> the code:
>
> 1. The initial early return only checked the properties of the first
> exclusion in the list, when these properties
PR bootstrap/115167 reports a bootstrap failure on AIX triggered by
r15-636-g770657d02c986c whilst building f951 in stage 2, due to
the linker not being able to find symbols for:
vtable for range_label_for_type_mismatch
range_label_for_type_mismatch::get_text(unsigned int) const
The only user
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-866-g2dbb1c124c1e58.
gcc/ChangeLog:
PR analyzer/115203
* diagnostic-path.h
(simple_diagnostic_path::disable_event_localization): New.
(simple_diagnostic_path::m_localize_events): N
Ping.
This patch has actually been *very* helpful to me when debugging
selftest failures involving ASSERT_STREQ.
Thanks
Dave
On Fri, 2024-05-17 at 15:51 -0400, David Malcolm wrote:
> Currently when ASSERT_STREQ or ASSERT_STREQ_AT fail we print
> both strings to stderr. However it can be hard to
Improve test coverage by removing 'prune-output' given that the features
are implemented in the meanwhile.
Comments, suggestions? Otherwise I will commit the patch as obvious.
Tobias
testsuite/*/gomp: Remove 'dg-prune-output "not supported yet"'
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/l
On Tue, May 28, 2024 at 07:43:00PM +0200, Tobias Burnus wrote:
> Improve test coverage by removing 'prune-output' given that the features are
> implemented in the meanwhile.
>
> Comments, suggestions? Otherwise I will commit the patch as obvious.
>
> Tobias
> testsuite/*/gomp: Remove 'dg-prune-o
PR Target/84790.
The gp init sequence
li $2,%hi(_gp_disp)
addiu $3,$pc,%lo(_gp_disp)
sll $2,16
addu$2,$3
is generated directly in `mips_output_function_prologue`, and does
not appear in the RTL.
So the IRA/IPA passes are not aware that $2/$3 have been
YunQiang Su 于2024年5月22日周三 17:54写道：
>
> If `find_a_program` cannot find `as/ld/objcopy` and we are a cross toolchain,
> the final fallback is `as/ld` of system. In fact, we can have a try with
> -as/ld/objcopy before fallback to native as/ld/objcopy.
>
> This patch is derivatived from Debian's pat
Thanks.
Committed with the change to the testcase.
Bootstraps on x86_64-pc-linux-gnu with no regressions.
Andrew
On 5/28/24 02:49, Richard Biener wrote:
On Tue, May 28, 2024 at 1:24 AM Andrew MacLeod wrote:
The strlen pass currently has a local ranger instance, but when it
invokes SCEV or
The original patch causing the PR made ranger's cache re-entrant to
enable SCEV to use the current range_query when called from within ranger..
SCEV uses the currently active range query (via get_range_query()) for
picking up values. fold_using_range is the general purpose stmt folder
many
On 5/26/24 09:01, Nathaniel Shead wrote:
Is this approach OK? Alternatively I suppose we could do a deep copy of
the overload list when this occurs to ensure we don't affect existing
referents, would that be preferable?
This strategy makes sense, but I have other concerns:
Bootstrapped and r
On 5/25/24 19:18, Patrick Palka wrote:
Bootstrap and regtest on x86_64-pc-linux-gnu in progress,
does this look OK for trunk if successful?
OK.
-- >8 --
When propagating structural equality in build_cp_fntype_variant, we
should consider structural equality of the exception-less variant, not
On Fri, May 24, 2024 at 10:15:56AM -0400, Jason Merrill wrote:
> On 5/23/24 19:57, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > We already warn for:
> >
> >x = std::move (x);
> >
> > which triggers:
> >
> >warning: moving 'x'
On 5/25/24 08:12, Alexandre Oliva wrote:
On Apr 27, 2023, Alexandre Oliva wrote:
On Apr 14, 2023, Alexandre Oliva wrote:
On Mar 23, 2023, Alexandre Oliva wrote:
This patch introduces infrastructure for targets to add an offset to
the label issued after the call_insn to set the call_return_p
Hi,
this patch disables movmisalign by default and introduces
the -mno-vector-strict-align option to override it and re-enable
movmisalign. For now, generic-ooo is the only uarch that supports
misaligned vector access.
The patch also adds a check_effective_target_riscv_v_misalign_ok to
the tests
-fopenmp-force-usm can be useful for some badly written code. Explicity
using 'omp requires' makes more sense but still. It might also make
sense for testing purpose.
Unfortunately, I did not see a simple way of testing it. When trying it
manually, I looked at the 'a.xamdgcn-amdhsa.c' -save-te
Hi Andre,
On 5/28/24 14:10, Andre Vehreschild wrote:
Hi all,
the attached patch fixes a memory leak with unlimited polymorphic return types.
The leak occurred, because an expression with side-effects was evaluated twice.
I have substituted the check for non-variable expressions followed by crea
On Tue, 2024-05-28 at 11:41 -0400, David Malcolm wrote:
> > On Tue, 2024-05-28 at 15:03 +0200, Mark Wielaard wrote:
> > Hi Maciej (Hi David, added to CC),
>
> > On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> > > As reported in PR target/79646 and fixed by a change proposed by
> > >
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-874-g9bda2c4c81b668.
libcpp/ChangeLog:
* Makefile.in (TAGS_SOURCES): Add include/label-text.h.
* include/label-text.h: New file.
* include/rich-location.h:
Simplify the table of default colors, avoiding the need to manually
add the strlen of each entry.
Consolidate the global state in diagnostic-color.cc into a
g_color_dict, adding selftests for the new class diagnostic_color_dict.
No functional change intended.
Successfully bootstrapped & regrteste
Avoid selftest.h requiring the "tree" type.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-873-gfb7a943ead689e.
gcc/analyzer/ChangeLog:
* region-model.cc: Include "selftest-tree.h".
gcc/ChangeLog:
* function-te
> Date: Mon, 27 May 2024 12:57:53 -0600
> From: Jeff Law
> > * resource.cc: Include cfgrtl.h. Use BLOCK_FOR_INSN (insn)->index
> > instead of calling find_basic_block (insn). Assert for not -1.
> > (find_basic_block): Remove function.
> > (init_resource_info): Call compute_bb_fo
On Sat, May 25, 2024 at 09:12:05AM -0300, Alexandre Oliva wrote:
You sent multiple patch series in one thread, and multiple versions of
the same series even.
This is very hard to even *read*, let alone work with. Please don't.
Segher
I can indeed restore _M_initialize_dispatch as it was before. It was not
fixing my initial problem. I simply kept the code simplification.
libstdc++: Use RAII to replace try/catch blocks
Move _Guard into std::vector declaration and use it to guard all
calls to
vector _M_allocate.
Use MOVD/PEXTRD and MOVD/PINSRD insn sequences to move DImode value
between XMM and GPR register sets for SSE4.1 x86_32 targets in order
to avoid spilling the value to stack.
The load from _Atomic location a improves from:
movqa, %xmm0
movq%xmm0, (%esp)
movl(%esp), %eax
On Fri, 24 May 2024, Kewen.Lin wrote:
> Following your suggestion and comments, I made this patch
> for mode_for_floating_type first, considering this touches
> a few FE and port specific code, I think I have to split
> it into a patch series. Before making that, I'd like to
> ensure this meets w
Thank you for the comments. See my answers below:
Joseph, please see the last question, I need your help on it. Thanks a lot for
the help.
Qing
> On May 28, 2024, at 03:38, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>>
>> Including the following changes:
>> *
> On May 28, 2024, at 03:39, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>>
>
> I have no comments here, if Siddesh is OK with this I approve.
thanks.
Qing
>
>> gcc/ChangeLog:
>>
>>* tree-object-size.cc (access_with_size_object_size): New function.
> On May 28, 2024, at 03:43, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:55 PM Qing Zhao wrote:
>>
>> to carry the TYPE of the flexible array.
>>
>> Such information is needed during tree-object-size.cc.
>>
>> We cannot use the result type or the type of the 1st argument
>> of the r
On Sat, May 25, 2024 at 09:13:12AM -0300, Alexandre Oliva wrote:
> Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
> out of a single call insn, but the call (bl) or jump (b) is not always
> the last opcode in the sequence.
> This does not seem to be a problem for exception h
YunQiang Su writes:
> If `find_a_program` cannot find `as/ld/objcopy` and we are a cross toolchain,
> the final fallback is `as/ld` of system. In fact, we can have a try with
> -as/ld/objcopy before fallback to native as/ld/objcopy.
>
> This patch is derivatived from Debian's patch:
> gcc-searc
On Fri, 24 May 2024, Martin Uecker wrote:
> This is another version of this patch with two changes:
>
> - I added a fix (with test) for PR 115177 which is just the same
> issue for hardbools which are internally implemented as enums.
>
> - I fixed the golang issue. Since the addition of the main
On Sun, 26 May 2024, Martin Uecker wrote:
> This is the patch I sent previously, but I tried to improve the
> description and added a long comment. This patch is needed so
> that we do not have to update TYPE_CANONICAL of structures / unions
> when a tagged type is completed that is (recursively)
On Sun, 26 May 2024, Martin Uecker wrote:
> +/* Helper function for comptypes. For two compatible types, return 1
> + if they pass consistency checks. In particular we test that
> + TYPE_CANONICAL ist set correctly, i.e. the two types can alias. */
s/ist/is/. OK with that fix.
--
Joseph
Richard Biener writes:
> On Mon, May 27, 2024 at 9:48 AM Jiawei wrote:
>>
>> Return NULL_TREE when genop3 equal EXACT_DIV_EXPR.
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652641.html
>>
>> version log v3: remove additional POLY_INT_CST check.
>> https://gcc.gnu.org/pipermail/gcc-patche
HAO CHEN GUI writes:
> Hi,
> This patch adds an optab for __builtin_isfinite. The finite check can be
> implemented on rs6000 by a single instruction. It needs an optab to be
> expanded to the certain sequence of instructions.
>
> The subsequent patches will implement the expand on rs6000.
>
>
The dom_ranger class used for fast vrp no longer needs it's own local
gimple_outgoing_range object as it is now always available from the
range_query parent class.
The builtin_unreachable code for adjusting globals and removing the
builtin calls during the final VRP pass can now function with
Rebased and combined these two patches into a series for precommit-CI to
properly test.
Edwin Lu (1):
RISC-V: Fix testcases renamed test flag options
Greg McGary (1):
RISC-V: add option -m(no-)autovec-segment
gcc/config/riscv/autovec.md | 4 +-
gcc/config/riscv/riscv-opts
From: Greg McGary
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/autovec.md (vec_mask_len_load_lanes,
vec_mask_len_store_lanes):
From: Edwin Lu
Some testcases still had --param=riscv-autovec-preference=_,
update to use -mrvv-vector-bits=_.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/no-segment.c: Update dejagnu flags
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c:
Ditto
On 5/28/24 14:55, Patrick O'Neill wrote:
> From: Greg McGary
>
> 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/autovec.md (vec_mas
On 5/28/24 14:55, Patrick O'Neill wrote:
> From: Edwin Lu
>
> Some testcases still had --param=riscv-autovec-preference=_,
> update to use -mrvv-vector-bits=_.
And this can be squashed with prev one, maybe added Tested-by Edwin.
Thx,
-Vineet
On Tue, May 28, 2024 at 02:09:50PM +0200, Richard Biener wrote:
> On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote:
> > As Haochen's previous reply, I think there are three cases:
> > 1) no optab defined, fold in a generic way;
> > 2) optab defined, SUCC, expand as what it defines;
> > 3) opt
Hi!
On Mon, May 27, 2024 at 05:37:23PM +0800, HAO CHEN GUI wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
>errno_set = true; builtin_optab = ilogb_optab; break;
> CASE_FLT_FN (BUILT_IN_ISINF):
>bui
While most of the nvptx systems I have access to don't have the support
for CU_DEVICE_ATTRIBUTE_PAGEABLE_MEMORY_ACCESS_USES_HOST_PAGE_TABLES,
one has:
Tesla V100-SXM2-16GB (as installed, e.g., on ORNL's Summit) does support
this feature. And with that feature, unified-shared memory support doe
Rebased to squash Edwin's fixup into Greg's patch. Split out the middle-end
change and xfailed the associated testcase so the second patch can land
seperately.
Relying on pre-commit CI for full testing.
Greg McGary (2):
RISC-V: add option -m(no-)autovec-segment
Prevent divide-by-zero
gcc/co
From: Greg McGary
gcc/ChangeLog:
* gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent
divide-by-zero.
* testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove xfail.
---
gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c | 1 -
gcc/tree-vect-stmts.cc
From: Greg McGary
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/autovec.md (vec_mask_len_load_lanes,
vec_mask_len_store_lanes):
Hello-
May I please ping this one (now for GCC 15)? Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
-Lewis
On Sat, Feb 10, 2024 at 9:02 AM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
>
> May I please ping this o
I just created two PRs for adding those new options into
riscv-toolchain-conventions, so that we could make sure it aligned
with clang/LLVM community.
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/49
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/50
On Wed,
on 2024/5/28 20:09, Richard Biener wrote:
> On Tue, May 28, 2024 at 9:09 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> on 2024/5/27 20:54, Richard Biener wrote:
>>> On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
Hi,
This patch adds an optab for __builtin_isfinite. The finite check ca
Richard Sandiford 于2024年5月29日周三 05:28写道：
>
> YunQiang Su writes:
> > If `find_a_program` cannot find `as/ld/objcopy` and we are a cross
> > toolchain,
> > the final fallback is `as/ld` of system. In fact, we can have a try with
> > -as/ld/objcopy before fallback to native as/ld/objcopy.
> >
> >
FAST_VRP uses a non-ranger gori_on_edge routine to calculate the full
set of SSA ranges that can be calculated on an edge. It allows an
optional outgoing_edge_range object if one wanted to use switches.
This is now integrated with the gori () method of a range_query, and is
no longer neede
1 - 100 of 129 matches
Mail list logo
