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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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.
>
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
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
> 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
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
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,
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:
>
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}.
>
>
> 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
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
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
> 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
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.
> 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
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
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
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
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
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
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
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
*
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
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
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
On Wed, 21 Jun 2023, Jeff Law wrote:
>
>
> On 6/21/23 01:49, Richard Biener via Gcc-patches wrote:
> > The following addresses a miscompilation by RTL scheduling related
> > to the representation of masked stores. For that we have
> >
> > (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40
On Wed, 21 Jun 2023, Jeff Law wrote:
>
>
> On 6/21/23 00:41, Richard Biener wrote:
> >> I thought during the introduction of erroneous path isolation that we
> >> concluded stores, calls and such had observable side effects that must be
> >> preserved, even when we hit a block that leads to
Hi Both,
> while I only had a minor question regarding gfc_is_ptr_fcn(),
> can you still try to enlighten me why that second part
> was necessary? (I believed it to be redundant and may have
> overlooked the obvious.)
Blast! I forgot about checking that. Lurking in the back of my mind
and going
55 matches
Mail list logo
