[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Siddhesh Poyarekar --- Original code also had the same UB, which I've sent a PR to fix: https://github.com/dk/Prima/pull/79
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6 from Yann Droneaud ---
c-reduce comes up with the following reproducer:
#include
typedef struct {
int a;
} b;
typedef struct {
b c[2];
} d;
d e;
int f = 2;
int main() {
b *g;
for (g = e.c; f; g++)
switch (g->a) {
case 0:
memmove(g, g + 1, sizeof(b));
f--;
g--;
}
}
gcc -fsanitize=undefined doesn't catch any issue ...
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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 case
reduction was valid and will close this out as invalid if there's nothing
interesting for the compiler to do there. Thanks!
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
(In reply to Siddhesh Poyarekar from comment #3)
> 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 (unsigned);
>
> for (unsigned *io = steps; 0 < n_steps; io++) {
> if (*io == 0) {
> __builtin_printf ("%zu\n", __builtin_dynamic_object_size (io, 0));
> if (__builtin_dynamic_object_size (io, 0) < sizeof (unsigned))
> __builtin_abort ();
> n_steps--;
> io--;
> }
> }
>
> return 0;
> }
How can this be valid? In the first iteration it already invokes UB, *io == 0,
so it will do n_steps-- (why is it misindented?) and then io--, which is
invalid,
because io == steps and steps - 1 is invalid pointer arithmetics.
If you want to do what you do in the body, then better steps[0] should not be
0...
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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 (unsigned);
for (unsigned *io = steps; 0 < n_steps; io++) {
if (*io == 0) {
__builtin_printf ("%zu\n", __builtin_dynamic_object_size (io, 0));
if (__builtin_dynamic_object_size (io, 0) < sizeof (unsigned))
__builtin_abort ();
n_steps--;
io--;
}
}
return 0;
}
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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 attempting some heuristics, like we'd like to do for invalidated realloc input pointers? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
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 from Jeffrey A. Law --- The compiler will sometimes create pointers outside any object -- the loop optimizers in particular will tend to do that. For the actual memory access, an offset will be applied to get the effective addresss of the memory reference into the proper object. It's also the case that Ada can create these inherently via "virtual origins" IIRC. I'm not sure this qualifies as a bug.
