Bug in x86-64 psABI or in gcc?

Bug in x86-64 psABI or in gcc?

[H.J. Lu]

Hi,


x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:

---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---

However, gcc treats _Bool as char:

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

Given that gcc never zeros the upper 63 bits in register nor
on stack, should we update x86-64 psABI to reflect what gcc
really does?

Thanks.


-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[H. Peter Anvin]

On 12/07/2009 10:33 AM, H.J. Lu wrote:
> Hi,
> 
> 
> x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
> 
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
> 
> However, gcc treats _Bool as char:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
> 
> Given that gcc never zeros the upper 63 bits in register nor
> on stack, should we update x86-64 psABI to reflect what gcc
> really does?
> 

Keep in mind it's not just gcc but at least also icc, the Solaris
compiler, and the Qlogic compiler... possibly others.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Bug in x86-64 psABI or in gcc?

[H. Peter Anvin]

On 12/07/2009 10:33 AM, H.J. Lu wrote:
> Hi,
> 
> 
> x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
> 
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
> 
> However, gcc treats _Bool as char:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
> 
> Given that gcc never zeros the upper 63 bits in register nor
> on stack, should we update x86-64 psABI to reflect what gcc
> really does?
> 

Another thing to check is to see if there are failure scenarios where
gcc 3.4.6 expects a fully zeroed register (it produces them, I don't
know if it expects to consume them that way, too.)

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Mon, 7 Dec 2009, H.J. Lu wrote:

> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---

That was the outcome of a discussion in 2005/2006.  We put this language 
in because at that time all compilers booleanized at the caller.  
GCC also makes use of this guarantee (although limited to the 
8 bit):

_Bool bartmp;
void foo(_Bool bar)
{
  bartmp = bar;
}

will generate

foo:
        movb    %dil, bartmp(%rip)
        ret

I do see value in limiting the zeroing to bits 1-31 when passed on stack.
But we'd need agreement on the discuss@ list, which for some reason didn't 
seem to get any of these mails.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Tue, Dec 8, 2009 at 8:50 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 7 Dec 2009, H.J. Lu wrote:
>
>> ---
>> When a value of type _Bool is passed in a register or on the stack,
>> the upper 63 bits of the eightbyte shall be zero.
>> ---
>
> That was the outcome of a discussion in 2005/2006.  We put this language
> in because at that time all compilers booleanized at the caller.
> GCC also makes use of this guarantee (although limited to the
> 8 bit):
>
> _Bool bartmp;
> void foo(_Bool bar)
> {
>  bartmp = bar;
> }
>
> will generate
>
> foo:
>        movb    %dil, bartmp(%rip)
>        ret
>
> I do see value in limiting the zeroing to bits 1-31 when passed on stack.
> But we'd need agreement on the discuss@ list, which for some reason didn't
> seem to get any of these mails.
>

Both icc and gcc generate:

[hjl@gnu-26 pr42324]$ cat b4.c
extern unsigned int bartmp;

