https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #32 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:194d0956ef5992d4e453bde3eb5772dc077f610c
commit r14-8838-g194d0956ef5992d4e453bde3eb5772dc077f610c
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Sam James changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #30 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:85094e2aa6dba7908f053046f02dd443e8f65d72
commit r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #29 from Sam James ---
Created attachment 57285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57285&action=edit
testcase w abort
Tweaked https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467#c26 so it can be
used as a testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #28 from Sam James ---
(In reply to Sam James from comment #13)
> this also fixes mpfr + gmp tests, thank you!
just ftr: the mpfr/gmp issue might actually be PR113576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
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=113467
Kacper Słomiński changed:
What|Removed |Added
CC||kacper.slominski72 at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #25 from Tamar Christina ---
So I think probably what's miscompiled is this loop
for (s=string; *s; s +=2 )
I think we currently incorrectly vectorize that. i.e. I think it's the same as
PR113588. I'm finishing testing for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #24 from Sam James ---
just checked trunk too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #23 from Sam James ---
I last tried around r14-8422-gc3de14ba1ba0e7 without that workaround patch
applied and it still failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #22 from Richard Biener ---
Is this fixed meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #21 from Richard Biener ---
(In reply to Tamar Christina from comment #20)
> (In reply to rguent...@suse.de from comment #19)
> > > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org
> > > :
> > >
> > > https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #20 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #19)
> > Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
> >
> > --- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #19 from rguenther at suse dot de ---
> Am 23.01.2024 um 18:06 schrieb tnfchris at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
>
> --- Comment #18 from Tamar Christina ---
> (In reply to Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #18 from Tamar Christina ---
(In reply to Richard Biener from comment #7)
> I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (since
> without early exits we cannot handle a non-empty latch because of correctness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #17 from Sam James ---
it was educational ;)
fwiw, no more miscompilations found yet with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #16 from Richard Biener ---
Also eventually see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364#c9 - a
pending fix for a wrong-code issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #15 from Richard Biener ---
(In reply to Sam James from comment #14)
> I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch,
> 0)->src)' as well given that seems way more sensible and that works too, but
> obviously if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #14 from Sam James ---
I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch, 0)->src)'
as well given that seems way more sensible and that works too, but obviously if
I pick something eager or always true, it's going to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #13 from Sam James ---
if I just cast RHS to basic_block (doubt that's the right thing), then
libgcrypt tests pass!
this also fixes mpfr + gmp tests, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #12 from Sam James ---
/home/sam/git/gcc/gcc/tree-vect-loop.cc: In function ‘edge_def*
vec_init_loop_exit_info(loop*)’:
/home/sam/git/gcc/gcc/tree-vect-loop.cc:1001:35: error: comparison between
distinct pointer types ‘basic_block’ {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #11 from Richard Biener ---
if (candidate && candidate->src != EDGE_PRED (loop->latch, 0))
return NULL;
then ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #10 from Sam James ---
(In reply to Sam James from comment #9)
> Reduced:
(just -O2 -m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #9 from Sam James ---
I get an ICE with that:
```
/tmp/build/./gcc/xgcc -B/tmp/build/./gcc/ -B/tmp/gcc/x86_64-pc-linux-gnu/bin/
-B/tmp/gcc/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/gcc/x86_64-pc-linux-gnu/include -isystem
/tmp/gcc/x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> Does the following fix the issue?
>
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 330c4571c8d..b67ee783002 100644
> --- a/gcc/tree-vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #7 from Richard Biener ---
I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (since
without early exits we cannot handle a non-empty latch because of correctness
issues). I'd very much have preferred to deal wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #6 from Sam James ---
Created attachment 57133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57133&action=edit
mpi-add.o (correct)
Attaching a good version of mpi-add.o too for comparison (built with
r14-6644-g5060825aa78b3d)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #5 from Sam James ---
I also see test failures for mpfr and gmp. I was hoping something else would
turn up without wrapped integers so I could reduce it a bit easier :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #4 from Sam James ---
Created attachment 57131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57131&action=edit
somewhat reduced t-mpi-point.c (not standalone)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #3 from Sam James ---
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #2 from Sam James ---
Created attachment 57130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57130&action=edit
mpi-add.i
gcc -m32 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -O3 -march=znver2 -ggdb3
-fvisibility=hidden -fno-de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #1 from Sam James ---
Created attachment 57129
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57129&action=edit
mpi-add.o (miscompiled)
The bad object is mpi-add.o, specifically _gcry_mpi_add_ui in there (verified
with optimiz
34 matches
Mail list logo
