public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: ObjC bug on 64-bit architectures?
@ 2001-10-16  8:01 Ulrich Weigand
  0 siblings, 0 replies; 8+ messages in thread
From: Ulrich Weigand @ 2001-10-16  8:01 UTC (permalink / raw)
  To: Stan Shebs; +Cc: gcc, Hartmut Penner

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: ObjC bug on 64-bit architectures?
@ 2001-10-15 16:32 Billinghurst, David (CRTS)
  0 siblings, 0 replies; 8+ messages in thread
From: Billinghurst, David (CRTS) @ 2001-10-15 16:32 UTC (permalink / raw)
  To: 'Ulrich Weigand', gcc; +Cc: Hartmut Penner

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread
* ObjC bug on 64-bit architectures?
@ 2001-10-15  9:14 Ulrich Weigand
  2001-10-15  9:43 ` H . J . Lu
  2001-10-15 17:14 ` Stan Shebs
  0 siblings, 2 replies; 8+ messages in thread
From: Ulrich Weigand @ 2001-10-15  9:14 UTC (permalink / raw)
  To: gcc; +Cc: Hartmut Penner

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2001-10-19 16:01 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-16  8:01 ObjC bug on 64-bit architectures? Ulrich Weigand
  -- strict thread matches above, loose matches on Subject: below --
2001-10-15 16:32 Billinghurst, David (CRTS)
2001-10-15  9:14 Ulrich Weigand
2001-10-15  9:43 ` H . J . Lu
2001-10-15 17:14 ` Stan Shebs
2001-10-16 12:53   ` Richard Henderson
2001-10-19 15:42   ` Toon Moene
2001-10-19 16:01     ` Stan Shebs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).