[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters

["matz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #41 from matz at gcc dot gnu dot org  2010-08-13 15:18 -------
You should really adjust your glasses if you want to continue trolling with
the high standards we're used to meanwhile:

> > What in the words "real segmentation like on 286, where there's no linear
> > relationship between effective address and segment+offset"

So, I think it's pretty clear that I'm referring to the 80286, whereas
you cite something ...

> From wikipedia:
> 
> "Rather than concatenating the segment register with the address
> register, as in most processors whose address space exceeded their
> register size, the 8086 shifted the 16-bit segment only 4 bits left

... about the 8086.  To make it very obvious, even to you: 86 vs 286.

As you have so huge experiences with such old processors, I'm sure
you can guess what I meant with "real segmentation" aka protected mode now. 
In case you still can't and because we seem to start using wikipedia to back
up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation .

Now, implement a routine that subtracts two pointer for this memory model.
You'll see that it requires bit-magic on the segment selector,
lookup in the GDT or LDT and finally some 24bit arithmetic to produce
the result.  The arithmetic is of course trivial, the lookup is expensive.
Doing it for every pointer subtract was what I called prohibitive expensive
for a normal pointer subtraction.

That, together with the fact that all
segments are max 2^16 in size, and that it's impossible to map back all
24bit numbers into segmented addresses without generally adding new
entries into the GDT/LDT made it useless to have pointer differences
any larger than 16 bit, not impossible but useless in real compilers.
Therefore the result of such a subtraction isn't always representable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265