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 fro
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 ins
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 sho
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 too
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
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 co
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
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
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 somet
