RE: ObjC bug on 64-bit architectures?

RE: ObjC bug on 64-bit architectures?

[Billinghurst, David (CRTS)]

I can confirm that this is an issue with mips-sgi-irix6.5.  The test passes
with the -n32 ABI and fails with the -64 ABI

		=== objc tests ===


Running target unix
FAIL: objc/execute/formal_protocol-6.m execution,  -O 
FAIL: objc.dg/method-2.m  (test for warnings, line 25)
FAIL: objc.dg/method-2.m  (test for warnings, line 25)

		=== objc Summary for unix ===

# of expected passes		203
# of unexpected failures	3

Running target unix/-mabi=64
FAIL: objc/execute/bycopy-3.m execution,  -O 
FAIL: objc/execute/formal_protocol-5.m execution,  -O 
FAIL: objc/execute/formal_protocol-6.m execution,  -O 
FAIL: objc.dg/method-2.m  (test for warnings, line 25)
FAIL: objc.dg/method-2.m  (test for warnings, line 25)

		=== objc Summary for unix/-mabi=64 ===

# of expected passes		201
# of unexpected failures	5


-----Original Message-----
From: Ulrich Weigand [ mailto:Ulrich.Weigand@de.ibm.com ]
Sent: Tuesday, 16 October 2001 2:14 
To: gcc@gcc.gnu.org
Cc: Hartmut Penner
Subject: ObjC bug on 64-bit architectures?


Hello,

I'm trying to track down an Objective C testsuite failure on 64-bit
s390x.  However, the problem doesn't appear to be s390x specific from
what I can see; it looks to me like this bug should appear on every
big-endian 64-bit platform with a 32-bit 'int' type.

Re: ObjC bug on 64-bit architectures?

[Stan Shebs]

Toon Moene wrote:
> 
> Stan Shebs wrote:
> 
> > I'll take a look at it.  I would have expected to see more 64-bit
> > problems actually, since ObjC doesn't get much exercise on the
> > 64-bit targets, but I'm not going to complain. :-)
> 
> Well, that's where *you* could make a difference !
> 
> I would certainly want to buy a 64-bit, big-endian G5-powered Titanic
> notebook if Apple deemed itself worthy of producing one ...

"No comment."

:-)

Stan

Re: ObjC bug on 64-bit architectures?

[Toon Moene]

Stan Shebs wrote:

> I'll take a look at it.  I would have expected to see more 64-bit
> problems actually, since ObjC doesn't get much exercise on the
> 64-bit targets, but I'm not going to complain. :-)

Well, that's where *you* could make a difference !

I would certainly want to buy a 64-bit, big-endian G5-powered Titanic
notebook if Apple deemed itself worthy of producing one ...

A 64-bit big-endian system would surely add to my g77/libf2c bug-hunting
capabilities :-)

"An apple a day keeps the doctor away"

:-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: ObjC bug on 64-bit architectures?

[Richard Henderson]

On Mon, Oct 15, 2001 at 05:11:42PM -0700, Stan Shebs wrote:
> I'll take a look at it.  I would have expected to see more 64-bit
> problems actually, since ObjC doesn't get much exercise on the
> 64-bit targets, but I'm not going to complain. :-)

64-bit little-endian tends to "happen to work" much more often than
big-endian.  It's one of the reasons why I've always believed that
Little is the One True Endian.  ;-)

Anyway, the best solution to this problem is to create proper record
types, create proper var_decls, and call the data output routines in
final.c and varasm.c.  Instead of what we do at the moment, which is 
to emit each data element by hand.


r~

Re: ObjC bug on 64-bit architectures?

[Ulrich Weigand]

Stan Shebs wrote:

>Ulrich Weigand wrote:
>>
>> Hello,
>>
>> I'm trying to track down an Objective C testsuite failure on 64-bit
>> s390x.  However, the problem doesn't appear to be s390x specific from
>> what I can see; it looks to me like this bug should appear on every
>> big-endian 64-bit platform with a 32-bit 'int' type.
>>
>> [...]
>>
>> Could someone familiar with the objc frontend have a look at this?
>
>I'll take a look at it.

Thanks.

>I would have expected to see more 64-bit
>problems actually, since ObjC doesn't get much exercise on the
>64-bit targets, but I'm not going to complain. :-)

I've got a second testcase failure (formal_protocol-5.m), but this
appears to be caused by the very same problem.  Except for those two
cases, the testsuite passes on 64-bit (on 31-bit all test cases pass).


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: ObjC bug on 64-bit architectures?

[Stan Shebs]

Ulrich Weigand wrote:
> 
> Hello,
> 
> I'm trying to track down an Objective C testsuite failure on 64-bit
> s390x.  However, the problem doesn't appear to be s390x specific from
> what I can see; it looks to me like this bug should appear on every
> big-endian 64-bit platform with a 32-bit 'int' type.
> 
> [...]
> 
> Could someone familiar with the objc frontend have a look at this?

I'll take a look at it.  I would have expected to see more 64-bit
problems actually, since ObjC doesn't get much exercise on the
64-bit targets, but I'm not going to complain. :-)

Stan

Re: ObjC bug on 64-bit architectures?

[H . J . Lu]

On Mon, Oct 15, 2001 at 06:14:00PM +0200, Ulrich Weigand wrote:
> 
> This assembly appears to be generated by the objc frontend routine
> generate_protocol_list (in the file gcc/objc/objc-act.c).  Unfortunately,
> my understanding of frontend code is rather limited, but it looks like that
> routine is indeed doing a type cast from the integer constant that
> specifies
> the count to some pointer type.  This looks like a bug to me, but I'm not
> sure how to fix it ...
> 

The assembly output directly from the objc frontend is very likely to
be broken. I have seen another one related to size for ELF symbols.


H.J.

ObjC bug on 64-bit architectures?

[Ulrich Weigand]

Hello,

I'm trying to track down an Objective C testsuite failure on 64-bit
s390x.  However, the problem doesn't appear to be s390x specific from
what I can see; it looks to me like this bug should appear on every
big-endian 64-bit platform with a 32-bit 'int' type.

What happens is that the testcase (bycopy-3.m) crashes in main because
a class_pointer of an objc_protocol is not correctly initialized.

This is turn happens because the constructor __objc_init_protocols gets
called with an incorrect struct objc_protocol_list having a count field
of 0 (instead of 1), and hence does not initialize the protocol.

The objc_protocol_list is generated by the objc frontend; the problem
appears to be caused by a type mismatch.  The definition of the structure
objc_protocol_list says (from the file libobjc/objc/objc-api.h):

struct objc_protocol_list {
  struct objc_protocol_list *next;
  int count;
  Protocol *list[1];
};

However, the compiler generates this instance:

        .align 8
        .type   _OBJC_CLASS_PROTOCOLS_MyObject,@object
        .size   _OBJC_CLASS_PROTOCOLS_MyObject,24
_OBJC_CLASS_PROTOCOLS_MyObject:
        .quad   0
        .quad   1
        .quad   _OBJC_PROTOCOL_MyProtocol

The '.quad 1' is incorrect, because 'int' is a 32-bit data type; because
our platform is big-endian, this causes the 'count' field to be read as 0.

This assembly appears to be generated by the objc frontend routine
generate_protocol_list (in the file gcc/objc/objc-act.c).  Unfortunately,
my understanding of frontend code is rather limited, but it looks like that
routine is indeed doing a type cast from the integer constant that
specifies
the count to some pointer type.  This looks like a bug to me, but I'm not
sure how to fix it ...

Could someone familiar with the objc frontend have a look at this?

Thanks,
Ulrich

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com