configure for a 'gcc builtins' (non-native) port?

[mhaberler]

http://concurrencykit.org/community.html 8) says:

If you don't want a native port, Concurrency Kit will drop-back to using GCC atomic intrinsics.

how do I achieve that?

It might be useful for us - as a baseline package which works everywhere, maybe just not with stellar performance

[sbahra]

That page is old, I should probably remove it. Right now there is no automatic "GCC" platform. We can add support for configure to do this, let's create a feature issue to track it, happy to discuss specifics there.

Basically, if no first-class platform is detected, we can just fallback and use a build.gcc. The work involved is minimal.

[cognet]

I added a configure option to force the use of the gcc bulitins, even if the platform is known and supported

[sbahra]

Do we fall back to this option if it is detected that the current platform is unsupported?

[mhaberler]

with a notice - ok not sure if "supported" will be a configure-only property, it might need a compile test due to compiler defaults diverging from arch/uname -m output

[cognet]

Right now configure will stop if it doesn't recognize the machine, it can easily be changed, though we should probably require a few informations from the user then, ie the memory model (or shall we default to RMO ?)

[cognet]

There's a few thing we'd have to deal with, too, as showed by the mips thing, such as the generic code assuming it can emit a 64bits CAS when it may not.

[sbahra]

We should default to RMO.

[sbahra]

@cognet Should this ticket be closed out?

[cognet]

Yup it should be fine