Bug 13421 - IA32 bigmem pointer subtraction and –ftrapv option causes unjustified program abort
Summary: IA32 bigmem pointer subtraction and –ftrapv option causes unjustified program...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-17 15:29 UTC by Vik Heyndrickx
Modified: 2005-12-24 20:42 UTC (History)
1 user (show)

See Also:
Host: gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-24 20:42:43


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vik Heyndrickx 2003-12-17 15:29:30 UTC
kernel-2.4.22-1.2115.nptl, glibc-2.3.2-101.1
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)

Circumstances: “-ftrapv” is a gcc compiler option used to detect signed integer 
overflow conditions, and as such is frequently used to debug programs. This 
flag is by default disabled.
On IA32 these days adressible memory for a process can be larger than 2^31 
octets. It is possible for a memory block whose lower bound address is less 
than 2^31 en whose upper bound address is larger than 2^31, to be assigned. 
Subtracting these two addresses is a normal operation to determine the size of 
that block. It appears however that when “-ftrapv” is used to compile a 
program, execution of this program is aborted when subtracting these pointers. 
In my opinion this should not happen, because there is nothing illegal about.

Example of failing program test.c (it looks "manufactured", but is short, the 
real program I encountered this problem with is less manufactured, I got the 
addresses from malloc(), and that program was long):

<cut>
long signed diff = 0;

void setdiff (unsigned char *a, unsigned char *b) {
        diff = b - a;
}

int main (void) {
        unsigned char *a, *b;

        a = (unsigned char*)0x7FFFF000u;
        b = (unsigned char*)0x80000001u;
        setdiff (a, b);
        return 0;
}
</cut>

Compiler command line:
gcc -ftrapv test.c

execution of the resulting program a.out:
Aborted
Comment 1 Andrew Pinski 2003-12-17 16:43:52 UTC
Pointers are signed on i386. Use a cast to unsigned to get the effect you want.
Comment 2 Falk Hueffner 2003-12-17 16:58:17 UTC
I don't understand why you consider this invalid. The code looks OK to me,
assuming the pointers were really gained from malloc. Could you elaborate?
Comment 3 Andrew Pinski 2003-12-17 17:01:46 UTC
Pointers are signed so the subtraction is also signed which causes this problem.
If you want to use the difference without the abort from -ftrapv then do (unsgined)(a)-
(unsigned)(b).
Comment 4 Vik Heyndrickx 2003-12-17 17:03:06 UTC
That is a (working) workaround, not a solution IMHO.
The workaround you propose means that basically any subtraction of any pair of 
pointer need to be casted to unsigned because in theory any data structure may 
end up near the middle of the address space. Otherwise anyone risks random 
aborts.

Even more, if I would want to write a portable program, I cannot do it using 
your proposed workaround because in general there is no such thing as an 
integer data type that can hold a pointer.
Comment 5 Andrew Pinski 2003-12-17 17:16:27 UTC
But pointers are singed so you have to, sorry but that is the only way for this to work.
Comment 6 Vik Heyndrickx 2003-12-17 17:28:10 UTC
Is there any need for having pointers to be signed?

Is there any need for -ftrapv checks to be done on pointers even when they are 
signed?

Could the GCC documentation to be changed, so that it mentions that if -ftrapv 
is used, a perfectly legal program may and will crash unexpectedly and randomly 
on signed pointer platforms...
Comment 7 Andrew Pinski 2003-12-17 17:53:11 UTC
Pointers signness are determined by the ABI.
Here are the list of targets that are unsigned:
./alpha/vms.h:#define POINTERS_EXTEND_UNSIGNED 0
./ia64/hpux.h:#define POINTERS_EXTEND_UNSIGNED -1
./mips/mips.h:#define POINTERS_EXTEND_UNSIGNED 0
./s390/s390.h:#define POINTERS_EXTEND_UNSIGNED -1
./sparc/sparc.h:#define POINTERS_EXTEND_UNSIGNED 1
There are not many.
-ftrapv is done for all signed "addition, subtraction, multiplication operations".
So this is a request for documentation about -ftrapv and pointer arightatic.
Comment 8 falk.hueffner 2003-12-17 18:05:57 UTC
Subject: Re:  IA32 bigmem pointer subtraction and ftrapv option causes unjustified program abort

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-17 17:53 -------
> Pointers signness are determined by the ABI.
> Here are the list of targets that are unsigned:
> ./alpha/vms.h:#define POINTERS_EXTEND_UNSIGNED 0
> ./ia64/hpux.h:#define POINTERS_EXTEND_UNSIGNED -1
> ./mips/mips.h:#define POINTERS_EXTEND_UNSIGNED 0
> ./s390/s390.h:#define POINTERS_EXTEND_UNSIGNED -1
> ./sparc/sparc.h:#define POINTERS_EXTEND_UNSIGNED 1
> There are not many.
> -ftrapv is done for all signed "addition, subtraction,
> multiplication operations".  So this is a request for documentation
> about -ftrapv and pointer arightatic.

Pointer signedness is an implementation detail which should not matter
to conforming programs IMHO. Also I would suppose it is feasible to
generate unsigned difference/division for pointer difference on any
platform.

Roger, you fixed bug 1823 which is related. Do you have any opinion on
this?

Comment 9 Zack Weinberg 2003-12-17 18:21:58 UTC
1) Indeed, this subtraction operation should work fine whether or not pointers
are unsigned, and whether or not -ftrapv is in use.  This is not a documentation
bug.

2) POINTERS_EXTEND_UNSIGNED does not mean what you think it means.  From the manual:

  `POINTERS_EXTEND_UNSIGNED'
     A C expression whose value is greater than zero if pointers that
     need to be extended from being `POINTER_SIZE' bits wide to `Pmode'
     are to be zero-extended and zero if they are to be sign-extended.
     If the value is less then zero then there must be an "ptr_extend"
     instruction that extends a pointer from `POINTER_SIZE' to `Pmode'.

     You need not define this macro if the `POINTER_SIZE' is equal to
     the width of `Pmode'.

In particular, this *only* affects extension of pointers from POINTER_SIZE to
Pmode.  It says *nothing* about whether address arithmetic should be treated as
signed.  I don't think we even have a way of talking about that.
Comment 10 Wolfgang Bangerth 2003-12-18 10:39:36 UTC
Just as a sidenote: the integer type that can hold pointers is, at 
least in C++, ptrdiff_t. Casting to this type should get you where 
you want. 
 
W. 
Comment 11 Vik Heyndrickx 2003-12-18 12:21:01 UTC
(In reply to comment #10)
> Just as a sidenote: the integer type that can hold pointers is, at 
> least in C++, ptrdiff_t. Casting to this type should get you where 
> you want. 

No, it won't. ptrdiff_t exists also in C by the way. The problem is not the 
result of the subtraction but the subtraction itself. 
In essence the problem is the signedness of pointers. Later on, I realizes that 
when p is a pointer, and q is set to e.g. p + 2, that q < p for some values of 
p (e.g. (void*)0x7FFFFFFFu) on IA32. Signedness and an addressible flat memory 
space larger than 2^31 are not compatible.
Comment 12 Wolfgang Bangerth 2003-12-18 13:11:13 UTC
Well, if prtdiff_t doesn't work, I would say that this is a bug in gcc. 
That's also what Zack says in his first point. 
 
W. 
Comment 13 Vik Heyndrickx 2003-12-19 10:23:24 UTC
(In reply to comment #11)
> Later on, I realizes that when p is a pointer, and q is set to 
> e.g. p + 2, that q < p for some values of p 
> (e.g. (void*)0x7FFFFFFFu) on IA32. Signedness and an addressible
> flat memory space larger than 2^31 are not compatible.

To my big surprise I found out today that pointer on IA32 are treated as 
unsigneds. At least when comparing pointers. The IA32 asm code for comparing 
unsigneds and pointers is the same. It differs for signeds.
Comment 14 eggert 2004-04-06 05:13:01 UTC
A point of clarification: even if pointers are changed to be consistently
unsigned internally (which seems to be the right thing to do, if pointer
comparison is unsigned), GCC must still check for overflow when subtracting
pointers. For example, suppose we have the 2 GiB array "a" successfully
allocated by "char *a = malloc (1u<<31);". Then the expression "(a + (1u<<31)) -
a" is of type ptrdiff_t, which is a signed 32-bit integer that cannot represent
(1u<<31). So this expression must generate a trap with -ftrapv, regardless of
whether pointers are unsigned internally.