Hi,
When c-typeck.cc:c_build_qualified_type builds an array type
from its element type, it does not copy the address space of
the element type to the array type itself. This is unlike
tree.cc:build_array_type_1, which explicitly does
TYPE_ADDR_SPACE (t) = TYPE_ADDR_SPACE (elt_type);
If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKLOAD to prevent
it to be transformed to vpblendd.
Bootstrapped and regtested on
On 6/20/23 14:49, Richard Sandiford via Gcc-patches wrote:
The SVE handling of stack clash protection copied the stack
pointer to X11 before the probe and set up X11 as the CFA
for unwind purposes:
/* This is done to provide unwinding information for the stack
adjustments we're
On Tue, Jun 20, 2023 at 3:37 PM Ian Lance Taylor wrote:
> On Tue, Jun 20, 2023 at 11:35 AM Andreas Schwab
> wrote:
> >
> > On Jun 20 2023, Ian Lance Taylor via Gcc-patches wrote:
> >
> > > This libgo patches changes the runtime pacakge to use a C function to
> call mmap.
> > >
> > > The final
You should remove all "unspec" related of "n" ncopysign including
riscv-vector-builtins-bases.cc
vector.md/ vector-iterators.md
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-20 20:47
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH]
Hi Paul,
On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did
On Jun 20 2023, Ian Lance Taylor wrote:
> OK, but I think that it does have something to do with big-endian.
> The bug was that on some 32-bit systems it was passing a 64-bit value
> to a function that expected a 32-bit value. The problem didn't show
> up on 32-bit x86 because it is
Several gcc.target/aarch64/sve/pcs tests started failing after
6a2e8dcbbd4, because the tests weren't robust against whether
an indirect argument register or the stack pointer was used as
the base for stores.
The patch allows either base register when there is only one
indirect argument. It
The SVE handling of stack clash protection copied the stack
pointer to X11 before the probe and set up X11 as the CFA
for unwind purposes:
/* This is done to provide unwinding information for the stack
adjustments we're about to do, however to prevent the optimizers
from
Richard Biener writes:
> On Mon, 19 Jun 2023, Richard Sandiford wrote:
>
>> Jeff Law writes:
>> > On 6/16/23 06:34, Richard Biener via Gcc-patches wrote:
>> >> IVOPTs has strip_offset which suffers from the same issues regarding
>> >> integer overflow that split_constant_offset did but the
Hi!
On 2023-06-19T12:37:52+0100, Andrew Stubbs wrote:
> This patch adds just enough TImode vector support to use them for moving
> data about.
Andrew tells me this need not be worried about, but -- for my future self
searching email archives for FAILs/ICEs -- I'd like to at least document
here
Le 20/06/2023 à 18:30, Tobias Burnus a écrit :
On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote:
Is there a better way to detect a type(c_ptr) formal argument?
u.derived->intmod_sym_id == ISOCBINDING_PTR ?
&& u.derived->from_intmod == INTMOD_ISO_C_BINDING ?
On Thu, May 25, 2023 at 2:32 AM naveenh--- via Gcc-patches
wrote:
>
> From: Naveen H S
>
> This patch adds support scalar_storage_order attribute to C++ front-end.
> It treats the opposite order fields similar as the packed fields are
> treated such that they will not bind to references.
> For
Tamar Christina writes:
> Hi All,
>
> define_cond_exec does not support the special @@ syntax
> and so can't support {@. As such just remove support
> for it.
>
> Bootstrapped and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR bootstrap/110324
> *
Hi Marc,
On 20/06/2023 15:47, Marc Poulhiès wrote:
> Hi,
>
> >> The package Interfaces.CHERI provides intrinsic bindings and
> >> helper functions to allow software to query, create, and
> >> manipulate CHERI capabilities.
> >
> > I'm curious what the motivation for these intrinsic wrappers is,
Hi!
The patch looks great now, thanks you!
But the commit message needs some work:
First off, the subject, which is a short (50 character max!) summary of
what the patch is about.
Fix power10 fusion and -fstack-protector, PR target/105325
There is absolutely nothing to do with stack protector,
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote:
> On 1/25/23 13:06, Ben Boeckel wrote:
> > - header-unit information fields
> >
> > Header units (including the standard library headers) are 100%
> > unsupported right now because the `-E` mechanism wants to import their
> > BMIs. A
> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote:
>
> On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>>> So for
>>>
>>> struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; };
>>>
>>> one knows during parsing that the .d is a designator
>>> and that .c is not.
>>
>>
On Tue, Jun 20, 2023 at 11:35 AM Andreas Schwab wrote:
>
> On Jun 20 2023, Ian Lance Taylor via Gcc-patches wrote:
>
> > This libgo patches changes the runtime pacakge to use a C function to call
> > mmap.
> >
> > The final argument to mmap, of type off_t, varies. In
> > https://go.dev/cl/445375
On Jun 20 2023, Ian Lance Taylor via Gcc-patches wrote:
> This libgo patches changes the runtime pacakge to use a C function to call
> mmap.
>
> The final argument to mmap, of type off_t, varies. In
> https://go.dev/cl/445375
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604158.html)
> Am 20.06.2023 um 18:46 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> In the following testcase we fail to pattern recognize the least significant
> .UADDC call. The reason is that arg3 in that case is
> _3 = .ADD_OVERFLOW (...);
> _2 = __imag__ _3;
> _1 = _2 != 0;
> arg3 =
Also change some internal variables and some function arguments to bool.
gcc/ChangeLog:
* calls.h (setjmp_call_p): Change return type from int to bool.
* calls.cc (struct arg_data): Change "pass_on_stack" to bool.
(store_one_arg): Change return type from int to bool
and adjust
Does this testsuite patch look OK?
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html
Thanks
David
On Mon, 2023-06-12 at 19:11 -0400, David Malcolm wrote:
> Please can someone review this testsuite patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html
>
>
Hi All,
define_cond_exec does not support the special @@ syntax
and so can't support {@. As such just remove support
for it.
Bootstrapped and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR bootstrap/110324
* gensupport.cc (convert_syntax): Explicitly check for RTX
This libgo patches changes the runtime pacakge to use a C function to call mmap.
The final argument to mmap, of type off_t, varies. In
https://go.dev/cl/445375
(https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604158.html)
we changed it to always use the C off_t type, but that broke 32-bit
On Mon, Jun 19, 2023 at 17:33:58 -0400, Jason Merrill wrote:
> On 5/12/23 10:24, Ben Boeckel wrote:
> > `file` can be omitted (the `output_stream` will be used then). I *think*
> > I see that adding:
> >
> > %{fdeps_file:-fdeps-file=%{!o:%b.ddi}%{o*:%.ddi%*}}
>
> %{!fdeps-file: but yes.
>
Hi!
In the following testcase we fail to pattern recognize the least significant
.UADDC call. The reason is that arg3 in that case is
_3 = .ADD_OVERFLOW (...);
_2 = __imag__ _3;
_1 = _2 != 0;
arg3 = (unsigned long) _1;
and while before the changes arg3 has a single use in some
On Tue, 2023-06-20 at 12:22 -0400, Jason Merrill via Gcc-patches wrote:
> diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
> index aaef8915..6dbe5d45 100644
> --- a/htdocs/bugs/index.html
> +++ b/htdocs/bugs/index.html
> @@ -122,6 +122,9 @@ three of which can be obtained from the
On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote:
Is there a better way to detect a type(c_ptr) formal argument?
u.derived->intmod_sym_id == ISOCBINDING_PTR ?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft
As announced on gcc@.
---
htdocs/bugs/index.html | 3 +
htdocs/conduct-faq.html | 66
htdocs/conduct-report.html | 122 ++
htdocs/conduct-response.html | 141 +++
htdocs/conduct.html | 118
Dear All,
This patch is verging on obvious. The PR was originally, incorrectly
blocking PR87477 and the testcase has remained in my 'associate'
directory. I thought that it is time to get shot of it!
Is there a better way to detect a type(c_ptr) formal argument?
Subject to advice on the
On Tue, 21 Mar 2023, Ken Matsui wrote:
> This patch lets libstdc++ use new built-in trait __is_const.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_const): Use __is_const built-in trait.
We should also use it in is_const_v (likewise for the __is_array and
__is_volatile
I notice there's some refactor in vectorizable_conversion
for code_helper,so I've adjusted my patch to that.
Here's the patch I'm going to commit.
We have already use intermidate type in case WIDEN, but not for NONE,
this patch extended that.
gcc/ChangeLog:
PR target/110018
*
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch gets std::is_reference to dispatch to new built-in trait
> __is_reference.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_reference): Use __is_reference built-in
> trait.
> (is_reference_v):
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch implements built-in trait for std::is_reference.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_reference.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE.
> * semantics.cc
On Mon, 12 Jun 2023, Ken Matsui via Gcc-patches wrote:
> This patch implements built-in trait for std::is_function.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_function.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION.
> * semantics.cc
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch gets std::is_function to dispatch to new built-in trait
> __is_function.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_function): Use __is_function built-in
> trait.
> (is_function_v): Likewise.
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch implements built-in trait for std::is_void. Since the new built-in
> name is __is_void, to avoid unintentional macro replacement, this patch also
> involves the removal of the existing __is_void in helper_functions.h and
>
On Fri, 2022-08-05 at 12:04 -0400, Lewis Hyatt via Gcc-patches wrote:
>
> When libcpp reports diagnostics whose locus is a macro name (such as
> for
> -Wunused-macros), it uses the location in the cpp_macro object that
> was
> stored by _cpp_new_macro. This is currently set to pfile-
>
On Thu, 15 Jun 2023, Ken Matsui via Libstdc++ wrote:
> Hi,
>
> For those curious about the performance improvements of this patch, I
> conducted a benchmark that instantiates 256k specializations of
> is_object_v based on Patrick's code. You can find the benchmark code
> at this link:
>
>
On Tue, Jun 20, 2023 at 02:08:07PM +, Li, Pan2 via Gcc-patches wrote:
> Thanks Jakub for the explanation, I have a try like below patch but I am not
> quite sure it is expected, and where should I put the assertion.
>
> > If yes, it needs to
> > be unsigned short, if not, we should add an
All done. Welcome Lehua.
I have received the system notification email, thank you very much.
Best,
Lehua
on a structure with a C99 flexible array member being nested in
another structure
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct or union (possibly recursively) as the last
field.
This patch is to introduce the IR bit
__builtin_object_size should treat struct with TYPE_INCLUDES_FLEXARRAY as
flexible size.
gcc/ChangeLog:
PR tree-optimization/101832
* tree-object-size.cc (addr_object_size): Handle structure/union type
when it has flexible size.
gcc/testsuite/ChangeLog:
PR
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
* A
This is the 10th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
compared to the 9th patch, the ONLY change is:
I split the 1st patch into the following two patches:
patch 1/3: Introduce IR bit
On Sat, 17 Jun 2023, Ken Matsui via Gcc-patches wrote:
> Hi,
>
> I conducted a benchmark for remove_pointer as well as is_object. Just
> like the is_object benchmark, here is the benchmark code:
>
> https://github.com/ken-matsui/gcc-benches/blob/main/remove_pointer_benchmark.cc
>
> On my
Thanks Richi's comments.
I have sent a new patch with addressing your comments.
I am so sorry V2 patch just broke on boostrap.
I sent the V3 patch that fixed it.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-20 20:18
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
From: Ju-Zhe Zhong
gcc/ChangeLog:
* internal-fn.cc (expand_partial_store_optab_fn): Add
LEN_MASK_{LOAD,STORE} vectorizer support.
(internal_load_fn_p): Ditto.
(internal_store_fn_p): Ditto.
(internal_fn_mask_index): Ditto.
On Tue, 20 Jun 2023 at 09:29, Jonathan Wakely wrote:
>
>
> On Tue, 20 Jun 2023 at 01:54, Patrick Palka wrote:
>
>> On Fri, 9 Jun 2023, Jonathan Wakely via Libstdc++ wrote:
>>
>> > Tested powerpc64le-linux. Pushed to trunk.
>> >
>> > This makes sense to backport after some soak time on trunk.
>>
Hi all,
On Tue, 2023-06-20 at 07:11 -0600, Jeff Law wrote:
> On 6/20/23 04:56, Robin Dapp wrote:
> > > Could you merge it ?
> > > By the way, could Lehua get the write access?
> >
> > IMHO nothing stands in the way but I'll defer to Jeff to have
> > the "official seal" :)
> > Once he ACKs Lehua
Thanks Jakub for the explanation, I have a try like below patch but I am not
quite sure it is expected, and where should I put the assertion.
> If yes, it needs to
> be unsigned short, if not, we should add an assertion (e.g. on streaming
> in the LTO table) that MAX_MACHINE_MODE <= 256.
diff
Committed, thanks Jeff and Juzhe.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Tuesday, June 20, 2023 10:12 PM
To: juzhe.zh...@rivai.ai; Li Xu ; gcc-patches
Cc: kito.cheng ; palmer
Subject: Re: [PATCH v2] RISC-V: Set the natural size of
On 6/20/23 00:47, juzhe.zh...@rivai.ai wrote:
LGTM. Thanks!
OK for the trunk, of course.
jeff
Hi Alex
again, thanks for working on this and for fixing the SDK blocker.
> On 20 Jun 2023, at 13:30, Alex Coplan wrote:
>
> The patch can now survive bootstrap on Darwin (it looks like we'll need
> to adjust some Objective-C++ tests in light of the new pedwarn, but that
> looks to be
Hi,
I'm going to commit the attached. Thanks Lehua for reporting.
Regards
Robin
>From 1a4dfe90f251e38e27104f2fa11feecd3b04c4c1 Mon Sep 17 00:00:00 2001
From: Robin Dapp
Date: Tue, 20 Jun 2023 15:52:16 +0200
Subject: [PATCH] RISC-V: testsuite: Add missing -mabi=lp64d.
This fixes more cases
Committed, thanks Robin and Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Tuesday, June 20, 2023 9:18 PM
To: Robin Dapp ; Juzhe-Zhong ;
gcc-patches@gcc.gnu.org
Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com;
Hi,
>> The package Interfaces.CHERI provides intrinsic bindings and
>> helper functions to allow software to query, create, and
>> manipulate CHERI capabilities.
>
> I'm curious what the motivation for these intrinsic wrappers is, given that
> GCC trunk doesn't currently support them. Out of
> By the way, shouldn't these cases have the `-mabi=lp64d` option added,
> otherwise I get the following failure message when I run tests on RV32 GCC.
>
> FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-1.c -std=c99 -O3
> -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test
Hi, Richi. I am not sure why I failed to send this patch to @sues email at the
first time.
Now I cc your gmail.
This is the V2 patch addressing your comments for V1.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-20 21:42
To: gcc-patches
CC: richard.sandiford; rguenther;
-/* { dg-additional-options "-march=rv64gcv_zvfh -Wno-pedantic" } */
+/* { dg-additional-options "-march=rv64gcv_zvfh -Wno-pedantic -Wno-psabi"
} */
By the way, shouldn't these cases have the `-mabi=lp64d` option added,
otherwise I get the following failure message when I run tests on RV32
From: Ju-Zhe Zhong
gcc/ChangeLog:
* internal-fn.cc (expand_partial_store_optab_fn): Add
LEN_MASK_{LOAD,STORE} vectorizer support.
(internal_load_fn_p): Ditto.
(internal_store_fn_p): Ditto.
(internal_fn_mask_index): Ditto.
I intend to push this to trunk once testing finishes.
I generated the diff with -b so the whitespace changes aren't shown,
because there was some re-indenting that makes the diff look larger than
it really is.
Honza, I don't think this is likely to make much difference for the PR
110287
On 6/20/23 00:59, Richard Biener via Gcc-patches wrote:
DSE isn't good at identifying program points that end lifetime
of variables that are not associated with virtual operands. But
at least for those that end basic-blocks we can handle the simple
case where this ending is in the same
Lehua fills out that form. List me as the approver and the process
will
run from there. Takes a day or two for everything to get into place.
I just followed this step to submit the form, thanks to Robin, Jeff and Juzhe.
Best,
Lehua
Just a quick update, the benchmark code link has been updated and can
now be accessed at
https://github.com/ken-matsui/gcc-benches/blob/main/remove_pointer.cc.
I have also created a report file which can be found at
https://github.com/ken-matsui/gcc-benches/blob/main/remove_pointer.md.
On Sat,
Just a quick update, the benchmark code link has been updated and can
now be accessed at
https://github.com/ken-matsui/gcc-benches/blob/main/is_object.cc. I
have also created a report file which can be found at
https://github.com/ken-matsui/gcc-benches/blob/main/is_object.md.
On Thu, Jun 15, 2023
On 6/20/23 03:01, Robin Dapp wrote:
LGTM.
Likewise -- that V2/V3 is a nice improvement over the original V1 approach.
jeff
Actually they are already in for a bit :)
51795b910737 (Robin Dapp 2023-06-01 14:18:57 +0200 1) /* { dg-do
compile } */
I thought something is special about them that they somehow didn't run
on your machine or so.
The time I just said is your commit time from this link
On 6/20/23 04:56, Robin Dapp wrote:
Could you merge it ?
By the way, could Lehua get the write access?
IMHO nothing stands in the way but I'll defer to Jeff to have
the "official seal" :)
Once he ACKs Lehua needs to go the usual way of requesting
sourceware access via
> Could you merge it ?
Committed.
Regards
Robin
> Oh, I should know why. These cases of yours were added yesterday,
> while I submitted the patch the day before, and then yesterday by Pan
> to help me merge in after your cases. Sorry for introducing this issue,
> I'll submit a new fix patch.
Actually they are already in for a bit :)
Hi,
On 20/06/2023 09:47, Marc Poulhiès via Gcc-patches wrote:
> From: Daniel King
>
> The package Interfaces.CHERI provides intrinsic bindings and
> helper functions to allow software to query, create, and
> manipulate CHERI capabilities.
I'm curious what the motivation for these intrinsic
Lehua, would they not show up in your test runs? You fixed several
other tests but these somehow not?
Oh, I should know why. These cases of yours were added yesterday,
while I submitted the patch the day before, and then yesterday by Pan
to help me merge in after your cases. Sorry for
Hi,
this adds vector copysign, ncopysign and xorsign as well as the
accompanying tests.
In order to easily match the ncopysign patterns I changed the
builtin implementation slightly. Juzhe might want to comment
on that. For now I kept the attribute's name even though
it doesn't emit an "n"
I just noticed there is also a -ffast-math missing in vadd-run.c
as well as one redundant in vrem-rv32gcv.c and added it to the
patch.
Going to commit the attached as obvious.
Regards
Robin
Subject: [PATCH] RISC-V: testsuite: Fix vmul test expectation and fix
-ffast-math.
I forgot to check
Hi Iain,
On 14/05/2023 17:05, Iain Sandoe wrote:
> Hi Alex,
>
> thanks for working on this.
>
> I’ve applied this patch and evaluated on a few Darwin versions (which is the
> target currently most affected, I believe):
>
> > On 9 May 2023, at 13:07, Alex Coplan wrote:
>
> > This patch
On Tue, 20 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> This patch is apply LEN_MASK_{LOAD,STORE} into vectorizer.
> I refactor gimple IR build to make codes look cleaner.
>
> gcc/ChangeLog:
>
> * internal-fn.cc (expand_partial_store_optab_fn): Add
>
> Committed, thanks Jeff.
The vec_set/vec_extract tests FAIL since this commit. I'm going to
commit the attached as obvious.
Lehua, would they not show up in your test runs? You fixed several
other tests but these somehow not?
Regards
Robin
Subject: [PATCH] RISC-V: testsuite: Add -Wno-psabi
A rather obvious fix. The allocator(...) bit showed up with -fdump-parse-tree.
Committed as Rev. r14-1988-g99e3214f582b08
Side remark:
Regarding the example inside the commit log: OpenMP 5.1 permitted derived-type
components. Due to global wording changes, OpenMP 5.2 disabled it for both
the
From: Eric Botcazou
This removes more bypasses for private views in instances that are present
in type predicates (Conforming_Types, Covers, Specific_Type and Wrong_Type),
which in exchange requires additional work in Sem_Ch12 to restore the proper
view of types during the instantiation of
From: Eric Botcazou
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_entity) : Pass
the NULL_TREE explicitly and test imported_p in lieu of
Is_Imported. : Remove public_flag local variable and
make extern_flag local variable a constant.
Tested on
From: Yannick Moy
After the recent change on detection of non-inlining, calls inside
the iterator part of a quantified expression were not considered
as preventing inlining anymore, leading to a crash later on inside
GNATprove. Now fixed.
gcc/ada/
* sem_res.adb (Resolve_Call): Fix
From: Ronan Desplanques
The Preelaborate pragma the removed comment was referring to was
indeed present in AI 167, as well as in clause 5.3 of the rationale
for Ada 2012, but it never made it into the 2012 version of the
reference manual.
gcc/ada/
* libgnarl/s-mudido.ads: Remove
On Tue, Jun 20, 2023 at 11:56 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi Richard,
> For the following reduced test-case taken from PR:
>
> #include "arm_sve.h"
> svuint32_t l() {
> alignas(16) const unsigned int lanes[4] = {0, 0, 0, 0};
> return svld1rq_u32(svptrue_b8(), lanes);
> }
Hi Tobias,
This looks good to me. I'm interested to see it in use :-)
OK for trunk
Paul
On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote:
>
> When just matching a symbol, one can use 'gfc_match_symbol (, host_assoc)'
> and has the option to match with and without host association.
>
>
> Could you merge it ?
> By the way, could Lehua get the write access?
IMHO nothing stands in the way but I'll defer to Jeff to have
the "official seal" :)
Once he ACKs Lehua needs to go the usual way of requesting
sourceware access via https://sourceware.org/cgi-bin/pdw/ps_form.cgi.
Regards
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did remember to include the testcases in the .diff :-)
I believe that, between
Could you merge it ?
By the way, could Lehua get the write access?
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-20 18:47
To: Lehua Ding; gcc-patches
CC: rdapp.gcc; juzhe.zhong; kito.cheng; palmer; jeffreyalaw; pan2.li
Subject: Re: [PATCH] RISC-V: Fix compiler warning of
On Tue, 20 Jun 2023 at 11:45, Jonathan Wakely wrote:
> On Tue, 20 Jun 2023 at 09:21, Andreas Schwab wrote:
>
>> On Jun 20 2023, Jakub Jelinek via Gcc-patches wrote:
>>
>> > Is it safe even on 64bit targets? I mean, doesn't say PowerPC already
>> allow
>> > full 64-bit virtual address space?
This keeps virtual SSA form up-to-date in phiprop when easily possible.
Only when we deal with aggregate copies the work would be too
heavy-handed in general.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-phiprop.cc (phiprop_insert_phi): For simple loads
When just matching a symbol, one can use 'gfc_match_symbol (, host_assoc)'
and has the option to match with and without host association.
However, when matching something more complex via 'gfc_match' like
"something ( %s ) , " the match uses host_assoc = false.
While it can be combined
> This little patch fixes a compile warning issue that my previous
> patch introduced, sorry for introducing this issue.
OK and obvious enough to push directly.
Regards
Robin
On Tue, 20 Jun 2023 at 09:21, Andreas Schwab wrote:
> On Jun 20 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > Is it safe even on 64bit targets? I mean, doesn't say PowerPC already
> allow
> > full 64-bit virtual address space? The assumption that one can't have
> > more than half of virtual
Hi all,
We've been asked to optimise the testcase in this patch of a 64-bit ADDP with
the low and high halves of the same 128-bit vector. This can be done by a
single .4s ADDP followed by just reading the bottom 64 bits. A splitter for
this is quite straightforward now that all the vec_concat
Hi Richard,
For the following reduced test-case taken from PR:
#include "arm_sve.h"
svuint32_t l() {
alignas(16) const unsigned int lanes[4] = {0, 0, 0, 0};
return svld1rq_u32(svptrue_b8(), lanes);
}
compiling with -O3 -mcpu=generic+sve results in following ICE:
during GIMPLE pass: fre
Ok.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-20 17:45
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; kito.cheng; palmer; jeffreyalaw; pan2.li
Subject: [PATCH] RISC-V: Fix compiler warning of riscv_arg_has_vector
Hi,
This little patch fixes a compile warning issue that my previous
Hi,
This little patch fixes a compile warning issue that my previous patch
introduced, sorry for introducing this issue.
Best,
Lehua
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_arg_has_vector): Add default branch.
---
gcc/config/riscv/riscv.cc | 6 --
1 file changed, 4
gcc/ChangeLog:
* shrink-wrap.cc (try_shrink_wrapping_separate):call
use_shrink_wrapping_separate.
(use_shrink_wrapping_separate): wrap the condition
check in use_shrink_wrapping_separate.
* shrink-wrap.h (use_shrink_wrapping_separate): add to extern
---
These 2 patches resolve confilct between zcmp multi push/pop and
shrink-wrap-separate.
As per Kito's review comment
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310564.html,
I split the orginal patch into two parts: RISC-V part and
the rest part (shrink-wrap.h / shrink-wrap.cc).
Fei
1 - 100 of 158 matches
Mail list logo
