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 after
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 like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Joshua Green changed:
What|Removed |Added
CC||jvg1981 at aim dot com
--- Comment #17 fr
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
#inc
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 #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.
Than
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 po
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 pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #10 from Richard Biener ---
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 pointer_int_sum they have differing im
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #8 from Jakub Jelinek ---
(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 object, or one past the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #7 from 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 can't produce undefined behavio
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 allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #5 from Jakub Jelinek ---
(In reply to mikulas from comment #4)
> ... and another related problem (try this on 32-bit system):
>
> #include
> #include
>
> int main(void)
> {
> short *a = malloc(0x5000 * sizeof(short));
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
#include
int main(void)
{
short *a = malloc(0x5000 * sizeof(short));
short *b = a + 0x500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
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.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
20 matches
Mail list logo
