> -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
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
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, 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-
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
> 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
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.
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
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
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
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'
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.
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
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
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
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
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
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
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
19 matches
Mail list logo
