https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #28 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cc383e9702897dd783657ea3dce4aecf48318441
commit r14-9203-gcc383e9702897dd783657ea3dce4aecf48318441
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #27 from Jakub Jelinek ---
Created attachment 57551
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57551=edit
gcc14-pr113988.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #26 from Zdenek Sojka ---
Created attachment 57548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57548=edit
testcase failing with -O -m32
This testcase does not need -mavx512f, but -m32 instead:
$ x86_64-pc-linux-gnu-gcc -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Bug 113988 depends on bug 114073, which changed state.
Bug 114073 Summary: during GIMPLE pass: bitintlower: internal compiler error:
in lower_stmt, at gimple-lower-bitint.cc:5530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Jakub Jelinek changed:
What|Removed |Added
Blocks|114073 |
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #23 from rguenther at suse dot de ---
On Thu, 22 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #22 from Jakub Jelinek ---
> Yeah, I was worried about partial ints.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #22 from Jakub Jelinek ---
Yeah, I was worried about partial ints. Or it could be punt if TYPE_MODEs are
different and at least one of them is BLKmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #21 from rguenther at suse dot de ---
On Thu, 22 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #20 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #20 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #19)
> I think the usual BLKmode check would be better here? Apart from
> that this looks correct, we shouldn't use a regular convert on
> a non-register type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #19 from rguenther at suse dot de ---
On Wed, 21 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #17 from Jakub Jelinek ---
> So, either we could somehow handle that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #18 from Jakub Jelinek ---
Created attachment 57479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57479=edit
gcc14-pr113988.patch
Full untested patch for that variant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #17 from Jakub Jelinek ---
So, I've tried
--- gcc/gimple-lower-bitint.cc.jj 2024-02-15 09:52:40.999145971 +0100
+++ gcc/gimple-lower-bitint.cc 2024-02-21 12:48:38.704163901 +0100
@@ -5307,12 +5307,15 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> --- gcc/gimple-fold.cc.jj 2024-02-06 12:59:58.343050621 +0100
> +++ gcc/gimple-fold.cc2024-02-19 19:48:11.162126759 +0100
> @@ -995,9 +995,27 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #14 from Jakub Jelinek ---
--- gcc/gimple-fold.cc.jj 2024-02-06 12:59:58.343050621 +0100
+++ gcc/gimple-fold.cc 2024-02-19 19:48:11.162126759 +0100
@@ -995,9 +995,27 @@ gimple_fold_builtin_memory_op (gimple_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #13 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> Though, bet that would mean we punt with -mavx -mno-avx2 on 32-byte copies,
> because there we support just V8SFmode and not V32QImode.
Punt AVX without AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #12 from rguenther at suse dot de ---
On Mon, 19 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #10 from Jakub Jelinek ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #10 from Jakub Jelinek ---
(In reply to Richard Biener from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Jakub Jelinek from comment #7)
> > > I think I can handle it like the VIEW_CONVERT_EXPR case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I think I can handle it like the VIEW_CONVERT_EXPR case, bet with
> > _BitInt(511) it would actually be a VCE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I think I can handle it like the VIEW_CONVERT_EXPR case, bet with
> _BitInt(511) it would actually be a VCE, but when it is same size
> BITINT_TYPE to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #7 from Jakub Jelinek ---
I think I can handle it like the VIEW_CONVERT_EXPR case, bet with _BitInt(511)
it would actually be a VCE, but when it is same size BITINT_TYPE to
INTEGER_TYPE we choose NOP_EXPR.
That said, I think it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #6 from Richard Biener ---
-mstore-max=128 -mmove-max=128 avoids it and we inline the memcpy as
D.5177 = MEM <_BitInt(512)> [(char * {ref-all})];
MEM <_BitInt(512)> [(char * {ref-all})digits.0] = D.5177;
using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #5 from Richard Biener ---
Likely "caused" by upping MOVE_MAX and GIMPLE memcpy folding exposing this
type by means of build_nonstandard_integer_type.
We have from that
D.5177 = MEM [(char * {ref-all})];
MEM [(char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #4 from Richard Biener ---
I wonder if we should stop claiming those modes are "supported". Maybe instead
of making them integer modes they should be OPAQUE_MODE or vector (integer)
modes in the first place? There's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #3 from Jakub Jelinek ---
Ugh, types that can't be really supported used like that are toxic :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #2 from Jan Schultke ---
Oh yeah, I should have noted that this only happens for AVX-512 targets.
Changing -march=znver4 to -march=znver3 stops the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-19
30 matches
Mail list logo
