https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #19 from Uroš Bizjak ---
https://gcc.gnu.org/g:337ed0eb490b14899f4049bc4c8922eb1d8a2e67
commit r11-6303-g337ed0eb490b14899f4049bc4c8922eb1d8a2e67
Author: Uros Bizjak
Date: Tue Dec 22 18:13:24 2020 +0100
i386: Fix __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #20 from Uroš Bizjak ---
https://gcc.gnu.org/g:0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6
commit r10-9164-g0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6
Author: Uros Bizjak
Date: Tue Dec 22 21:11:51 2020 +0100
i386: Fix __builtin_fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #21 from Uroš Bizjak ---
https://gcc.gnu.org/g:c40b640ebcef1aae78eaca56e04d204dda9e4cad
commit r9-9126-gc40b640ebcef1aae78eaca56e04d204dda9e4cad
Author: Uros Bizjak
Date: Wed Dec 23 09:09:29 2020 +0100
i386: Fix __builtin_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #22 from Uroš Bizjak ---
https://gcc.gnu.org/g:edb28850520d1137d12a1cc1c0e89c11e6b0c6ef
commit r8-10691-gedb28850520d1137d12a1cc1c0e89c11e6b0c6ef
Author: Uros Bizjak
Date: Wed Dec 23 09:18:12 2020 +0100
i386: Fix __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #22 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #21)
> Add define_code_attr like aarch64/iterators.md?
>
> --
> ;; Map rtl objects to optab names
> (define_code_attr optab [(ashift "ashl")
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
--- Comment #3 from Uroš Bizjak ---
I don't think this is a backend bug. The position of split pass in the pass
sequence assumes that no split candidates will be emitted after regstack, as
can be seen from the gate function of the pass_split_for_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
Uroš Bizjak changed:
What|Removed |Added
CC||10walls at gmail dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
--- Comment #5 from Uroš Bizjak ---
This is fixed in gcc-11:
--cut here--
struct TestFloat { float x; };
struct TestDouble { double x; };
struct TestFloat foo (struct TestFloat x) { return x; }
struct TestDouble bar (struct TestDouble x) { retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |10.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98567
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 49901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49901
gcc11-pr98567.patch
>+(define_insn "*bmi_blsi__cmp"
>+ [(set (reg:CCZ FLAGS_REG)
>+ (compare:CCZ
>+(and:SWI4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #2 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #1)
> and by the time of output __fentry__ in gcc, register is already accocated,
> is there any regs supposed to be safe in the entry of function? or we need
> to spill re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Hongtao.liu from comment #1)
> > and by the time of output __fentry__ in gcc, register is already accocated,
> > is there any regs supposed to be safe in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #5 from Uroš Bizjak ---
(In reply to Topi Miettinen from comment #4)
> Sorry, I didn't check the ABI. It seems that %r11 and maybe %r10 should be
> usable:
%r11 is already used as PROFILE_COUNT_REGISTER for !NO_PROFILE_COUNTERS
targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #9 from Uroš Bizjak ---
(In reply to Topi Miettinen from comment #8)
> I'm unfortunately ignorant to GCC internals and usage of %r10, but otherwise
> the patch looks good to me.
>
> For -mcmodel=large -fPIC, the call sequence probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> If we are emitting for nested functions
> pushq %r10
> 1:call__fentry__
> popq%r10
> (is it ok to misalign the stack for __fentry__? but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98683
--- Comment #1 from Uroš Bizjak ---
Maybe TARGET_CANONICALIZE_COMPARISON would help here? x86 had a similar issue
with ficom x87 insn where float RTX was always the first operand, but the
compare was with the float extend of the second one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
--- Comment #6 from Uroš Bizjak ---
(In reply to David Binderman from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > I'm not sure if solving this would bring us anything.
>
> For clarity, at very most a 4% reduction in the size of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
--- Comment #8 from Uroš Bizjak ---
Comment on attachment 49969
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49969
Optimize combination of comparisons to dec+compare
>+/* y == XXX_MIN || x < y --> x <= y - 1 */
Can we use TYPE_MIN inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713
--- Comment #4 from Uroš Bizjak ---
Please see PR 56309 (and PR 85559 meta bug).
Quote from Honza:
The decision on whether to use cmov or jmp was always tricky on x86
architectures. Cmov increase dependency chains, register pressure (both value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724
--- Comment #1 from Uroš Bizjak ---
Sorry, I don't have access to alpha anymore.
(And I'm surprised that gnat even builds, because I've never tried.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
--- Comment #8 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #7)
> I asked my colleagues within intel to revise the descriptions in the
> intrinsics guide to make it more explicit about NAN operands.
>
> I'll fix this issue after th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #2 from Uroš Bizjak ---
This can be optimized with peephole2, we already have similar case in sync.md:
;; This peephole2 and following insn optimize
;; __sync_fetch_and_add (x, -N) == N into just lock {add,sub,inc,dec}
;; followed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961
Uroš Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961
--- Comment #3 from Uroš Bizjak ---
Please note that LZCNT insn has it own set of problems (e.g.
TARGET_AVOID_FALSE_DEP_FOR_BMI), so I'm not convinced that even:
int z (int i)
{
return i == 0;
}
benefits from using LZCNT:
0: 31 c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98962
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Another possibility is add x/v constraints to *andsi_1 and *anddi_1 with the
> immediates and disparage that alternative enough to reflect the fact that
> the immed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 50154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154
gcc11-pr99025.patch
>2021-02-09 Jakub Jelinek
>+ if (SUBREG_P (operands[1]))
>+operands[1] = force_reg (V2SFmode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #1 from Uroš Bizjak ---
This should be a no-op. According to the documentation:
--q--
Macro: REG_ALLOC_ORDER
If defined, an initializer for a vector of integers, containing the numbers
of hard registers in the order in which GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #3 from Uroš Bizjak ---
It looks to me another one is in reload1.c, find_reg:
if (this_cost < best_cost
/* Among registers with equal cost, prefer caller-saved ones, or
use REG_ALLOC_ORDER if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #4 from Uroš Bizjak ---
Created attachment 50185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50185&action=edit
Proposed patch
Proposed patch that fixes ira-color.c and introduces HONOR_REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #5 from Uroš Bizjak ---
Martin, can you please benchmark the patch from Comment #4?
The patch is not totally trivial, because it introduces HONOR_REG_ALLOC_ORDER
to x86 and this define disables some other code in ira-color.c,
assign_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #6 from Uroš Bizjak ---
As a side note, it is strange that ADJUST_REG_ALLOC_ORDER somehow require
REG_ALLOC_ORDER to be defined (c.f. Comment #3), while its documentation says:
The macro body should not assume anything about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #8 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
I agree, this is the safest way at this time. The situation now looks like
going into ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> There are a lot of targets that define REG_ALLOC_ORDER ^
> HONOR_REG_ALLOC_ORDER and thus are affected by this change...
The following patch should solve this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
Uroš Bizjak changed:
What|Removed |Added
Known to work||11.0
--- Comment #3 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
--- Comment #4 from Uroš Bizjak ---
Compiles OK with:
GNU C++14 (GCC) version 8.4.1 20210216 [releases/gcc-8 revision
c6513400d84:39c49bc104d:1f3a07da9b6bcfa4733750826746bd18ac6f20db]
(alpha-unknown-openbsd6.8)
built as a cross from x86_64-linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 99083, which changed state.
Bug 99083 Summary: Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 99083, which changed state.
Bug 99083 Summary: Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #8 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #7)
> Confirmed, let me fix this.
Please note that the current definition of vzeroupper does not model effects of
the instruction at all. The current definition is intende
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #4)
> Indeed as far as I understand an unspec volatile isn't sth clobbering
> registers (not even memory?!). The insn is missing inputs/outputs
> (we might be able to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Richard Biener from comment #4)
> > Indeed as far as I understand an unspec volatile isn't sth clobbering
> > registers (not even memory?!). The insn i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100312
Uroš Bizjak changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Bug 98375 depends on bug 98060, which changed state.
Bug 98060 Summary: Failure to optimize cmp+setnb+add to cmp+sbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355
--- Comment #3 from Uroš Bizjak ---
(In reply to Christophe Lyon from comment #2)
> Tried that, but it's not taken into account.
>
> ieee.exp uses c-torture-execute, maybe that function does not honor dg
> directives? (none of the tests under i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
--- Comment #3 from Uroš Bizjak ---
For some reason the *input* value at BSWAP insn is truncated to 32bits.
v256u128 v256u128_1 =
SHLV (SHLSV (__builtin_bswap64 (u128_0), (v256u128) (0 < v256u128_0)) <=
0, v256u128_0);
u128_0 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
--- Comment #4 from Uroš Bizjak ---
The problematic insn is:
401cec: 44 89 f6mov%r14d,%esi
This one should be 64 bit wide,
movl%r14d, %esi # 613 [c=4 l=3] *movqi_internal/2
but is actually a QIm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
--- Comment #5 from Uroš Bizjak ---
The problem can be seen in _.pro_and_epilogue pass:
Starting with:
_.cmpelim
2741: r14:DI=[sp:DI+0x38]
...
368: di:DI=r14:DI
...
613: si:QI=r14:QI
...
2737: bp:DI=r14:DI
...
658: strict_low_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
--- Comment #7 from Uroš Bizjak ---
I have traced a bit where (insn 2275) and (insn 2287) come from.
In _.ira, we have:
613: r125:QI=r2067:DI#0
...
659: zero_extract(r2080:DI,0x8,0x8)=r125:QI#0
And in _.reload, a DImode reload is insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
--- Comment #8 from Uroš Bizjak ---
FYI, this whole analysis was done with Fedora 33 system compiler:
gcc version 10.3.1 20210422 (Red Hat 10.3.1-1) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Bug 98375 depends on bug 98218, which changed state.
Bug 98218 Summary: [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for
64bit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #5 from Uroš Bizjak ---
ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is
needed:
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 347295afbb5..667dd057e0d 100644
--- a/gcc/config/i386/mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is
> needed:
Ah, you beat me by the second ;)
Anyway, I have no XOP target, so probably y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #9 from Uroš Bizjak ---
ix86_use_mask_cmp_p should be refined, it has an early return for 64bit modes:
if (GET_MODE_SIZE (mode) == 64)
return true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #10 from Uroš Bizjak ---
Following patch fixes the failures:
--cut here--
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 4dfe7d6c282..61b2f921f41 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Uroš Bizjak changed:
What|Removed |Added
Summary|[TARGET_MMX_WITH_SSE] Miss |[TARGET_MMX_WITH_SSE]
|v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Bug 98375 depends on bug 98218, which changed state.
Bug 98218 Summary: [TARGET_MMX_WITH_SSE] Implement 64bit vector compares
(AVX512 masked compares missing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Uroš Bizjak changed:
What|Removed |Added
Assignee|ubizjak at gmail dot com |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #12 from Uroš Bizjak ---
(In reply to David Binderman from comment #11)
> I might be seeing something similar:
>
> caxcpy.f: In function 'caxcpy':
> caxcpy.f:53:72: error: unrecognizable insn:
>53 | end subroutine
> |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #13 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #12)
> Yeah, this is a non-existent SSE "cmove". I tried to find all paths where
> this should divert to a sequence of logic instructions or PBLENDB, but due
> to plethora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581
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=100581
--- Comment #3 from Uroš Bizjak ---
(In reply to Alex Coplan from comment #1)
> Is it valid to create a vector type with total size less than the element
> size? Shouldn't this be rejected?
No, the generated code is:
vmovq ff_b(%rip)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100581
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #16 from Uroš Bizjak ---
(In reply to David Binderman from comment #15)
> Bug first appears sometime between git hash 21dfb22920ce32fc,
> dated yesterday and git hash 097fde5e7514e909, dated today.
Fixed by PR100581.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
--- Comment #3 from Uroš Bizjak ---
*di3_doubleword calls split_double_mode with:
op0: (subreg:DI (reg/v:SI 89 [ li_18 ]) 0)
op1: (reg:DI 90 [ uc_4 ])
op2: (mem/c:DI (plus:SI (reg/f:SI 19 frame)
(const_int -4 [0xfffc]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637
Bug ID: 100637
Summary: [i386] Vectorize 4-byte vectors
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
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=100696
Bug ID: 100696
Summary: mult_higpart is not vectorized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696
Uroš Bizjak changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100722
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2021-05-22
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100722
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100880
Bug ID: 100880
Summary: The build should error out for define_insn without
insn template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100936
Bug ID: 100936
Summary: %p and %P modifiers should not emit segment overrides
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100936
--- Comment #1 from Uroš Bizjak ---
Proposed patch:
--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04649b42122..0773a4a9ba8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13531,7 +13531,7 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43526
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100936
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101021
Bug ID: 101021
Summary: PSHUFB is emitted instead of PSHUFD, PSHUFLW and
PSHUFHW with -msse4
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101021
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2021-06-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101021
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101044
--- Comment #1 from Uroš Bizjak ---
The first neg also sets sign flag (SF) for the following CMOVS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2021-06-14
Assignee|unassigned
101 - 200 of 904 matches
Mail list logo
