https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #18 from Richard Biener ---
(In reply to Jakub Jelinek from comment #13)
> Seems get_ref_base_and_extent already has code for some cases of the
> flexible array members, but it has apparently some dead code in it that
> wasn't really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #13 from Jakub Jelinek ---
Seems get_ref_base_and_extent already has code for some cases of the flexible
array members, but it has apparently some dead code in it that wasn't really
meant to be dead (hint, this check is after a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #16 from Jakub Jelinek ---
(In reply to Dominique d'Humieres from comment #14)
> > But I guess even this doesn't help, while it will help poor man's flexible
> > array members in C/C++, in this Fortran case the problem is that there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #15 from Jakub Jelinek ---
Note the dead code is there since r204391. Perhaps we need goto done; vs. goto
done2;, so that for MEM_REF/TARGET_MEM_REF we bypass this check?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Dominique d'Humieres from comment #14)
> > > But I guess even this doesn't help, while it will help poor man's flexible
> > > array members in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #14 from Dominique d'Humieres ---
> But I guess even this doesn't help, while it will help poor man's flexible
> array members in C/C++, in this Fortran case the problem is that there is
> COMMON /FMCOM/ X(1)
> in this TU, while
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
The stores are getting optimized out because equal_mem_array_ref_p considers
equal pairs of MEM_REFS like
fmcom.x[_168] and fmcom.x[_208]
That is, a ARRAY_REF whose first operand is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #11 from Jakub Jelinek ---
Bet we shouldn't use get_ref_base_and_extent comparisons if there is a variable
ARRAY_REF index and the corresponding array is flexible array member or poor
man's flexible array member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #12 from Jakub Jelinek ---
Otherwise, we happily consider in
struct S { char a[1]; int b; char c[1]; };
void
foo (struct S *p, int i, int j)
{
p->c[i]
...
p->c[j]
}
the above two as equivalent, while we should only consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc*-*-*|powerpc*-*-*, aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #5 from Wilco ---
This still fails on AArch64 in exactly the same way with latest trunk - can
someone reopen this? I don't seem to have the right permissions...
(In reply to Richard Biener from comment #4)
> So - can you please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #8 from Wilco ---
In a few functions GCC decides that the assignments in loops are redundant. The
loops still execute but have their loads and stores removed. Eg. the first DO
loop in MP2NRG should be:
.L1027:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #6 from Wilco ---
This still fails on AArch64 in exactly the same way with latest trunk - can
someone reopen this? I don't seem to have the right permissions...
(In reply to Richard Biener from comment #4)
> So - can you please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #7 from rguenther at suse dot de ---
On Mon, 1 Feb 2016, wdijkstr at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #6 from Wilco ---
> This still fails on AArch64 in exactly the same way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #9 from Wilco ---
The loops get optimized away in dom2. The info this phase emits is hard to
figure out, so it's not obvious why it thinks the array assignments are
redundant (the array is used all over the place so clearly cannot be
16 matches
Mail list logo
