LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-04 13:50
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Fix one bug for floating-point static frm
From: Pan Li
This patch would like to fix one bug to align below
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=110170
--- Comment #10 from Hongtao.liu ---
There're couple of other issues.
1. rtx_cost for and/ior/xor:SF/DF is not right, it actually generate vector
instructions.
2. branch_cost is COSTS_N_INSN(1) instead of BRANCH_COST ().
which make noce more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #5 from Hao Liu ---
BTW, there is no warning is probably because the original code is too
complicated and not inlined.
Compile the simple case by "g++ -O3 -S -Wall hello.c":
int foo(bool a) {
bool b;
if (a || b)
return 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #4 from Hao Liu ---
> IMHO, the initialization with false is unnecessary and very likely it isn't
> able to get optimized, it seems worse from this point of view.
Sorry. I don't think so. See more at
Hi Jeff,
on 2023/7/4 10:18, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> If a constant is possible to be rotated to/from a positive or negative
> value from "li", then "li;rotldi" can be used to build the constant.
>
> Compare with the previous version:
>
Hi Robin,
Just revert this patch, it reports some weird illegal instr, I may need more
time for this.
Pan
-Original Message-
From: Li, Pan2
Sent: Monday, July 3, 2023 11:00 PM
To: Robin Dapp ; juzhe.zh...@rivai.ai; gcc-patches
Cc: jeffreyalaw ; Wang, Yanzhang
; kito.cheng
Subject:
Committed as both the bootstrap and regression tests passed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Sandiford via Gcc-patches
Sent: Monday, July 3, 2023 9:50 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
Subject: Re:
Hi,
For function with different target attributes, current logic rejects to
inline the callee when any arch or tune is mismatched. Relax the
condition to allow callee with default arch/tune to be inlined.
Boostrapped/regtested on x86-64-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
*
Hi,
Gentle ping ...
Jiufu Guo via Gcc-patches writes:
> Gentle ping...
>
> Jiufu Guo via Gcc-patches writes:
>
>> Gentle ping...
>>
>> Jiufu Guo via Gcc-patches writes:
>>
>>> Hi
>>>
>>> I would like to ping this patch for stage1:
>>>
vpternlog is also used for optimization which doesn't need any valid
input operand, in that case, the destination is used as input in the
instruction and that creates a false dependence.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/ChangeLog:
PR
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Tuesday, July 4, 2023 10:20 AM
To: Robin Dapp
Cc: Juzhe-Zhong ; gcc-patches@gcc.gnu.org;
kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com;
Hi Carl,
on 2023/6/30 05:36, Carl Love wrote:
> GCC maintainers:
>
> Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some
> of the scan-assembler-times checks to cover multiple similar
> instructions. Change the function check macro to a macro to generate a
> function to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #3 from Kewen Lin ---
(In reply to Hao Liu from comment #2)
> > Is the warning from some static analyzer?
>
> No. I just find it maybe a bug while looking at the code.
>
> > slp should be true always (always do analyze slp), it
LGTM
On Mon, Jul 3, 2023 at 8:47 PM Robin Dapp wrote:
>
> LGTM.
>
> Regards
> Robin
>
Hi,
If a constant is possible to be rotated to/from a positive or negative
value from "li", then "li;rotldi" can be used to build the constant.
Compare with the previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621961.html
This patch just did minor changes to the style and
Hi Carl,
on 2023/7/3 23:57, Carl Love wrote:
> Kewen:
>
> On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote:
>> Segher never liked the above way of looking at the assembly. He
>> prefers:
>> gcc -S -g -mcpu=power8 -o vsx-vector-6-func-2lop.s vsx-vector-6-
>> func-
>> 2lop.c
>>
>> grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #2 from Hao Liu ---
> Is the warning from some static analyzer?
No. I just find it maybe a bug while looking at the code.
> slp should be true always (always do analyze slp), it doesn't care what's in
> slp_done_for_suggested_uf.
This is just expected to be a change in representation.
No code is expected to change; no new tests are added.
* config/cris/cris.md (CRIS_UNSPEC_SWAP_BITS): Remove.
("cris_swap_bits", "ctzsi2"): Use bitreverse instead.
---
gcc/config/cris/cris.md | 9 ++---
1 file changed, 2
Committed as obvious after regtest for cris-elf together
with the "next" patch, that replaces unspec
CRIS_UNSPEC_SWAP_BITS with bitreverse (which hit the ICE).
-- >8 --
This seems to have just been overlooked when introducing
BITREVERSE. Note that the function name mem_loc_descriptor
is a
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 elimination during DFmode input reload):
Likewise.
---
gcc/config/xtensa/xtensa.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
--- Comment #6 from Andrew Pinski ---
With selective scheduling on my reduced testcase:
```
Time variable usr sys wall
GGC
phase setup: 0.00 ( 0%) 0.01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
--- Comment #5 from Andrew Pinski ---
Here is a testcase which does not go into an infinite loop but takes a little
more than 4 seconds to compile which is a lot:
```
static unsigned short g_231 = 1UL;
void func_61(unsigned p_62) {
unsigned
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 following code is conforming:
>
> program p
> call s ((1))
> contains
> subroutine s (x)
> integer :: x
> x = 42
>
On Mon, 3 Jul 2023 at 23:14, Thomas Rodgers via Libstdc++
wrote:
>
> This testcase is causing some timeout issues. This patch splits the
> testcase up by individual set algorithm.
I think the Apache license requires a notice saying the original file
was modified. A comment in each new file
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The header is only supported for the cxx11 ABI. The
declarations of basic_syncbuf, basic_osyncstream, syncbuf and
osyncstream were already correctly guarded by a check for
_GLIBCXX_USE_CXX11_ABI, but the wsyncbuf and wosyncstream declarations
were
Pushed to trunk now.
On Fri, 30 Jun 2023 at 21:17, Jonathan Wakely via Libstdc++
wrote:
>
> Jakub made a similar change a few yeas ago, but I think it got lost
> in the recent PSTL rebase.
>
> Tested x86_64-linux.
>
> Does this look OK for trunk?
>
> -- >8 --
>
> This reapplies
Tested x86_64-linux. Pushed to trunk.
This isn't a regression, but is safe to backport.
-- >8 --
These calls should be qualified to prevent ADL, which can cause errors
for incomplete types that are associated classes.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (_Destroy):
On Mon, 3 Jul 2023 19:24:23 +
Richard Nardi via Gcc wrote:
>
> Hello,
> I hope you are having a wonderful day. I would like to engage your firm to
> prepare my tax return for the current tax year. [...]
Sounds legit. I have a feeling you'll be asking me for my credit card number
and bank
This testcase is causing some timeout issues. This patch splits the
testcase up by individual set algorithm.
From 857359b72f8886b6e90db3b596d04f08559d2b51 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Mon, 3 Jul 2023 15:04:45 -0700
Subject: [PATCH] libstdc++: Split up pstl/set.cc testcase
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 vect_analyze_loop_costing where we use the main loop
>
Thanks, applied to master.
--Philipp.
On Mon, 3 Jul 2023 at 15:42, Kito Cheng wrote:
> Thanks, LGTM :)
>
> Christoph Muellner 於 2023年7月3日 週一，19:08寫道：
>
>> From: Christoph Müllner
>>
>> This series adds basic support for the vector crypto extensions:
>> * Zvbb
>> * Zvbc
>> * Zvkg
>> * Zvkned
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
Andrew Pinski changed:
What|Removed |Added
Summary|Timeout with with specific |selective scheduling seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #25 from Sergei Trofimovich ---
Specifically this bug.c.034t.ccp1's bit looks fishy:
...
Folding statement: LookupFlags_14 = 1;
Queued stmt for removal. Folds to: 1
Folding statement: LookupFlags_15 = 0;
Queued stmt for removal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110510
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110510
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d0a333612bfb7faf8d61210c831165388e758768
commit r14-2270-gd0a333612bfb7faf8d61210c831165388e758768
Author: Andrew Pinski
Date:
Following the similar support for C++ and Fortran, here is the
C implementation for the OpenMP 5.0 array-shaping operator, and for
strided and rectangular updates for "target update".
Much of the implementation is shared with the C++ support added earlier
in this patch series. Some details of
This patch implements noncontiguous "target update" for Fortran.
The existing middle end/runtime bits relating to C++ support are reused,
with some small adjustments, e.g.:
1. The node used to map the OMP "array descriptor" (from omp-low.cc
onwards) now uses the OMP_CLAUSE_SIZE field as a
At present, map/to/from clauses on OpenMP "target" directives may be
expanded into several mapping nodes if they describe array sections with
pointer or reference bases, or similar. This patch allows the original
clause to be replaced during that expansion, mostly by passing the list
pointer to
This patch series adds support for the array-shaping operator from OpenMP
5.0, and strided and rectangular transfers for "target update" directives.
The patches were previously posted for mainline here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613785.html (C++)
This patch fixes "exit data" for (C++) reference-to-pointer struct
components with array sections, such as:
struct S { int * [...] };
...
#pragma omp target exit data map(from: str->ptr, str->ptr[0:n])
Such exits need two "detach" operations. We need to unmap
both the pointer and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
A few thing to double check below.
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 30946ba3f63..16e8f037cfc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
(...)
@@ -6117,6 +6118,33 @@
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> Hi all,
>
> 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 kernel's? That's
what it sounded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
--- Comment #1 from Andrew Pinski ---
>clobbering other parameters and callee-saved registers.
(insn 2 8 3 2 (set (reg:DI 84)
(reg:DI 5 di [ aD.2522 ])) "/app/example.cpp":3:25 -1
(nil))
(insn 3 2 4 2 (set (reg:DI 85)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-03
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110536
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Hello,
I hope you are having a wonderful day. I would like to engage your firm to
prepare my tax return for the current tax year. Prior to this year, my wife had
always been in charge of our tax returns. However, our financial situation has
changed, and she has also taken on additional
Hi all,
This is a request for comments on extending the atomic builtins API to
help avoiding redundant memory barriers. Indeed, there are
discrepancies between the Linux kernel consistency memory model (LKMM)
and the C11/C++11 memory consistency model [0]. For example,
fully-ordered atomic
This has been in use for some time in the Darwin branches that are used
by downstream distributions. Re-tested on x86_64-darwin, pushed to trunk,
thanks,
Iain
--- 8< ---
The addition of the multiply_defined suppress flag has been handled for some
considerable time now in the Darwin specs; remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #6 from Costas Argyris ---
Part of this may be because the driver::finalize function introduced here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9376dd63e6a2d94823f6faf8212c9f37bef5a656
is not called from main:
int
main
__normal_iterator > >; _UnaryOperation =
make_type_param_vector(const
std::initializer_list&)::]',
inlined from 'std::vector make_type_param_vector(const
std::initializer_list&) [with TypeParam = unsigned char; T = int]' at
:10:17:
/opt/compiler-explorer/gcc-trunk-20230703/include/c++/14.
W dniu 3.07.2023 o 18:57, Richard Earnshaw (lists) pisze:
On 03/07/2023 17:42, Rafał Pietrak via Gcc wrote:
Hi Ian,
[-]
And WiKi reporting up to 40% performance improvements in some corner
cases is impressive and encouraging. I believe, that the reported
average of 5-8%
On 03/07/2023 17: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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #7 from Andreas Schwab ---
You are probably looking for a constraint that mirrors the quad_int_reg_operand
predicate.
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 than just the new widening IFNs.
But since this is the only
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 accomodate the functionality could be as
little as one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535
Bug ID: 110535
Summary: Internal error when performing a surrogate call with
unsatisfied constraints
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
Hi David,
W dniu 3.07.2023 o 16:52, David Brown pisze:
[]
But, before I dive into learning C++ (forgive the naive question)
isn't it so, that C++ comes with a heavy runtime? One that will bloat
my tiny project? Or the bloat comes only when one uses particular
elaborated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 110534, which changed state.
Bug 110534 Summary: confusing -Wuninitialized when strict aliasing is violated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
Andrew Pinski changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
libstdc++: Recognize C++ random access iterators as random access in PSTL
[PR110432]
The check for random access iterators in the PSTL only checks whether the
iterator inherits from the random_access_iterator_tag, failing to recognize
random access iterators originating in C++20 ranges and views.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
--- Comment #1 from Andrew Pinski ---
There are different levels of -Wstrict-aliasing and iirc level 3 will warn.
Note I don't think the uninitialized warning is a bad thing here. Because it
does point out gcc is thinking it is uninitialized
Kewen:
On Fri, 2023-06-30 at 15:20 -0700, Carl Love wrote:
> Segher never liked the above way of looking at the assembly. He
> prefers:
> gcc -S -g -mcpu=power8 -o vsx-vector-6-func-2lop.s vsx-vector-6-
> func-
> 2lop.c
>
> grep xxlor vsx-vector-6-func-2lop.s | wc
> 34 68 516
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> Constraints are completely the wrong tool for this. Just use modes, which
> *are* the right tool?
Well you cannot specify modes in the asm, so I think
On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc wrote:
>
> W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze:
> [---]
> > I think I understand what you're asking for but:
> > 1) You'd need a new ABI specification to handle this, probably involving
> > register assignments
Sure, every change need test and will pay attention for this in future.
Pan
-Original Message-
From: Robin Dapp
Sent: Monday, July 3, 2023 10:57 PM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches
Cc: rdapp@gmail.com; jeffreyalaw ; Wang, Yanzhang
; kito.cheng
Subject: Re:
> Sorry for inconvenient, still working on fix it. If urgent I can
> revert this change to unblock your work ASAP.
I'm not blocked by this, thanks, just wanted to document it here.
I was testing another patch and needed to dig for a while until
I realized the FAILs come from this one. In general
Sorry for inconvenient, still working on fix it. If urgent I can revert this
change to unblock your work ASAP.
Pan
-Original Message-
From: Robin Dapp
Sent: Monday, July 3, 2023 10:49 PM
To: Li, Pan2 ; juzhe.zh...@rivai.ai; gcc-patches
Cc: rdapp@gmail.com; jeffreyalaw ; Wang,
On 28/06/2023 10:35, Rafał Pietrak via Gcc wrote:
Hi Jonathan,
W dniu 28.06.2023 o 09:31, Jonathan Wakely pisze:
If you use a C++ library type for your pointers the syntax above
doesn't need to change, and the fancy pointer type can be implemented
portable, with customisation for targets
Hmm, looks like it wasn't simple enough...
I'm seeing execution fails for various floating point test cases.
This is due to a mismatch between the FRM_DYN definition (0b111 == 7)
and the attribute value (== 5). Therefore we set the rounding mode
to 5 instead of 7.
Regards
Robin
On 03/07/2023 15:34, Joel Sherrill wrote:
On Mon, Jul 3, 2023, 4:33 AM Claudio Eterno
wrote:
Hi Joel, I'll give an answer ASAP on the newlib and libgloss...
I supposed your question were about the licences question on newlib,
instead you were really asking what changed on the repo libs...
Also change internal variable from int to bool.
gcc/ChangeLog:
* tree.h (tree_int_cst_equal): Change return type from int to bool.
(operand_equal_for_phi_arg_p): Ditto.
(tree_map_base_marked_p): Ditto.
* tree.cc (contains_placeholder_p): Update function body
for bool return
Committed as passed both the bootstrap and regression test, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Sandiford via Gcc-patches
Sent: Monday, July 3, 2023 5:27 PM
To: juzhe.zh...@rivai.ai
Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
Subject: Re:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:12897414d309d9cf398259c212923aa7b031a3af
commit r13-7528-g12897414d309d9cf398259c212923aa7b031a3af
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:025a3f417899577710eb88527897fc571a0280ff
commit r13-7526-g025a3f417899577710eb88527897fc571a0280ff
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108835
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:e79c65331190bef99c88062c77d557d161caf380
commit r13-7525-ge79c65331190bef99c88062c77d557d161caf380
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
--- Comment #1 from Roman Lebedev ---
To spell it out explicitly, not storing the resulting `.sarif`
next to the produced object file itself, like it's done in (all?)
other cases, very much looks like a not-a-feature,
basically making the
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> Hi, Richi and Richard.
>
> Base one the review comments from Richard:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623405.html
>
> I change len_mask_gather_load/len_mask_scatter_store order into:
> {len,bias,mask}
>
> We adjust adding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
--- Comment #12 from Jakub Jelinek ---
Wrong-code issues like this shouldn't be just closed.
I think you should ping Uros on this, or another option would be to revert on
the branch the change that caused the regression.
Thanks, LGTM :)
Christoph Muellner 於 2023年7月3日 週一，19:08寫道：
> From: Christoph Müllner
>
> This series adds basic support for the vector crypto extensions:
> * Zvbb
> * Zvbc
> * Zvkg
> * Zvkned
> * Zvkhn[a,b]
> * Zvksed
> * Zvksh
> * Zvkn
> * Zvknc
> * Zvkng
> * Zvks
> * Zvksc
> * Zvksg
> * Zvkt
Lgtm
juzhe.zh...@rivai.ai 於 2023年7月3日 週一，19:11寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-07-03 18:57
> To: gcc-patches
> CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.
> From: Pan Li
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|NEW
Summary|[13/14
From: Eric Botcazou
The problem is that the predefined equality operator for unchecked union
types is implemented out of line by invoking a function that takes more
parameters than the two operands, which means that the renaming is not
seen as type conforming with this function and, therefore,
From: Eric Botcazou
The expansion of the predefined equality operator for untagged record types
can be done either in line, i.e. into the component-wise comparison of the
operands, or out of line, i.e. into a call to a function implementing this
comparison, and the heuristics of the selection
From: Eric Botcazou
This is the clause about inferable discriminants in unchecked unions.
gcc/ada/
* sem_util.adb (Has_Inferable_Discriminants): In the case of a
component with a per-object constraint, also return true if the
enclosing object is not of an unchecked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Bug ID: 110534
Summary: confusing -Wuninitialized when strict aliasing is
violated
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
On Mon, 3 Jul 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
---
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 vect_analyze_loop_costing where we use the main loop
analysis to constrain the epilogue
Dear Friends:
1) I have (of course) kept your copyright notice at the start of the « asm.h »
header file of my project.
2) I have published my source code using your GPL V3 license
I am not trying to steal you anything. And I would insist that I have great
respect for the people working with
LGTM.
Regards
Robin
Richard Biener via Gcc-patches writes:
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #12 from Jonathan Wakely ---
13.1 has already been released, it can't be changed now.
As comment 10 says, the fix is only on trunk so far and has not been backported
to the gcc-13 branch. It will be in the next 13.x release after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
Bug ID: 110533
Summary: [x86-64] naked with -O0 and register-passed
struct/int128 clobbers parameters/callee-saved regs
Product: gcc
Version: unknown
Status:
I recently noticed that current VSETVL pass has a unnecessary restriction on
local
AVL propgation.
Consider this following case:
+ insn 1: vsetvli a5,a3,e8,mf4,ta,mu
+ insn 2: vsetvli zero,a5,e32,m1,ta,ma
+ ...
+
Hi everyone,
We will be having our next monthly community call on the 10th of July at
9am UTC.
https://meet.jit.si/gccrs-community-call-july
https://hackmd.io/Abr_eMmrRty8fJMsZQXB7Q
Please feel free to join even if you'd just like to listen!
Kindly,
Arthur
OpenPGP_0x1B3465B044AD9C65.asc
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
1 - 100 of 181 matches
Mail list logo
