Gary Funck writes:
> We recently ran into this 'as' bug running
> tests with the GCC (4.5 pre-cursor) "trunk" compiler
> on an x86_64 target running Ubuntu 8.04:
> http://sourceware.org/bugzilla/show_bug.cgi?id=10255
> (the bug was marked fixed in June 2009).
>
> The issue was noted in this GCC P
On 01/15/2010 05:42 PM, Robert Grimm wrote:
Greetings all,
I'm working with the powerpc-eabi architecture (specifically, the MPC563
processor). For some time we have been using GCC 3.4.3 and I noticed gcc
generating code that makes use of the floating point registers for 64-bit
integer loads
Greetings all,
I'm working with the powerpc-eabi architecture (specifically, the MPC563
processor). For some time we have been using GCC 3.4.3 and I noticed gcc
generating code that makes use of the floating point registers for 64-bit
integer loads and whatnot... which we don't want it to do a
We recently ran into this 'as' bug running
tests with the GCC (4.5 pre-cursor) "trunk" compiler
on an x86_64 target running Ubuntu 8.04:
http://sourceware.org/bugzilla/show_bug.cgi?id=10255
(the bug was marked fixed in June 2009).
The issue was noted in this GCC PR:
http://gcc.gnu.org/bugzilla/sho
cirrus75 writes:
> I could not understand exactly how to specify instruction size to gcc (so it
> can really optimize the code size when -Os is used).
>
> I would like to inform gcc that if some registers are used for certain
> operations, the instruction will be smaller. For example, an add wh
Hi,
I could not understand exactly how to specify instruction size to gcc (so it
can really optimize the code size when -Os is used).
I would like to inform gcc that if some registers are used for certain
operations, the instruction will be smaller. For example, an add which
destination regi
This is the beta release of binutils 2.20.51.0.5 for Linux, which is
based on binutils 2010 0115 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
2010/1/15 Ian Lance Taylor :
> There are many places where that insn could be generated, so it's
> pretty hard to answer your question as asked.
>
> I recommend setting a breakpoint on make_insn_raw if
> cfun->emit->x_cur_insn_uid == 479. Then a backtrace will show you
> what is creating the insn.
Paolo Carlini wrote:
> On 01/15/2010 05:05 PM, Adam Butcher wrote:
If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\
or CTRL-4) instead of SIGINT?
>>> Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes
>>> corrupted beyond anything 'svn cleanup'
On 01/15/2010 05:05 PM, Adam Butcher wrote:
>>> If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or
>>> CTRL-4) instead of SIGINT?
>>>
>> Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes
>> corrupted beyond anything 'svn cleanup' could repair in one
On Fri, January 15, 2010 3:57 pm, Dave Korn wrote:
> Adam Butcher wrote:
>> On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>>> I mean, why a well designed application should refuse to listen to ctrl-c
>>> when something goes wrong? Why every time for some reason it gets stuck,
>>> I have to
Paul Koning wrote:
>> Paolo Carlini wrote:
>> guaranteeing atomicity/preventing corrupted sandbox?
>
> Not just crude, but wrong. You can't get atomicity (or rather,
> transactional integrity) that way, because blocking ^C doesn't block
> SIGKILL, or panics, or power failures, or (in the case of
Adam Butcher wrote:
> On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>> I mean, why a well designed application should refuse to listen to ctrl-c
>> when something goes wrong? Why every time for some reason it gets stuck,
>> I have to kill it from another shell? That's definitely annoying.
> Paolo Carlini wrote:
> > Hi,
> >
> > I mean, why a well designed application should refuse to listen to
> > ctrl-c when something goes wrong? Why every time for some reason it
> gets
> > stuck, I have to kill it from another shell? That's definitely
> annoying.
> >
> > Paolo.
> ...
> Looks like
Paolo Carlini wrote:
> Hi,
>
> I mean, why a well designed application should refuse to listen to
> ctrl-c when something goes wrong? Why every time for some reason it gets
> stuck, I have to kill it from another shell? That's definitely annoying.
>
> Paolo.
Hmm, this is also Debian bug #50222
On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>
> I mean, why a well designed application should refuse to listen to
> ctrl-c when something goes wrong? Why every time for some reason it gets
> stuck, I have to kill it from another shell? That's definitely annoying.
>
If you're on a posix-
Hi,
I mean, why a well designed application should refuse to listen to
ctrl-c when something goes wrong? Why every time for some reason it gets
stuck, I have to kill it from another shell? That's definitely annoying.
Paolo.
On Fri, Jan 15, 2010 at 8:56 AM, Paulo De Oliveira Cantante De Matos
wrote:
>
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> Behalf Of Andrew Pinski
>> Sent: 14 January 2010 17:08
>> To: Paulo J. Matos
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Sibc
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Andrew Pinski
> Sent: 14 January 2010 17:08
> To: Paulo J. Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Sibcall on recursive functions
>
>
> Because it is not really sibcalled but rather turne
19 matches
Mail list logo
