On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote:
> > On the avr, the stack pointer (SP)
> >is not used to access stack slots
> It is very uncommon target then.
Same with the VAX target. SP is used for outgoing function arguments,
function calls, alloca only. AP is used for incoming
> On Jul 27, 2023, at 7:50 AM, Maciej W. Rozycki wrote:
>
> On Fri, 14 Jul 2023, Vladimir Makarov via Gcc wrote:
>
>>> On the avr, the stack pointer (SP)
>>> is not used to access stack slots
>> It is very uncommon target then.
>
> Same with the VAX target. SP is used for outgoing
Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc:
Hi,
The avr target has a bunch of patterns that directly set hard regs at expand
time, like so
The correct approach would be to use usual predicates together with
constraints that describe the register instead of hard
* Thomas Koenig via Gcc:
> Intel recommends to have the new registers as caller-saved for
> compatibility with current calling conventions. If I understand this
> correctly, this is required for exception unwinding, but not if the
> function called is __attribute__((nothrow)).
Nothrow functions
Hey,
On Thu, 27 Jul 2023, Thomas Koenig via Gcc wrote:
> Intel recommends to have the new registers as caller-saved for
> compatibility with current calling conventions. If I understand this
> correctly, this is required for exception unwinding, but not if the
> function called is
Status
==
GCC 13.2 has been released, the releases/gcc-13 branch is open again
for regression and documentation bugfixing. GCC 13.3 can be expected
in spring next year unless something serious changes the plans.
Quality Data
Priority # Change from last report
With the upcoming Intel APX extension, Intel processors will
finally gain 32 general-purpose registers and three-operand
arithmetic, see
https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html
Intel recommends to have the new registers as
The GNU Compiler Collection version 13.2 has been released.
GCC 13.2 is the first bug-fix release from the GCC 13 branch containing
important fixes for regressions and serious bugs in GCC 13.1 with more
than 58 bugs fixed since the previous release.
This release is available from the WWW servers
Hi Dave,
Thanks for the comments!
[...]
> Do you have any DejaGnu tests for this functionality? For example,
> given PyList_New
> https://docs.python.org/3/c-api/list.html#c.PyList_New
> there could be a test like:
>
> /* { dg-require-effective-target python_h } */
>
> #define
Snapshot gcc-11-20230727 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230727/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 7/23/23 20:26, Ben Boeckel wrote:
On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote:
It occurs to me that the model I am envisioning is similar to CMake's object
libraries. Object libraries are a convenient name for a bunch of object files.
IIUC they're linked by naming the
On Thu, 2023-07-27 at 18:13 -0400, Eric Feng wrote:
> Hi Dave,
>
> Thanks for the comments!
>
> [...]
> > Do you have any DejaGnu tests for this functionality? For example,
> > given PyList_New
> > https://docs.python.org/3/c-api/list.html#c.PyList_New
> > there could be a test like:
> >
> >
Hi,
We're discussing to implement `-fno-coroutines` in clang so that we can
disable the coroutine feature with C++ standard higher than 20.
A full discussion can be found here: https://reviews.llvm.org/D156247. A major
motivation for us to do this is to keep consistency with GCC.
However, we
On Thu, Jul 27, 2023 at 7:11 PM chuanqi.xcq via Gcc wrote:
>
> Hi,
> We're discussing to implement `-fno-coroutines` in clang so that we can
> disable the coroutine feature with C++ standard higher than 20.
> A full discussion can be found here: https://reviews.llvm.org/D156247. A
> major
On Thu, 2023-07-27 at 15:11 +0200, Georg-Johann Lay wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 17.07.23 um 13:33 schrieb SenthilKumar.Selvaraj--- via Gcc:
> > Hi,
> >
> >The avr target has a bunch of patterns that directly
On Thu, 13 Jul 2023, Jeff Law via Gcc-patches wrote:
> > Question for the experts: how is this handled? Do I need to apply this
> > change to my workspace and commit it, with Mikael as the change author?
> That's what I usually do for someone without write access. commit it locally
> using the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #19 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d1c072a1c3411a6fe29900750b38210af8451eeb
commit r14-2821-gd1c072a1c3411a6fe29900750b38210af8451eeb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110788
--- Comment #4 from Hongtao.liu ---
> kmovw %edx, %k0
> vpbroadcastmw2d %k0, %xmm1
>
> instead of
>
> vpbroadcastw%edx, %xmm1
>
It's not vpbroadcastw, it's
movzwl %dx, %ecx
vpbroadcastd%ecx, %xmm0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #52 from Shaohua Li ---
*** Bug 107257 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107257
Shaohua Li changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110781
Jose E. Marchesi changed:
What|Removed |Added
Resolution|--- |MOVED
My first impression is those emit_insn (gen_rtx_SET()) seems
necessary, but I got the point after I checked vector.md :P
Committed to trunk, thanks :)
On Thu, Jul 27, 2023 at 6:23 PM juzhe.zh...@rivai.ai
wrote:
>
> Oh, YES.
>
> Thanks for fixing it. It makes sense since the ternary operations
The following fixes the lack of simplification of a vector shift
by an out-of-bounds shift value. For scalars this is done both
by CCP and VRP but vectors are not handled there. This results
in PR91838 differences in outcome dependent on whether a vector
shift ISA is available and thus vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110830
Bug ID: 110830
Summary: -Wanalyzer-use-of-uninitialized-value false negative
due to use-after-free::supercedes_p.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a426b91b27e28985f47d16827a532fbc28c09bd7
commit r14-2820-ga426b91b27e28985f47d16827a532fbc28c09bd7
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54056
Patrick Palka changed:
What|Removed |Added
Keywords||compile-time-hog
Ever confirmed|0
Prevent rtl optimization of vec_duplicate + zero_extend to
vpbroadcastm since there could be an extra kmov after RA.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ready to push to trunk.
gcc/ChangeLog:
PR target/110788
* config/i386/sse.md (avx512cd_maskb_vec_dup):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92335
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
Hi,
This patch fixes profile update in tree_transform_and_unroll_loop which is used
by predictive comming. I stared by attempt to fix
gcc.dg/tree-ssa/update-unroll-1.c I xfailed last week, but it turned to be
harder job.
Unrolling was never fixed for changes in duplicate_loop_body_to_header_edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55642|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110814
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110720
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109472
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #18 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #8 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #11 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110566
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #7 from Richard
I change as follows:
(define_insn_and_split "*mov_mem_to_mem"
[(set (match_operand:VLS_AVL_IMM 0 "memory_operand")
(match_operand:VLS_AVL_IMM 1 "memory_operand"))]
"TARGET_VECTOR && can_create_pseudo_p ()"
"#"
"&& 1"
[(const_int 0)]
{
if (GET_MODE_BITSIZE (mode).to_constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110824
--- Comment #4 from Denis Yaroshevskiy ---
Appreciate it.
I'm still going to support gcc11 for the forseable future. Is there some easy
way you see I can confirm that this is this issue?
So that I don't create more duplicates?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110829
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:41482832ad0aeaa0e4ae2f8d2beff17023cd00bf
commit r14-2816-g41482832ad0aeaa0e4ae2f8d2beff17023cd00bf
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110829
--- Comment #3 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:00c806ea70406e6e67170e51095533dcb8a20cf8
commit r13-7613-g00c806ea70406e6e67170e51095533dcb8a20cf8
Author: Richard
>> Hmmm, does it mean we'll have (set (mem) (mem)) after legitimize_move???
The answer is yes. It's odd I know.
And I found the regression fail, for mem to mem pattern, I change it into:
(define_insn_and_split "*mov_mem_to_mem"
[(set (match_operand:VLS_AVL_IMM 0 "memory_operand")
The following XFAILs recognizing a complex store as memset.
Tested on x86_64-unknown-linux-gnu, pushed to trunk and branch.
PR tree-optimization/110829
* gcc.dg/pr56837.c: XFAIL part of the testcase.
---
gcc/testsuite/gcc.dg/pr56837.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Pan Li
According to below RVV doc, the related intrinsic is not longer needed.
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/249
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv_vector.h (enum RVV_CSR): Removed.
(vread_csr): Ditto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #18 from Uroš Bizjak ---
(In reply to Richard Biener from comment #17)
> Interestingly even with -mno-sse we somehow have a shift for V2QImode.
This is implemented by a combination of shl rl,cl and shl rh,cl, so no XMM
registers are
On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> The following fixes the lack of simplification of a vector shift
> by an out-of-bounds shift value. For scalars this is done both
> by CCP and VRP but vectors are not handled there. This results
> in PR91838 differences in outcome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #8 from Matt Godbolt ---
Fantastic: thanks everyone!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110828
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:50bc490c090cc95175e6068ed7438788d7fd7040
commit r14-2825-g50bc490c090cc95175e6068ed7438788d7fd7040
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108046
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-12-10 00:00:00 |2023-07-27
--- Comment #4 from
LGTM, I just found this patch still on the list, I mostly tested with
qemu, so I don't think that is a problem before, but I realize it's a
problem when we run on a real board that does not support those
extensions.
On Sun, Jun 18, 2023 at 6:07 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Thursday, July 27, 2023 6:50 PM
To: Li, Pan2
Cc: GCC Patches ; 钟居哲 ; Wang,
Yanzhang
Subject: Re: [PATCH v1] RISC-V: Remove unnecessary vread_csr/vwrite_csr
intrinsic.
Ok, thanks:)
Pan Li via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> 於
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 64031, which changed state.
Bug 64031 Summary: (un-)conditional execution state is not preserved by PRE/sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|NEW
Hi,
this fixes two bugs in tree-ssa-loop-im.cc. First is that cap probability is
not
reliable, but it is constructed with adjusted quality. Second is that sometimes
the conditional has wrong joiner BB count. This is visible on
testsuite/gcc.dg/pr102385.c however the testcase triggers another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110788
--- Comment #3 from Uroš Bizjak ---
(In reply to Richard Biener from comment #0)
> I suppose it could also be a missed optimization in REE since I think
> the HImode regs should already be zero-extended?
No, only SImode moves have implicit zero
On Thu, 27 Jul 2023, Jakub Jelinek wrote:
> On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> > The following fixes the lack of simplification of a vector shift
> > by an out-of-bounds shift value. For scalars this is done both
> > by CCP and VRP but vectors are not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #3 from Michael Duggan ---
(In reply to Richard Biener from comment #1)
> I'm seeing all code properly instrumented. The coverage I see is
>
> -:1:#include
> -:2:#include
> -:3:
> -:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110809
--- Comment #9 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:8e811edea309b2097e23cde48ee6fb6467a9094d
commit r13-7614-g8e811edea309b2097e23cde48ee6fb6467a9094d
Author: Patrick Palka
> LGTM, I just found this patch still on the list, I mostly tested with
> qemu, so I don't think that is a problem before, but I realize it's a
> problem when we run on a real board that does not support those
> extensions.
I think we can skip this one as I needed to introduce vector_hw and
On 7/27/23 02:43, Xiao Zeng wrote:
2. According to your opinions, I have modified the code, but out of caution
for upstream, I conducted a complete regression tests on patch V2, which took
some time. I was unable to reply to emails and upload patch V2 in a timely
manner.
Sorry to have
On Thu, Jul 27, 2023 at 01:07:58PM +, Richard Biener wrote:
> On Thu, 27 Jul 2023, Jakub Jelinek wrote:
>
> > On Thu, Jul 27, 2023 at 12:00:56PM +, Richard Biener wrote:
> > > The following fixes the lack of simplification of a vector shift
> > > by an out-of-bounds shift value. For
Hi,
profile_count::apply_probability misses check for uninitialized
probability which leads to completely random results on applying
uninitialized probability to initialized scale. This can make
difference when i.e. inlining -fno-guess-branch-probability function to
-fguess-branch-probability
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
A decimal point was being added to the end of the string for {:#.0}
because the __expc character was not being set, for the _Pres_none
presentation type, so __s.find(__expc) didn't the 'e' in "1e+01" and so
we created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816
--- Comment #4 from Richard Biener ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The only way to access that byte is to use memcpy or via char.
> > -ftrivial-auto-var-init is not designed
On Wed, 26 Jul 2023, Jeff Law wrote:
>
>
> On 7/26/23 07:27, Richard Biener via Gcc-patches wrote:
> > The following patch makes sure to elide a redundant permute that
> > can be merged with existing splats represented as load permutations
> > as we now do for non-grouped SLP loads. This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110817
--- Comment #6 from Andrew Pinski ---
_5 = VEC_COND_EXPR <_9, { 0, 0 }, { -1, -1 }>;
_6 = VIEW_CONVERT_EXPR(_5);
>From that veclower produces:
_36;
_36 = BIT_FIELD_REF <_9, 32, 0>;
_37 = _36 != 0;
_38 = _36 == 0;
_39 = (signed
> ../../../.././gcc/libstdc++-v3/libsupc++/eh_personality.cc:805:1: internal
> compiler error: in insert_insn_on_edge, at cfgrtl.cc:1976.
This error comes from assert of insert_insn_on_edge, the edge cannot be
ABNORMAL and CRITIAL.
Thus, I try to filter out it like gcse.cc:2168 do like below,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108121
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #21 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #20 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107856
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108124
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110145
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #9 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #8 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685
--- Comment #6 from Thomas Neumann ---
> GCC 13.2 is being released, retargeting bugs to GCC 13.3.
the bug should be closed as fixed, the bug fix is already in the 13.2 branch.
(I do not have permissions to do that, though).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110269
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #15 from Richard
Hmmm, does it mean we'll have (set (mem) (mem)) after legitimize_move???
Or maybe try to
use define_insn_and_split rather than define_split for the (set (mem) (mem))
On Thu, Jul 27, 2023 at 5:50 PM juzhe.zh...@rivai.ai
wrote:
>
> Hi, kito.
> I tried to reject mem->mem in this pattern:
>
> Yes, potentially similar for all the other ifs but I didn't check
> all of them.
Thanks and sure thing, will clean up this in v8.
> if (mode != no_mode && mode != last_mode)
> {
This comes from after not the emit part as I mentioned, I am not quit familiar
with this part, as well as if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110824
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110788
--- Comment #1 from Hongtao.liu ---
I prefer to add an UNSPEC to vpbroadcastm, don't want to mix gpr and kmask too
much for vec_duplicate:zero_extend pattern.
>> Why do we appear to return a different mode here? We already request
>> FRM_MODE_DYN_CALL in mode_needed. It looks like in the whole function
>> we do not change the mode so we could just always return the incoming
>> mode?
>
> Because we need to emit 2 insn when meet a call. One before the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106634
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #6 from Richard
1 - 100 of 306 matches
Mail list logo
