https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #21 from David Binderman ---
(In reply to rsand...@gcc.gnu.org from comment #20)
> Thanks for the testing.
You are welcome.
> Could you open new PRs for the new backtraces?
Done. Most of them were already mentioned in bugzilla,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #20 from rsandifo at gcc dot gnu.org
---
> Most of these are array bounds. I'll find out stack backtraces for
> each of these.
Thanks for the testing. Could you open new PRs for the new backtraces?
These are really independent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #19 from David Binderman ---
For ./c-c++-common/Warray-bounds-2.c
../../trunk/gcc/poly-int.h:1107:5: runtime error: signed integer overflow: 8 *
-9223372036854775796 cannot be represented in type 'long int'
#0 0x2ddd587 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #18 from David Binderman ---
(In reply to rsand...@gcc.gnu.org from comment #14)
> Yeah, the patch I committed fixed two separate instances of
> undefined overflow, but I think there are a lot more left.
Excellent results so far,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #17 from Martin Liška ---
> Could you open separate PRs for the new tests? We could perhaps
> have a meta-bug for ubsan failures too, if we don't already.
I did so: PR90213 and PR90214.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #16 from Vittorio Zecca ---
On Saturday afternoon I had a power failure that probably damaged my disk,
so I cannot help you now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #15 from Martin Liška ---
>
> Could you open separate PRs for the new tests? We could perhaps
> have a meta-bug for ubsan failures too, if we don't already.
We do have one ('ubsan' alias name):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #14 from rsandifo at gcc dot gnu.org
---
Yeah, the patch I committed fixed two separate instances of
undefined overflow, but I think there are a lot more left.
The testsuite results with bootstrap-ubsan show a lot of failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #13 from Martin Liška ---
Can you please use:
$ export UBSAN_OPTIONS="print_stacktrace=1"
so that we see the complete back-trace? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #12 from Vittorio Zecca ---
Here are two more test cases with undefined behaviour in poly-int.h
Must be compiled with nonzero optimization
cat gccerr73.c
// must be compiled with nonzero optimization
//
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #11 from Vittorio Zecca ---
After applying your fixes I still have overflow compiling the following
// Must be compiled with nonzero optimization
//../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer
overflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #10 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Apr 18 12:30:36 2019
New Revision: 270443
URL: https://gcc.gnu.org/viewcvs?rev=270443=gcc=rev
Log:
Fix UB in int_const_binop
When testing PR 85164, the baseline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Apr 18 12:29:56 2019
New Revision: 270442
URL: https://gcc.gnu.org/viewcvs?rev=270442=gcc=rev
Log:
Fix two ubsan failures (PR85164)
Two fixes for UB when handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> (In reply to rsand...@gcc.gnu.org from comment #6)
>
> Thanks for handling this.
>
> > > template
> > > inline POLY_BINARY_COEFF (Ca, Ca)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #7 from Jakub Jelinek ---
(In reply to rsand...@gcc.gnu.org from comment #6)
Thanks for handling this.
> > template
> > inline POLY_BINARY_COEFF (Ca, Ca)
> > known_alignment (const poly_int_pod )
> > {
> > typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #4 from Martin Liška ---
For the 2 test-cases we reach these backtraces:
$ ./xgcc -B. test.c -O1
../../gcc/poly-int.h:1941:12: runtime error: negation of -9223372036854775808
cannot be represented in type 'long int'; cast to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #3 from David Binderman ---
I'd be happy to help out with any testing of any speculative patch
for this bug.
I am surprised that more than 64 bits of precision are required.
Would a data type like float or double do the job ? Less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
David Binderman changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
21 matches
Mail list logo
