https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #11 from Haochen Jiang ---
We have two temporary solutions in GCC 14 and GCC 15 since we could not simply
reject -mno-evex512. In GCC 16, since it is deprecated, no more issue for that.
Plan A: Use vmovq to only clear lower 64 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #10 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #9)
> Proposed change:
>
> diff --git a/gcc/config/i386/i386-options.cc
> b/gcc/config/i386/i386-options.cc
> index a9fac011f3d..789c1f1ae54 100644
> --- a/gcc/confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #9 from Haochen Jiang ---
Proposed change:
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index a9fac011f3d..789c1f1ae54 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #8 from Haochen Jiang ---
After some more consideration, my current plan is to raise an error if
-mno-evex512 is not used with AVX512VL enabled in GCC 14 and GCC 15, since w/o
AVX512VL, we could only use scalar instructions. I suppos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #7 from Haochen Jiang ---
The problem is under msabi, -fzero-call-used-regs=all will also try to clear
xmm16+. However, under -mavx512f -mno-evex512, we have no instructions to do
that.
There are two solutions for that:
1. Reject m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #5 from Haochen Jiang ---
Just take a quick try on the option combination. Eliminating either
-fzero-call-used-regs=all or -mabi=ms will not get ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #4 from Haochen Jiang ---
(In reply to Hongtao Liu from comment #3)
> (In reply to Hongtao Liu from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > I think we need to disable the effect of -mno-evex512, looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119549
--- Comment #3 from Haochen Jiang ---
That is odd the AVX10.1 patch would change that behavior.
Lin, could you have a look on that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119410
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383
--- Comment #4 from Haochen Jiang ---
I am dealing with AVX10 refactor issue this week and have no time to look into
that.
I will try to find a way to reduce that next week or someone could reproduce
that to look into that for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383
--- Comment #2 from Haochen Jiang ---
I have got the upcoming target in thread test fail:
...failed updating 18 targets...
testing.capture-output
../../../bin.v2/libs/thread/test/ex_executor.test/gcc-15/dbg/thrd-mlt/vsblt-hdn/ex_executor.run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383
Bug ID: 119383
Summary: [15 Regression] Boost 1.85 lib build fail after commit
r15-8011
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270
--- Comment #5 from Haochen Jiang ---
>From my run, it should have fixed the regression. Thx!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270
--- Comment #1 from Haochen Jiang ---
>From my bisect, it might caused by r15-7932 on single copy for Ice Lake.
Guilty Commit: e355fe414aa3aaf215c7dd9dd789ce217a1b458c
Author: Vladimir N. Makarov
Date: 2025-03-11 04:27:51 Tuesday
Diff: -2.45499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
--- Comment #10 from Haochen Jiang ---
I could not reproduce that from scratch for now either since if I recalled that
correctly, I reproduce that on one specific Sky Lake machine, not all.
BTW, the DSB issue is some time just a "bad luck" caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #4 from Haochen Jiang ---
I suppose that patch should be reverted, caused by Richard S's patch.
https://gcc.gnu.org/pipermail/gcc-regression/2025-March/081825.html
(I almost thought my script went buggy and needed to shut down toda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
Haochen Jiang changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #8 from Haochen Jiang ---
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675748.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #7 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #6)
> I am testing a patch with this fix:
>
> "
> @@ -2751,10 +2752,11 @@ ix86_option_override_internal (bool main_args_p,
> }
>
>/* Set EVEX512 if one of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #16 from Haochen Jiang ---
Fixed so far on trunk and GCC14 for avx512bw intrin header.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #6 from Haochen Jiang ---
I am testing a patch with this fix:
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 3467ab0bbeb..f2c536d1e33 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #5 from Haochen Jiang ---
It is caused by the EVEX512 set and condition judge on warnings.
EVEX512 should not be set or taken into consideration if AVX512 not explicitly
enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #4 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #3)
> Which makes this thing more weird than my expected is that avx10_2rounding
> and avx10_2minmax intrin file seems not reporting the warning. It also
> should from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #3 from Haochen Jiang ---
Which makes this thing more weird than my expected is that avx10_2rounding and
avx10_2minmax intrin file seems not reporting the warning. It also should from
my understanding, but it may shed the light of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #2 from Haochen Jiang ---
My guess (and probably it should be) is on the push and pop target for AVX10
related options and evex512 usage causing the issue.
AVX10.2-256 will only use 256 size, and there is elsewhere enabling evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #12 from Haochen Jiang ---
And the define seems not to be the workaround for those two PRs. It is much
like a typo when moving things around for AVX10 since GCC13 (before AVX10
introduction), it is still wrapped by #ifdef.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #11 from Haochen Jiang ---
It should be #ifdef instead of #if here from my first glance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118270
Haochen Jiang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118609
--- Comment #1 from Haochen Jiang ---
I am going to revise the testcase through the thread:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674157.html
Dup with PR118270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118270
--- Comment #2 from Haochen Jiang ---
I just revised a lot more mnemonics in Binutils first to catch up with Binutils
2.44 freeze this Sunday. Thus, there would be more tests compiling with latest
Binutils fail. They are expected.
I am working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118270
--- Comment #1 from Haochen Jiang ---
It is caused by binutils and gcc mnemonics currently misaligned.
The mnemonics got some changes after GCC upstreamed. Binutils is using some new
mnemonics, while GCC does not. Since there would be more comi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #9 from Haochen Jiang ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Haochen Jiang ---
> > Testcase fixed on trunk.
>
> Great, thanks.
>
> > Since I do not have a Solaris machine, I could n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117731
--- Comment #4 from Haochen Jiang ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Haochen Jiang from comment #2)
> > I also notice that but why the warning does not appear previously since it
> > is always using gnu14?
>
> becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117731
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #7 from Haochen Jiang ---
Testcase fixed on trunk.
Since I do not have a Solaris machine, I could not to solve the problem on
Solaris/x86 for:
> Weirdly, adding -fomit-frame-pointer to the testcases
> make no difference on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #5 from Haochen Jiang ---
Patch with change Hongtao proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669647.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #3 from Haochen Jiang ---
Proposed change:
diff --git a/gcc/testsuite/gcc.target/i386/avx10_2-vmovd-1.c
b/gcc/testsuite/gcc.target/i386/avx10_2-vmovd-1.c
index 6a5d84ac6cd..be1631f3060 100644
--- a/gcc/testsuite/gcc.target/i386/avx1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117697
--- Comment #2 from Haochen Jiang ---
I see, let me change that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117527
Haochen Jiang changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117496
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117527
Bug ID: 117527
Summary: [15 regression] 511.povary_r with
march_native_ofast_lto build fail since r15-5021
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117301
--- Comment #6 from Haochen Jiang ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117301
--- Comment #4 from Haochen Jiang ---
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/95.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117137
--- Comment #3 from Haochen Jiang ---
>From my bisect:
5977b746db3925aaba37722f5312419d5f2968a5 is the first bad commit
commit 5977b746db3925aaba37722f5312419d5f2968a5
Author: Richard Biener
Date: Tue Oct 8 09:01:01 2024 +0200
tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117082
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065
Haochen Jiang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117086
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116617
--- Comment #8 from Haochen Jiang ---
Fixed on trunk, GCC14, GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116617
--- Comment #4 from Haochen Jiang ---
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662455.html
I would commit this next Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116617
--- Comment #3 from Haochen Jiang ---
We will not add doc previously if the option is only an alias to another
platform, which is similar for meteorlake and raptorlake.
Lunarlake is actually the alias for arrowlake-s. That is why we don't add i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065
--- Comment #4 from Haochen Jiang ---
It seems to me gcc-13-3950-g071e428c24e is the guilty commit.
071e428c24ee8c1ed062597a093708bba29509c9 is the first bad commit
commit 071e428c24ee8c1ed062597a093708bba29509c9
Author: Hongyu Wang
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065
--- Comment #3 from Haochen Jiang ---
Maybe I could first start with a bisect since GCC12.1 is known to ok and
GCC13.1 is known to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #4 from Haochen Jiang ---
Hmm, it is interesting that I even could not reproduce that on the same
machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065
Bug ID: 116065
Summary: [13/14/15 Regression] Function attribute optimize()
might make ISA target attribute broken
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116046
Bug ID: 116046
Summary: vmovdqa64 is used when unaligned memory caused by
unaligned %rsp/%rbp
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
--- Comment #9 from Haochen Jiang ---
I would rather do not touch all the ISA level since it might cause unexpected
problems after thinking twice.
Since there is also indirect call, I will throw an error for this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
--- Comment #8 from Haochen Jiang ---
One potential solution is to let the resolver ISA level becomes the highest one
in target_clones instead of the default one.
Then it will not get the memory/register mismatch when passing/returning
argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
--- Comment #6 from Haochen Jiang ---
I have got a machine to reproduce the regression.
Seem like a DSB miss from my data, but don't know why. Need more investigation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
Haochen Jiang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #1 from Haochen Jiang ---
Forgot to mention, the memory consumption collection is collected on x86_64
target in order to get the test finished. Therefore, we could debug on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
Bug ID: 115208
Summary: [15 Regression] Memory consumption get extremely high
after r15-809
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115025
Haochen Jiang changed:
What|Removed |Added
CC||jh at suse dot cz
--- Comment #6 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #22 from Haochen Jiang ---
Fixed in GCC14 and GCC15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #19 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #18)
> SPEC
SPEC seems all same binary to me. So there is no surprise.
I suppose let's go with patch from Uros to just emphasize the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #18 from Haochen Jiang ---
SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #15 from Haochen Jiang ---
I am doing like this way. Suppose should be same as Comment 8.
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index a6132911e6a..1e8334877d6 100644
--- a/gcc/config/i386/i386-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #12 from Haochen Jiang ---
(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 I need to
> > test more benchmarks to see if ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #10 from Haochen Jiang ---
A patch like Comment 8 could definitely solve the problem. But I need to test
more benchmarks to see if there is surprise.
But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #6 from Haochen Jiang ---
(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=115025
--- Comment #5 from Haochen Jiang ---
My guess is that for the prime judging loop:
for (i = 5; i < max; i += 6)
if ((n % i == 0) || (n % (i + 2) == 0))
return 0;
In GCC13, it extracts the first l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115071
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115002
--- Comment #5 from Haochen Jiang ---
It seems that mainly caused by codesize increase in GCC14 since the actual
instruction retired increase ratio is similar to the regression.
Also, just like PR114987, I tried with GCC11, seems it gets the be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987
--- Comment #7 from Haochen Jiang ---
Furthermore, when I build with GCC11, the codegen is much better:
vaddps 0xc0(%rsp),%ymm5,%ymm2
vaddps 0xe0(%rsp),%ymm4,%ymm1
vmovaps %ymm2,0x80(%rsp)
vmovdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114987
--- Comment #5 from Haochen Jiang ---
What I have found is that the binary built with GCC13 and GCC14 will regress on
Cascadelake and Skylake.
But when I copied the binary to Icelake, it won't. Seems Icelake might fix this
with micro-tuning.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #18 from Haochen Jiang ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Carlos Eduardo Seo from comment #15)
> > I see some failures after this patch on aarch64-linux-gnu:
> >
> > FAIL: gcc.dg/guality/pr54693-2.c -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
Haochen Jiang changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #3 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #2)
> Actually it is caused by option -funsafe-math-optimizations but not
> -mavx10.1.
>
> Before my commit, while using option:
>
> -frounding-math -O3 -mavx512fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #2 from Haochen Jiang ---
Actually it is caused by option -funsafe-math-optimizations but not -mavx10.1.
Before my commit, while using option:
-frounding-math -O3 -mavx512fp16 -mavx512vl -funsafe-math-optimizations
It will also re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656
--- Comment #1 from Haochen Jiang ---
>From the first glance, it seems that the op here is wrongly interpreted.
Investigating why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113534
Bug ID: 113534
Summary: printf might report segmentation fault under -mabi=ms
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
--- Comment #6 from Haochen Jiang ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
--- Comment #3 from Haochen Jiang ---
Adding them are quite straightforward. But I am not quite sure how the whole
libgomp patch works.
Is the patch attempt to check whether it is a perfect match for each ISA
detected from a hardware? If that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
--- Comment #1 from Haochen Jiang ---
(In reply to Tobias Burnus from comment #0)
> As noted in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.html
>
> There is not #define for -mavx10.1-256 and -mavx10.1-512
>
> By contrast,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #11 from Haochen Jiang ---
I just checked the code and pattern. I suppose the simple remove is reasonable
here. We should only allow x/ymm16+ for scalar instructions, but not this
pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #7 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #1)
> Created attachment 56962 [details]
> Proposed patch
>
> Patch in testing.
>
> lowpart_subreg can't handle:
>
> lowpart_subreg (V4SFmode, operands[0], DFmode);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #6 from Haochen Jiang ---
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 this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #5 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #3)
> This patch also fixes the failure:
>
> --cut here--
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index ca6dbf42a6d..cdb9ddc4eb3 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Haochen Jiang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Bug ID: 112675
Summary: [14 Regression] r14-5385-g0a140730c97087 caused
regression on testcases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #24 from Haochen Jiang ---
Patch aims to fix that:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #23 from Haochen Jiang ---
I have root caused the issue and also discovered some other minor problems
unrelated to this PR but hard to discover.
I will write a patch to fix all of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #22 from Haochen Jiang ---
A quick workaround would be not appending -mno-avx10.1-xxx into -march=native.
And it should work after my experiment. However, I am finding a better way to
do that.
The real problem seems like the AVX10 a
1 - 100 of 150 matches
Mail list logo
