https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787
--- Comment #8 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> I think the issue is that we pad out the compare RTXen with zeros but
> not the RHS when they are equal to the compare operands. We then later
> are not able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #0)
> typedef float v4sf __attribute__((vector_size (sizeof (4 * sizeof
> (float);
>
> v4sf
> foo (v4sf x, v4sf y)
> {
> return x < y ? y : x;
> }
>
> is no lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to Uroš Bizjak from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > Though, unsure about why ieee is used in the name of some of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> I think the problem is the mixing of four different substitutions in a
> single pattern,
> in particular round_saeonly and round_saeonly_scalar and mask and
> ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> Though, unsure about why ieee is used in the name of some of the patterns,
> my copy of IEEE says that minNum and maxNum should return the non-NaN
> operand if o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #10 from Uroš Bizjak ---
Created attachment 59136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59136&action=edit
Prototype patch
Prototype patch that fails build with:
../../git/gcc/gcc/config/i386/sse.md:3336:1: duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #5)
> The problem is that those builtins are expanded into RTL using SMIN/SMAX RTL
> codes, and those are documented to be undefined in that case:
VM variants of minss a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116698
Uroš Bizjak changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116698
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2024-09-13
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #10 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #7)
> For the m vs. o, there are quite a few (grepped just for the :TI cases
> because :DI doesn't necessarily mean double-word):
> grep 'match_operand:TI . ([^)]*).*m'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> For the :DI !TARGET_64BIT, perhaps *insvdi_lowpart_1,
> *adddi3_doubleword_zext, *adddi3_doubleword_concat,
> *adddi3_doubleword_concat_zext
*_concat_* should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ubizjak at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> E.g. *adddi3_doubleword, *adddi3_doubleword_zext (that one even has &r,rm,r),
> ...
This one is not the problematic one since "m" is with word-mode operand. But
th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> But in that case, why doesn't LRA consider simply forcing the complex memory
> address into a single register and with that needing one less register?
> &r,ro,r or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
Uroš Bizjak changed:
What|Removed |Added
Summary|ICE: in |[14/15 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116587
Uroš Bizjak changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Hongtao Liu from comment #0)
> >
> > > g++: g++.target/i386/pr100637-1b.C
> > > g++: g++.target/i386/pr1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #5 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #0)
> g++: g++.target/i386/pr100637-1b.C
> g++: g++.target/i386/pr100637-1w.C
> g++: g++.target/i386/pr103861-1.C
>
> There're extra 1 pcmpeq instruction generated in be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 51492, which changed state.
Bug 51492 Summary: vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #23 from Uroš Bizjak ---
Current compiler produces (-O3):
f:
movl$4194368, %edx
movl$head, %eax
movd%edx, %xmm1
pshufd $0, %xmm1, %xmm1
.L2:
movdqa (%rax), %xmm0
addq$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #17 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #16)
> > Unfortunately, x86 has no vector mode .SAT_TRUNC instruction.
> No, AVX512 supports both signed and unsigned saturation
Indeed.
BTW: PACKUSmn (despite the name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #22 from Uroš Bizjak ---
(In reply to Sam James from comment #21)
> I think the instructions were for OP's benefit.
True ;)
@Maciej: I'd like to keep the testcase that also exercises the assembler,
because the error is best detecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #15 from Uroš Bizjak ---
(In reply to Li Pan from comment #14)
> Hi Uroš,
>
> > Please note two new instructions in the second asm dump. These are expanded
> > from .SAT_TRUNC and are not present in the first asm dump.
>
> > The pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #18 from Uroš Bizjak ---
> make -k check-gcc RUNTESTFLASG=alpha.exp=pr115526.c
s/RUNTESTFLASG/RUNTESTFLAGS/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> Can you please test this slightly cleaned up testcase?
Just put it in gcc/testsuite/gcc.target/alpha and do:
make -k check-gcc RUNTESTFLASG=alpha.exp=pr115526.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #16 from Uroš Bizjak ---
Created attachment 58666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58666&action=edit
Cleaned up testcase
Can you please test this slightly cleaned up testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
> Created attachment 58650 [details]
> Testcase that illustrates performance issue
Without ustrunc{m}{m}2 optab the loop in the testcase compiles to (gcc -O2):
.L7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #10 from Uroš Bizjak ---
Created attachment 58650
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58650&action=edit
Testcase that illustrates performance issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
--- Comment #9 from Uroš Bizjak ---
(In reply to Li Pan from comment #8)
> Thanks Richard.
> Yes, the .SAT_TRUNC doesn't pay any attention the other possible use of
> MIN_EXPR.
>
> As your suggestion, we may need one additional check here (lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
--- Comment #5 from Uroš Bizjak ---
(In reply to Richard Sandiford from comment #4)
> As expected, the results weren't pretty. Things like:
>
> (define_split
> [(set (match_operand:SWI48 0 "register_operand")
> (and:SWI48 (match_dup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Uroš Bizjak changed:
What|Removed |Added
Keywords|ice-checking|
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115863
Uroš Bizjak changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #11 from Uroš Bizj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #12 from Uroš Bizjak ---
(In reply to Andreas K. Huettel from comment #11)
> > Can someone please regression test the attached patch?
>
> More in a bit, but:
Any progress with testing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #35 from Uroš Bizjak ---
(In reply to Mayshao-oc from comment #34)
> Can we extend this patch to Zhaoxin processors as well?
Just post the enablement patch to gcc-patches@ mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Attachment #58618|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #8 from Uroš Bizjak ---
Some more explanation:
Later in emit_store_flag_1 we have:
if (icode != CODE_FOR_nothing)
{
do_pending_stack_adjust ();
rtx tem = emit_cstore (target, icode, code, mode, comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #6)
> Proposed patch.
Here is the problem:
The compiler enters emit_store_flag_1 with:
op0=(subreg:SF (reg:SI 424 [ _676 ]) 0)
op1=(reg:SF 1308)
First, the function doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #5 from Uroš Bizjak ---
ICE happens in:
#1 0x018e82a7 in ix86_expand_int_movcc (operands=0x7fffc140) at
../../git/gcc/gcc/config/i386/i386-expand.cc:3821
3821 out = expand_simple_binop (mode, PLUS, copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115836
--- Comment #2 from Uroš Bizjak ---
The testcase compiles OK for me with today's compiler:
xgcc (GCC) 15.0.0 20240709 (experimental) [master r15-1905-g23ab7f632f4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> Created attachment 58549 [details]
> Proposed patch
Can someone please regression test the attached patch?
||2024-07-01
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #9 from Uroš Bizjak ---
Created attachment 58549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58549&action=edit
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #7 from Uroš Bizjak ---
(In reply to Richard Biener from comment #6)
> So it likely expects f1@GOTPCREL(%rip) to be CSEd?
>
> f2:
> .LFB2:
> .cfi_startproc
> subq$8, %rsp
> .cfi_def_cfa_offset 16
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #8 from Uroš Bizjak ---
(In reply to Sam James from comment #7)
> Uros, is there any chance you'd be so kind to take a look?
I'm afraid that this is not some dead-simple issue that I can fix without the
access to the alpha machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643
--- Comment #8 from Uroš Bizjak ---
(In reply to Evgeny Karpov from comment #7)
> Thanks for pointing that out! The fix will be included in the patch that
> fixes the regression.
While there, can you perhaps rename:
PE_COFF_EXTERN_DECL_SHOULD_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115655
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
--- Comment #2 from Uroš Bizjak ---
Similar to PR114942.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
--- Comment #2 from Uroš Bizjak ---
For the original testcase tree optimizers optimize to:
[local count: 114863530]:
_30 = _2 & 240;
if (_30 == 224)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 75809929]:
if (_30 <=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115452
--- Comment #1 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #0)
> cut from i386-features.cc:1056---
>
> if (dump_file)
> fprintf (dump_file, " Preloading operand for insn %d into r%d\n",
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387
--- Comment #6 from Uroš Bizjak ---
The testcase is at [1].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404#c4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
--- Comment #3 from Uroš Bizjak ---
(In reply to Sergei Trofimovich from comment #0)
> if (__builtin_add_overflow ((uintptr_t) string, maxlen, &end))
> end = -1;
>
> Could it be that dead store to `&end` somehow conflicts with a f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Uroš Bizjak changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115374
--- Comment #8 from Uroš Bizjak ---
When compiling the following testcase:
--cut here--
#include
double
__attribute__((noinline))
do_fmod (double x, double y)
{
return fmod(x, y);
}
--cut here--
one can find in _.265t.optimized:
__attribu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2024-06-03
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Uroš Bizjak ---
Created attachment 58327
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58327&action=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
--- Comment #1 from Uroš Bizjak ---
Created attachment 58315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58315&action=edit
Proposed patch
any_divmod instructions are modelled with invalid RTX:
[(set (match_operand:DI 0 "register_ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> though on x86 there's no high word preserving swap of the lower 2 bytes.
There is, please try:
asm ("xchgb %h0, %b0" : "+Q" (val));
like:
--cut here--
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 58261 [details]
> gcc15-pr115172.patch
>
> Full untested patch.
I can confirm that this patch fixes boot for the kernel config from
PR115172#4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> What the kernel does is terrible, why they just don't declare the extern
> with __seg_gs attribute?
This is how kernel currently handles percpu variables. They a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #50 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #49)
> Will do in a moment.
PR 115172
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #47 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #46)
> Created attachment 58259 [details]
> Preprocessed file
>
> gcc -O2 -fsanitize=kernel-address -fasan-shadow-offset=0xdc00
> --param asan-instrumentatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #46 from Uroš Bizjak ---
Created attachment 58259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58259&action=edit
Preprocessed file
gcc -O2 -fsanitize=kernel-address -fasan-shadow-offset=0xdc00
--param asan-instru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #17 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #15)
> I am doing like this way. Suppose should be same as Comment 8.
Yes, but IMO the patch in Comment #8 better describes where the problem is.
Please note that wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #13 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #12)
> (In reply to Hongtao Liu from comment #11)
> > (In reply to Haochen Jiang from comment #10)
> > > A patch like Comment 8 could definitely solve the problem. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #8 from Uroš Bizjak ---
(In reply to Levy Hsu from comment #5)
> case E_V16QImode:
> mode = V8HImode;
> gen_shr = gen_vlshrv8hi3;
> gen_shl = gen_vashlv8hi3;
Hm, why vector-by-vector shift here? Should there be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #9 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #8)
> A better patch:
The real issue is that the following permutation (truncation):
+ for (i = 0; i < d.nelt; ++i)
+ d.perm[i] = i * 2;
+
+ ok = ix86_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
--- Comment #3 from Uroš Bizjak ---
R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
--- Comment #2 from Uroš Bizjak ---
This is the insn in question:
;; Alternative 1 is needed to work around LRA limitation, see PR82524.
(define_insn_and_split "*qi_ext_1_slp"
[(set (strict_low_part (match_operand:QI 0 "register_operand" "+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|13.3|11.5
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 58013 [details]
> gcc14-pr114810.patch
>
> So like this? Tried hard to reduce the testcase, but it didn't progress at
> all, so at least tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #12 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #9)
> (In reply to Uroš Bizjak from comment #7)
> >
> >
> > Please note that the insn is defined as:
> >
> > (define_insn_and_split "*andn3_doubleword_bmi"
> > [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > (define_insn_and_split "*andn3_doubleword_bmi"
> > [(set (match_operand: 0 "register_operand" "=&r,r,r")
> > (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #7 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #6)
> The problem is that the alternative assumes 3 DI values live simultaneously.
> This means 6 regs and we have only 6 available ones. One input reg is
> assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #4 from Uroš Bizjak ---
An interesting observation, when the insn is defined only with problematic
alternative:
(define_insn_and_split "*andn3_doubleword_bmi"
[(set (match_operand: 0 "register_operand" "=&r")
(and:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #13 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #12)
> short a;
> short c;
> short d;
> void
> foo (short b, short f)
> {
> c = b + a;
> d = f + a;
> }
>
> foo(short, short):
> addwa(%rip), %di
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #13 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> You cannot use a :CC value as argument of an unspec, as explained before.
>
> The result of a comparison is expressed as a comparison, in RTL. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #11 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #10)
> It is still wrong. You're trying to sweep tour wrong assumptions under the
> rug,
> but they will only rear up elsewhere. Just fix the actual *target* pro
1 - 100 of 3070 matches
Mail list logo