https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #44 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Jun 13 10:03:30 2016
New Revision: 237371
URL: https://gcc.gnu.org/viewcvs?rev=237371=gcc=rev
Log:
Backport from Mainline
2015-09-25 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
--- Comment #43 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Jun 13 09:58:34 2016
New Revision: 237369
URL: https://gcc.gnu.org/viewcvs?rev=237369=gcc=rev
Log:
Backport from Mainline
2015-09-01 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79237
--- Comment #3 from avieira at gcc dot gnu.org ---
Hi,
My outstanding patch for PR71607 fixes this ICE too. I am currently retesting
it after some comments upstream and should be posting a new version soon.
Cheers,
Andre
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hello,
We are seeing a regression for arm-none-eabi on a Cortex-M7. This regression
was observed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
avieira at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #7 from avieira at gcc dot gnu.org ---
if-convert is a no go here, for the reason Andrew pointed out, sorry missed
that comment!
So I dont know... Only thing I can think of is better "value-range"-like
analysis f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #9 from avieira at gcc dot gnu.org ---
> > So I dont know... Only thing I can think of is better "value-range"-like
> > analysis for combine, but that might be too costly?
>
> So we are not really lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #6 from avieira at gcc dot gnu.org ---
> so we are talking about the uxthne insn (I don't know arm / thumb very well).
Yes, the uxthne is the "zero_extend" that is otherwise optimized away if you
turn off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #11 from avieira at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #10)
> That is what nonzero_bits etc. is about. We could do much better nowadays
> with the generic DF framework.
>
I am not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77695
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #1 from avieira at gcc dot gnu.org ---
When I say without errors I meant without segfaulting. It will print out the
following error for version 5 if you dont include '-mfpu=neon':
t.c:1:9: error: '__simd64_float16_t' does not name
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hello,
When compiling the following:
$ cat t.c
typedef __simd64_float16_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #3 from avieira at gcc dot gnu.org ---
Just to make it clear:
The command I showed without the '-g' did use to error on gcc-5, but it doesnt
on 6 and 7:
$ gcc-5/arm-none-eabi-g++ -S t.c -mfloat-abi=hard -march=armv7-a
t.c:1:9: error
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
As first reported by Andrew on
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1616992
To reproduce on trunk:
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #1 from avieira at gcc dot gnu.org ---
OK I think I assigned the blame to the wrong function, I think it is the
responsibility of 'is_indirect_tailcall_p' to catch this. Though I believe the
last time it is called during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #2 from avieira at gcc dot gnu.org ---
The approach I had doesnt work, it ICE's elsewhere...
At the time I am not sure how to fix this without disabling indirect tail calls
for the current function if any sibcall is done within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538
--- Comment #6 from avieira at gcc dot gnu.org ---
I had a look at this and after some digging I found the bug is not due to LTO,
but rather with "local" functions. If you make bar static you will end up with
the same faulty behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #12 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Fri Dec 9 16:46:42 2016
New Revision: 243494
URL: https://gcc.gnu.org/viewcvs?rev=243494=gcc=rev
Log:
PR78255: Make postreload aware of NO_FUNCTION_CSE
gcc/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #13 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Fri Dec 9 17:22:20 2016
New Revision: 243496
URL: https://gcc.gnu.org/viewcvs?rev=243496=gcc=rev
Log:
PR78255: Make postreload aware of NO_FUNCTION_CSE
gcc/ChangeLog.arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #15 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Jan 11 15:08:25 2017
New Revision: 244319
URL: https://gcc.gnu.org/viewcvs?rev=244319=gcc=rev
Log:
PR78255: Make postreload aware of NO_FUNCTION_CSE
gcc/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607
--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Dec 5 17:36:03 2016
New Revision: 243266
URL: https://gcc.gnu.org/viewcvs?rev=243266=gcc=rev
Log:
[ARM] PR71607: New approach to arm_disable_literal_pool
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255
--- Comment #14 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Jan 9 09:58:54 2017
New Revision: 244220
URL: https://gcc.gnu.org/viewcvs?rev=244220=gcc=rev
Log:
PR78255: Make postreload aware of NO_FUNCTION_CSE
gcc/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu May 24 08:53:39 2018
New Revision: 260635
URL: https://gcc.gnu.org/viewcvs?rev=260635=gcc=rev
Log:
PR target/83009: Relax strict address checking for store pair lanes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- Comment #10 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed May 30 15:59:14 2018
New Revision: 260957
URL: https://gcc.gnu.org/viewcvs?rev=260957=gcc=rev
Log:
Reverting r260635
gcc
2018-05-30 Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86366
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #2 from avieira at gcc dot gnu.org ---
I am having quite a lot of trouble understanding what is going wrong, or maybe
I should say, what parts are going right.
I believe it tries to match the fifth alternative for anddi3_insn here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #3 from avieira at gcc dot gnu.org ---
@Vlad: I added you to this ticket to see if maybe you can shine some light on
how GCC's register allocator deals with register pairs in big endian, I am
struggling to figure out how all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #46 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Tue Jul 31 08:42:21 2018
New Revision: 263082
URL: https://gcc.gnu.org/viewcvs?rev=263082=gcc=rev
Log:
Reverting 'AsyncI/O patch committed' as it is breaking bare-metal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- Comment #11 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu Jul 19 14:03:21 2018
New Revision: 262881
URL: https://gcc.gnu.org/viewcvs?rev=262881=gcc=rev
Log:
[AArch64][PATCH 2/2] PR target/83009: Relax strict address checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- Comment #5 from avieira at gcc dot gnu.org ---
I have been looking at this and the problem does indeed lie with the register
not being a hard reg because aarch64_mem_pair_lanes_operand invokes
aarch64_legitimate_address_p with 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009
--- Comment #7 from avieira at gcc dot gnu.org ---
Bootstrap and regression testing looks good. Ill put the patch up on the ML
when we enter stage 1 again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #5 from avieira at gcc dot gnu.org ---
I can confirm the ICE no longer occurs, but I am not entirely convinced the
issue was "fixed" by this. I fear the underlying fault is still there, it is
simply hidden now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224
--- Comment #3 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Fri Dec 14 09:04:24 2018
New Revision: 267124
URL: https://gcc.gnu.org/viewcvs?rev=267124=gcc=rev
Log:
PR target/88224: Fix FPU configuration of Cortex-R7 and Cortex-R8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224
--- Comment #2 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Thu Nov 29 10:20:13 2018
New Revision: 266612
URL: https://gcc.gnu.org/viewcvs?rev=266612=gcc=rev
Log:
[PATCH] [Arm] Fix fpu configurations for Cortex-R7 and Cortex-R8
gcc
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
The Cortex-R7 and Cortex-R8 TRM's* indicate that both CPUs can be configured
with one of the following FPU options:
1) No FPU
2) Single precision-only VFPv3, with 16 double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #7 from avieira at gcc dot gnu.org ---
Hi,
This one sort of fell through the cracks on me. With help from Vlad and Richard
S. I managed to track the issue to uses_hard_regs_p and the way it handles
paradoxical subregs (or fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #8 from avieira at gcc dot gnu.org ---
Oliver,
Your new example doesn't seem to be hitting the same issue as the first one.
The first failure was being caused by paradoxical subregs, the second one
doesn't have paradoxical subregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #12 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Feb 20 14:11:43 2019
New Revision: 269039
URL: https://gcc.gnu.org/viewcvs?rev=269039=gcc=rev
Log:
[GCC] PR target/86487: fix the way 'uses_hard_regs_p' handles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #10 from avieira at gcc dot gnu.org ---
Hi Vlad,
I don't think it is a duplication. I believe this PR is caused by an issue with
'uses_hard_regs_p' and paradoxical subregs. I proposed a patch in
https://gcc.gnu.org/ml/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 91460, which changed state.
Bug 91460 Summary: gcc -mpreferred-vector-width=256 is slower than
-mpreferred-vector-width=128 for some loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91460
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88915
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||skpgkp2 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91460
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92347
--- Comment #4 from avieira at gcc dot gnu.org ---
The second case seems to be because vectorizable_simd_clone_call seems to be
inserting values and phi-nodes on the epilogue's preheader edge which uses a
value defined in the main loop's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92347
--- Comment #3 from avieira at gcc dot gnu.org ---
I had a look at the first testcase. I think the problem is I was setting the
epilogue's safelen to the loop's safelen, after the loop->safelen had been
cleared, as we do this after vectorizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
--- Comment #2 from avieira at gcc dot gnu.org ---
So I had a look at this, the ICE occurs because 'vectorizable_condition' does
not know how to handle a constant cond_expr.
The reason this cond_expr is constant in the epilogue is because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92347
--- Comment #5 from avieira at gcc dot gnu.org ---
Not quite sure the third case has anything to do with epilogue vectorization
though... It still manifests itself with it turned off. Seems to be a lack of
"folding" again.
I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92347
--- Comment #7 from avieira at gcc dot gnu.org ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92460
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317
--- Comment #3 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Nov 6 11:22:35 2019
New Revision: 277877
URL: https://gcc.gnu.org/viewcvs?rev=277877=gcc=rev
Log:
[vect] PR92317: fix skip_epilogue creation for epilogues
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317
--- Comment #1 from avieira at gcc dot gnu.org ---
Confirmed. It seems get_loop_copy is returning NULL. I'm looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92317
--- Comment #2 from avieira at gcc dot gnu.org ---
Actually upon a second look it has nothing to do with that, that get_loop_body
doesn't make much sense there anyways. I believe that should have just been
'loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92351
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92351
--- Comment #3 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Fri Nov 8 13:52:56 2019
New Revision: 277974
URL: https://gcc.gnu.org/viewcvs?rev=277974=gcc=rev
Log:
[vect] PR 92351: When peeling for alignment make alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 91573, which changed state.
Bug 91573 Summary: Vectorization failure for a loop to do multiply-add because
SLP loads unnecessarily require permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 91573, which changed state.
Bug 91573 Summary: Vectorization failure for a loop to do multiply-add because
SLP loads unnecessarily require permutation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91573
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88915
--- Comment #5 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Tue Oct 29 13:15:46 2019
New Revision: 277569
URL: https://gcc.gnu.org/viewcvs?rev=277569=gcc=rev
Log:
[vect]PR 88915: Vectorize epilogues when versioning loops
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #15 from avieira at gcc dot gnu.org ---
Jeff seems to have backported this to gcc-8 already, so I guess we can close
this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
--- Comment #5 from avieira at gcc dot gnu.org ---
Hi Martin,
Sorry about that, forgot to check it after I got back from holidays. I wrote up
a patch, actually going with solution 2) (fixes both issues locally).
Just running more tests now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
--- Comment #5 from avieira at gcc dot gnu.org ---
Yeah...
So far I have checked that 'gimplify_call_expr' creates the right gimple, and
up until 'gimplify_modify_expr' I can verify it does by using
gimple_call_fntype .
Though at expansion time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
--- Comment #4 from avieira at gcc dot gnu.org ---
Yeah...
So far I have checked that 'gimplify_call_expr' creates the right gimple, and
up until 'gimplify_modify_expr' I can verify it does by using
gimple_call_fntype .
Though at expansion time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
--- Comment #6 from avieira at gcc dot gnu.org ---
I have also identified that this only goes wrong in O2 or higher. And it
happens sometime between tailcall optimization pass 1 and 2. But there's loads
of passes in between.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94445
--- Comment #2 from avieira at gcc dot gnu.org ---
start_decl seems to be doing the right thing, investigation continues...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94814
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91246
--- Comment #5 from avieira at gcc dot gnu.org ---
I have posted a prototype on the mailing list
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541908.html
This is really just a prototype to investigate code-gen impact, I don't expect
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
An example of this issue can be observed when trying to compile:
#include
uint16x8_t foo (uint16x8_t a, int16_t b)
{
return vaddq (a, (b<<3));
}
This wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-15
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #4 from avieira at gcc dot gnu.org ---
With -mcpu=cortex-m55+nomve should be equivalent to -march=armv8.1-m.main+dsp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327
--- Comment #5 from avieira at gcc dot gnu.org ---
Your other one:
-mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp
This has cpu without mve and arch with mve.
Another fun caveat to look at is in:
-mcpu=cortex-m55 -mfloat-abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
avieira at gcc dot gnu.org changed:
What|Removed |Added
Summary|arm-none-eabi function |[GCC 9/10] arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
--- Comment #12 from avieira at gcc dot gnu.org ---
@jakub: backported to gcc-8 and gcc-9. OK to close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981
--- Comment #5 from avieira at gcc dot gnu.org ---
Yeah that works. Ran it as is, no abort, ran it with s/ne/eq/ and it aborts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981
--- Comment #6 from avieira at gcc dot gnu.org ---
FYI Tamar asked me to make sure the instructions were being generated. I
checked and they were, but not being used as it decides to inline MAIN__ and
inlining seems to break (as in not apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 98974, which changed state.
Bug 98974 Summary: [11 Regression] ICE in vectorizable_condition after
STMT_VINFO_VEC_STMTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
What|Removed
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
After
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b05d5563f4be13b4a0d0951375a82adf483973c0
we found vectorizable_condition to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
--- Comment #1 from avieira at gcc dot gnu.org ---
The testcase above issues a warning, around do j=jts,enddo
To use it as a testcase in my patch I'd like to get rid of it so if someone
proficient in Fortran knows a way to get rid of it that'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
avieira at gcc dot gnu.org changed:
What|Removed |Added
Known to work|10.2.1 |
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
--- Comment #8 from avieira at gcc dot gnu.org ---
Aye my bad there, Thanks for the change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98657
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #8 from avieira at gcc dot gnu.org ---
Also at some point we should figure out why the vectorizer is generating this
much code for this example, where I think it should be able to optimized it to:
a = 22;
b &= c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #7 from avieira at gcc dot gnu.org ---
I'm looking at this and I have a feeling there is a disconnect on how some
passes define VECTOR_CST and how the expand pass handles it.
So the problem here seems to lie with the V4SImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #5 from avieira at gcc dot gnu.org ---
Posted a fix on ML:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588237.html
Sorry for the breakage, wrong assumption by my part :(
1 - 100 of 195 matches
Mail list logo