void foo(_Bool bar)
{
 bartmp = bar;
}
[hjl@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b4.c -S
[hjl@gnu-26 pr42324]$ cat b4.s
	.file	"b4.c"
	.text
	.p2align 4,,15
.globl foo
	.type	foo, @function
foo:
.LFB2:
	movzbl	%dil, %edi
	movl	%edi, bartmp(%rip)
	ret

We should just drop

---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---

from psABI. Since _Bool has one byte in size with values of 0 and 1.
Compilers have to clear upper 7 bits in one byte.


-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[H. Peter Anvin]

On 12/08/2009 10:24 AM, H.J. Lu wrote:
> 
> We should just drop
> 
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
> 
> from psABI. Since _Bool has one byte in size with values of 0 and 1.
> Compilers have to clear upper 7 bits in one byte.
> 

What about the Solaris compiler?  It's probably the only other
significant user of the x86-64 ABI (the Qlogic and LLVM compilers I
presume will follow gcc.)

	-hpa

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Tue, 8 Dec 2009, H.J. Lu wrote:

> Both icc and gcc generate:
> 
> [hjl@gnu-26 pr42324]$ cat b4.c
> extern unsigned int bartmp;
> 
> void foo(_Bool bar)
> {
>  bartmp = bar;
> }
> [hjl@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b4.c -S
> [hjl@gnu-26 pr42324]$ cat b4.s
> 	.file	"b4.c"
> 	.text
> 	.p2align 4,,15
> .globl foo
> 	.type	foo, @function
> foo:
> .LFB2:
> 	movzbl	%dil, %edi
> 	movl	%edi, bartmp(%rip)
> 	ret

Yes, so they expect the upper bits (at least 1-7) cleared on the caller 
side.  And if they do that, somebody needs to make this guarantee which 
only the ABI can.

> We should just drop
> 
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---

If anything we can only change it to say something less strict ...

> from psABI. Since _Bool has one byte in size with values of 0 and 1.
> Compilers have to clear upper 7 bits in one byte.

... because this part can only be guaranteed by the ABI.  Without the 
above language a compiler would be free to implement any non-zero byte as 
true for parameter passing without violating the ABI.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 2:04 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 8 Dec 2009, H.J. Lu wrote:
>
>> Both icc and gcc generate:
>>
>> [hjl@gnu-26 pr42324]$ cat b4.c
>> extern unsigned int bartmp;
>>
>> void foo(_Bool bar)
>> {
>>  bartmp = bar;
>> }
>> [hjl@gnu-26 pr42324]$ /usr/gcc-4.4/bin/gcc -O2 b4.c -S
>> [hjl@gnu-26 pr42324]$ cat b4.s
>>       .file   "b4.c"
>>       .text
>>       .p2align 4,,15
>> .globl foo
>>       .type   foo, @function
>> foo:
>> .LFB2:
>>       movzbl  %dil, %edi
>>       movl    %edi, bartmp(%rip)
>>       ret
>
> Yes, so they expect the upper bits (at least 1-7) cleared on the caller
> side.  And if they do that, somebody needs to make this guarantee which
> only the ABI can.
>
>> We should just drop
>>
>> ---
>> When a value of type _Bool is passed in a register or on the stack,
>> the upper 63 bits of the eightbyte shall be zero.
>> ---
>
> If anything we can only change it to say something less strict ...
>
>> from psABI. Since _Bool has one byte in size with values of 0 and 1.
>> Compilers have to clear upper 7 bits in one byte.
>
> ... because this part can only be guaranteed by the ABI.  Without the
> above language a compiler would be free to implement any non-zero byte as
> true for parameter passing without violating the ABI.
>

Aren't bits in the _Bool byte of"bar" specified by the psABI or the C
language standard already?

---
extern unsigned int bartmp;
extern _Bool bar;

void foo()
{
 bartmp = bar;
}
---

Why should the _Bool byte in "void foo(_Bool bar)"  be any different?

-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[H. Peter Anvin]

On 12/09/2009 06:44 AM, H.J. Lu wrote:
> 
> Aren't bits in the _Bool byte of"bar" specified by the psABI or the C
> language standard already?
> 

The psABI, yes.  They are obviously not defined by the C language standard.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1008 bytes --]

Hi,

On Wed, 9 Dec 2009, H.J. Lu wrote:

> > ... because this part can only be guaranteed by the ABI.  Without the
> > above language a compiler would be free to implement any non-zero byte as
> > true for parameter passing without violating the ABI.
> >
> 
> Aren't bits in the _Bool byte of"bar" specified by the psABI

Right now they are specified in the psABI, you suggested to remove that 
specification.

> or the C language standard already?

Nope.  If you don't look at the specific value of a _Bool (by e.g. storing 
it in some global variable) the C standard doesn't say anything about what 
this value must be, except that the true/false behaviour has to be 
preserved.  As-if rules and so on.  The psABI needs to be more specific.

> ---
> extern unsigned int bartmp;
> extern _Bool bar;
> 
> void foo()
> {
>  bartmp = bar;
> }
> ---
> 
> Why should the _Bool byte in "void foo(_Bool bar)"  be any different?

Because it can be different when the psABI doesn't say otherwise.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[H. Peter Anvin]

On 12/09/2009 06:56 AM, Michael Matz wrote:
>>
>> Aren't bits in the _Bool byte of"bar" specified by the psABI
> 
> Right now they are specified in the psABI, you suggested to remove that 
> specification.
> 

The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
(and higher bits as don't cares, the same way a char is passed), as
opposed to the current text which requires <63:1> == 0 when passed as
registers or on the stack (and <7:1> == 0 when stored in a memory
object.)  Furthermore, the current psABI text is inconsistent for
arguments are return values; this is a bug in the wordsmithing of the
text rather than intentional, if I remember the original discussions
correctly.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 6:56 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > ... because this part can only be guaranteed by the ABI.  Without the
>> > above language a compiler would be free to implement any non-zero byte as
>> > true for parameter passing without violating the ABI.
>> >
>>
>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>
> Right now they are specified in the psABI, you suggested to remove that
> specification.
>
>> or the C language standard already?
>
> Nope.  If you don't look at the specific value of a _Bool (by e.g. storing
> it in some global variable) the C standard doesn't say anything about what
> this value must be, except that the true/false behaviour has to be
> preserved.  As-if rules and so on.  The psABI needs to be more specific.
>
>> ---
>> extern unsigned int bartmp;
>> extern _Bool bar;
>>
>> void foo()
>> {
>>  bartmp = bar;
>> }
>> ---
>>
>> Why should the _Bool byte in "void foo(_Bool bar)"  be any different?
>
> Because it can be different when the psABI doesn't say otherwise.
>

The psABI doesn't say anything about the _Bool return value.  Can compiler
use a different byte pattern for _Bool return byte?

-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 444 bytes --]

Hi,

On Wed, 9 Dec 2009, H.J. Lu wrote:

> >> Why should the _Bool byte in "void foo(_Bool bar)"  be any different?
> >
> > Because it can be different when the psABI doesn't say otherwise.
> >
> 
> The psABI doesn't say anything about the _Bool return value.

That's a bug in the psABI.  We probably implicitely thought the return 
case is included in the sentence talking about passing arguments.  This 
needs to be fixed.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[Andrew Haley]

