[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-15 Thread yann at droneaud dot fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #10 from Yann Droneaud --- (In reply to Jakub Jelinek from comment #8) > -fsanitize=undefined with no diagnostics doesn't mean code is UB free. This is a pity, it would have help users do diagnose the issue in their code.

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |INVALID

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #8 from Jakub Jelinek --- -fsanitize=undefined with no diagnostics doesn't mean code is UB free. This testcase is still invalid. Before the first g--;, g == , so g-- will set g to g - sizeof (int). That is UB.

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #7 from Siddhesh Poyarekar --- Thanks, is that from the code in prima[1] or the Red Hat bugzilla report? The latter is undefined as per the above discussion. [1] https://github.com/dk/Prima/issues/78

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread yann at droneaud dot fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #6

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #5 from Siddhesh Poyarekar --- Ack, I had a thinko with unsigned steps[] = {1, 1}; because in that case too n_steps doesn't get decremented, resulting in OOB access. I'm going to look at the original report[1] to see if the test

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #3 from Siddhesh Poyarekar --- Oops, sorry I messed up the reproducer, here's the correct one. The principles don't really change though: unsigned steps[2]; int main(void) { unsigned n_steps = sizeof (steps) / sizeof

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread siddhesh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #2 from Siddhesh Poyarekar --- Yeah, I've been ping-ponging about the validity too, which is why I filed a bug to get some consensus position. I suppose if we don't treat it as a bug, should we try and support it in cases we can by

[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer

2023-01-13 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #1