https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #12 from Martin Doucha <mdoucha at suse dot cz> ---
(In reply to Alexander Monakov from comment #7)
> I think your report was misunderstood. Anyway, when EBP is not a frame
> pointer, I think the chances are low that it is derived from ESP. Would
> accurate placement of segment override prefixes be worth the effort compared
> to prefixing all EBP-relative accesses with DS override?
Expanding on my previous comment (#9), EBP should be preferred to address local
arrays and local variables allocated on the stack. Access to these variables
should not have the DS prefix in order to enforce the stack limit. But trying
to trace segment association through function calls that take a pointer and
return another is not worth the effort.
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)&b;
> size_t t1 = (size_t)a;
> return *(int*)(((size_t)&b)+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
I assume that you're trying to associate the value of pointer "a" with the
stack segment (but that should be (&b)+(t1-t) instead). As you've writtend it
with the type cast to size_t before adding and subtracting, GCC should just
drop any segment association because you're adding plain numbers, not doing
actual pointer arithmetic. Without the typecast (i.e. (&b)+(t1-t)), the result
of the pointer arithmetic is undefined according to C standard section 6.5.6
paragraph 8.
