Hi Daniel,
> On 09/22/2017 02:18 AM, Rainer Orth wrote:
>> Hi Daniel,
>>
>>> On 09/21/2017 05:18 PM, Daniel Santos wrote:
So libgcc doesn't use a config.in. :(
>>> Scratch that, I forgot that we're using gcc/config.in via auto-host.h.
>>> So I only have to add this to gcc/configure.ac and it
On 09/22/2017 02:18 AM, Rainer Orth wrote:
> Hi Daniel,
>
>> On 09/21/2017 05:18 PM, Daniel Santos wrote:
>>> So libgcc doesn't use a config.in. :(
>> Scratch that, I forgot that we're using gcc/config.in via auto-host.h.
>> So I only have to add this to gcc/configure.ac and it will be available
>
Hi Daniel,
> On 09/21/2017 05:18 PM, Daniel Santos wrote:
>> So libgcc doesn't use a config.in. :(
>
> Scratch that, I forgot that we're using gcc/config.in via auto-host.h.
> So I only have to add this to gcc/configure.ac and it will be available
> for my libgcc header -- this is what I used to
On 09/21/2017 05:18 PM, Daniel Santos wrote:
> So libgcc doesn't use a config.in. :(
Scratch that, I forgot that we're using gcc/config.in via auto-host.h.
So I only have to add this to gcc/configure.ac and it will be available
for my libgcc header -- this is what I used to sniff out support for
On 09/21/2017 11:14 AM, Rainer Orth wrote:
> Hi Daniel,
>
>> On 09/19/2017 01:58 AM, Jakub Jelinek wrote:
>>> What can be done in libgcc is detect in configure whether the assembler
>>> supports AVX, and if not, provide some alternative (e.g. because the insns
>>> are always the same, you could jus
Hi Daniel,
> On 09/19/2017 01:58 AM, Jakub Jelinek wrote:
>> What can be done in libgcc is detect in configure whether the assembler
>> supports AVX, and if not, provide some alternative (e.g. because the insns
>> are always the same, you could just code them as .byte or something similar).
>>
>>
On Thu, Sep 21, 2017 at 3:58 AM, Daniel Santos wrote:
> On 09/19/2017 01:58 AM, Jakub Jelinek wrote:
>> What can be done in libgcc is detect in configure whether the assembler
>> supports AVX, and if not, provide some alternative (e.g. because the insns
>> are always the same, you could just code
On 09/19/2017 01:58 AM, Jakub Jelinek wrote:
> What can be done in libgcc is detect in configure whether the assembler
> supports AVX, and if not, provide some alternative (e.g. because the insns
> are always the same, you could just code them as .byte or something similar).
>
> Say like:
> --- i38
On 09/19/2017 07:13 AM, Rainer Orth wrote:
> Daniel Santos writes:
>
>> On 09/17/2017 10:53 AM, Uros Bizjak wrote:
>>> OK.
>>>
>>> Thanks,
>>> Uros.
>> Thanks. I should have posted this Friday when my tests finished, but
>> I'll be committing with one minor change so tests don't run on m32 or mx32
On 09/19/2017 01:58 AM, Jakub Jelinek wrote:
> On Mon, Sep 18, 2017 at 06:10:29PM -0500, Daniel Santos wrote:
>> Mike, can you take a look at this please?
>>
>> On 09/18/2017 10:17 AM, Dominique d'Humières wrote:
>>> This patch (r252896) breaks bootstrap on x86_64-apple-darwin10 configured
>>> wit
Uros Bizjak writes:
>> However, they do FAIL on 64-bit Solaris/x86:
>>
>> +FAIL: gcc.target/i386/pr82196-1.c (test for excess errors)
>>
>> Excess errors:
>> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr82196-1.c:14:1:
>> error: bp cannot be used in asm here
>>
>> +UNRESOLVED: gcc.
On Tue, Sep 19, 2017 at 2:13 PM, Rainer Orth
wrote:
> Daniel Santos writes:
>
>> On 09/17/2017 10:53 AM, Uros Bizjak wrote:
>>> OK.
>>>
>>> Thanks,
>>> Uros.
>>
>> Thanks. I should have posted this Friday when my tests finished, but
>> I'll be committing with one minor change so tests don't run o
Daniel Santos writes:
> On 09/17/2017 10:53 AM, Uros Bizjak wrote:
>> OK.
>>
>> Thanks,
>> Uros.
>
> Thanks. I should have posted this Friday when my tests finished, but
> I'll be committing with one minor change so tests don't run on m32 or mx32:
>
> --- a/gcc/testsuite/gcc.target/i386/pr82196-1
On Mon, Sep 18, 2017 at 06:10:29PM -0500, Daniel Santos wrote:
> Mike, can you take a look at this please?
>
> On 09/18/2017 10:17 AM, Dominique d'Humières wrote:
> > This patch (r252896) breaks bootstrap on x86_64-apple-darwin10 configured
> > with
> >
> > ../work/configure --prefix=/opt/gcc/gcc
On Tue, Sep 19, 2017 at 1:10 AM, Daniel Santos wrote:
> Mike, can you take a look at this please?
>
> On 09/18/2017 10:17 AM, Dominique d'Humières wrote:
>> This patch (r252896) breaks bootstrap on x86_64-apple-darwin10 configured
>> with
>>
>> ../work/configure --prefix=/opt/gcc/gcc8w
>> --enab
Mike, can you take a look at this please?
On 09/18/2017 10:17 AM, Dominique d'Humières wrote:
> This patch (r252896) breaks bootstrap on x86_64-apple-darwin10 configured with
>
> ../work/configure --prefix=/opt/gcc/gcc8w
> --enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-n
This patch (r252896) breaks bootstrap on x86_64-apple-darwin10 configured with
../work/configure --prefix=/opt/gcc/gcc8w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin
/opt/gcc/build_w/./gcc/xgc
On 09/17/2017 10:53 AM, Uros Bizjak wrote:
> OK.
>
> Thanks,
> Uros.
Thanks. I should have posted this Friday when my tests finished, but
I'll be committing with one minor change so tests don't run on m32 or mx32:
--- a/gcc/testsuite/gcc.target/i386/pr82196-1.c
+++ b/gcc/testsuite/gcc.target/i386
On Thu, Sep 14, 2017 at 6:03 AM, Daniel Santos wrote:
> I made a silly mistake in libgcc by testing the cpp macro __AVX__ to
> determine rather to use movaps or vmovaps in the stubs. This resulted
> in the stubs choice of instruction being decided by the machine flags
> when the compiler was buil
I made a silly mistake in libgcc by testing the cpp macro __AVX__ to
determine rather to use movaps or vmovaps in the stubs. This resulted
in the stubs choice of instruction being decided by the machine flags
when the compiler was built rather than those being supplied at the
command line. This p
20 matches
Mail list logo
