We sometimes get to ask to decompose, say V2DFmode into two halves.
Currently this results in composing it from two DImode pieces
instead of the obvious two DFmode pieces. The following adjusts
vector_vector_composition_type for this trivial case and avoids
a VIEW_CONVERT_EXPR in the initial code
On Thu, 22 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * internal-fn.cc (expand_partial_store_optab_fn): Adapt for
> LEN_MASK_STORE.
> (internal_load_fn_p): Add LEN_MASK_LOAD.
> (internal_store_fn_p): Add LEN_MA
This patch documents a glitch in gcc.misc-tests/outputs.exp: it checks
whether the linker is GNU ld, and uses that to decide whether to
expect collect2 to create .ld1_args files under -save-temps, but
collect2 bases that decision on whether HAVE_GNU_LD is set, which may
be false zero if the linke
On Thu, Jun 22, 2023 at 4:12 AM Philipp Tomsich
wrote:
>
> From: Manolis Tsamis
>
> Fixes: 6a2e8dcbbd4bab3
>
> Propagation for the stack pointer in regcprop was enabled in
> 6a2e8dcbbd4bab3, but set ORIGINAL_REGNO/REG_ATTRS/REG_POINTER for
> stack_pointer_rtx which caused regression (e.g., PR 110
On Thu, Jun 22, 2023, 4:47 PM Peter Bergner wrote:
> On 6/22/23 6:37 PM, Peter Bergner via Gcc-patches wrote:
> > On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
> >> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> >> wrote:
> >>>
> >>> TARGET_AIX is defined to a no
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
> On 1/25/23 16:06, Ben Boeckel wrote:
> > They affect the build, so report them via `-MF` mechanisms.
>
> Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is neutered in patch 3 where
`write_m
On Jun 2, 2023, Alexandre Oliva wrote:
> Introduce -finline-stringops
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620472.html
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disi
On 6/1/23 11:54 PM, Ajit Agarwal via Gcc-patches wrote:
>
>
> On 01/06/23 2:06 pm, Bernhard Reutner-Fischer wrote:
>> On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This patch improves code sinking pass to sink statements before call to
>>> reduce
>>> register pressure
It seems prudent to add C++26 now that the first C++26 papers have been
approved. I followed commit r11-6920 as well as r8-3237.
I was puzzled to see that -std=c++23 was marked Undocumented but
-std=c++2b wasn't. I think it should be the other way round, like
the earlier modes.
As for __cpluspl
On 6/21/23 11:20 AM, Paul E Murphy via Gcc-patches wrote:
>
>
> On 6/19/23 3:39 AM, Thomas Schwinge wrote:
>> Hi Paul!
>>
>> On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches"
>> wrote:
>>> This was noticed when fixing the gccgo usage of the macro, the
>>> rust usage is very similar.
From: Ju-Zhe Zhong
Address comments from Richard and Bernhard from V5 patch.
V6 fixed all issues according their comments.
gcc/ChangeLog:
* internal-fn.cc (expand_partial_store_optab_fn): Adapt for
LEN_MASK_STORE.
(internal_load_fn_p): Add LEN_MASK_LOAD.
(internal_store
On 6/22/23 6:37 PM, Peter Bergner via Gcc-patches wrote:
> On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
>> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
>> wrote:
>>>
>>> TARGET_AIX is defined to a non-zero value on linux and maybe other
>>> powerpc64le targets. T
On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> wrote:
>>
>> TARGET_AIX is defined to a non-zero value on linux and maybe other
>> powerpc64le targets. This leads to unexpected behavior such as
>> dropping the .go_exp
Thanks Richard! Will send V6 patch to address your comments.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-06-23 02:27
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re: [PATCH V5] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhon
Thanks so much. Will send V6 patch.
juzhe.zh...@rivai.ai
From: Bernhard Reutner-Fischer
Date: 2023-06-23 00:05
To: juzhe.zhong
CC: rep.dot.nop; gcc-patches; rguenther; richard.sandiford
Subject: Re: [PATCH V5] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer
On Thu, 22 Jun 2023 21:53:48 +080
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
Why isn't this covered by the existing code in preprocessed_module?
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Signed-off-by: Ben Boeckel
---
On Wed, 21 Jun 2023 22:08:55 -0300
Alexandre Oliva wrote:
> Thanks for the test.
>
> Did you mean for me to incorporate it into the patch, or do you mean to
> contribute it separately, if the feature happens to be accepted?
These were your tests that i quoted but i or my MUA botched to add one
Hello,
liuhongt via Gcc-patches writes:
> 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.
Dear all,
gfortran's ABI specifies that actual arguments to CHARACTER(LEN=1),VALUE
dummy arguments are passed by value in the scalar case. That did work
for constant strings being passed, but not in several other cases, where
pointers were passed, resulting in subsequent random junk...
The attac
From: benjamin priour
Resend with proper subject line ...
Hi,
Below is the fix to regression bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Was bootstrapped and regtested successfully on x86_64-linux-gnu
Considering mishap from last patch, I'd would appreciate if you could
also regtes
Hi,
Below is the fix to regression bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Was bootstrapped and regtested successfully on x86_64-linux-gnu
Considering mishap from last patch, I'd would appreciate if you could
also regtest it, to be sure :)
Thanks,
Benjamin.
>From 04186f04a3f172d
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * internal-fn.cc (expand_partial_store_optab_fn): Adapt for
> LEN_MASK_STORE.
> (internal_load_fn_p): Add LEN_MASK_LOAD.
> (internal_store_fn_p): Add LEN_MASK_STORE.
> (internal_fn_mask_index)
Some comments below, all quite minor. I'll continue to review tomorrow,
I need a fresher brain for arm_mve_check_df_chain_back_for_implic_predic
;)
+static int
+arm_mve_get_vctp_lanes (rtx x)
+{
+ if (GET_CODE (x) == SET && GET_CODE (XEXP (x, 1)) == UNSPEC
+ && (XINT (XEXP (x, 1), 1) ==
On Wed, Jun 21, 2023 at 04:44:00PM -0400, David Malcolm via Gcc-patches wrote:
> I'd like to ping this C++ FE patch for review:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621779.html
Not an approval, but LGTM, though some nits below:
> On Wed, 2023-06-14 at 20:28 -0400, David Malc
Looks Jivan notices this issue too, cc Jivan for awareness.
> Re: LTO: buffer overflow in lto_output_init_mode_table
> Hi Robbin.
> Thank you for responding.
> I will defer my thread.
> On Thu, Jun 22, 2023 at 3:42 PM Robin Dapp wrote:
>> Hi Jivan,
>>
>> I think Pan is already on this problem.
> Just curious about the combine pass you mentioned, not very sure my
> understand is correct but it looks like the combine pass totally
> ignore the iterator requirement?
>
> It is sort of surprise to me as the combine pass may also need the
> information of iterators.
combine tries to match ins
Richard,
OK for backport to GCC-13?
Thanks,
Philipp.
On Thu, 22 Jun 2023 at 16:18, Richard Sandiford via Gcc-patches
wrote:
>
> Di Zhao OS via Gcc-patches writes:
> > This patch enables reassociation of floating-point additions on ampere1.
> > This brings about 1% overall benefit on spec2017 f
Just curious about the combine pass you mentioned, not very sure my understand
is correct but it looks like the combine pass totally ignore the iterator
requirement?
It is sort of surprise to me as the combine pass may also need the information
of iterators.
Pan
From: 钟居哲
Sent: Thursday, Ju
Di Zhao OS via Gcc-patches writes:
> This patch enables reassociation of floating-point additions on ampere1.
> This brings about 1% overall benefit on spec2017 fprate cases. (There
> are minor regressions in 510.parest_r and 508.namd_r, analyzed here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?i
Hi, Richi. Thanks so much for the review && comments.
I have sent V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622539.html
with addressing your comments.
Would you mind taking a look at it？ This only difference between V5 and V4 is
optabs-tree.cc
Thanks.
juzhe.zh...@rivai.ai
From: Ju-Zhe Zhong
gcc/ChangeLog:
* internal-fn.cc (expand_partial_store_optab_fn): Adapt for
LEN_MASK_STORE.
(internal_load_fn_p): Add LEN_MASK_LOAD.
(internal_store_fn_p): Add LEN_MASK_STORE.
(internal_fn_mask_index): Add LEN_MASK_{LOAD,STORE}.
(interna
>
>
> On 6/22/23 00:31, Richard Biener wrote:
> > I think there's a difference in that __builtin_trap () is observable
> > while __builtin_unreachable () is not and reaching __builtin_unreachable
> > () invokes undefined behavior while reaching __builtin_trap () does not.
> >
> > So the isolatio
Oh. I see. I think I am wrong. Sorry for that :).
load/store are using 'V' iterators.
This patch looks reasonable to me now.
Thanks for catching this.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-22 21:32
To: 钟居哲; gcc-patches; palmer; kito.cheng; pan2.li; Jeff Law
CC: rdapp.gcc
Subje
On 6/22/23 00:31, Richard Biener wrote:
I think there's a difference in that __builtin_trap () is observable
while __builtin_unreachable () is not and reaching __builtin_unreachable
() invokes undefined behavior while reaching __builtin_trap () does not.
So the isolation code marking the trap
> I don't understand why it is necessary to bother "VF". "VF” should
> not be changed since intrinsic stuff is quite stable and any
> unreasonable changes are unacceptable.
Ok, I hear your concern. My argument is: Currently our mechanism
of disabling instructions is incorrect and if any of the VF
I don't understand why it is necessary to bother "VF".
"VF” should not be changed since intrinsic stuff is quite stable and any
unreasonable changes
are unacceptable.
>> What are the many instructions that are valid in TARGET_ZVFHMIN?
vle/vse/vluxei/vloxei/vsuxei/vsoxei/vlse/vsse.
juzhe.zh...@
> You change "VF" constraint as "TARGET_ZVFH" which is incorrect since
> we a lot of instructions are valid in "TARGET_ZVFHMIN" in vector.md
> but you disabled them in this patch. You disabled them unexpectedly.
Yes that was kind of the point :) IMHO all the :VF insns are actually
only valid in
You change "VF" constraint as "TARGET_ZVFH" which is incorrect since we
a lot of instructions are valid in "TARGET_ZVFHMIN" in vector.md but you
disabled them in this patch.
You disabled them unexpectedly.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-22 21:03
To: gcc-patches; palmer;
Committed as r14-2032-g2cd0689a79498d
Nonetheless, comments are highly welcome. https://gcc.gnu.org/PR110364
lists some follow-up tasks related to environment variables, both in
terms of code handling and in terms of documentation.
Tobias
-
Siemens Electronic Design Automation Gm
Hi,
when working on FP widening/narrowing I realized the Zvfhmin handling
is not ideal right now: We use the "enabled" insn attribute to disable
instructions not available with Zvfhmin (but only with Zvfh).
However, "enabled == 0" only disables insn alternatives, in our case all
of them when the
On Wed, 21 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * internal-fn.cc (expand_partial_store_optab_fn): Adapt for
> LEN_MASK_STORE.
> (internal_load_fn_p): Add LEN_MASK_LOAD.
> (internal_store_fn_p): Add LEN_MASK_STORE.
> (
On Thu, Jun 22, 2023 at 11:08 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 20 Jun 2023 at 16:47, Richard Biener
> wrote:
> >
> > 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:
> > >
>
Hi Robbin.
Thank you for responding.
I will defer my thread.
On Thu, Jun 22, 2023 at 3:42 PM Robin Dapp wrote:
> Hi Jivan,
>
> I think Pan is already on this problem. Please see this thread:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622129.html
>
> Regards
> Robin
>
--
With th
Hi Jivan,
I think Pan is already on this problem. Please see this thread:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622129.html
Regards
Robin
In the case when enabled -flto=N GCC aborted compilation.
The reason is the overflowing streamer_mode_table buffer.
It has 1 << 8 bytes but lto_output_init_mode_table() tries to fill
with MAX_MACHINE_MODE bytes.
gcc/ChangeLog:
* tree-streamer.h (streamer_mode_table): Changed buffer size
From: Manolis Tsamis
Fixes: 6a2e8dcbbd4bab3
Propagation for the stack pointer in regcprop was enabled in
6a2e8dcbbd4bab3, but set ORIGINAL_REGNO/REG_ATTRS/REG_POINTER for
stack_pointer_rtx which caused regression (e.g., PR 110313, PR 110308).
This fix adds special handling for stack_pointer_rtx
Hi Thomas,
This patch adjusts the implementation of acc_map_data/acc_unmap_data API library
routines to more fit the description in the OpenACC 2.7 specification.
Instead of using REFCOUNT_INFINITY, we now define a REFCOUNT_ACC_MAP_DATA
special value to mark acc_map_data-created mappings, and allo
On Wed, 2023-06-21 at 18:37 +, Joseph Myers wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote:
>
> > > This patch sets the address space of the array type to that of the
> > >
On Tue, 20 Jun 2023 at 16:47, Richard Biener wrote:
>
> 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 l
Hi Alex,
> 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 wrap
The following fixes an ICE that occurs when we visit an edge
inserted load from the code validating correctness for inserting
an aggregate copy there. We can simply skip those loads here.
Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/110332
* tr
This should be covered by PR110308 (proposed fix attached there) and PR110313.
Our bootstrap runs are still in progress to confirm.
On Thu, 22 Jun 2023 at 09:40, Richard Biener wrote:
>
> On Thu, Jun 22, 2023 at 1:42 AM Thiago Jung Bauermann
> wrote:
> >
> >
> > Hello,
> >
> > Jeff Law writes:
On Thu, Jun 22, 2023 at 1:42 AM Thiago Jung Bauermann
wrote:
>
>
> Hello,
>
> Jeff Law writes:
>
> > On 6/19/23 22:52, Tamar Christina wrote:
> >
> >>> It's a bit hackish, but could we reject the stack pointer for operand1 in
> >>> the
> >>> stack-tie? And if we do so, does it help?
> >> Yeah t
On Wed, Jun 21, 2023 at 10:39 PM Joseph Myers wrote:
>
> On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote:
>
> > > > int32_t x = (int32_t)0x1.0p32;
> > > > int32_t y = (int32_t)(int64_t)0x1.0p32;
> > > >
> > > > sets x to 2147483647 and y to 0.
> >
> > Hmm, good question. GENERIC has a d
54 matches
Mail list logo
