On Wed, Jun 24, 2009 at 5:35 PM, Richard Henderson wrote:
> Have a quick look at the implementation of invert_jump, and both
> questions are quickly answered.
Heh, well, all those functions in jump.c also really confuse me --
probably because I've never really understood how all the functions to
On Mon, Jun 22, 2009 at 3:19 PM, Dave
Korn wrote:
> Joe Buck wrote:
>
>> As a general rule there is a performance cost for making iterators
>> on a data structure safe with respect to modifications of that data
>> structure. I'm not in a position to say what the right solution is
>> in this case,
2009/6/23 Ian Lance Taylor :
> Paolo Bonzini writes:
>
>> I don't think this warning can report anything that -Wuninitialized
>> cannot report, so it should go in -Wc++-compat only.
>
> For the record, it can, as in when compiling this case without
> optimization. This is not a strong example by
Dave Hudson wrote:
I would have hoped that having done the analysis early on that the
register allocator would try to allocate from the preferred register
class rather than the cover class but it seems that doesn't happen?
So you're saying that the register preferences look reasonable, but in
Joe Buck wrote:
As a general rule there is a performance cost for making iterators
on a data structure safe with respect to modifications of that data
structure.
Absolutely true.
I'm not in a position to say what the right solution is
in this case, but passes that iterate over bitmaps withou
田晓南 wrote:
> Hello, guys:
> The porting is really a difficult and huge job. So many things I
> don't know or miss result in countless bugs.
>
Definitely true. Though it gets easier the 2nd, 3rd, 4th, time around :-)
>
> Here I encounter some unrecognizable RTL (R0 to R15 are
daniel tian wrote:
>
> it will be called in GO_IF_LEGITIMATE_ADDRESS, and
> LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL
> has gone.
>
I would _strongly_ recommend you initially develop your port without
defining LEGITIMIZE_RELOAD_ADDRESS. Let reload work in the way it was
On Thu, Jun 25, 2009 at 8:11 PM, Manuel
López-Ibáñez wrote:
> 2009/6/23 Ian Lance Taylor :
>> Paolo Bonzini writes:
>>
>>> I don't think this warning can report anything that -Wuninitialized
>>> cannot report, so it should go in -Wc++-compat only.
>>
>> For the record, it can, as in when compiling
2009/6/25 Richard Guenther :
> On Thu, Jun 25, 2009 at 8:11 PM, Manuel
> López-Ibáñez wrote:
>> 2009/6/23 Ian Lance Taylor :
>>> Paolo Bonzini writes:
>>>
I don't think this warning can report anything that -Wuninitialized
cannot report, so it should go in -Wc++-compat only.
>>>
>>> For
Ian Lance Taylor wrote:
daniel tian writes:
Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted from file *.
I am pleased to report that if you configure gcc with
--enable-build-with-cxx, which causes the core compiler to be built
using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
completes.
I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other
daniel tian wrote:
PS: there are 16 general registers in my RISC chip, from R0 to R15.
R14, and R15 are used for FP,SP. R0 register is special.
Every large immediate, larger than 512, must be moved into R0
register, which means that R0 is the only register to load large
immediate.
This is a thorn
On Thu, Jun 25, 2009 at 10:32 PM, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage peop
daniel tian wrote:
You mean before LEGITIMIZE_RELOAD_ADDRESS, cc1 must generate the
correct RTL code, regardless of whether efficient or not.
The compiler should work with or without defining
LEGITIMIZE_RELOAD_ADDRESS. It's often difficult to write a correct
LEGITIMIZE_RELOAD_ADDRESS with
On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage pe
(now sending to gcc@ instead of gcc-help@, as suggested)
I have narrowed it down to this reduced commandline (the time is there
just to show that it may take a while, but this particular issue doesn't
cause a hang):
m...@hargett-755:~/src/gcc-obj/prev-gcc$ time
/home/matt/src/gcc-obj/./prev
On Thu, Jun 25, 2009 at 11:50 PM, Laurent GUERBY wrote:
> On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
>> I am pleased to report that if you configure gcc with
>> --enable-build-with-cxx, which causes the core compiler to be built
>> using a C++ compiler, a bootstrap on x86_64-unknown
On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> * Test starting the bootstrap with earlier versions of the compiler to
> see which C++ compiler version is required, and document that.
I think the right approach is not documenting observations like that, but
investigating the causes of failures
Richard Guenther writes:
>> I guess this has to do with reserved word conflict on "new":
>>
>> <<
>> tree
>> substitute_in_type (tree t, tree f, tree r)
>> {
>> tree new;
>>
>> Do you have some way to deal with this?
>
> Use a non-reserved identifier. I guess on trunk Ada doesn't build
> w
Jeff Law wrote:
> My biggest concern would be catching all the exit paths from the
> gazillion iterators we use and making sure they all reset the readonly
> flag. Ick...
Heh. GCC-in-CXX would solve that for us :) or we could implement
try...finally clauses
cheers,
DaveK
> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compi
On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>
> > * Test starting the bootstrap with earlier versions of the compiler to
> > see which C++ compiler version is required, and document that.
>
> I think the right approach is not d
Laurent GUERBY writes:
> Wanting to test Ada on the branch, after checkout I did on x86_64-linux:
>
> ../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
> --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
> --with-gmp=/opt/cfarm/gmp-4.2.4/ --prefix=/n/16/gu
Snapshot gcc-4.5-20090625 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090625/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> But not terribly uncommon.
>
> Do you need to synthesize large constants? ie, what code would you generate
> to load the value 0x12345 into a register?
>
> If you need to synthesize large constants, do you need any additional
> scratch registers, or can you do so using just r0?
>
Only do using R
>
> The compiler should work with or without defining LEGITIMIZE_RELOAD_ADDRESS.
> It's often difficult to write a correct LEGITIMIZE_RELOAD_ADDRESS without
> knowing the internals of how reload works. Therefore, I strongly recommend
> first writing the port without LEGITIMIZE_RELOAD_ADDRESS --
On Thu, Jun 25, 2009 at 5:47 PM, Joe Buck wrote:
> On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
>> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>>
>> > * Test starting the bootstrap with earlier versions of the compiler to
>> > see which C++ compiler version is required, and d
27 matches
Mail list logo
