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
>>
在 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
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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
--- 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=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
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 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
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,
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
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
> -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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement,
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
Bug ID: 110554
Summary: more invalid wide Boolean values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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.
>
>
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
>
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:
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
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=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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110552
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
Blocks|
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 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=110438
--- Comment #3 from Alexander Monakov ---
Patch available:
https://inbox.sourceware.org/gcc-patches/8f73371d732237ed54ede44b7bd88...@ispras.ru/T/#u
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
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
> 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
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=110552
--- Comment #1 from Andrew Pinski ---
reducing ...
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
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).
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
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
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=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=110551
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
--- Comment #1 from Andrew Pinski ---
Created attachment 55468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55468=edit
testcase
Please next time attach (which you can do paste in the box) or paste inline the
testcase rather than just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110376
--- Comment #4 from Andrew Pinski ---
(In reply to Shaohua Li from comment #3)
> You post a commit for fixing this bug. Does this mean this report is not a
> DUP of 110228?
The commit was just a testcase (more testcases the better really);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
Bug ID: 110551
Summary: [11 / 12 / 13 /14 regression] Suboptimal codegen for
128 bits multiplication on x86_64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487
Andrew Pinski changed:
What|Removed |Added
Target Milestone|12.4|14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487
--- Comment #13 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:71b68cc559b5d30d07e6b507df7cc6d008f56aad
commit r14-2299-g71b68cc559b5d30d07e6b507df7cc6d008f56aad
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487
--- Comment #12 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:2e5c1b123d5bc4b7eca91f1eb2dab88d0bcdfcfa
commit r14-2298-g2e5c1b123d5bc4b7eca91f1eb2dab88d0bcdfcfa
Author: Andrew Pinski
Date:
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=110550
Bug ID: 110550
Summary: libintl build without -fPIC even though
--enable-shared is configured
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
Jonathan Wakely changed:
What|Removed |Added
CC||vaibhavawale3 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110549
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
From: benjamin priour
Script contrib/check_GNU_style.sh complains about there being a space
before a left square bracket ("operator new []").
Though, it is actually within a literal string, and the space
is required to correctly detect the function.
Succesfully regstrapped on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110549
Bug ID: 110549
Summary: Undefined behavior sanitizer triggered in
basic_string::_M_construct that uses iterator overload
with input iterator tag
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #8 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > Constraints are completely the wrong tool for this. Just use modes, which
> > *are* the right tool?
>
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
Hi!
On 2013-01-24T10:14:58-0500, Diego Novillo wrote:
> [...] the patch [...] committed [...]
This did clean up some things:
> --- a/gcc/ggc-internal.h
> +++ b/gcc/ggc-internal.h
> @@ -55,8 +55,7 @@ extern struct ggc_pch_data *init_ggc_pch (void);
> of an object. Update the ggc_pch_data
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110376
--- Comment #3 from Shaohua Li ---
You post a commit for fixing this bug. Does this mean this report is not a DUP
of 110228?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110523
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> I have tried to start a git bisect and the current range is
> g:f3d87219dd502d5c .. g:9757e4440bd8755d.
>
> This is 15 commits.
I messed this one up and
On Tue, Jul 04, 2023 at 11:26:26AM +0200, Mikael Morin wrote:
> Le 04/07/2023 à 01:56, Steve Kargl a écrit :
> > On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
> > >
> > > Indeed, this is a nice demonstration.
> > >
> > > While playing, I was wondering whether the
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 ht_identifier':
On 2022-10-18T18:14:54-0400, Lewis Hyatt via
Hi Jakub!
On 2023-06-30T18:37:59+0200, Jakub Jelinek wrote:
> On Fri, Jun 30, 2023 at 08:45:38PM +0800, Kito Cheng wrote:
>> Hmmm, I think maybe what we need is to leverage C++ language features
>> to declare enum with underlying types like that:
>>
>> enum machine_mode : uint16_t
>
> What would
On Mon, Jul 3, 2023 at 5:57 PM Takayuki 'January June' Suwa
wrote:
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (machine_function, xtensa_expand_prologue):
> Change to use HARD_REG_BIT and its macros.
> * config/xtensa/xtensa.md
> (peephole2: regmove
On 27.06.2023 07:11, Hongtao Liu wrote:
> On Tue, Jun 20, 2023 at 5:34 PM Hongtao Liu wrote:
>>
>> On Tue, Jun 20, 2023 at 5:03 PM Jan Beulich wrote:
>>>
>>> On 20.06.2023 10:33, Hongtao Liu wrote:
On Tue, Jun 20, 2023 at 3:07 PM Jan Beulich via Gcc-patches
wrote:
>
> I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110546
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.1.0, 12.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110548
Bug ID: 110548
Summary: Segfault with optional argument and OpenMP tasks
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110547
Bug ID: 110547
Summary: Improper finalization calls with OpenMP tasks
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #34 from Sergei Trofimovich ---
(In reply to rguent...@suse.de from comment #33)
> On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
> >
> > --- Comment #32 from Sergei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107437
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
> On Wed, 28 Jun 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > There's an existing bug in loop frequency scaling where the if statement
> > checks
> > to see if there's a single exit, and records an dump file note but then
> > continues.
> >
> > It then tries to access the null pointer,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> + val = std::move(*__old_start);
If this is changed to just val = *__old_start then the error comes back.
110542.cc: In function 'int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542
--- Comment #3 from Jonathan Wakely ---
The GCC error is fixed by this change:
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -701,6 +701,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110546
Bug ID: 110546
Summary: Function clone not treated as valid allocator with
-Wmismatched-dealloc
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Keywords:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542
--- Comment #2 from Jonathan Wakely ---
I don't understand why GCC *doesn't* fail without the fix above, when that code
clearly gets used during constant evaluation and the runtime version of that
function *does* access objects outside their
> The mod-subtract optimization with ncounts==1 produced incorrect edge
> probabilities due to incorrect conditional probability calculation. This
> patch fixes the calculation.
>
> gcc/ChangeLog:
>
> * value-prof.cc (gimple_mod_subtract_transform): Correct edge
> prob calculation.
On Mon, Jul 3, 2023 at 12:12 PM Robin Dapp wrote:
>
> Hi Manolis,
>
> that looks like a nice enhancement of what's already possible. The concern
> I had some years back already was that this function would eventually
> grow and cannibalize on some of what the other functions in ifcvt already
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542
--- Comment #1 from Jonathan Wakely ---
There seem to be two separate bugs here, which I don't understand.
The clang error is fixed by:
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110545
Bug ID: 110545
Summary: gcda files not generated for some shared libs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110544
Bug ID: 110544
Summary: [14 regression] gcc.dg/vect/pr71264.c ICEs after
r14-2150
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #33 from rguenther at suse dot de ---
On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
>
> --- Comment #32 from Sergei Trofimovich ---
> (In reply to Richard Biener from
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 2017
> > > that are caused by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #32 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #29)
> I can't reproduce the original failure on trunk or with GCC 13.1, but the
> testcase from comment#16 is now fixed. I also cannot reproduce the testcase
Le 03/07/2023 à 22:49, Harald Anlauf a écrit :
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
These look good, but I'm surprised that there is no similar change at
the 6819 line.
This is the class array actual vs class array dummy case.
It seems to be checked by the "bar" subroutine in
Yes, thanks Robin, we can move to another mail thread for this, avoiding
misleading.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, July 4, 2023 9:15 PM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches
Cc: rdapp@gmail.com; jeffreyalaw ; Wang, Yanzhang
; kito.cheng
Hi Robin,
Thanks for reviewing, sorry for my silly mistakes in the original patch, CIL.
> Here you are referring to 10.1 in the spec I assume. Could we add this as a
> comment in the code?
Sure, from the spec rvv 1.0, aka "All standard vector floating-point arithmetic
operations follow the
> Just revert this patch, it reports some weird illegal instr, I may
> need more time for this.
The illegal instruction is due to the wrong rounding mode. We set
5 instead of 7 because the two enums don't match. A simple but ugly
fix would be two dummy entries so that FRM_MODE_DYN is entry 7 in
Sorry for I made a mistake in V4:
+ if (final_len && final_len)
It should be
+ if (final_len && final_mask)
I fixed it on V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623589.html
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date:
From: Ju-Zhe Zhong
Hi, Richard and Richi.
Address comments from Richi.
Make gs_info.ifn = LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE.
I have fully tested these 4 format:
length = vf is a dummpy length,
mask = {-1,-1, ... } is a dummy mask.
1. no length, no mask
LEN_MASK_GATHER_LOAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92562
Marc Mutz changed:
What|Removed |Added
CC||marc.mutz at hotmail dot com
--- Comment #2
1 - 100 of 208 matches
Mail list logo
