This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/67999] Wrong optimization of pointer comparisons
- From: "danielmicay at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 19 Oct 2015 02:30:51 +0000
- Subject: [Bug c/67999] Wrong optimization of pointer comparisons
- Auto-submitted: auto-generated
- References: <bug-67999-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
Daniel Micay <danielmicay at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |danielmicay at gmail dot com
--- Comment #5 from Daniel Micay <danielmicay at gmail dot com> ---
An implementation can have object size limits, but I think it's incorrect if
those limits are not enforced for all standard ways of allocating objects.
Objects larger than PTRDIFF_MAX are forbidden with musl (malloc, mmap and
friends report ENOMEM and it's explicitly undefined to create them in another
way and use them with libc), and it would make a lot of sense for glibc to do
the same thing. I recently landed the same feature in Android's Bionic libc for
mmap.
Since glibc's implementations of standard library functions don't handle
objects larger than PTRDIFF_MAX, this can definitely be considered as a buggy
area in glibc. The typical issue is `end - start` but compilers considering
addition to be undefined in this case isn't surprising either.
FWIW, Clang also treats `ptr + size` with `size > PTRDIFF_MAX` as undefined for
standard C pointer arithmetic because the underlying getelementptr instruction
in LLVM is inherently a signed arithmetic operation. Clang marks standard C
pointer arithmetic operations as "inbounds", which among other things makes use
of the value returned from wrapping into undefined behavior. Last time I
checked, the non-standard GNU C `void *` arithmetic doesn't get tagged as
"inbounds" by Clang, so wrapping is well-defined for that.