On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc wrote:
>
> Hi all,
>
> Currently to disable the warning that a noreturn method does return, it's
> required to disable warnings entirely. This can be very inconvenient when
> -Werror is enabled with a noreturn method that isn't specifically
On Tue, Jul 4, 2023 at 6:32 PM Julian Waters wrote:
>
> Hi Andrew, thanks for the quick response,
>
> What if the method has a return value? I know it sounds counterintuitive, but
> in some places HotSpot relies on the noreturn attribute being applied to
> methods that do return a value in an
Hi,
W dniu 5.07.2023 o 00:57, Martin Uecker pisze:
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
[]
Yes. named address spaces would be great. And for code, too.
While certainly some work, implementation effort for
new kinds of named address spaces does not
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> >
> > I think a C++ class (or rather, class template) with inline functions is
> > the way to go here. gcc's optimiser will give good code, and the C++
> > class will let you get nice syntax to hide the messy details.
>
>
Hi all,
Currently to disable the warning that a noreturn method does return, it's
required to disable warnings entirely. This can be very inconvenient when
-Werror is enabled with a noreturn method that isn't specifically calling
something like std::abort() at the end, when one wants all other
在 2023/7/5 09:40, Andrew Pinski via Gcc 写道:
It is wrong to use noreturn on a function other than one which has a
return type of void as documented.
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute
:
```
It does not make sense for a noreturn
On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote:
> On Mon, 03 Jul 2023, Alan Stern wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> >> This is a request for comments on extending the atomic builtins API to
> >> help avoiding redundant memory barriers.
On Tue, Jul 04, 2023 at 04:25:45PM -0400, Alan Stern wrote:
> On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote:
[ . . . ]
> > I am puzzled by this. Initialization of a shared variable does not need
> > to be atomic until its publication. Could you expand on this?
>
> In the
Hi Andrew, thanks for the quick response,
What if the method has a return value? I know it sounds counterintuitive,
but in some places HotSpot relies on the noreturn attribute being applied
to methods that do return a value in an unreachable code path. Does the
unreachable builtin cover that case
> I think a C++ class (or rather, class template) with inline functions is
> the way to go here. gcc's optimiser will give good code, and the C++
> class will let you get nice syntax to hide the messy details.
>
> There is no good way to do this in C. Named address spaces would be a
>
On Tue, 4 Jul 2023 at 10:47, Peter Zijlstra wrote:
>
> On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
>
> > int x = 0;
> > int y = 0;
> > int r0, r1;
> >
> > int dummy;
> >
> > void t0(void)
> > {
> > __atomic_store_n(, 1, __ATOMIC_RELAXED);
> >
> >
On 03/07/2023 18:42, Rafał Pietrak via Gcc wrote:
Hi Ian,
W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze:
On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc
wrote:
[]
I was thinking about that, and it doesn't look as requiring that deep
rewrites. ABI spec, that could
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(, 1, __ATOMIC_SEQ_CST);
>
W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
Hi David,
[--]
4. It is worth taking a step back, and thinking about how you would
like to use these pointers. It is likely that you would be better
thinking in terms of an array, rather than pointers - after all, you
don't want
Hi,
W dniu 4.07.2023 o 14:38, David Brown pisze:
[-]
A key difference is that using 32-bit pointers on an x86 is enough
address space for a large majority of use-cases, while even on the
smallest small ARM microcontroller, 16-bit is not enough. (It's not
even enough to access all
On 04/07/2023 16:20, Rafał Pietrak wrote:
W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
Hi David,
[--]
4. It is worth taking a step back, and thinking about how you would
like to use these pointers. It is likely that you would be better
thinking in terms of an array, rather
On 04/07/2023 16:46, Rafał Pietrak wrote:
Hi,
W dniu 4.07.2023 o 14:38, David Brown pisze:
[-]
A key difference is that using 32-bit pointers on an x86 is enough
address space for a large majority of use-cases, while even on the
smallest small ARM microcontroller, 16-bit is not
W dniu 4.07.2023 o 17:13, David Brown pisze:
[]
If you have a circular buffer, it is vastly more efficient to have an
array with no pointers or indices, and use head and tail indices to
track the current position. But I'm not sure if that is what you are
looking for. And you
W dniu 4.07.2023 o 17:55, David Brown pisze:
On 04/07/2023 16:46, Rafał Pietrak wrote:
[--]
Yes. named address spaces would be great. And for code, too.
It is good to have a wishlist (and you can file a wishlist "bug" in the
gcc bugzilla, so that it won't be forgotten). But it
On Mon, 03 Jul 2023, Alan Stern wrote:
> On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
>> This is a request for comments on extending the atomic builtins API to
>> help avoiding redundant memory barriers. Indeed, there are
>
> What atomic builtins API are you talking about? The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
--- Comment #5 from Andrew Pinski ---
Actually the issue is:
signed-boolean:32 _8 = _7 > 1;
That is not [-1,0] but still [0,1] ... (VRP says it is too).
Let me see where that is built.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
PR target/110438 requests to emit PXOR before VPTERNLOG. This patch
implements that.From 815779936d0ca213b4c9ec798ed6acf8179fc2e7 Mon Sep 17 00:00:00 2001
From: Yan Simonaytes
Date: Tue, 4 Jul 2023 21:11:04 +0300
Subject: [PATCH] Generating all-ones zmm needs dep-breaking pxor before
ternlog
> Kito (or somebody else), would you mind doing a RISC-V bootstrap? It would
> take forever on my machine. Thank you.
I did a bootstrap myself now and it finally finished. Going to commit the
attached tomorrow.
Regards
Robin
Subject: [PATCH] Change MODE_BITSIZE to MODE_PRECISION for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515
--- Comment #7 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #6)
> Turning off PRE also allows it to pass but I guess it's the same as with SRA.
> -fno-strict-aliasing also helps, -fno-ipa-modref doesn't. I suspect
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110553
--- Comment #1 from Andrew Pinski ---
I wonder what function uses 64bit values for atomics in ubsan. I only saw 32bit
values (well I saw pointers and size_t in backtrace and 32bit in ubsan).
Richard Biener writes:
> On Thu, 29 Jun 2023, Richard Biener wrote:
>
>> On Thu, 29 Jun 2023, Richard Sandiford wrote:
>>
>> > Richard Biener writes:
>> > > With applying loop masking to epilogues on x86_64 AVX512 we see
>> > > some significant performance regressions when evaluating SPEC CPU
On Linux/x86_64,
0682a32c026f1e246eb07bb8066abca4636f01d8 is the first bad commit
commit 0682a32c026f1e246eb07bb8066abca4636f01d8
Author: Richard Biener
Date: Mon Jul 3 13:59:33 2023 +0200
tree-optimization/110310 - move vector epilogue disabling to analysis phase
caused
FAIL:
Hi Richard,
changed the patch according to your comments and I agree that
it is more readable that way. I hope using lhs as target for
the extract directly is possible the way I did it. Richard's
patch for aarch64 is already, therefore testsuites on aarch64 and
i386 are unchanged.
Regards
On Wed, Jul 5, 2023 at 2:25 AM simonaytes.yan--- via Gcc-patches
wrote:
>
> PR target/110438 requests to emit PXOR before VPTERNLOG. This patch
> implements that.
I prefer using UNSPEC_INSN_FALSE_DEP like we did for lzcnt/tzcnt/popcnt.
i.e.
18866; False dependency happens when destination is
Hi Richard/Andrew!
Richard Biener writes:
> On Thu, 29 Jun 2023, Jiufu Guo wrote:
>
>>
>> Hi,
>>
>> Jiufu Guo writes:
>>
>> > Hi,
>> >
>> > Integer expression "(X - N * M) / N" can be optimized to "X / N - M" if
>> > there is no wrap/overflow/underflow and "X - N * M" has the same sign
>>
Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along with the deallocation not only fixes
the regression, but also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Looks like it is a lambda inside a decltype is causing it.
The reason why I say that is if I change __apply_fn's operator() not to take a
second argument and
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, July 4, 2023 11:30 PM
> To: Hongtao Liu
> Cc: gcc-patches@gcc.gnu.org; Kirill Yukhin ; Liu,
> Hongtao
> Subject: Re: [PATCH v3] x86: make VPTERNLOG* usable on less than 512-bit
> operands with just AVX512F
>
> On 27.06.2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
--- Comment #3 from Andrew Pinski ---
It is this one:
/* Handle cases of two conversions in a row. */
(for ocvt (convert float fix_trunc)
(for icvt (convert float)
(simplify
(ocvt (icvt@1 @0))
...
/* A truncation to an unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Bug ID: 110554
Summary: more invalid wide Boolean values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Jie Mei 于2023年7月4日周二 17:52写道：
>
> A mips16e2 related test fails after the ifcvt change. The mips16e2
> addition also causes a test for unrelated module to fail.
>
> This patch adjusts branch costs when running the two affected tests.
>
> These tests should not require the -mbranch-cost option,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
--- Comment #4 from Andrew Pinski ---
So originally we have:
signed-boolean:32 _8 = _7 > 1;
_Bool _9 = (_Bool) _8;
(int) _9;
I think if we swap around where the convert was, it will fix the issue.
That is:
(bit_and (convert @0) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
Bug ID: 110552
Summary: ICE on valid code in maybe_instantiate_noexcept
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110553
Bug ID: 110553
Summary: -fsanitize=undefined needs -latomic on
powerpc-unknown-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
--- Comment #1 from Andrew Pinski ---
reducing ...
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along with the deallocation not only fixes
the regression, but also the cases I tested.
Attached is a "sneak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
--- Comment #3 from Moncef Mechri ---
> Please next time attach (which you can do paste in the box) or paste inline
> the testcase rather than just link to godbolt .
Noted. Apologies.
> It is an older regression though.
> ```
> #include
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
--- Comment #3 from Alexander Monakov ---
Patch available:
https://inbox.sourceware.org/gcc-patches/8f73371d732237ed54ede44b7bd88...@ispras.ru/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
--- Comment #3 from Andrew Pinski ---
Created attachment 55470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55470=edit
reduced but invalid code
This is the reduced testcase I got but it became invalid code; maybe the
original is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-04
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
--- Comment #4 from Andrew Pinski ---
Created attachment 55471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55471=edit
changed slightly to produce valid code
Hi,
This patch skips redundant vector extract insn to be generated when
the extracted element is the first element of dword0 and the destination
is a memory operand. Only one 'stxsi[hb]x' instruction is enough.
The V4SImode is fixed in a previous patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110555
Bug ID: 110555
Summary: internal compiler error: Segmentation fault when using
std::ranges::range auto as a template parameter
Product: gcc
Version: 14.0
Status:
On Tue, Jul 4, 2023 at 11:50 AM Thomas Schwinge wrote:
>
> Hi!
>
> I came across this one here on my way working through another (somewhat
> related) GTY issue. I generally do understand the issue here, but do
> have a question about 'unsigned int len' field in
> 'libcpp/include/symtab.h:struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement,
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-04 20:26
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Use FRM_DYN when add the rounding mode operand
From: Pan Li
This patch would like to take FRM_DYN const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
Hao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
On 22.05.23 14:51, Sebastian Huber wrote:
Make sure that the API enums have at least the size of int. Otherwise the
following build error may occur:
In file included from gcc/libgomp/env.c:34:
./libgomp_f.h: In function 'omp_check_defines':
./libgomp_f.h:77:8: error: size of array 'test' is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #26 from Richard Biener ---
(In reply to Sergei Trofimovich from comment #24)
> Trying to understand the failure mode here:
>
> In bug.c.033t.early_objsz I still see the explicit stores to LocalFlags:
>
>:
> LookupFlags_15 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110537
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107004
sbouchex changed:
What|Removed |Added
CC||sbouchex at infovista dot com
--- Comment
On Tue, 4 Jul 2023, Richard Biener wrote:
> On Mon, 3 Jul 2023, Andre Vieira (lists) wrote:
>
> > Hi,
> >
> > This patch makes the vectorizer treat any vector widening IFN as simple,
> > like
> > it did with the tree codes VEC_WIDEN_*.
> >
> > I wasn't sure whether I should make all IFN's
Richard Biener writes:
> On Tue, 4 Jul 2023, Richard Biener wrote:
>
>> On Mon, 3 Jul 2023, Richard Sandiford wrote:
>>
>> > Richard Biener writes:
>> > > The following removes late deciding to elide vectorized epilogues to
>> > > the analysis phase and also avoids altering the epilogues niter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #28 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b083203f053f1666e9cc1ded2abdf4e1688d1ec0
commit r14-2289-gb083203f053f1666e9cc1ded2abdf4e1688d1ec0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #9 from CVS Commits ---
The master branch has been updated by Hao Liu :
https://gcc.gnu.org/g:2c12ccf800fc7890925402d30a02f0fa9e2627cc
commit r14-2290-g2c12ccf800fc7890925402d30a02f0fa9e2627cc
Author: Hao Liu
Date: Tue Jul 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110538
Bug ID: 110538
Summary: [14 Regression] Dead Code Elimination Regression since
r14-368-ge1366a7e4ce
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Andrew Pinski changed:
What|Removed |Added
CC||pgodbole at nvidia dot com
--- Comment
Hi,
As mentioned in PR108338, on p9, we could use mtvsrws to implement
the bitcast from SI#0 to SF (or lowpart DI to SF).
For code:
*(long long*)buff = di;
float f = *(float*)(buff);
"sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn 1,1" is generated.
But "mtvsrws 1,3 ; xscvspdpn 1,1" would be better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #6 from Kewen Lin ---
It's an arguable topic, I can't find the thread that previously some reviewers
told me it's not always good to initialize the local variable. IIRC, the case
is that I initialized one variable at the top, but
When trying to associate (v + INT_MAX) + INT_MAX we are using
the TREE_OVERFLOW bit to check for correctness. That isn't
working for VECTOR_CSTs and it can't in general when one considers
VL vectors. It looks like it should work for COMPLEX_CSTs but
I didn't try to single out _Complex int in
Update PATCH V2 for DYN in needed as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623543.html
Pan
From: Li, Pan2
Sent: Tuesday, July 4, 2023 2:50 PM
To: juzhe.zh...@rivai.ai; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ;
Wang, Yanzhang ; kito.cheng
Subject: RE: [PATCH v1] RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #7 from Hao Liu ---
> int foo() {
> bool a = true;
> bool b;
> if (a || b)
> return 1;
> b = true;
> return 0;
> }
>
> still has the warning, it looks something can be improved (guess we prefer
> not to emit
From: Lili Cui
Hi Maintainer,
This patch is to enable ENQCMD and UINTR for march=sierraforest according to
Intel ISE.
Bootstrapped and regtested. Ok for trunk? And I will backport this patch to
GCC13.
Thanks,
Lili.
Enable ENQCMD and UINTR for march=sierraforest according to Intel ISE
On Tue, Jul 4, 2023 at 4:15 PM Cui, Lili wrote:
>
> From: Lili Cui
>
> Hi Maintainer,
>
> This patch is to enable ENQCMD and UINTR for march=sierraforest according to
> Intel ISE.
>
> Bootstrapped and regtested. Ok for trunk? And I will backport this patch to
> GCC13.
Ok.
>
> Thanks,
> Lili.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #3 from YunQiang Su ---
Ohhh, I think that the real problem is that:
why DINS is used instead of INS when work with an INT?
On Tue, 4 Jul 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 4 Jul 2023, Richard Biener wrote:
> >
> >> On Mon, 3 Jul 2023, Richard Sandiford wrote:
> >>
> >> > Richard Biener writes:
> >> > > The following removes late deciding to elide vectorized epilogues to
> >> > >
On Tue, Jul 4, 2023 at 10:32 AM Hongyu Wang wrote:
>
> > In a follow-up patch, can you please document inlining rules involving
> > -march and -mtune to "x86 Function Attributes" section? Currently, the
> > inlining rules at the end of "target function attribute" section does
> > not even mention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Thanks Juzhe, passed all the test of riscv.exp and rvv.exp, will commit it with
the reverted one with the final approval.
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, July 4, 2023 1:53 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ; Li,
Pan2 ; Wang, Yanzhang ; kito.cheng
On Tue, 4 Jul 2023, Richard Biener wrote:
> On Mon, 3 Jul 2023, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > The following removes late deciding to elide vectorized epilogues to
> > > the analysis phase and also avoids altering the epilogues niter.
> > > The costing part from
On Mon, 3 Jul 2023, Andre Vieira (lists) wrote:
> Hi,
>
> This patch makes the vectorizer treat any vector widening IFN as simple, like
> it did with the tree codes VEC_WIDEN_*.
>
> I wasn't sure whether I should make all IFN's simple and then exclude some
> (like GOMP_ ones), or include more
From: Eric Botcazou
The procedure is not stable under repeated invocation. Now it may be called
twice on the same node, for example during the expansion of the renaming of
the predefined equality operator after the unchecked union type is frozen.
gcc/ada/
* exp_ch4.ads
From: Eric Botcazou
This relaxes the condition under which Expand_Assign_Array leaves the
assignment to or from an array slice untouched. The main prerequisite
for the code generator is that everything be aligned on byte boundaries
and Is_Possibly_Unaligned_Slice is too strong a predicate for
From: Yannick Moy
The query Inherited_Subprograms was returning a list containing
some subprograms whose overridding was also in the list, when
interfaces was present. This was an issue for GNATprove. Now propose
a mode for this function to filter out overridden primitives.
gcc/ada/
*
From: Pan Li
This patch would like to introduce 2 new patter of fsrm with SImode, aka:
1. fsrmsi_backup
2. fsrmsi_restore
Both patterns accept the imm and reg format, and then leverage the imm
format instead of reg when RVV floating-point static rounding mode.
Signed-off-by: Pan Li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:729aa4fa48d627c4344764676edad3b65d40a003
commit r14-2288-g729aa4fa48d627c4344764676edad3b65d40a003
Author: Richard Biener
Date:
> -Original Message-
> From: Hongtao Liu
> Sent: Tuesday, July 4, 2023 4:27 PM
> To: Cui, Lili
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] x86: Enable ENQCMD and UINTR for march=sierraforest.
>
> On Tue, Jul 4, 2023 at 4:15 PM Cui, Lili wrote:
> >
> > From: Lili Cui
> >
> >
slp_done_for_suggested_uf is used in vect_analyze_loop_2 without
initialization, which is undefined behavior. Initialize it to false
according to the discussion.
gcc/ChangeLog:
PR tree-optimization/110531
* tree-vect-loop.cc (vect_analyze_loop_1): initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #29 from Richard
Hi,
I just submit a new version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623533.html
So, we could ignore this ping and check the new version.
BR,
Jeff (Jiufu Guo)
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Gentle ping ...
>
> Jiufu Guo via Gcc-patches writes:
>
>> Gentle
On Mon, 3 Jul 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > The following removes late deciding to elide vectorized epilogues to
> > the analysis phase and also avoids altering the epilogues niter.
> > The costing part from vect_determine_partial_vectors_and_peeling is
> > moved to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0682a32c026f1e246eb07bb8066abca4636f01d8
commit r14-2281-g0682a32c026f1e246eb07bb8066abca4636f01d8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f703d2fd3f03890a180e8cc04df087c208999e81
commit r14-2282-gf703d2fd3f03890a180e8cc04df087c208999e81
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 110310, which changed state.
Bug 110310 Summary: vector epilogue handling is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
From: Pan Li
This patch would like to fix one bug to align below items of spec.
1. By default, the RVV floating-point will take dyn mode.
2. DYN is invalid in FRM register for RVV floating-point.
When mode switching the function entry and exit, it will take DYN as
the frm mode.
Signed-off-by:
> In a follow-up patch, can you please document inlining rules involving
> -march and -mtune to "x86 Function Attributes" section? Currently, the
> inlining rules at the end of "target function attribute" section does
> not even mention -march and -mtune. Maybe a subsubsection "Inlining
> rules"
1 - 100 of 208 matches
Mail list logo
