[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>

I'm unsure about this. I _hate_ the extra branches this adds;

13 messages 2014/03/12

[ruby-core:61192] Re: [ruby-trunk - Bug #9507] Ruby 2.1.0 is broken on ARMv5: tried to create Proc object without a block

From: Eric Wong <normalperson@...>
Date: 2014-03-01 19:27:52 UTC
List: ruby-core #61192
rubylang.10.webmeister@spamgourmet.com wrote:
> My config.h for ARMv5 contains both `#define HAVE_LONG_LONG 1` and
> `#define HAVE_UINT64_T 1`, so for all versions of the code it will
> always take the first path. The `unsigned long long` variant as well
> as the `uint64_t` variant seem to be broken on ARMv5, so I decided to
> try the third one (`unsigned long`) by simply removing all other
> alternatives (patch attached). This successfully fixes the problem.

Could be a compiler problem with 64-bit emulation.  Which
compiler/version is this?  Can you try a newer one?
Can you try any other code which uses 64-bit math?

Also, it could be an alignment problem; but I don't see places
where rb_serial_t is not 32-bit aligned...

> I'm not sure why you use the different types in the first place. If it
> works with `unsigned long` (i.e. you do not need more than 32 bits),
> what is the benefit of using `unsigned long long`? If it does bring
> some benefit for other architectures, could you disable its usage at
> least on ARMv5 or check your code whether it makes some assumptions
> about these types that do not hold on ARMv5?

64-bits is needed to avoid overflow on VM state changes.
Otherwise our caches could give false hits and crash.

In This Thread

Prev Next