2014-09-23 20:10 GMT+04:00 Jeff Law :
> On 09/23/14 10:03, Jakub Jelinek wrote:
>>
>> On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
>>>
>>> On 09/23/14 08:34, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
>
> use fixed EBX at least
Hi,
This patch is something I was playing around with assistance of Ian Taylor.
It seems I need bit more help though :)
It adds support for direct output of SLIM LTO files to the compiler binary.
It works as proof of concept, but there are two key parts missing
1) extension of libiberty's simple
On Tue, 23 Sep 2014, Uros Bizjak wrote:
> Hello!
>
> Joseph, is there any support for underflow control in soft-fp library?
> >From a private correspondence with FX about implementing gfortran IEEE
> support for extended modes, soft-fp that implements 128bit support on
> x86 could read this setti
On 09/23/14 08:34, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
info generation. If we have such option then gcc.target/i386/pic-1.c and
For debug info, it seems you are already hand
On 09/23/14 10:03, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
On 09/23/14 08:34, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
info generation. If
Hello!
Joseph, is there any support for underflow control in soft-fp library?
>From a private correspondence with FX about implementing gfortran IEEE
support for extended modes, soft-fp that implements 128bit support on
x86 could read this setting from FPU control registers and handle
denormals ac
On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
> On 09/23/14 08:34, Jakub Jelinek wrote:
> >On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
> >>use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
> >>info generation. If we have such option then gcc.tar
Jakub Jelinek writes:
> look at the sizes of .debug_info/.debug_loc sections with/without the
> patch, or use the locstat utility from elfutils
Not actually part of elfutils, but available either here:
https://github.com/pmachata/dwlocstat
... or packaged in Fedora.
Thanks,
PM
On 09/23/14 08:23, Uros Bizjak wrote:
On Tue, Sep 23, 2014 at 3:54 PM, Ilya Enkovich wrote:
Here is a patch which combines results of my and Vladimir's work on EBX
enabling.
It works OK for SPEC2000 and SPEC2006 on -Ofast + LTO. It passes bootstrap but
there are few new failures in make ch
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
> use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
> info generation. If we have such option then gcc.target/i386/pic-1.c and
For debug info, it seems you are already handling this in
delegitimize_address target
On Tue, Sep 23, 2014 at 3:54 PM, Ilya Enkovich wrote:
> Here is a patch which combines results of my and Vladimir's work on EBX
> enabling.
>
> It works OK for SPEC2000 and SPEC2006 on -Ofast + LTO. It passes bootstrap
> but there are few new failures in make check.
>
> gcc.target/i386/pic-1.c
On 03 Sep 16:19, Vladimir Makarov wrote:
> On 2014-08-29 2:47 AM, Ilya Enkovich wrote:
> >Seems your patch doesn't cover all cases. Attached is a modified
> >patch (with your changes included) and a test where double constant is
> >wrongly rematerialized. I also see in ira dump that there is stil
On Tue, Sep 23, 2014 at 6:49 PM, Richard Biener
wrote:
>
> I suppose doing "m" (*params_ptr) would also work.
>
> Richard.
This one works! Thank you.
Regards,
Bin
On Tue, Sep 23, 2014 at 6:41 PM, Andrew Haley wrote:
>
> And neither are they used by the asm; so you have no right to expect %edx
> to contain anything, and neither have you the right to touch it.
>
> Do this:
>
> asm volatile (
> "pushl %1;"
> "call *%%eax;"
> "add
> The original plan was for Balaji to take on this role; however, his assignment
> within Intel has changed and thus he's not going to have time to work on
> Cilk+ anymore.
>
> Igor Zamyatin has been doing a fair amount of Cilk+ maintenance/bugfixing
> and it might make sense for him to own it in
On Tue, Sep 23, 2014 at 12:41 PM, Andrew Haley wrote:
> On 09/23/2014 10:39 AM, Bin Meng wrote:
>> On Tue, Sep 23, 2014 at 5:11 PM, Bin Meng wrote:
>>>
>>> Sorry I still don't get it. The inline-asm codes are put in the very end
>>> of the test function just before return, so the clobbered regist
On Tue, Sep 23, 2014 at 11:39 AM, Bin Meng wrote:
> On Tue, Sep 23, 2014 at 5:11 PM, Bin Meng wrote:
>>
>> Sorry I still don't get it. The inline-asm codes are put in the very end
>> of the test function just before return, so the clobbered registers are
>> not used by gcc. The %edx gets overwrit
On 09/23/2014 10:39 AM, Bin Meng wrote:
> On Tue, Sep 23, 2014 at 5:11 PM, Bin Meng wrote:
>>
>> Sorry I still don't get it. The inline-asm codes are put in the very end
>> of the test function just before return, so the clobbered registers are
>> not used by gcc.
And neither are they used by the
On Tue, Sep 23, 2014 at 5:11 PM, Bin Meng wrote:
>
> Sorry I still don't get it. The inline-asm codes are put in the very end
> of the test function just before return, so the clobbered registers are
> not used by gcc. The %edx gets overwritten before the inline-asm block.
>
> I just did a modific
On Tue, Sep 23, 2014 at 4:32 PM, Jakub Jelinek wrote:
> You are doing a call in the inline-asm behind compiler's back, and
> some registers are call clobbered in the ABI. So, unless you call a very
> special function written in assembly that doesn't clobber those registers
> (basically, uses a cu
On Tue, Sep 23, 2014 at 04:20:16PM +0800, Bin Meng wrote:
> Hi Richard,
>
> On Tue, Sep 23, 2014 at 4:09 PM, Richard Biener
> wrote:
> > Your asm constraints do not specify that they use %edx.
> >
> > Richard.
> >
>
> Sorry, I don't understand. The %edx is not used by the inline assembly codes.
Hi Richard,
On Tue, Sep 23, 2014 at 4:09 PM, Richard Biener
wrote:
> Your asm constraints do not specify that they use %edx.
>
> Richard.
>
Sorry, I don't understand. The %edx is not used by the inline assembly codes.
The 'mov(%eax),%edx' corresponds to C code:
pcall = (PCALL)(r->a + r->b);
On Tue, Sep 23, 2014 at 9:51 AM, Bin Meng wrote:
> Hi,
>
> I get a piece of code to be compiled by gcc with the combined '-Os
> -mregparm=3' options to generate the x86 32-bit codes, and I found gcc
> created broken codes.
>
> The test codes that can be used to trigger this issue: (save the
> foll
Hi,
I get a piece of code to be compiled by gcc with the combined '-Os
-mregparm=3' options to generate the x86 32-bit codes, and I found gcc
created broken codes.
The test codes that can be used to trigger this issue: (save the
following to test.c.)
typedef struct {
int a;
int
24 matches
Mail list logo
