gcc 4.1.1 and Bliss frontend.
Hi I am writing a Bliss frontend for gcc, and the current Bliss release is a frontend for gcc 3.4.3. (Downloadable from ftp://ftp.nvg.ntnu.no/pub/vms/bliss/bliss-0_114.tgz, if anyone is interested. Do not mind the vms path, it compiles on Linux.) I have started working on moving the frontend from 3.4.3 to 4.1.1. But it seems EXIT_BLOCK_EXPR and LABELED_BLOCK_EXPR have been moved to java, since no one else was using it. Would it be possible to move that code back, please? -- -Roar Thronæs
Re: gcc 4.1.1 and Bliss frontend.
On Jul 22, 2006, at 1:05 AM, Roar Thronæs wrote: Hi But it seems EXIT_BLOCK_EXPR and LABELED_BLOCK_EXPR have been moved to java, since no one else was using it. Would it be possible to move that code back, please? I don't think it should be moved back. You can add it to your front-end instead as nothing outside of the front-end really uses these tree code as they are useless once you go into CFG- gimple. In fact the question is why don't you emit these trees anyways? They have another form you can take, see how the java-gimple.java lowers them. -- Pinski
Re: MIPS RDHWR instruction reordering
On 21 Jul 2006 10:06:34 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > I also don't see why revision 108713 would affect this. > > But I do note that this version is still bad. The rdhwr instruction > is in the branch delay slot, and is therefore always executed. Yes, and I think rdhwr should not be in delay slot anyway. Just avoiding delay slot is quite easy. Here is a proposal patch. With this patch, it seems gcc 4.2 generate desired code for now, though there might be somewhere to fix. Index: gcc/config/mips/mips.md === --- gcc/config/mips/mips.md (revision 115370) +++ gcc/config/mips/mips.md (working copy) @@ -5450,6 +5450,9 @@ ; MIPS 32r2 specification, but we use it on any architecture because ; we expect it to be emulated. Use .set to force the assembler to ; accept it. +; Since rdhwr always generate a trap for now, it should not be be put +; on delay slot. It it was on delay slot, the emulation will be +; slower. (define_insn "tls_get_tp_" [(set (match_operand:P 0 "register_operand" "=v") @@ -5458,6 +5461,7 @@ "HAVE_AS_TLS && !TARGET_MIPS16" ".set\tpush\;.set\tmips32r2\t\;rdhwr\t%0,$29\;.set\tpop" [(set_attr "type" "unknown") + (set_attr "can_delay" "no") (set_attr "mode" "")]) ; The MIPS Paired-Single Floating Point and MIPS-3D Instructions.
Re: Searching configured and relocated prefix.
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote: We currently search both the relocated compilers prefix and the originally configured prefix. Should a relocated compiler be searching both directories? Yes because someone might have just relocated the compiler but not the rest of the tools. The main use of this is that untar a common sysroot and use different versions of the compiler which normally would be installed under that common location. Thanks, Andrew Pinski
Re: MIPS RDHWR instruction reordering
Atsushi Nemoto <[EMAIL PROTECTED]> writes: > On 21 Jul 2006 10:06:34 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > I also don't see why revision 108713 would affect this. > > > > But I do note that this version is still bad. The rdhwr instruction > > is in the branch delay slot, and is therefore always executed. > > Yes, and I think rdhwr should not be in delay slot anyway. Just > avoiding delay slot is quite easy. Here is a proposal patch. > > With this patch, it seems gcc 4.2 generate desired code for now, > though there might be somewhere to fix. This may be right, but I'm not sure that it is. If it is OK to unconditionally execute rdhwr, then it should be OK to put it in a delay slot. Unless that will break something when rdhwr is emulated. Or will the emulation code run slower when rdhwr is in a delay slot? That is, slower than it would if rdhwr were emulated without being in a delay slot? Ian
Re: MIPS RDHWR instruction reordering
On Sat, Jul 22, 2006 at 09:52:44AM -0700, Ian Lance Taylor wrote: > This may be right, but I'm not sure that it is. If it is OK to > unconditionally execute rdhwr, then it should be OK to put it in a > delay slot. Unless that will break something when rdhwr is emulated. > Or will the emulation code run slower when rdhwr is in a delay slot? > That is, slower than it would if rdhwr were emulated without being in > a delay slot? Yes. Much, much slower. There's a fast path support for rdhwr (I'm not sure if it is committed yet but it's definitely floating around) which only handles the non-branch-delay case. It will still work in a delay slot, but it's a much heavier-weight operation. So, until and unless there is a revision of the MIPS architecture on which this instruction is not guaranteed to trap, I think we should not put it in a delay slot. -- Daniel Jacobowitz CodeSourcery
gcc-4.2-20060722 is now available
Snapshot gcc-4.2-20060722 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060722/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 115676 You'll find: gcc-4.2-20060722.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060722.tar.bz2 C front end and core compiler gcc-ada-4.2-20060722.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060722.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060722.tar.bz2 C++ front end and runtime gcc-java-4.2-20060722.tar.bz2 Java front end and runtime gcc-objc-4.2-20060722.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060722.tar.bz2The GCC testsuite Diffs from 4.2-20060715 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [PATCH] Install drivers from gcc/Makefile.in
What about Ada ? Will things still work after your change ? It would seem cleaner (if not mandatory) to take all languages into account in your change. Only now I realize that I answered in private :-( The install-common target works as before, so the ada front end is not affected. The proposed patch factor codes that install programs that have both a short name (g++) and a name with an architecture prefix (i686-pc-linux-gnu-g++). I couldn't find any such program in the ada front end, so it is not affected by this patch. Thanks in advance. Best Regards, Rafael
Re: MIPS RDHWR instruction reordering
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Sat, Jul 22, 2006 at 09:52:44AM -0700, Ian Lance Taylor wrote: > > This may be right, but I'm not sure that it is. If it is OK to > > unconditionally execute rdhwr, then it should be OK to put it in a > > delay slot. Unless that will break something when rdhwr is emulated. > > Or will the emulation code run slower when rdhwr is in a delay slot? > > That is, slower than it would if rdhwr were emulated without being in > > a delay slot? > > Yes. Much, much slower. There's a fast path support for rdhwr (I'm > not sure if it is committed yet but it's definitely floating around) > which only handles the non-branch-delay case. It will still work in a > delay slot, but it's a much heavier-weight operation. > > So, until and unless there is a revision of the MIPS architecture on > which this instruction is not guaranteed to trap, I think we should not > put it in a delay slot. OK, patch is approved, with a ChangeLog entry, and assuming it passes the testsuite. Thanks. Ian
