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

["rogerio at rilhas dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #38 from rogerio at rilhas dot com  2010-08-13 14:47 -------
(In reply to comment #36)
> > > If you include real segmentation
> > > like on 80286, where there's no linear relationship between effective
> > > address and segment+offset, subtraction would have been prohibitively
> > > expensive to implement anyway.
> > What you don't know is that when you subtracted far pointers the compiler
> > generated the code to change seg16:ofs16 into abs20.
> What in the words "real segmentation like on 286, where there's no linear
> relationship between effective address and segment+offset" was unclear to
> you to expect that abs20==seg16*16+ofs16?  The "prohibitive expensive"
> referred to the necessary lookup of the base in the LDT/GDT that would have
> been required for every far pointer subtraction.

>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 before adding it to the 16-bit
offset (16·segment + offset), therefore producing a 20-bit external (or
effective or physical) address from the 32-bit segment:offset pair."

So there you go: the relation between effective abs20 address and seg16:ofs16
pair. And it is a linear relation: abs20=K*seg+ofs establishes a linear
relation. Check your algebra, and check x86 operation before saying "random
stuff".

Can you guess how tricky it is for a compiler to get an effective abs20 address
out of a seg:ofs pair?

abs20=seg*16+ofs (voilá! ...magic!!)

What are you dreaming about LDT/GDT? Do you think you need any of that to get
an abs20 from a seg16:ofs16 pair? Or maybe you think that a far qualifier would
noke the compiler carry seg16 and ofs16 everywhere it went? You just made that
stuff up again. Michael Michael Michael: what did I tell you about making stuff
up? You don't need to prove to anyone that you are creative, will all know that
by now.

... and if Wikipedia is not good enough for you then you can learn about
segmentation and how to compute effective addresses in many places. All will
teach you what Wikipedia shows. I would teach you if you paid me. No, scratch
that: I woudn't, so I'll just leave you alone on this one.


> > > And you still wouldn't get around the size limitation of ptrdiff_t that
> > > was 16bit.
> > What the hell are you talking about????? I personally disassembled code in
> > the late 80's to see how the compiler implemented 32-bit arithmetic on a
> > 286. It did, and it did it well. You weren't able to go beyond 16 bits in
> > the 80's?
> Did I say that?  Let's see: "size limitation of ptrdiff_t that was 16bit".
> Nope.  I didn't.  The point being that if ptrdiff_t is only 16 bit, then
> no matter how fantastically capable the compiler was in emitting 32bit
> arithmetic, the result of subtracting to char pointers pointing more than
> 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t.

The code I used to do was somthing like "long dif=ptr2-ptr1" (long was most
often 32-bit back then). Why the hell did you bring "ptrdiff_t" to the
conversation? I didn't get it, honestly. But if you brought it was was surely
to show me that there was no point in doing 20-bit arithmetic because I would
not be able to fit that result anywhere, right? Maybe not, you lost me with the
whole "ptrdiff_t" that you decided to bring into the conversation.


> > No, not me, I don't want to write nonsense on the web,
> Maybe you don't necessarily want to.  But ... , well, there we are.


Yup. You have still to make one valid claim, and I've been easily shooting you
down everytime. And I back it up, isn't that an amazing concept? You should try
it sometime.


> > I prefer to be clear headed. One never knows when stuff one wrote on the
> > net will come back and bite one in the ass!!
> I'm not sure you realize just how true that is.  But keep going, you're
> by far one of the best trolls I've seen in GCC land.  Much better than
> Pizarro.

... is troll code for "guy who doesn't forgive any false claims and repeatedly
shoots down and squashes people who do that repeatedly like a mean son of a
<insert_repulsive_animal_here>" that he is?

In that case thanks! :-)


-- 


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