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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #21 from Haochen Jiang ---
(In reply to Andrew Pinski from comment #20)
> The use of __builtin_ia32_2intersectd128 in avx512vp2intersectvlintrin.h has:
> #pragma GCC target("avx512vp2intersect,avx512vl,no-evex512")
>
> While i386-bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #16 from Haochen Jiang ---
Well I still could not reproduce that. Need some more investigation if they are
the same case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #14 from Haochen Jiang ---
Intel(R) Core(TM) i5-8250U and AMD Ryzen 7 PRO 6850U both have AVX.
I am trying to reproduce that on building trunk with GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #10 from Haochen Jiang ---
(In reply to Andrew Pinski from comment #7)
> I suspect the common theme here is enable-default-pie .
>
> In the case of the original report was built with a compiler that had
> enabled and --disable-boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #4 from Haochen Jiang ---
It is weird since everything passed even under bootstrap.
Could you provide the exact options you build GCC with --disable-bootstrap for
me to reproduce?
I suppose all of them are '--enable-libsanitizer' '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
--- Comment #7 from Haochen Jiang ---
I have got a same binary w/ and w/o my commit with the options if nothing went
wrong.
Seems we need more investigation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
--- Comment #4 from Haochen Jiang ---
I checked the znver3 plot on the site, it seems that no regression occurs.
Since znver4 enabled AVX512, that is the reason why I guessed previously.
Could you also provide the option you ran with? I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
--- Comment #3 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #2)
> It is weird since I did not touch the tune.
>
> Need a bisect to check that but I do not have a zen4 machine.
>
> Could you try with this commit g:459866eaeec1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
--- Comment #2 from Haochen Jiang ---
It is weird since I did not touch the tune.
Need a bisect to check that but I do not have a zen4 machine.
Could you try with this commit g:459866eaeec151e72aecd670695f014f4ec48588 to
see if the regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112435
--- Comment #12 from Haochen Jiang ---
Seems like we should prevent the optimization in that commit to register
x/ymm16+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #8 from Haochen Jiang ---
Should be fixed on trunk now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #6 from Haochen Jiang ---
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635410.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
Haochen Jiang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #5 from Haochen Jiang ---
BTW, it should be disabled since it will use zmm previously.
foo(_Float128, _Float128):
pushrbp
mov rbp, rsp
vmovdqa XMMWORD PTR [rbp-16], xmm0
vmovdqa XMMWORD PTR [r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907
--- Comment #4 from Haochen Jiang ---
I guess it is caused by "*andnot3", not confirmed yet.
The isa for the last constraint changed to avx512f_512, which will make the
pattern disabled under -mavx512f -mno-evex512.
Let me find a solution on tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
--- Comment #5 from Haochen Jiang ---
It is actually a legacy issue from this:
$ cat 2.c
#include
__attribute__ ((target ("no-avx2")))
void foo ()
{
return _mm_empty ();
}
$ x86_64-pc-linux-gnu-gcc -O2 -mavx512f 2.c
It will also fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111772
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
--- Comment #6 from Haochen Jiang ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
--- Comment #3 from Haochen Jiang ---
My proposal for this problem is to also push "no-evex512" when defining 128/256
intrins. But I am not sure if there will be some potential problems.
Currently working on an experiment on that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
--- Comment #2 from Haochen Jiang ---
Here is the Godbolt example of that:
https://godbolt.org/z/b3n8h4rb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
--- Comment #1 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #0)
> Created attachment 56155 [details]
> Simple testcase
>
> With this simple testcase and command like this:
>
> x86_64-pc-linux-gnu-gcc -O2 -march=x86-64 1.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889
Bug ID: 111889
Summary: [14 Regression] 128/256 intrins could not be used with
only specifying "no-evex512, avx512vl" in function
attribute
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
--- Comment #4 from Haochen Jiang ---
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633677.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
--- Comment #3 from Haochen Jiang ---
It seems like caused by I changed the behavior when trying to use x/ymm16+ w/o
avx512vl specified.
Working on a solution for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
--- Comment #3 from Haochen Jiang ---
See patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627829.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051
--- Comment #2 from Haochen Jiang ---
It is caused by when including immintrin.h, since the pragma is removed, there
will be no AVX support, which makes _mm256_setzero_pd invisible.
Adding a AVX2 pragma instead of removing it should solve the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083
Bug ID: 110083
Summary: [14 Regression] ICEs for testcase on
fp-int-convert*timode after r14-1466-g3635e8c67e1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #4 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Haochen Jiang from comment #1)
> > I further checked the reason, V2SI should never dropped into that function
> > because we have no pattern under V2S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #1 from Haochen Jiang ---
I further checked the reason, V2SI should never dropped into that function
because we have no pattern under V2SI.
I suppose it is because -march=cascadelake will open SSE4.1, with the new
pattern, it wrongl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Bug ID: 109807
Summary: [14 Regression] sse2-mmx-pmaddwd.c met ICE after
commit gcc-14-666-g608e7f3ab47 with march=cascadelake
Product: gcc
Version: 14.0
Status: UNCONFI
1 - 100 of 119 matches
Mail list logo
