https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #24 from Tamar Christina ---
The case I thought would go wrong with the above fix is:
#include
#include
#include
#define N 306
#define NEEDLE 135
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #23 from Tamar Christina ---
small standalone reducer:
#include
#include
#include
#define N 306
#define NEEDLE 136
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n", x[NEEDLE]);
return x[NEEDLE];
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #22 from Tamar Christina ---
(In reply to Richard Biener from comment #21)
> loop->nb_iterations_upper_bound exactly is an upper bound on the number of
> latch executions, so maybe I'm missing the point here. When we update it it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #21 from Richard Biener ---
loop->nb_iterations_upper_bound exactly is an upper bound on the number of
latch executions, so maybe I'm missing the point here. When we update it it as
well has to reflect an upper bound on that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #20 from Tamar Christina ---
[local count: 21718864]:
...
_54 = (short unsigned int) bits_106;
_26 = _54 >> 9;
_88 = _139 + 7;
_89 = _88 & 7;
_111 = _26 + 10;
[local count: 181308616]:
# i_66 = PHI
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #19 from Tamar Christina ---
Ok, removing all the noise shows that this is the same issue as I saw before.
The code out of the vectorizer is correct, but cunroll does a dodgee unrolling.
-fdisable-tree-cunroll confirms it's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #18 from Tamar Christina ---
Loop that gets miscompiled is the initialization loop:
while (parse_tables_n-- && i < 306)
table[i++] = 0;
and indeed, the compiler seems to also be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #17 from Tamar Christina ---
(In reply to Sam James from comment #16)
> Created attachment 57393 [details]
> test.c
>
> OK, all done now (I figured I'd let cvise finish). No more :)
>
> By the way, this fails on arm64 too (at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Sam James changed:
What|Removed |Added
Attachment #57390|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #15 from Tamar Christina ---
(In reply to Sam James from comment #14)
> Created attachment 57390 [details]
> test.c
>
> I'll try reducing it preprocessed now (couldn't do it before as checking w/
> clang as well in the reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Sam James changed:
What|Removed |Added
Attachment #57384|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Sam James changed:
What|Removed |Added
Attachment #57379|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #12 from Sam James ---
Created attachment 57379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57379=edit
test.c
Here's an initial stab at a standalone testcase. I'm going to try reduce it
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #11 from Richard Biener ---
(In reply to Tamar Christina from comment #10)
> (In reply to Richard Biener from comment #9)
> > Another bug in the dependence checking code is
> >
> > if (dr_may_alias_p (dr_ref,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #10 from Tamar Christina ---
(In reply to Richard Biener from comment #9)
> Another bug in the dependence checking code is
>
> if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
>
> which will end up using TBAA -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #9 from Richard Biener ---
Another bug in the dependence checking code is
if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
which will end up using TBAA - dr_may_alias_p doesn't think you are ever
going to move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #8 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #7 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #6 from Tamar Christina ---
The reason for the miscompile popping up is this change from the previous patch
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 109d4ce5192..df3eab2e8d5 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #0)
> /home/sam/data/libarchive/libarchive-3.7.2/libarchive/test/
> test_read_format_rar5.c:106: bytes_read != fsize
> bytes_read=-30 (0xffe2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #4 from Tamar Christina ---
Narrowed down the change part that caused the failure, but it should have been
correct to do. So looking into why the change caused the failure. Please
hold..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-03
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #1 from Sam James ---
Not made much progress yet.
libarchive/archive_read_support_format_rar5.c.o is the miscompiled obj, using
#pragma GCC optimize ("O0") on parse_tables fixes things.
24 matches
Mail list logo
