https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
--- Comment #3 from cuilili ---
I reproduced S1244 regression on znver3.
Src code:
for (int i = 0; i < LEN_1D-1; i++)
{
a[i] = b[i] + c[i] * c[i] + b[i] * b[i] + c[i];
d[i] = a[i] + a[i+1];
}
On 25.06.2023 06:42, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> +(define_code_iterator andor [and ior])
>> +(define_code_attr nlogic [(and "nor") (ior "nand")])
>> +(define_code_attr ternlog_nlogic [(and "0x11") (ior "0x77")])
>> +
>>
On Tue, 13 June 2023 12:02, Richard Biener wrote:
> On Mon, Jun 12, 2023 at 4:04 PM Roger Sayle
> wrote:
> > The following simple test case, from PR 104610, shows that memcmp ()
> > == 0 can result in some bizarre code sequences on x86.
> >
> > int foo(char *a)
> > {
> > static const char
On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches
wrote:
>
> Following two-operand bitwise operations, add another splitter to also
> deal with not followed by broadcast all on its own, which can be
> expressed as simple embedded broadcast instead once a broadcast operand
> is actually
On Wed, Jun 21, 2023 at 2:28 PM Jan Beulich via Gcc-patches
wrote:
>
> With respective two-operand bitwise operations now expressable by a
> single VPTERNLOG, add splitters to also deal with ior and xor
> counterparts of the original and-only case. Note that the splitters need
> to be separate,
On Wed, Jun 21, 2023 at 2:28 PM Jan Beulich via Gcc-patches
wrote:
>
> The intended broadcast (with AVX512) can very well be done right from
> memory.
Ok.
>
> gcc/
>
> * config/i386/sse.md: Permit non-immediate operand 1 in AVX2
> form of splitter for PR target/100711.
>
> ---
On Wed, Jun 21, 2023 at 2:27 PM Jan Beulich via Gcc-patches
wrote:
>
> When it's the memory operand which is to be inverted, using VPANDN*
> requires a further load instruction. The same can be achieved by a
> single VPTERNLOG*. Add two new alternatives (for plain memory and
> embedded
On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
wrote:
>
> All combinations of and, ior, xor, and not involving two operands can be
> expressed that way in a single insn.
>
> gcc/
>
> PR target/93768
> * config/i386/i386.cc (ix86_rtx_costs): Further special-case
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110400
Bug ID: 110400
Summary: Reuse vector register for both scalar and vector
value.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309
--- Comment #4 from Hongtao.liu ---
Fixed for GCC14.
Note: unspec is not added to maskstore since vpblendd doesn't support memeory
dest, so there's no chance for a maskstore be optimized to vpblendd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309
--- Comment #3 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:c79476da46728e2ab17e0e546262d2f6377081aa
commit r14-2070-gc79476da46728e2ab17e0e546262d2f6377081aa
Author: liuhongt
Date: Tue Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #9 from Hongtao.liu ---
> So we can simply clear only MEM_EXPR (and MEM_OFFSET), that cuts off the
> problematic part of alias analysis. Together with UNSPEC this might be
> enough to fix things.
>
Note maskstore won't optimized
Hi, Li.
Appreciate for catching this!
I think it's better:
-emit_insn (gen_rtx_SET (gen_lowpart (e.vector_mode (), e.target), src));
+emit_move_insn (gen_lowpart (e.vector_mode (), e.target), src);
do this to fix this issue.
Thanks.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-06-25 11:08
To:
From: Ju-Zhe Zhong
When trying to enable LEN_MASK_{LOAD,STORE} in RISC-V port,
I found I made a mistake in case of argument index of BIAS.
This patch is an obvious fix,
Ok for trunk ?
gcc/ChangeLog:
* internal-fn.cc (expand_partial_store_optab_fn): Fix bug of BIAS
argument index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #7 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Thiago Jung Bauermann from comment #0)
> > Created attachment 55387 [details]
> > Output of running gfortran with -freport-bug
> >
> > In today's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #6 from Hongtao.liu ---
(In reply to Thiago Jung Bauermann from comment #0)
> Created attachment 55387 [details]
> Output of running gfortran with -freport-bug
>
> In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
arg and target should be expanded to reg rtx during expand pass.
Consider this following case:
void test_vlmul_ext_v_i8mf8_i8mf4(vint8mf8_t op1) {
vint8mf4_t res = __riscv_vlmul_ext_v_i8mf8_i8mf4(op1);
}
Compilation fails with:
test.c: In function 'test_vlmul_ext_v_i8mf8_i8mf4':
test.c:5:1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #5 from Hongtao.liu ---
Reproduced with
typedef struct dest
{
double m[3][3];
} dest;
typedef struct src
{
int m[3][3];
} src;
void
foo (dest *a, src* s)
{
for (int i = 0; i != 3; i++)
for (int j = 0; j != 3; j++)
Such issue will be addressed by this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622440.html
But still wait for Jakub's comments.
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2023-06-23 18:25
To: shiyulong
CC: gcc-patches; palmer; kito.cheng; jim.wilson.gcc; juzhe.zhong;
Hi,
This patch adds a new insn for vector splat with small V2DI constants on P8.
If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be loaded
with vspltisw and vupkhsw on P8. It should be efficient than loading vector from
memory.
Compared to last version, the main change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13421
Andrew Pinski changed:
What|Removed |Added
CC||baiwfg2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
--- Comment #1 from Andrew Pinski ---
32 bit, w1=2
w2=2
w3=2
w4=0
w5=2
Program received signal SIGABRT, Aborted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
Bug ID: 110399
Summary: pointer substraction causes coredump with ftrapv on
edge case
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
On Sat, Jun 24, 2023, at 11:01 AM, Jeff Law via Gcc-patches wrote:
> On 6/21/23 02:14, Wang, Yanzhang wrote:
>> Hi Jeff, sorry for the late reply.
>>
>>> The long branch handling is done at the assembler level. So the clobbering
>>> of $ra isn't visible to the compiler. Thus the compiler has to
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Saturday, June 24, 2023 10:09 PM
To: 钟居哲 ; gcc-patches
Cc: rguenther ; richard.sandiford
Subject: Re: [PATCH] SSA ALIAS: Apply LEN_MASK_{LOAD, STORE} into SSA alias
analysis
On Sun, Jun 25, 2023 at 9:17 AM Liu, Hongtao wrote:
>
>
>
> > -Original Message-
> > From: Jan Beulich
> > Sent: Wednesday, June 21, 2023 8:40 PM
> > To: Hongtao Liu
> > Cc: gcc-patches@gcc.gnu.org; Kirill Yukhin ; Liu,
> > Hongtao
> > Subject: Re: [PATCH v2] x86: make better use of
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, June 21, 2023 8:40 PM
> To: Hongtao Liu
> Cc: gcc-patches@gcc.gnu.org; Kirill Yukhin ; Liu,
> Hongtao
> Subject: Re: [PATCH v2] x86: make better use of VBROADCASTSS /
> VPBROADCASTD
>
> On 21.06.2023 09:44, Jan Beulich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #4 from Hongtao.liu ---
I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110398
Bug ID: 110398
Summary: Program_Error sem_eval.adb:4635 explicit raise
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, June 24, 2023 10:51 PM
To: juzhe.zh...@rivai.ai; yulong ; gcc-patches
Cc: palmer ; Kito.cheng ; Li, Pan2
; wuwei2016 ; jiawei
; shihua ; dje.gcc ;
pinskia ; Robin Dapp
Subject: Re: [PATCH V1] RISC-V:Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77294
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384
Andrew Pinski changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110373
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #32 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #31)
> (In reply to Vincent Lefèvre from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > I mean that if the compiler can't see it is in [0, 1],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
--- Comment #3 from Andrew Pinski ---
Note it is not an infinite loop, just many basic blocks (over 4 of them)
causing the performance to be very very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
--- Comment #1 from Andrew Pinski ---
On the trunk it takes no time at all:
[apinski@xeond2 upstream-gcc-git]$ ~/upstream-gcc/bin/g++ t.cc --coverage
[apinski@xeond2 upstream-gcc-git]$ LD_LIBRARY_PATH=~/upstream-gcc/lib64 ./a.out
> Hi,
Hi,
I am sorry for late reaction.
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." So as a first step, I am adding .symtab along with
> __gnu_lto_slim symbol into it so that at a later stage, it can be
> recognized that this object file has been
Snapshot gcc-13-20230624 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230624/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #18 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8f6c747c8638d4c3c47ba2d4c8be86909e183132
commit r14-2065-g8f6c747c8638d4c3c47ba2d4c8be86909e183132
Author: Roger Sayle
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
--- Comment #3 from Ivan Sorokin ---
I tried to investigate why GCC is able to simplify `(a | b) ^ a` and `(a | ~b)
^ a` from comment 2, but not similarly looking `(~a | b) ^ a` from comment 0.
`(a | b) ^ a` matches the following pattern from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788
Andrew Pinski changed:
What|Removed |Added
CC||stevenxia990430 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
--- Comment #1 from Andrew Pinski ---
Note here is the odd thing about this issue, it only shows up some of the time.
You can reproduce it 100% of the time if you use -fdump-tree-original .
Also don't need the include of iostream (though if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344
--- Comment #3 from Jason Merrill ---
Version of the paper testcase that just adds constexpr, that we currently
reject:
#include
struct Sheep {
constexpr std::string_view speak() const noexcept { return "Baa"; }
};
struct Cow {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
Bug ID: 110397
Summary: types may not be defined in parameter types leads to
ICE
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #7 from Andrew Pinski ---
(In reply to jackyguo18 from comment #6)
> @Andrew Pinski - Thanks, just confirmed that that was the issue.
>
> Why doesn't GCC choose to delete the function (thus causing the weird
> behaviour) early at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
jackyguo18 at hotmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #5 from jackyguo18 at hotmail dot com ---
@Andrew Pinski - Thanks, just confirmed that that was the issue.
Why doesn't GCC choose to delete the function (thus causing the weird
behaviour) early at lower optimization levels?
Seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #3 from Brecht Sanders
---
Any pointers on which files to edit in order to support aarch64-mingw ?
I think it won't require reinventing the wheel as it will probably be a mix of
existing *-mingw and aarch64-* stuff...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
--- Comment #5 from Andrew Pinski ---
On the trunk with the original testcase here we get:
tree copy headers : 12.16 ( 19%) 0.01 ( 2%) 21.57 ( 28%)
771k ( 0%)
(I suspect the rest is due to not setting release
Hi Paul!
On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
extra blank line, introduced by my last patch. I played safe and went
exclusively for class functions with attr.class_pointer set on the
grounds that
++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230624 (experimental) [master r14-924-gd709841ae0f] (GCC)
[604] %
[604] % gcctk -O3 -fsel-sched-pipelining -fschedule-insns
-fselective-scheduling2 -fPIC small.c
during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
--- Comment #4 from Andrew Pinski ---
VRP/ranger uses SCEV now so it might even be worse, the testcase from PR 110396
has that behavior too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
Andrew Pinski changed:
What|Removed |Added
CC||luydorarko at vusra dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #23 from anlauf at gcc dot gnu.org ---
You could check the input arguments for validity, e.g. using ieee_is_finite
from the intrinsic ieee_arithmetic module.
use, intrinsic :: ieee_arithmetic, only: ieee_is_finite
...
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Bug ID: 110396
Summary: Compile-time hog with -O2 and -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Dear all,
the first part of the patch came with a testcase that also exercised
code for constant string arguments, which was not touched by that patch
but seems to have caused runtime failures on big-endian platforms
(e.g. Power-* BE) for all optimization levels, and on x86 / -m32
at -O1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #22 from Jürgen Reuter ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.
Indeed, I think you are right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #13 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3f97d10aa1ff5984d6fd657f246d3f251b254ff1
commit r14-2064-g3f97d10aa1ff5984d6fd657f246d3f251b254ff1
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> Created attachment 55393 [details]
> Patch to truncate string argument longer than 1
>
> This truncates the string to length 1 and appears to work on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #21 from anlauf at gcc dot gnu.org ---
I forgot to mention that you need to check that the location where a symptom
is seen sometimes may not be the location of the cause.
This patch contains a pair of (related) optimizations in i386.md that
allow us to generate better code for the example below (this is a step
towards fixing a bugzilla PR, but I've forgotten the number).
__int128 foo64(__int128 x, long long y)
{
__int128 t = (__int128)y << 64;
return x ^ t;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #13 from Alexander Westbrooks ---
I sent in the patch to those emails. Hopefully now the ball will start rolling
and I can slowly get this packaged into a legitimate fix. I'll post updates
here as I receive them.
The patch is below,
Hello,
I am new to the GFortran community. Over the past two weeks I created a
patch that should fix PR82943 for GFortran. I have attached it to this
email. The patch allows the code below to compile successfully. I am
working on creating test cases next, but I am new to the process so it may
This patch teaches i386's STV pass how to handle SUBREG conversions,
i.e. that a TImode SUBREG can be transformed into a V1TImode SUBREG,
without worrying about other DEFs and USEs.
A motivating example where this is useful is
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
On 6/22/23 07:03, Robin Dapp wrote:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #3 from Andrew Pinski ---
You can also try -fno-lifetime-dse to see if you get the behavior you were
expecting too. Though I am not sure it will help extend the lifetime of the
temporary here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Bug ID: 110395
Summary: GCOV stuck in an infinite loop with large std::array
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #1 from jackyguo18 at hotmail dot com ---
Created attachment 55396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55396=edit
.ii file which triggers the bug
I couldn't attach the original .ii file, so I had to compress it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Bug ID: 110394
Summary: Lambda capture receives wrong value
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -O2 and -O3 |[12/13/14 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392
Andrew Pinski changed:
What|Removed |Added
Summary|ICE at -O3 with "-w -O3 |ICE at -O3 with "-O3 -Wall
On Tue, Jun 20, 2023 at 8:32 AM Patrick Palka wrote:
>
> 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
On 6/21/23 02:14, Wang, Yanzhang wrote:
Hi Jeff, sorry for the late reply.
The long branch handling is done at the assembler level. So the clobbering
of $ra isn't visible to the compiler. Thus the compiler has to be
extremely careful to not hold values in $ra because the assembler may
On 6/21/23 01:46, juzhe.zh...@rivai.ai wrote:
LGTM. Thanks.
OK from me as well.
jeff
Here is the benchmark result for is_volatile:
https://github.com/ken-matsui/gcc-benches/blob/main/is_volatile.md#sat-jun-24-074036-am-pdt-2023
Time: -2.42335%
Peak Memory Usage: -1.07651%
Total Memory Usage: -1.62369%
On Sat, Jun 24, 2023 at 7:24 AM Ken Matsui wrote:
>
> This patch implements
On 6/23/23 07:48, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
Hi, since we are going to have LEN_MASK_{LOAD,STORE} into loopVectorizer.
Currenly,
1. we can fold MASK_{LOAD,STORE} into MEM when mask is all ones.
2. we can fold LEN_{LOAD,STORE} into MEM when (len - bias) is VF.
Now, I
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Saturday, June 24, 2023 10:04 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; pal...@rivosinc.com; rdapp@gmail.com
Subject: Re: [PATCH] RISC-V:
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Saturday, June 24, 2023 10:06 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; pal...@rivosinc.com; rdapp@gmail.com
Subject: Re: [PATCH V3] RISC-V:
On 6/21/23 08:24, 钟居哲 wrote:
LGTM.
Likewise. OK for the trunk.
jeff
On 6/22/23 00:39, Richard Biener wrote:
I suspect there's no way to specify the desired semantics? OTOH
code that looks at the MEM operand only and not the insn (which
should have some UNSPEC wrapped) needs to be conservative, so maybe
the alias code shouldn't assume that a (mem:V16SI ..)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105212
--- Comment #2 from Honki Tonk ---
The error still occurs with version 13.1.
This patch lets libstdc++ use new built-in trait __is_volatile.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_volatile): Use __is_volatile built-in
trait.
(is_volatile_v): Likewise.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/std/type_traits | 13
On 6/22/23 07:42, Jan Hubicka wrote:
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
This patch implements built-in trait for std::is_volatile.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
Here is the benchmark result for is_array:
https://github.com/ken-matsui/gcc-benches/blob/main/is_array.md#sat-jun-24-070630-am-pdt-2023
Time: -15.511%
Peak Memory Usage: +0.173923%
Total Memory Usage: -6.2037%
On Sat, Jun 24, 2023 at 6:54 AM Ken Matsui wrote:
>
> This patch implements
On 6/23/23 17:20, 钟居哲 wrote:
Not sure since I saw MASK_STORE/LEN_STORE didn't compute size.
Also OK after a re-review on my part. The code sets the size to -1
after doing the ao_ref_init_from_ptr_and_size, meaning it's not a known
size.
jeff
On 6/23/23 17:21, 钟居哲 wrote:
Not sure since I saw MASK_STORE/LEN_STORE didn't compute size.
Yea, I think you're right. We take the size from the LHS. My mistake.
This is fine for the trunk.
jeff
On 6/21/23 09:53, Juzhe-Zhong wrote:
This patch adds RVV floating-point auto-vectorization.
Also, fix attribute bug of floating-point ternary operations in vector.md.
gcc/ChangeLog:
* config/riscv/autovec.md (fma4): New pattern.
(*fma): Ditto.
(fnma4): Ditto.
On 6/21/23 16:38, Juzhe-Zhong wrote:
Long time ago, I encounter ICE when trying to set clobber register as Pmode
and I forgot the reason.
So, I clobber SI scratch and PUT_MODE to make it Pmode after reload which
makes patterns look unreasonable.
According to Jeff's comments, I tried it
1 - 100 of 155 matches
Mail list logo
