https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #13 from Uroš Bizjak ---
(In reply to Richard Biener from comment #12)
> > But I think, we could do better. Adding CC.
>
> We sure could, but I doubt it's too important? Maybe for Go/Ada.
Preloading stuff is simply loading from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Uroš Bizjak changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #9 from Uroš Bizjak ---
The offending insn is emitted in general_scalar_chain::convert_op due to
preloading, but I have no idea how EH should be adjusted. There is another
instance in timode_scalar_chain::convert_op.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Uroš Bizjak changed:
What|Removed |Added
Attachment #57614|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #25 from Uroš Bizjak ---
Created attachment 57614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57614=edit
Proposed patch
Proposed patch that changes optimize_function_for_size_p (cfun) to
optimize_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #23 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #21)
> Looking at the prototype patch, why need to change also the splitters?
Purely for implementation reasons, we check for general resp. SSE register in
the operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #19 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #18)
> But the problem here is more that optab initializations happens only at
> the optimization_node changes and not if we switch from hot function to
> cold?
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Seems various backends use e.g. optimize_size or !optimize_size or optimize
> > 0 etc. in
> insn-flags.h, so perhaps change optimize_function_for_size_p (cfun)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
--- Comment #9 from Uroš Bizjak ---
Noticed this in passing:
--> movq%rcx, %rdx
addqv(%rip), %rax
adcqv+8(%rip), %rdx
vmovq %rax, %xmm1
vpinsrq $1, %rdx, %xmm1, %xmm0
We could use %rcx instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> Still, it would be nice to understand what changed
> optimize_function_for_size_p (cfun)
> after IPA. Is something adjusting node->count or node->frequency?
>
at gcc dot gnu.org |ubizjak at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #10 from Uroš Bizjak ---
Created attachment 57612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57612=edit
Protot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> > grep optimize_ insn-flags.h | wc -l
> 14
>
> so it's not very many standard patterns that would be affected. I'd say
> using these kind of flags on standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #5 from Uroš Bizjak ---
Huh, it looks that optimize_function_for_size_p (cfun) is not stable during
LTO?!
Using:
--cut here--
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 2856ae6ffef..80114494b0b 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #4 from Uroš Bizjak ---
(In reply to Sam James from comment #0)
> (insn 160 159 161 26 (parallel [
> (set (reg:V2QI 250 [ vect_patt_207.470_183 ])
> (minus:V2QI (reg:V2QI 251)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
at gcc dot gnu.org |ubizjak at gmail dot com
Status|NEW |RESOLVED
--- Comment #8 from Uroš Bizjak ---
Assuming fixed, please reopen if not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #56 from Uroš Bizjak ---
The testcase is fixed with g:430c772be3382134886db33133ed466c02efc71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #55 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #53)
> Comment on attachment 57424 [details]
> Proposed testsuite patch
>
> As skylake-avx512 is -mavx512{f,cd,bw,dq,vl}, requiring just avx512f
> effective target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #52 from Uroš Bizjak ---
Created attachment 57424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57424=edit
Proposed testsuite patch
This patch fixes the failure for me (+ some other dg.exp/vect inconsistencies).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #48 from Uroš Bizjak ---
The runtime testcase fails on non-AVX512F x86 targets due to:
/* { dg-do run } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-march=skylake-avx512" { target { x86_64-*-*
i?86-*-* } } } */
but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Uroš Bizjak changed:
What|Removed |Added
Attachment #57417|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
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=113720
--- Comment #5 from Uroš Bizjak ---
(In reply to Matthias Klose from comment #4)
> Uros proposed patch lets the build succeed.
FTR, the problem was in umuldi3_highpart expander, which did:
if (REG_P (operands[2]))
operands[2] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720
--- Comment #1 from Uroš Bizjak ---
Created attachment 57292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57292=edit
Patch that introduces umul_highpart RTX
Please try the attached (untested) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Uroš Bizjak changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> > The most problematic function is f3, which regressed noticeably from
> > gcc-12.3:
>
> This patch solves the regression:
>
> --cut here--
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #0)
> Following testcase:
>
> --cut here--
> typedef unsigned __int128 U;
>
> U f0 (U x, U y) { return x + y; }
> U f1 (U x, U y) { return x - y; }
>
> U f2 (U x, U y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
Uroš Bizjak changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
typedef unsigned __int128 U;
U f0 (U x, U y) { return x + y; }
U f1 (U x, U y) { return x - y; }
U f2 (U x, U y) { return x | y; }
int f3 (U x, U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113609
--- Comment #2 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #1)
> Since they're different modes, CCZ for cmp, but CCS for kortest, it could be
> diffcult to optimize it in RA stage by adding alternatives(like we did for
> compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
--- Comment #9 from Uroš Bizjak ---
The current mainline compiles:
--cut here--
_Bool foo(int i)
{
return (i & 0xFF) == ((i & 0xFF00) >> 8);
}
_Bool bar(int i)
{
return (i & 0xFF) <= ((i & 0xFF00) >> 8);
}
--cut here--
with -O2 to:
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
--- Comment #8 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #7)
> I believe this PR was recently fixed by
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=a729b6e002fe76208f33fdcdee49d6a310a1940e
Yes, I can confirm that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
Uroš Bizjak changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
--- Comment #2 from Uroš Bizjak ---
If we consider the following testcase:
--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
unsigned int r = a & 0x1;
unsigned int p = b & ~0x3;
return r + p + 2;
}
unsigned int bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
--- Comment #1 from Uroš Bizjak ---
This conversion happens due to th following code in match.pd:
/* If we are XORing or adding two BIT_AND_EXPR's, both of which are and'ing
with a constant, and the two constants have no bits in common,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #3 from Uroš Bizjak ---
_.dse1 pass is removing the store for some reason, -fno-dse "fixes" the
testcase.
Before _.dse1 pass, we have:
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Uroš Bizjak changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #8 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #6)
> Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and
> that is why I added that to allow them.
>
> Let me find a way to see if we can fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #2 from Uroš Bizjak ---
Another testcase:
--cut here--
void
foo1 (double *d, float f)
{
register float x __asm ("xmm16") = f;
asm volatile ("" : "+v" (x));
*d = x;
}
void
foo2 (float *f, double d)
{
register double x
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #1 from Uroš Bizjak ---
Created attachment 56962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56962=edit
Propo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #7 from Uroš Bizjak ---
(In reply to Richard Biener from comment #6)
> > BTW: I also checked with clang, and it creates expected code in all cases.
>
> But you don't get
>
>movl%gs:b(%rip), %eax
>addl%eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #5 from Uroš Bizjak ---
The issue in comment #2 happens in a couple of places when compiling linux
kernel (with named address spaces enabled). However, the issue is not specific
to named AS, I was just more attentive to moves from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #3)
> The situation with address-spaces isn't valid as we need to preserve the
> second load because it's volatile. I think we simply refuse to combine
> volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044
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=113106
--- Comment #2 from Uroš Bizjak ---
For reference, the same optimization should be applied with address spaces:
--cut here--
int __seg_gs b;
int bar(void)
{
return *(volatile __seg_gs int *) + b;
}
--cut here--
the above testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #1 from Uroš Bizjak ---
Perhaps related,
--cut here--
int a;
int foo(void)
{
return *(volatile int *) + *(volatile int *)
}
--cut here--
compiles with -O2 to:
movla(%rip), %eax
movla(%rip), %edx
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The following testcase:
--cut here--
int a;
int foo(void)
{
return *(volatile int *) + a;
}
--cut here--
compiles with -O2 to:
movla(%rip), %eax
addla(%rip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #7 from Uroš Bizjak ---
(In reply to GCC Commits from comment #5)
> The master branch has been updated by Richard Biener :
Can this patch be backported to gcc-13 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113043
Uroš Bizjak changed:
What|Removed |Added
Component|target |sanitizer
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
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=112962
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:
This goes out of my (limited) area of expertise, so if my proposed (trivial)
patch is papering over some other issue, I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Something like this?
--cut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Yes, this could be a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112760
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Uroš Bizjak changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
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=112494
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Bug 112560 depends on bug 112494, which changed state.
Bug 112494 Summary: ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #9 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
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=89316
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #4 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #3)
> parityhi2 should have:
> rtx extra = gen_reg_rtx (HImode);
> emit_move_insn (extra, operands[1]);
> emit_insn (gen_parityhi2_cmp (extra));
>
> Or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I think this goes wrong during combine.
Combine does not / should not combine moves from hard registers just because of
extending register live range. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #6 from Uroš Bizjak ---
This is by design, CMOV should not be used instead of well predicted jumps.
FYI, CMOV is quite problematic on x86, there are several PRs where conversion
to CMOV resulted in 2x slower execution. Please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #5 from Uroš Bizjak ---
Digging a bit further:
if_info.max_seq_cost is calculated via targetm.max_noce_ifcvt_seq_cost, where
without params set we return:
return BRANCH_COST (true, predictable_p) * COSTS_N_INSNS (2);
with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Andrew Pinski from comment #2)
>
> > Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> > on aarch64. Note there are some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> on aarch64. Note there are some new changes to ifcvt.cc in review which
> might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Keywords||patch
--- Comment #14 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Attachment #56637|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
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=111657
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> I'd say it is a user error to invoke memcpy/memset etc. with pointers to
> non-default address spaces, and for aggregate copies the middle-end should
> ensure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #1)
> It might be one of the x86 specific target patches ...
I don't think so, these patches deal specifically with high registers, and:
$ grep %.h pr112581.s
finds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #1 from Uroš Bizjak ---
Mine, due to [1], this time I managed to split to invalid RTX...
I have a patch.
[1] https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112540
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |ubizjak at gmail dot com
Target Milestone|--- |14.0
Ever confirmed|0 |1
Host||x86
Status|UNCONFIRMED |ASSIGNED
--- Comment #4 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #7 from Uroš Bizjak ---
It looks to me that gcc_unreachable is problematic in SELECT_CC_MODE. We should
simply return CCmode for all unrecognised RTX:
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #6 from Uroš Bizjak ---
Now we have:
#1 0x0286a3aa in try_combine (i3=0x7fffe3c18100, i2=0x7fffe3c18000,
i1=0x0, i0=0x0, new_direct_jump_p=0x7fffd8eb,
last_combined_insn=0x7fffe3c18100) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #5 from Uroš Bizjak ---
Created attachment 56567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56567=edit
Proposed patch
Nope, even with the above patch the compiler ICEs at the same place:
0x1956968 ix86_cc_mode(rtx_code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Component|rtl-optimization|target
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #4 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #3)
> I almost want to say this is a bug in the x86 back-end where it pushes the
> flags onto the stack.
Yes, could be - let me look into this a bit more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #8)
> I need some code generation help for gcc.target/i386/pr110790-2.c, I have a
> patch where we now generate:
> ```
> movq(%rdi,%rax,8), %rax
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to LIU Hao from comment #4)
> > Are there any reasons why this was not done for 64?
> > (https://gcc.godbolt.org/z/7vddPdxaP)
>
> There is zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #6 from Uroš Bizjak ---
(In reply to LIU Hao from comment #4)
> Are there any reasons why this was not done for 64?
> (https://gcc.godbolt.org/z/7vddPdxaP)
There is zero-extension from the result of __builtin_clzll that confuses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #3 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 35d073c9a21..75c75f610c2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -25748,7 +25748,7 @@ (define_peephole2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #2 from Uroš Bizjak ---
(In reply to Sergei Trofimovich from comment #1)
> Slightly shorter example:
>
> typedef union {
> double d;
> int L[2];
> } U;
> void d2b(int*);
> void _Py_dg_dtoa(double dd) {
> int be;
> U u;
>
101 - 200 of 6636 matches
Mail list logo
