https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> Doesn't the SDM guarantee the right behavior though?
Indeed, this is what is missing from Table 3-31.
> It is true that the FPREM results table says * and **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #14 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #13)
> The question is whether gcc can rely on the undocumented Intel behavior as
> described in Comment 7. glibc already relies on it anyway.
I don't think this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #12 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> The revert makes it 13x faster. But the produced code still falls back to
> calling glibc fmod() as shown in the disassembly in Comment 0.
> If I use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #11 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> It is true replacing fmod() with fmodl() makes it 5x faster (but only 5x).
> There is still some infinity check and I haven't found any real
> justification in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Alexander Monakov from comment #3)
> > I guess Uros' claim was based on what Intel and AMD manuals specify rather
> > than observed behavior of CPUs.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #5 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #3)
> I guess Uros' claim was based on what Intel and AMD manuals specify rather
> than observed behavior of CPUs.
As a "committer", I really don't remember the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104375
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
Uroš Bizjak changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108831
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805
Uroš Bizjak changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108832
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> and so ICEs if we see the same REGNO as from in a different mode.
> I think we actually don't need most of what replace_rtx is doing, we don't
> need to simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108831
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #1)
> The patch also handles constant memory operands on x86_64.
--cut here--
struct S
{
unsigned char pad1;
unsigned char val;
unsigned short pad2;
};
unsigned
dot gnu.org |ubizjak at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-02-17
--- Comment #1 from Uroš Bizjak ---
Created attachment 54479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54479=edit
Propo
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
struct S
{
unsigned char pad1;
unsigned char val;
unsigned short pad2;
};
unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108805
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=108805
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Summary|Useless movzx
at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #6 from Uroš Bizjak ---
Created attachment 54454
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54454=edit
patch to relax extract modes
This patch relaxes extract and insert operand modes to no longer match op mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104054
--- Comment #11 from Uroš Bizjak ---
The testcase now PASSes compare-debug with:
gcc version 13.0.1 20230203 (experimental) [master r13-5678-g167b04b9b8a] (GCC)
... but passes due to different register allocation, where regrename is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #22 from Uroš Bizjak ---
BTW: It is the reload pass that duplicates read from
__gcov0.prep_compound_page[7].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #20 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #19)
> __gcov0.prep_compound_page. But as shown in Comment #15, we have two
Comment #16, actually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #19 from Uroš Bizjak ---
Some further analysis:
pretmp_94 = __gcov0.prep_compound_page[7]; <--
_179 = pretmp_94 + 1; <--
ivtmp.1725_211 = (unsigned long long) _179;
_135 = (unsigned int) nr_pages_11;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Uroš Bizjak changed:
What|Removed |Added
Component|target |tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #17 from Uroš Bizjak ---
The assembly is just mirroring what tree optimizers prepare:
pretmp_94 = __gcov0.prep_compound_page[7];
_179 = pretmp_94 + 1;
ivtmp.1725_211 = (unsigned long long) _179;
...
[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #16 from Uroš Bizjak ---
addl$1, __gcov0.prep_compound_page+48
adcl$0, __gcov0.prep_compound_page+52
cmpl$1, %ebx
jle .L1470
leal1(%edi), %eax
movl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #15 from Uroš Bizjak ---
Sorry, %esi/%edi is the correct order.
-24(%ebp): some value previously saved to stack frame
%ecx: address to write to
%eax/%edx: loop iterator
%esi/%edi: termination value
.L1469:
movl%eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #14 from Uroš Bizjak ---
The loop is actually pretty simple, please see the interpretation below
-24(%ebp): some value previously saved to stack frame
%ecx: address to write to
%eax/%edx: loop iterator
%edi/%esi: termination value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #13 from Uroš Bizjak ---
-fverbose-asm annotated assembly:
prep_compound_page:
pushl %ebp#
movl%esp, %ebp #,
pushl %edi#
movl%eax, %edi # tmp356, page
pushl
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
In the unsigned int case (baz) fwprop over-optimizes the addition to a logical
or:
--cut here--
int lock;
int bar (int old)
{
int val = (old >> 1) &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing). The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
--- Comment #2 from Uroš Bizjak ---
The type of extendbfsf2_1 insn should be sseishft1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #4 from Uroš Bizjak ---
Created attachment 53901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53901=edit
Patch that adds relevant zero_extract patterns
This patch adds relevant zero_extract patterns that optimize:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107404
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 107404, which changed state.
Bug 107404 Summary: [12/13 Regression] Wrong code with -O3 since
r12-6416-g037cc0b4a6646cc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107404
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107404
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=107404
--- Comment #4 from Uroš Bizjak ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> This is due to the peephole2 added in r12-2640-gf7bf03cf69cc:
>
> ;; Eliminate a reg-reg mov by inverting the condition of a cmov (#2).
> ;; mov r2,r3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057
--- Comment #9 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #7)
> And it looks like the pattern is wrongly defined since from [1].
>
> --cut begin
> Matching constraints are used in these circumstances. More
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107281
--- Comment #2 from Uroš Bizjak ---
Try to compile the testcase with -msse4.2.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The following testcase:
--cut here--
#define N 16
_Float16 r[N], a[N], b[N];
void foo (void)
{
for (int i = 0; i < N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #24 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU: (REG:CCCmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057
--- Comment #2 from Uroš Bizjak ---
Reload starts with:
(insn 76 67 101 5 (set (reg/v:V2DF 108 [ x ])
(vec_concat:V2DF (reg:DF 182)
(reg:DF 182))) "pr107057.c":7:10 5952 {vec_concatv2df}
(expr_list:REG_EQUAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #4 from Uroš Bizjak ---
(In reply to Christian Ehrhardt from comment #3)
> > Just drop -mbuild-constants.
>
> Thanks for the hint Uroš, but I'm not sure if one can do that, this option
> is from [1]. I do not have the background on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #2 from Uroš Bizjak ---
(In reply to Christian Ehrhardt from comment #0)
> alpha-linux-gnu-gcc -O2 -g1 -Wall -fvisibility=hidden -fno-strict-aliasing
> -msmall-text -msmall-data -mno-fp-regs -mbuild-constants -mcpu=ev67
Just drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
--- Comment #5 from Uroš Bizjak ---
The following pattern is matched by a peephole2 pattern:
(insn 164 161 165 5 (set (reg:DI 0 ax [orig:91 _10 ] [91])
(reg:DI 0 ax)) "pr106707.c":13:12 82 {*movdi_internal}
(expr_list:REG_UNUSED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85037
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90261
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |12.2
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 95201, which changed state.
Bug 95201 Summary: Some x86 vector-extend patterns are not exercised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Bug 92658 depends on bug 95201, which changed state.
Bug 95201 Summary: Some x86 vector-extend patterns are not exercised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #22 from Uroš Bizjak ---
(In reply to Martin Liška from comment #20)
> Hmm, can't reproduce with x86_64 compiler with -m32:
>
> $ g++ --version
> g++ (SUSE Linux) 12.1.1 20220721 [revision
> 4f15d2234608e82159d030dadb17af678cfad626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
--- Comment #16 from Uroš Bizjak ---
(In reply to Alexandre Oliva from comment #15)
> Uroš,
>
> stack-prot-sym.c fails on ia32 with PIC/PIE: the address/value of my_guard
> is loaded from the GOT, instead of appearing as %gs:my_guard.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #10 from Uroš Bizjak ---
(In reply to Mathieu Malaterre from comment #9)
> Technically I can also execute the `uint16` portion of the unit test and
> produce a failure (so this seems to be consistent behavior with signed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #6 from Uroš Bizjak ---
Comment on attachment 53261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53261
This patch aims to handle memory issue when unpacking in cvtps2pd
>@@ -9270,7 +9270,15 @@
> (vec_select:V2SF
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |ubizjak at gmail dot com
Resolution|--- |FIXED
Target Milestone|--- |10.4
--- Comment #7 from Uroš Bizjak ---
Fixed for gcc-10.4+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #2 from Uroš Bizjak ---
emit_move_insn in this part of ix86_output_mi_thunk:
21464 if (!sibcall_insn_operand (fnaddr, word_mode))
21465 {
21466 tmp = gen_rtx_REG (word_mode, tmp_regno);
21467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993
--- Comment #2 from Uroš Bizjak ---
Created attachment 53149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53149=edit
Patch to fix the failure
The patch fixes this particular failure by using (match_dup X). In general,
rtx_equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105953
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2022-06-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #1)
> CC author.
g:6362627b27f395b054f359244fcfcb15ac0ac2ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105927
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104777
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104777
Uroš Bizjak changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936
--- Comment #4 from Uroš Bizjak ---
Digging a bit further with current gcc-10 branch...
Instrumenting a TLS address splitter in i386.md with some creative printfs:
(define_split
[(match_operand 0 "tls_address_pattern")]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936
--- Comment #3 from Uroš Bizjak ---
For some reason, split1 pass converts (insn):
(insn 54 51 109 9 (parallel [
(asm_operands/v ("btrl %1,%0") ("") 0 [
(mem/c:BLK (plus:DI (plus:DI (unspec:DI [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105927
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=105927
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105778
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> It is the same thing done a few lines later in the preexisting code too.
> Shall I all of those change to gen_lowpart (QImode, force_reg (GET_MODE
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105778
--- Comment #3 from Uroš Bizjak ---
Comment on attachment 53058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53058
gcc13-pr105778.patch
>+ operands[2] = gen_lowpart (QImode, operands[2]);
We have learned that pre-reload splits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624
--- Comment #8 from Uroš Bizjak ---
> I think it would work to keep the constraints for
> const_int_operands that are in a % pair and drop them
> elsewhere. (So a partial reapplication, rather than a
> full reapplication.)
OK, let's throw the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624
--- Comment #6 from Uroš Bizjak ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> FWIW, I think the problem is specific to operands that are
> commutative with a non-constant operand. For example,
> suppose the pre-RA instruction had a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105624
--- Comment #1 from Uroš Bizjak ---
Ho-hum - this was my patch that removed constraint from const_int predicates.
We are talking about:
(define_insn_and_split "*anddi_1_btr"
[(set (match_operand:DI 0 "nonimmediate_operand" "=rm")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #3 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #2)
> Just note #c4 in pr105504 also solve this issue.
>
> >Another possible solution is add a little bit dislike for "m"
> >alternative(like ?m) to avoid potential
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073
Bug 105073 depends on bug 105079, which changed state.
Bug 105079 Summary: _mm_storeu_si16 inefficiently uses pextrw to an integer reg
(without SSE4.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105079
What|Removed
|RESOLVED
Target Milestone|--- |13.0
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #3 from Uroš Bizjak ---
Implemented for gcc-13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105429
--- Comment #1 from Uroš Bizjak ---
The intrinsic is defined as:
unsinged __int64 _mm_crc32_u64( unsinged __int64 crc, unsigned __int64 data )
and the unnecessary move is in fact zero-extend:
movl%eax, %eax # 16[c=1 l=2]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073
Bug 105073 depends on bug 51954, which changed state.
Bug 51954 Summary: __int128_t (and long long on x86) negation can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51954
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51954
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209
--- Comment #2 from Uroš Bizjak ---
Created attachment 52780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52780=edit
Proposed patch
This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 105139, which changed state.
Bug 105139 Summary: [12 Regression] GCC produces vmovw instruction with an
incorrect argument for -O3 -march=sapphirerapids since
r12-6215-g708b87dcb6e48cb4
at gcc dot gnu.org |ubizjak at gmail dot com
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Uroš Bizjak ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139
--- Comment #6 from Uroš Bizjak ---
*movv2qi_internal was not fixed in the same way as *movhi_internal, so:
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 29d470bdef2..197f19e4b1a 100644
--- a/gcc/config/i386/mmx.md
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136
--- Comment #2 from Uroš Bizjak ---
The regression in bar: is due to RA regression for:
(insn 28 27 29 2 (parallel [
(set (reg:SI 89)
(plus:SI (reg:SI 92)
(subreg:SI (reg:DI 87) 0)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105079
--- Comment #1 from Uroš Bizjak ---
Created attachment 52700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52700=edit
Proposed patch
The attached patch handles the case from Comment #0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105073
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781
--- Comment #3 from Uroš Bizjak ---
Comment on attachment 52563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52563
A patch
>From ba4854c13c4aaa5b50127f23cb09cf05e3eb229d Mon Sep 17 00:00:00 2001
>From: "H.J. Lu"
>Date: Fri, 4 Mar 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target
301 - 400 of 6562 matches
Mail list logo
