Robert Stevenson writes:
> I am trying to add some information/instructions into loop statements in
> GCC front-end. For this, in the previous gcc, I have used "add_stmt" to
> insert
> these instructions and they worked fine. When I do it in gcc 4.6 (snapshot
> 2010/12/4) I get "undefine
On Wed, Dec 15, 2010 at 6:27 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote:
>>> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote:
>>>
The initial implementation of my proposal is available on hjl/lto-mixed
branch at
"H.J. Lu" writes:
> On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote:
>> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote:
>>
>>> The initial implementation of my proposal is available on hjl/lto-mixed
>>> branch at
>>>
>>> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
>>
>>
On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote:
> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote:
>
>> The initial implementation of my proposal is available on hjl/lto-mixed
>> branch at
>>
>> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
>
> I don't know how to separate
Hello Everyone,
I am trying to add some information/instructions into loop statements in
GCC front-end. For this, in the previous gcc, I have used "add_stmt" to insert
these instructions and they worked fine. When I do it in gcc 4.6 (snapshot
2010/12/4) I get "undefined references to "add_s
On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote:
> The initial implementation of my proposal is available on hjl/lto-mixed
> branch at
>
> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
I don't know how to separate this idea from the other work on that branch.
I'm concerned that th
I finally found some time to write some documentation for the branch.
I've created http://gcc.gnu.org/wiki/pph with some initial
documentation on the pre-tokenization and pre-parsing work we are
doing on the branch.
The big missing piece is a more detailed design document that Lawrence
will be pos
This is the beta release of binutils 2.21.51.0.3 for Linux, which is
based on binutils 2010 1215 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 am facing a strange behaviour with secondary reload in gcc43.
I have a type of register that can load and store from virtually anything
else, lets call the class CHIP_REGS, meaning it has no need for reload.
However, if I get an input reload for ALL_REGS then I assume the worst
case scen
Jan Hubicka writes:
> The problem is that GCC produce constructors/destructors at various places
> and they all used to be called GLOBAL__I
> and GLOBAL__D. Then in some cases (on targets that don't have global
> ctors/dtors or with LTO and ctor/dtor merging)
> it actually collect them into si
> I don't understand this at all.
>
> I thought you were saying that these are static functions, and that gcc
> gathers them all together into a single global constructor. Are there
> cases where gcc does not gather them together? Why would that be?
At the moment we don't gather when there is o
It is Wed now. Will we see a official release this week ?
--
Dennis
Jan Hubicka writes:
> 2) Do the actual renaming of _GLOBAL__I into something else (fully local
> name like static_ctor.1234 at a time it is being inserted
> into merged ctor.
>
> We can't avoid producing these names early since on target that havecdtors
> we avoid producing merged c
> Jan Hubicka writes:
>
> > The problem is that GCC produce constructors/destructors at various places
> > and they all used to be called GLOBAL__I
> > and GLOBAL__D. Then in some cases (on targets that don't have global
> > ctors/dtors or with LTO and ctor/dtor merging)
> > it actually collec
Jan Hubicka writes:
>> Jan Hubicka writes:
>>
>> > I think bootstrap with C++ or GO is broken for a while on targets not
>> > having ctor support, but now it broke
>> > on targets with ctor support as a result of my patch renaming some of the
>> > ctors from GLOBAL__I into GLOBAL__sub_I.
>>
> Now if this breaks other logic in ld & friends on have_cdtor targets, I guess
> we could
0) return to always inlining on non_have_cdtors targets and hope for the
best :)
> 1) du _sub_I/sub_D mangling only on targets not having ctors/dtors where
> merged constructor is always produced
>
> > Jan Hubicka writes:
> >
> > > I think bootstrap with C++ or GO is broken for a while on targets not
> > > having ctor support, but now it broke
> > > on targets with ctor support as a result of my patch renaming some of the
> > > ctors from GLOBAL__I into GLOBAL__sub_I.
> >
> > I didn't kn
> Jan Hubicka writes:
>
> > I think bootstrap with C++ or GO is broken for a while on targets not
> > having ctor support, but now it broke
> > on targets with ctor support as a result of my patch renaming some of the
> > ctors from GLOBAL__I into GLOBAL__sub_I.
>
> I didn't know you were maki
Jan Hubicka writes:
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on targets with ctor support as a result of my patch renaming some of the
> ctors from GLOBAL__I into GLOBAL__sub_I.
I didn't know you were making that change.
Hi,
I am doing a port in GCC 4.5.1.
The target supports storing immediate values into memory location
represented by a symbolic address. So in the move pattern i have given
constraints to represent this.
(define_insn "movqi_op"
[(set (match_operand:QI 0 "nonimmediate_operand" "=!Q,!Q,d,d,d,d,d,
On Wed, 2010-12-15 at 13:57 +0100, Jan Hubicka wrote:
> Hi,
> the problem is that we special case constructors and avoid random seed on
> them on targets that have global ctors.
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on ta
Hi,
the problem is that we special case constructors and avoid random seed on them
on targets that have global ctors.
I think bootstrap with C++ or GO is broken for a while on targets not having
ctor support, but now it broke
on targets with ctor support as a result of my patch renaming some of t
> -696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711
> 00b6 00011580 2**4
> +696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89
> 00b6
I believe, something broke the trunk tip build recently:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/s
24 matches
Mail list logo
