Hi!
I didn't find any precedent of the following before, so this can be a start for
discussion.
Options are known to be different between compilers and achieve options
compatibility is somewhat complex because of this. GCC can be taken as a
reference point, but since other comilers still can (and
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
You may have failed to consider that unwind.h is installed and can be
#include'd by any program that is built with GCC. Renaming the
installed file will break an unknown number of existing programs.
Ian
No I considered that but I think that num
On 15 April 2014 12:45, Douglas B Rupp wrote:
> No I considered that but I think that number will be very small. Will you
> concede, in hindsight, that it would be better had the name been chosen to
> be more unique?
No argument from me there, but the same applies to VxWorks, who have
now chosen t
AFAIK GCC's unwind.h installed into GCC's private directory, e. g.
/usr/lib/gcc/x86_64-pc-solaris2.11/4.8/include/unwind.h
Is there any real problem?
On Tue, Apr 15, 2014 at 01:03:42PM +0100, Jonathan Wakely wrote:
> On 15 April 2014 12:45, Douglas B Rupp wrote:
> > No I considered that but I think that number will be very small. Will you
> > concede, in hindsight, that it would be better had the name been chosen to
> > be more unique?
>
> No a
On 15 April 2014 13:08, Игорь Пашев wrote:
> AFAIK GCC's unwind.h installed into GCC's private directory, e. g.
> /usr/lib/gcc/x86_64-pc-solaris2.11/4.8/include/unwind.h
>
> Is there any real problem?
Which header do you get if you say #include ?
Which header did you intend to include?
On Sat, Apr 12, 2014 at 12:53 AM, Hannes Frederic Sowa
wrote:
> Hi!
>
> On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
>> For a "quick" GCC implementation of the builtins you could expand
>> them to a open-coded sequence during gimplification. But due to
>> the issues pointed out
If any of the authors of this section are interested in dramatically improving
it,
I volunteer to be a user testing subject.
We use this information to maintain a driver for ld that allows specification
of initialization order of all .o files, including those from libraries.
On 15 April 2014 22:13, Dave Yost wrote:
> If any of the authors of this section are interested in dramatically
> improving it,
> I volunteer to be a user testing subject.
>
> We use this information to maintain a driver for ld that allows specification
> of initialization order of all .o files,
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>
>> You may have failed to consider that unwind.h is installed and can be
>> #include'd by any program that is built with GCC. Renaming the
>> installed file will break an unknown number of
For small micros such as MSP430 & friends and many of the Renasis
MCUs,
some of which only have 2K or ram on board, this could be a real
issue.
Although I reproduced the same behaviour on i386 using a stock
compiler,
I was wondering if there was something missing in my port that
prevents
spill
I've got a small test case there the ira pass produces this ...
(insn 35 38 36 5 (set (reg/v:SI 29 [orig:17 _b ] [17])
(reg/v:SI 17 [ _b ])) 48 {*ldsi}
(expr_list:REG_DEAD (reg/v:SI 17 [ _b ])
(nil)))
and the LRA processes it as follows ...
Spilling non-eliminable h
12 matches
Mail list logo
