https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #20 from Joshua Green ---
> "But if we don't know which pointer is greater, it gets more complicated:
> ..."
>
> I'm not sure that this is true. For types that are larger than 1 byte, it
> seems that one can do the subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #19 from Marc Glisse ---
This seems fixed in gcc-8, no?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #18 from joseph at codesourcery dot com ---
On Tue, 21 Aug 2018, jvg1981 at aim dot com wrote:
> intptr_t pVal = ((uintptr_t) p)/(sizeof *p);
> intptr_t qVal = ((uintptr_t) q)/(sizeof *q);
Note that this can be expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Joshua Green changed:
What|Removed |Added
CC||jvg1981 at aim dot com
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #14 from Florian Weimer ---
(In reply to Szabolcs Nagy from comment #13)
> if gcc treats p-q as (ssize_t)p-(ssize_t)q and makes
> optimization decisions based on signed int range then
> that's broken and leads to wrong code gen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #16 from Alexander Cherepanov ---
On 2015-11-23 14:58, rguenth at gcc dot gnu.org wrote:
> Note that in practice it needs exposal of the address constant to trigger the
> bogus optimization.
No. The program:
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Szabolcs Nagy changed:
What|Removed |Added
CC||nszabolcs at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> The problem is that we don't have a POINTER_DIFF_EXPR similar to
> POINTER_PLUS_EXPR, which would take two pointers and return an integer, and
> the FEs emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
To support the standards definition of p1 - p2 we'd need a POINTER_DIFF_EXPR
that also embeds the exact division by the array element size.
Btw, while C and C++ share
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #11 from mikulas at artax dot karlin.mff.cuni.cz ---
Richard Biener: if the middle end tells us that one pointer is greater or equal
than the other pointer, we could do unsigned subtraction and shift.
But if we don't know which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Jakub Jelinek: I know, but the problem happened in perfectly valid program.
Suppose that you do:
char *p = malloc(0x2000); - the allocator allocates the array at
0x7000.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #4 from mikulas at artax dot karlin.mff.cuni.cz ---
... and another related problem (try this on 32-bit system):
#include stdio.h
#include stdlib.h
int main(void)
{
short *a = malloc(0x5000 * sizeof(short));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to mikulas from comment #4)
... and another related problem (try this on 32-bit system):
#include stdio.h
#include stdlib.h
int main(void)
{
short *a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #6 from mikulas at artax dot karlin.mff.cuni.cz ---
you really can't have an object bigger than half of the address space in
C/C++ - where does the standard claim this? If this is true, we should change
malloc so that it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Yes, I consider it a bug in malloc that it produces objects 2GB or more in
size on 32-bit systems (because of the one-past-end address, the largest
size that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to mikulas from comment #6)
Regarding pointer difference, the C standard says this:
When two pointers are subtracted, both shall point to elements of the same
array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #9 from mikulas at artax dot karlin.mff.cuni.cz ---
See what I wrote, any object size bigger than half of address space really
isn't supportable, because then (char *) (P) - (char *) (Q) might not fit into
ptrdiff_t. There is no
20 matches
Mail list logo
