https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826
--- Comment #3 from haochen.jiang at intel dot com ---
(In reply to Andrew Pinski from comment #2)
> math-vector-fortran.h comes from glibc so this is a glibc bug and not a GCC
> bug.
> installed header files from glibc should match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826
Bug ID: 102826
Summary: Glibc "--disable-mathvec" configure option fail to
disable traces to libmvec
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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=112374
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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
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
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=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=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
--- 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 #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
Bug ID: 111889
Summary: [14 Regression] 128/256 intrins could not be used with
only specifying "no-evex512, avx512vl" in function
attribute
Product: gcc
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=111772
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
--- Comment #8 from Haochen Jiang ---
Fixed for GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #4 from Haochen Jiang ---
Created attachment 53261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53261=edit
This patch aims to handle memory issue when unpacking in cvtps2pd
I am trying to solve this ICE problem with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43618
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #7 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #6)
> Comment on attachment 53261 [details]
> 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=106180
--- Comment #8 from Haochen Jiang ---
Created attachment 53269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53269=edit
This patch aims to handle memory issue when unpacking in cvtps2pd (version 2)
Just fully tested on this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #9 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #8)
> Created attachment 53269 [details]
> This patch aims to handle memory issue when unpacking in cvtps2pd (version 2)
>
> Just fully tested on this patch. Changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Haochen Jiang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Bug ID: 107669
Summary: [13 Regression] commit
r13-3931-59a63247992eb13153b82c4902aadf111460eac2
causes lots of testcase failure
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
Bug ID: 109118
Summary: [13 Regression] gcc.dg/mla_1.c failed on target w/o
__Uint32x4_t support
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
--- Comment #9 from Haochen Jiang ---
(In reply to Jakub Jelinek from comment #8)
> Should be fixed now.
Sorry for the late reply.
Yes, it fixed for me now. Thx a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #2 from Haochen Jiang ---
(In reply to Andrew Stubbs from comment #1)
> I tested it on i686-pc-linux-gnu before I posted the patch, and it was
> working then. Can you be more specific what configuration you were testing,
> please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
Bug ID: 108898
Summary: [13 Regression] Test introduced by
r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d
failed on i386
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
Bug ID: 108899
Summary: [13 Regression] ERROR: can't rename to
"saved-unsupported": command already exists on i386
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Bug ID: 109549
Summary: [14 Regression] cmov6.c test fail after commit
r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
Bug ID: 109596
Summary: [14 Regression] Lots of testcases fails on x86_64
after r14-162-gcda246f8b421ba
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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
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:
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
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
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=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 #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 #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=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=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
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=112675
Bug ID: 112675
Summary: [14 Regression] r14-5385-g0a140730c97087 caused
regression on testcases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
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=112675
Haochen Jiang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
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
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
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=113656
Haochen Jiang changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment
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=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
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 #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=111907
--- Comment #8 from Haochen Jiang ---
Should be fixed on trunk now.
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=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
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=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 #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 #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
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
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=114238
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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=110621
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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.
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)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115071
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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
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
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
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
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
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
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=115069
--- Comment #22 from Haochen Jiang ---
Fixed in GCC14 and GCC15
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=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
Haochen Jiang changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
89 matches
Mail list logo
