Boost logo

Boost :

Subject: Re: [boost] [Predef] Pre-review comments
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-02-25 17:09:15

On 2/22/2012 3:28 AM, Mathias Gaunard wrote:
> On 02/22/2012 07:17 AM, Rene Rivera wrote:
>> On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
>>> My use-cases
>> [...]
>>> - Work-around a bug in the GCC backend
>> Is that with a non-GCC front end?
> The bug in question is in the GCC backend, more precisely in the RTL
> optimization passes.
> I don't really care what frontend is used as long as code eventually
> gets through there.
> In practice, GCC should be the only compiler to use the GCC backend.
> I know that there are compilers though, that use the GCC frontend but
> another backend, such as DragonEgg.
> LLVM doesn't have this bug so I'd rather not add the workaround when
> compiling with DragonEgg.
>>> - Define special versions of functions for x86 both 32- and 64-bit
>>> - Define special versions of functions for x86-64 only
>> I have that same use case. And was partly the impetus for me bringing
>> back this library. I have cross-language binding code, ObjectiveC <==>
>> C++, that needs to make ABI distinctions in these cases.
> But your library does not provide a single macro to test whether I'm on
> x86 regardless of word size.
> I have to do

Technically none of them are detecting word size. They are detecting the
instruction-set, and ABI, for the architecture. Which is the key
distinction for my use case. The subject of detecting the word size is
mostly orthogonal to this.

The key question is whether IA64 and AMD64 should be considered
sub-categories of X86? And if so, what would we name the "traditional"
non-IA64 or AMD64, other than X86?

It's starting to sound to me that people want some "meta-architectures"
defined as opposed to, or perhaps in addition to, the specific

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost list run by bdawes at, gregod at, cpdaniel at, john at