On 25 janv. 2013, at 18:13, Rainer Müller wrote:
> This could still be okay if the actual CPU support is checked at runtime
> and a fallback code is provided.
Via a CPUID instruction? Could be, but I’m fairly dubious. If it were the case,
why check the CPU type at configure time…
Anyhow, AFAIK
On 2013-01-25 17:20, Vincent Habchi wrote:
> On 25 janv. 2013, at 16:30, Rainer Müller wrote:
>
>> This will still become a problem if we are going to distribute this
>> software as a pre-compiled binary, as the machine running the buildbot
>> might have support for AVX instructions while the end
On 25 janv. 2013, at 16:30, Rainer Müller wrote:
> This will still become a problem if we are going to distribute this
> software as a pre-compiled binary, as the machine running the buildbot
> might have support for AVX instructions while the end-user might not
> have that.
This is already the
On 25 janv. 2013, at 14:50, Michael Dickens wrote:
> Maybe the answer is still found in this thread from a couple years back?
>
> <
> http://lists.macosforge.org/pipermail/macports-dev/2011-October/016335.html
>>
>
> On Oct 3, 2011, at 3:50 PM, vincent habchi wrote:
>> Ok, finally I figured o
Michael:
> Hi Vincent - Thanks for your reply; it seems like that thread from a
> while back said pretty much what you're now saying. So, what I'm trying
> to do is create a configure-time test which first tries to compile a
> "xgetbv" instruction, and if that succeeds then it tries to execute th
On 2013-01-25 16:13, Michael Dickens wrote:
> Hi Vincent - Thanks for your reply; it seems like that thread from a
> while back said pretty much what you're now saying. So, what I'm trying
> to do is create a configure-time test which first tries to compile a
> "xgetbv" instruction, and if that su
Hi Vincent - Thanks for your reply; it seems like that thread from a
while back said pretty much what you're now saying. So, what I'm trying
to do is create a configure-time test which first tries to compile a
"xgetbv" instruction, and if that succeeds then it tries to execute the
binary. If the
On 2013-1-26 01:54 , vincent habchi wrote:
> On 25 janv. 2013, at 15:07, Rainer Müller wrote:
>
>> When compiling the code with gcc-mp-4.7, it calls the assembler
>> /opt/local/bin/as (which is the same or even a newer version than
>> /usr/bin/as),
>
> There is no such file as /opt/local/bin/as.
On 25 janv. 2013, at 15:07, Rainer Müller wrote:
> To make this more clear, a C compiler does not touch the assembler
> instructions in the __asm__() statement. Rather, these are passed down in raw
> form to the assembler.
Thanks Rainer for elaborating. I was in a suburb train and had to be som
On 2013-01-25 14:15, vincent habchi wrote:
>
> On 25 janv. 2013, at 04:02, Michael Dickens wrote:
>
>> but, this code does not compile using MacPorts' gcc 4.7; it errors out
>> with "no such instruction: `xgetbv'". Apple's clang compiles this code
>> without the #if, but it errors out when runni
On Jan 24, 2013, at 10:02 PM, Michael Dickens
wrote:
> I've been told, and a quick internet search ("xgetbv") agrees, that the
> following code snippet should be appropriate to use for GCC >= 4.4:
>
> {{{
> #if __GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 4
> static inline unsigned long lo
On 25 janv. 2013, at 04:02, Michael Dickens wrote:
> but, this code does not compile using MacPorts' gcc 4.7; it errors out
> with "no such instruction: `xgetbv'". Apple's clang compiles this code
> without the #if, but it errors out when running with "Illegal
> instruction: 4". Ditto for MacPo
I'm trying to compile gnuradio using configure.compiler=macports-gcc-4.7
to see if their SIMD detection is working (a component they call VOLK).
VOLK was originally designed for GCC-based compilers, and they are
working on augmenting for CLANG. I've been told, and a quick internet
search ("xgetbv
13 matches
Mail list logo