H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> Right now they are specified in the psABI, you suggested to remove that 
>> specification.
>>
> 
> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
> (and higher bits as don't cares, the same way a char is passed), as
> opposed to the current text which requires <63:1> == 0 when passed as
> registers or on the stack (and <7:1> == 0 when stored in a memory
> object.)  Furthermore, the current psABI text is inconsistent for
> arguments are return values; this is a bug in the wordsmithing of the
> text rather than intentional, if I remember the original discussions
> correctly.

Surely Postel's Law applies:

  Be conservative in what you do; be liberal in what you accept from others.

So, return values should be zero-extended to the full word, but we shouldn't
assume that parameters will be.

Andrew.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Wed, 9 Dec 2009, H. Peter Anvin wrote:

> On 12/09/2009 06:56 AM, Michael Matz wrote:
> >>
> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
> > 
> > Right now they are specified in the psABI, you suggested to remove that 
> > specification.
> > 
> 
> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
> (and higher bits as don't cares, the same way a char is passed),

Or bits <31:1> .  But he also repeatedly suggests to remove the whole 
sentence about the bit clearing.  That's what I'm opposing.  I'm not 
against limiting the bit range that must be zero.

> opposed to the current text which requires <63:1> == 0 when passed as
> registers or on the stack (and <7:1> == 0 when stored in a memory
> object.)  Furthermore, the current psABI text is inconsistent for
> arguments are return values; this is a bug in the wordsmithing of the
> text rather than intentional, if I remember the original discussions
> correctly.

Right, I remember the same.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 7:10 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H. Peter Anvin wrote:
>
>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>> >>
>> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> >
>> > Right now they are specified in the psABI, you suggested to remove that
>> > specification.
>> >
>>
>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>> (and higher bits as don't cares, the same way a char is passed),
>
> Or bits <31:1> .  But he also repeatedly suggests to remove the whole
> sentence about the bit clearing.  That's what I'm opposing.  I'm not
> against limiting the bit range that must be zero.

I just want _Bool to have the same specification for parameter pass
and function return, ideally memory object.

>> opposed to the current text which requires <63:1> == 0 when passed as
>> registers or on the stack (and <7:1> == 0 when stored in a memory
>> object.)  Furthermore, the current psABI text is inconsistent for
>> arguments are return values; this is a bug in the wordsmithing of the
>> text rather than intentional, if I remember the original discussions
>> correctly.
>
> Right, I remember the same.
>

Then fix the psABI.

Thanks.


-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley <aph@redhat.com> wrote:
> H. Peter Anvin wrote:
>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>> Right now they are specified in the psABI, you suggested to remove that
>>> specification.
>>>
>>
>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>> (and higher bits as don't cares, the same way a char is passed), as
>> opposed to the current text which requires <63:1> == 0 when passed as
>> registers or on the stack (and <7:1> == 0 when stored in a memory
>> object.)  Furthermore, the current psABI text is inconsistent for
>> arguments are return values; this is a bug in the wordsmithing of the
>> text rather than intentional, if I remember the original discussions
>> correctly.
>
> Surely Postel's Law applies:
>
>  Be conservative in what you do; be liberal in what you accept from others.
>
> So, return values should be zero-extended to the full word, but we shouldn't
> assume that parameters will be.
>

I guess you missed the discussion around July 2007:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324#c5


-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[Dave Korn]

Andrew Haley wrote:

> Surely Postel's Law applies:

  Surely Postel's Law must have been repealed by now? :-)

     cheers,
      DaveK

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 7:15 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Wed, 9 Dec 2009, H. Peter Anvin wrote:
>>
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> >>
>>> >> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>> >
>>> > Right now they are specified in the psABI, you suggested to remove that
>>> > specification.
>>> >
>>>
>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>> (and higher bits as don't cares, the same way a char is passed),
>>
>> Or bits <31:1> .  But he also repeatedly suggests to remove the whole
>> sentence about the bit clearing.  That's what I'm opposing.  I'm not
>> against limiting the bit range that must be zero.
>
> I just want _Bool to have the same specification for parameter pass
> and function return, ideally memory object.
>
>>> opposed to the current text which requires <63:1> == 0 when passed as
>>> registers or on the stack (and <7:1> == 0 when stored in a memory
>>> object.)  Furthermore, the current psABI text is inconsistent for
>>> arguments are return values; this is a bug in the wordsmithing of the
>>> text rather than intentional, if I remember the original discussions
>>> correctly.
>>
>> Right, I remember the same.
>>
>
> Then fix the psABI.
>

Don't we need to specify passing and returning char, short and int since
they are smaller than the integer class, which is eightbytes?

-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Wed, 9 Dec 2009, Andrew Haley wrote:

> > The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
> > (and higher bits as don't cares, the same way a char is passed), as
> > opposed to the current text which requires <63:1> == 0 when passed as
> > registers or on the stack (and <7:1> == 0 when stored in a memory
> > object.)  Furthermore, the current psABI text is inconsistent for
> > arguments are return values; this is a bug in the wordsmithing of the
> > text rather than intentional, if I remember the original discussions
> > correctly.
> 
> Surely Postel's Law applies:
> 
>   Be conservative in what you do; be liberal in what you accept from others.
> 
> So, return values should be zero-extended to the full word, but we shouldn't
> assume that parameters will be.

We also try to be efficient (meaning not doing booleanization at producer 
_and_ consumer side), that's why we define an psABI at all.  So, while 
generally a good principle, it shouldn't be applied blindly :)


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Wed, 9 Dec 2009, H.J. Lu wrote:

> > Then fix the psABI.
> 
> Don't we need to specify passing and returning char, short and int since 
> they are smaller than the integer class, which is eightbytes?

Since the mapping from domain to bitpatterns is bijective, we don't have 
to (although if one wants to be extra anal one could say that the psABI 
expects the identity mapping).  We have to say something about _Bool only 
because this mapping is not necessarily bijective.  And in doing so we 
obviously were a bit too aggressive in specifying the bit range.

So, IMO we have two sensible proposals:
(a) specify that bits <7:1> must be zero
(b) specify that bits <31:1> must be zero

In both, the value would be in bit 0, other bits are don't 
care/unspecified.  Both cases would do the conversion at the producer 
side, when necessary, i.e. before the call, or before the return.

I have no opinion which one would be better.  Defining only the low 8 bit 
might introduce partial register stalls or needless movzbl's.  Defining 
the low 32 bit might require needless movzbl in other places.

There's a case to be made for (a), because that one specifies exactly the 
bits that would be stored also in memory.

I'd like to hear at least from the Solaris guys what they think about the 
whole thing.


Ciao,
Michael.

Re: Bug in x86-64 psABI or in gcc?

[Andrew Haley]

H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley <aph@redhat.com> wrote:
>> H. Peter Anvin wrote:
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>>> Right now they are specified in the psABI, you suggested to remove that
>>>> specification.
>>>>
>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>> (and higher bits as don't cares, the same way a char is passed), as
>>> opposed to the current text which requires <63:1> == 0 when passed as
>>> registers or on the stack (and <7:1> == 0 when stored in a memory
>>> object.)  Furthermore, the current psABI text is inconsistent for
>>> arguments are return values; this is a bug in the wordsmithing of the
>>> text rather than intentional, if I remember the original discussions
>>> correctly.
>> Surely Postel's Law applies:
>>
>>  Be conservative in what you do; be liberal in what you accept from others.
>>
>> So, return values should be zero-extended to the full word, but we shouldn't
>> assume that parameters will be.
> 
> I guess you missed the discussion around July 2007:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324#c5

No, I didn't miss it.  We have had discussions about this before.
I still think Postel's Law applies, particularly as we have an
explicit guarantee in the psABI that

---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---

Andrew.

Re: Bug in x86-64 psABI or in gcc?

[Andrew Haley]

Hi,

Michael Matz wrote:

> On Wed, 9 Dec 2009, Andrew Haley wrote:
> 
>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>> (and higher bits as don't cares, the same way a char is passed), as
>>> opposed to the current text which requires <63:1> == 0 when passed as
>>> registers or on the stack (and <7:1> == 0 when stored in a memory
>>> object.)  Furthermore, the current psABI text is inconsistent for
>>> arguments are return values; this is a bug in the wordsmithing of the
>>> text rather than intentional, if I remember the original discussions
>>> correctly.
>> Surely Postel's Law applies:
>>
>>   Be conservative in what you do; be liberal in what you accept from others.
>>
>> So, return values should be zero-extended to the full word, but we shouldn't
>> assume that parameters will be.
> 
> We also try to be efficient (meaning not doing booleanization at producer 
> _and_ consumer side), that's why we define an psABI at all.  So, while 
> generally a good principle, it shouldn't be applied blindly :)

Yeah, but maximizing efficiency, while generally a good principle, shouldn't
be applied blindly either.  :-)

AIUI, the proposal on the table is to change the psABI in a way that removes a
guarantee, i.e. in the opposite direction from the robustness principle.  So,
at least in theory, we might break things.  And, I remember from a good deal
of libffi hacking that I had to do last time, this is a nonzero risk.

Andrew.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley <aph@redhat.com> wrote:
> H.J. Lu wrote:
>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley <aph@redhat.com> wrote:
>>> H. Peter Anvin wrote:
>>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>>>> Right now they are specified in the psABI, you suggested to remove that
>>>>> specification.
>>>>>
>>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>>> (and higher bits as don't cares, the same way a char is passed), as
>>>> opposed to the current text which requires <63:1> == 0 when passed as
>>>> registers or on the stack (and <7:1> == 0 when stored in a memory
>>>> object.)  Furthermore, the current psABI text is inconsistent for
>>>> arguments are return values; this is a bug in the wordsmithing of the
>>>> text rather than intentional, if I remember the original discussions
>>>> correctly.
>>> Surely Postel's Law applies:
>>>
>>>  Be conservative in what you do; be liberal in what you accept from others.
>>>
>>> So, return values should be zero-extended to the full word, but we shouldn't
>>> assume that parameters will be.
>>
>> I guess you missed the discussion around July 2007:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324#c5
>
> No, I didn't miss it.  We have had discussions about this before.
> I still think Postel's Law applies, particularly as we have an
> explicit guarantee in the psABI that
>
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---

Please read it again. It is only for parameter passing, not for
function return. Since gcc 4.3, we return _Bool in %AL.


-- 
H.J.

Re: Bug in x86-64 psABI or in gcc?

[Andrew Haley]

H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley <aph@redhat.com> wrote:
>> H.J. Lu wrote:
>>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> H. Peter Anvin wrote:
>>>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>>>>> Right now they are specified in the psABI, you suggested to remove that
>>>>>> specification.
>>>>>>
>>>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>>>> (and higher bits as don't cares, the same way a char is passed), as
>>>>> opposed to the current text which requires <63:1> == 0 when passed as
>>>>> registers or on the stack (and <7:1> == 0 when stored in a memory
>>>>> object.)  Furthermore, the current psABI text is inconsistent for
>>>>> arguments are return values; this is a bug in the wordsmithing of the
>>>>> text rather than intentional, if I remember the original discussions
>>>>> correctly.
>>>> Surely Postel's Law applies:
>>>>
>>>>  Be conservative in what you do; be liberal in what you accept from others.
>>>>
>>>> So, return values should be zero-extended to the full word, but we shouldn't
>>>> assume that parameters will be.
>>> I guess you missed the discussion around July 2007:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324#c5
>>
>> No, I didn't miss it.  We have had discussions about this before.
>> I still think Postel's Law applies, particularly as we have an
>> explicit guarantee in the psABI that
>>
>> ---
>> When a value of type _Bool is passed in a register or on the stack,
>> the upper 63 bits of the eightbyte shall be zero.
>> ---
> 
> Please read it again. It is only for parameter passing, not for
> function return. Since gcc 4.3, we return _Bool in %AL.

Yes, I know that too.  Why does the fact that this is only for parameter
passing make any difference?

Andrew.

Re: Bug in x86-64 psABI or in gcc?

[H.J. Lu]

On Wed, Dec 9, 2009 at 7:49 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 9 Dec 2009, H.J. Lu wrote:
>
>> > Then fix the psABI.
>>
>> Don't we need to specify passing and returning char, short and int since
>> they are smaller than the integer class, which is eightbytes?
>
> Since the mapping from domain to bitpatterns is bijective, we don't have
> to (although if one wants to be extra anal one could say that the psABI
> expects the identity mapping).  We have to say something about _Bool only
> because this mapping is not necessarily bijective.  And in doing so we
> obviously were a bit too aggressive in specifying the bit range.
>
> So, IMO we have two sensible proposals:
> (a) specify that bits <7:1> must be zero
> (b) specify that bits <31:1> must be zero
>
> In both, the value would be in bit 0, other bits are don't
> care/unspecified.  Both cases would do the conversion at the producer
> side, when necessary, i.e. before the call, or before the return.
>
> I have no opinion which one would be better.  Defining only the low 8 bit
> might introduce partial register stalls or needless movzbl's.  Defining
> the low 32 bit might require needless movzbl in other places.
>
> There's a case to be made for (a), because that one specifies exactly the
> bits that would be stored also in memory.
>
> I'd like to hear at least from the Solaris guys what they think about the
> whole thing.

I uploaded sources and object files generated by gcc 4.4, icc 11.1
and Sun Studio 12 Update 1 at -O to:

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

If we go with (a), no changes are needed for gcc, icc and sun studio.
All existing object files are OK.

If we go with (b), gcc 4.3 and 4.4 are broken in function return. Object
files generated by gcc 4.3 and 4.4 aren't compatible with object files
which assuming bits 1-31 in _Bool return are zero.

I think (a) is the safest option.


-- 
H.J.

Re: [discuss] Bug in x86-64 psABI or in gcc?

[Michael Matz]

Hi,

On Wed, 9 Dec 2009, H.J. Lu wrote:

> > So, IMO we have two sensible proposals:
> > (a) specify that bits <7:1> must be zero
> > (b) specify that bits <31:1> must be zero
> 
> I uploaded sources and object files generated by gcc 4.4, icc 11.1
> and Sun Studio 12 Update 1 at -O to:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
> 
> If we go with (a), no changes are needed for gcc, icc and sun studio.
> All existing object files are OK.
> 
> If we go with (b), gcc 4.3 and 4.4 are broken in function return. Object
> files generated by gcc 4.3 and 4.4 aren't compatible with object files
> which assuming bits 1-31 in _Bool return are zero.
> 
> I think (a) is the safest option.

The ABI now contains this:

------------------------
When a value of type \code{_Bool} is returned or passed in a register or
on the stack, bit 0 contains the truth value and bits 1 to 7 shall be
zero.
------------------------


Ciao,
Michael.