rrently in the "too hard"
basket.
Some were ASCII assumptions (the
i370 port is EBCDIC).
And there was a genuine bug which I
have passed on to Dave Pitts for
analysis.
Regarding the ASCII errors, here’s an
example:
C:\devel\gcc\gcc\testsuite\gcc.c-torture\execute>type 2412-3.c
typed
Hello all.
I have previously succeeded in getting configure to
work for gcc 3.4.6. Unfortunately gcc 3.4.6 is too
buggy to use and needs to wait for Dave Pitts or
someone to fix.
gcc 3.2.3 has no known bugs for the i370 target,
but it has not been done using configure.
I am now trying to get
Hi Paul,
I put some debugging on here:
op0 = XEXP (operands[0], 0);
if (GET_CODE (op0) == REG
|| (GET_CODE (op0) == PLUS GET_CODE (XEXP (op0, 0)) == REG
GET_CODE (XEXP (op0, 1)) == CONST_INT
(unsigned) INTVAL (XEXP (op0, 1)) 4096))
{
op0 = operands[0];
Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
I have made this change:
C:\devel\gcc\gcc\config\i370cvs diff -c -r 1.23 i370.md
Index: i370.md
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.23
Paul Edwards wrote:
I have reviewed the 'W' code in PRINT_OPERAND:
else if (CODE == 'W')
{
/* hand-built sign-extension of signed 32-bit to 64-bit */
mvs_page_lit += 8;
if (0 = INTVAL (XV)) {
fprintf (FILE, =XL8');
} else {
fprintf (FILE,
Paul Edwards wrote:
I've managed to isolate the problem to a small test program.
Any suggestions on how to debug this?
bug27.c:28: error: unrecognizable insn:
(insn 116 34 35 2 (set (reg:SI 5 5)
(plus:SI (plus:SI (reg:SI 2 2 [orig:54 i ] [54])
(reg/f:SI 13 13))
Ah, yes. The problem is that reload assumes any valid address
can be loaded into a register with a single instruction, and
it will thus simply generate such instructions unconditionally
-- and if the target then doesn't actually provide such a pattern,
it will fail with unrecognizable insn.
Hi
Hi Ulrich.
A further question.
I put some debugging on here:
op0 = XEXP (operands[0], 0);
if (GET_CODE (op0) == REG
|| (GET_CODE (op0) == PLUS GET_CODE (XEXP (op0, 0)) == REG
GET_CODE (XEXP (op0, 1)) == CONST_INT
(unsigned) INTVAL (XEXP (op0, 1)) 4096))
{
op0 =
give that a try tomorrow.
Thanks. Paul.
-Original Message-
From: Ulrich Weigand
Sent: Monday, August 22, 2011 10:22 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
if (operands[1] == const0_rtx)
{
CC_STATUS_INIT;
mvs_check_page (0
Edwards
Sent: Thursday, April 05, 2012 11:31 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Hi Ulrich.
I'm getting back to this after a long hiatus.
I have reviewed the 'W' code in PRINT_OPERAND:
else if (CODE == 'W')
{
/* hand-built sign-extension of signed 32-bit to 64-bit
Paul Edwards wrote:
if (operands[1] == const0_rtx)
{
CC_STATUS_INIT;
mvs_check_page (0, 6, 8);
return \MVC%O0(8,%R0),=XL8'00'\;
}
mvs_check_page (0, 6, 8);
return \MVC%O0(8,%R0),%1\;
}
[(set_attr length 8)]
)
forces it to use XL8'00' instead of the
(like the 8 byte move from F'0'). I'll do my own investigation
of that and report that later.
Ok, the bad MVC:
MVC 112(8,13),=F'0'
is being generated by the movdi instruction:
;
; movdi instruction pattern(s).
;
(define_insn
[(set (match_operand:DI 0 nonimmediate_operand =d,m,S)
And here is the same debug info as last time ...
#include config.h
#include system.h
#include coretypes.h
#include tm.h
#include rtl.h
rtx
foo (rtx addr, int size, int n_refs)
{
int offset = 0;
switch (GET_CODE (addr))
{
case PRE_INC:
offset = (n_refs + 1) * size;
break;
Adding this code:
C:\devel\gcc\gcc\config\i370cvs diff i370.md
Index: i370.md
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.21
diff -r1.21 i370.md
845a846,851
if (operands[1] == const0_rtx)
{
, only a constant,
so cannot perform a swap.
Let me know if that is not the debugging required.
Thanks. Paul.
-Original Message-
From: Ulrich Weigand
Sent: Tuesday, August 16, 2011 11:25 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
Unfortunately
Paul Edwards wrote:
Hi Ulrich. I put in the following debug:
op0 = find_replacement (XEXP (in, 0));
op1 = find_replacement (XEXP (in, 1));
/* Since constraint checking is strict, commutativity won't be
checked, so we need to do that here to avoid spurious failure
if
.
-Original Message-
From: Ulrich Weigand
Sent: Thursday, August 18, 2011 11:14 PM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
Hi Ulrich. I put in the following debug:
op0 = find_replacement (XEXP (in, 0));
op1 = find_replacement (XEXP
Paul Edwards wrote:
Unfortunately it's not quite right, seemingly not loading R9 properly:
LR9,13
AR9,13
MVC 0(10,9),0(2)
That's weird. What does the reload dump (.greg) say?
I have trimmed the code down to a reasonably small size so that I
could provide the .greg file
Paul Edwards wrote:
I was surprised that an instruction that is marked as s_operand
was getting a seemingly non-s_operand given to it, so I added an
S constraint:
That's right. It is not good to have a constraint that accepts
more than the predicate, since reload will at this point only
You'll need to mark your new constraint as EXTRA_MEMORY_CONSTRAINT
so that reload knows what to do when an argument doesn't match.
Thanks! That certainly produced an effect.
Unfortunately it's not quite right, seemingly not loading R9 properly:
LR9,13
AR9,13
MVC 0(10,9),0(2)
And it
Paul Edwards wrote:
Unfortunately it's not quite right, seemingly not loading R9 properly:
LR9,13
AR9,13
MVC 0(10,9),0(2)
That's weird. What does the reload dump (.greg) say?
And it had a knock-on effect too, producing bad code elsewhere:
SLR 2,2
SLR
Hi Ulrich and group.
The i370 port of GCC 3.4.6 is now complete and the result can be
downloaded from http://gccmvs.sourceforge.net
It can be built using configure/make, and there weren't that many
changes that needed to be made to the code to get it to work.
However, I have encountered a bug
richard.guent...@gmail.com
To: Paul Edwards mutazi...@gmail.com
Cc: gcc@gcc.gnu.org
Sent: Sunday, November 29, 2009 2:02 AM
Subject: Re: i370 port - music/sp - possible generic gcc problem
On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards mutazi...@gmail.com wrote:
I think I have found a bug in gcc
Paul Edwards wrote:
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify
can compile a
hello, world program!
The changes to 4.4.0 required to do that can be found here:
http://rapidshare.com/files/317504205/gcc4-alpha6.zip
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user
I think I would stop right there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
It got an internal error. I don't have the skills to get that to work,
but I do have the skills to bypass it one way or another (and I
demonstrated what I am doing now
Latest information -
Ok, based on this, I traced it back further:
rtx
gen_rtx_fmt_e0 (code, mode, arg0)
RTX_CODE code;
enum machine_mode mode;
rtx arg0;
{
rtx rt;
rt = ggc_alloc_rtx (2);
memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
The request for 2 (I guess,
I think I have found a bug in gcc, that still exists in gcc 4.4
I found the problem on 3.2.3 though.
While MVS and VM have basically been working fine, when I did
the port to MUSIC/SP I started getting strange compilation failures.
Initializing the stack to NULs made the problem go away, but I
On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards mutazi...@gmail.com wrote:
I think I have found a bug in gcc, that still exists in gcc 4.4
I found the problem on 3.2.3 though.
While MVS and VM have basically been working fine, when I did
the port to MUSIC/SP I started getting strange
Anyway, I tracked down the particular malloc() which gave changed
behaviour depending on whether the malloc() did a memory initialization
to NULs or not.
Well, GC hands out non-zeroed memory - the callers are responsible
for initializing it. So the fix below is not a fix but papering over an
On Sat, Nov 28, 2009 at 5:35 PM, Paul Edwards mutazi...@gmail.com wrote:
Anyway, I tracked down the particular malloc() which gave changed
behaviour depending on whether the malloc() did a memory initialization
to NULs or not.
Well, GC hands out non-zeroed memory - the callers are responsible
If GC does that, then how come there is all this effort to do
mmap testing to see if it has the facility to zero memory, and
I can't see what you are refering to.
I obviously misinterpreted that then.
why is the surrounding code (in GCC 4.4's alloc_page())
calling XCNEWVEC instead of
stdin: In function `acos':
stdin:137: Internal compiler error in ?, at stdin:724
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
I might be able to trace it from a different approach, getting more
information about
supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code.
The s390 port uses IEEE float instead of hex float throughout,
so
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code
Ok, now that 3.4.6 is fully working, I made a start on the 4.4 port.
4.4 appears to have invalidated a lot of 3.4.6 things. Below are all
the changes I needed to make just to get an xgcc executable
built. I didn't really know what most of it was about, but the
purpose was just to scope the
Paul Edwards mutazi...@gmail.com writes:
Index: gcc4/config.sub
diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
*** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/config.sub Mon Nov 23 22:47:08 2009
You should send patches for config.{guess,sub} to
config-patc...@gnu.org.
Andreas.
On 11/23/2009 11:32 AM, Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them?
I think your best bet is to grep the changelogs for what has changes,
and see what was done for other ports. Many
gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions. So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.
I don't see how the generated number depends on the MVS
version ... It is supposed to
On 11/14/2009 12:27 PM, Paul Edwards wrote:
So what I have done is get the compiler to fail on any missing
prototype. I think perhaps we need to have a generic gcc or
autoconfigure option called config by prototype. MVS is just
one instance where you might wish to do it this way. Other
ports
Paul Edwards wrote:
gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions. So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.
I don't see how the generated number depends on the MVS
version
Ok, I've now reached a new milestone - the mshort.h which
redefines all the long names into ZZZ_123 etc is now
automatically generated as part of the build process.
The libiberty and gcc aren't split yet, but I'll probably defer
that to gcc 4, and see if I can simply reproduce what I have
with
I have wonderful news to report.
I am finally able to build GCC 3.4.6 for MVS using the normal
build process.
There is still a lot of extra i370-specific utilities to e.g. generate
compile JCL, but these are completely separate scripts so not
intrusive at all.
Here's all the changes I have
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS
* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in
LIBOBJS includes a strcasecmp.s$U.s
That suffix is certainly strange-looking though. I checked in
config.log and I can see that it automatically detected that
my object code has a .s extension, which is basically
correct given that I forced the -S option.
Why do you pass -S in the compiler
Ok, now I have some results from the auto-compile-script-generation.
I got it to work, but it required some manual corrections.
First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING
Paul Edwards wrote:
First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING was not defined
(that's my quick analysis, anyway). So I just grepped those
files out of the source list.
Paul Edwards:
1. I think my unixio.h, which has a stack of POSIX functions
that need to be there (mkdir, pwait, open, fileno etc), needs to
be considered honorary ansi (after all, so much code assumes
that they exist) and get included in ansidecl, with unixio.h
living in include, and
Next, a stack of libiberty files were not compiled - strcasecmp,
vasprintf, asprintf, getpagesize, strdup. I don't know why this
would be the case, because e.g. HAVE_STRCASECMP is
not defined. Anyway, I added them to the source list manually,
and with a script, awk and m4, I was able to produce
Paul Edwards wrote:
The thing is, I already know it has detected that I don't have
strcasecmp. That's why it doesn't have HAVE_STRCASECMP
defined in the config.h. You are right that I don't have a linker,
but the compile with error-on-no-prototype is working fine - I
can see the result in
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with my own scripts as per
normal.
There's still a stack more
Hello Paul,
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and
* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
Well, I have good news to report. The restructuring was a success.
That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with
be in libiberty, probably in include/libiberty.h.
Another where question. The i370 port can't cope with 64-bit
integers. The below bit keeps on defining it. So I created a
WANT64 which obviously is never going to be set.
I've just updated config/i370/mvspdp.h to define
USE_C_ALLOCA
because the i370
Paul Edwards mutazi...@gmail.com writes:
Another where question. The i370 port can't cope with 64-bit
integers.
I think I would stop right there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
That said, these days gcc always defines
there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
It got an internal error. I don't have the skills to get that to work,
but I do have the skills to bypass it one way or another (and I
demonstrated what I am doing now, but I know that that
intrusive code
Paul Edwards mutazi...@gmail.com writes:
and c-parse.c:
That file no longer exists so I don't know how to interpret this.
I think I would stop right there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
It got an internal error. I don't have
Still making great progress.
The process is being simplified.
I have a question. I need to remap long names to short, and I
wish to use #defines to do this as it is portable.
So I have a whole lot of:
#define align_functions ZZZ_1
#define align_functions_log ZZZ_2
etc
and I have put them
Paul Edwards mutazi...@gmail.com writes:
Now all code needs to be exposed to this. ie libiberty and
gcc. To fit in with the new style of building, I basically want
to update ansidecl.h to do a:
#ifdef PUREISO
#include mshort.h
#endif
Does that seem reasonable?
The ISO C99 standard
Now all code needs to be exposed to this. ie libiberty and
gcc. To fit in with the new style of building, I basically want
to update ansidecl.h to do a:
#ifdef PUREISO
#include mshort.h
#endif
Does that seem reasonable?
The ISO C99 standard requires that an identifier have 31 significant
Paul Edwards wrote:
The QI must be a signed char, and thus rejecting any value greater than 127.
As you can see, I changed it to SI, which, with the constraints and tests
in place, should be fine.
Ah, OK. That would explain it.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux
+ STARTING_FRAME_OFFSET. It seems for the i370 port,
this should resolve to
register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size
Overall, the middle-end would therefore replace reg 21 + 456 with
reg 13 + X, where X is constant computed from 456 + STACK_POINTER_OFFSET
I've been having fantastic success building gcc. I have got it
to iterate through the entire build (as far as I can tell) now.
Then finally I ran into an internal compiler error which I haven't seen
before. One of the gcc options must have triggered something off.
Perhaps it was
This means that if your GCC source tree resides in a directory, say,
~/gcc-src
you should *not* run ./configure while in ~/gcc-src. Instead, you
should create a second, empty directory
~/gcc-build
(which is not a subdirectory of ~/gcc-src), and run
../gcc-src/configure ...
while in
As to the pex-unix.c, you certainly should provide a MVS-specific
version of the PEX callbacks. They are selected in configure.ac:
# Figure out which version of pexecute to use.
case ${host} in
*-*-mingw* | *-*-winnt*) pexecute=pex-win32.o ;;
*-*-msdosdjgpp*)
Paul Edwards mutazi...@gmail.com writes:
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
it was including things in because it thought that the prototypes
Paul Edwards wrote:
Ok, perhaps this error was because when I hit errors in intl,
which I've never used before, I just went to the gcc directory and
did a make.
Regardless, I added a stack of touch xxx.o in the intl directory
after the failure of the first make, which allowed me to do a
If you use --disable-nls on the configure line, the intl directory
should be skipped ...
Ok, that's working.
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
Paul Edwards wrote:
Are you running the top-level configure? (If you run a
subdirectory configure, e.g. the one in gcc/, directly,
things may not work correctly.)
Yes I am.
One other thing I did - I compiled the cross-compiler, and installed it.
Then I wiped out the directory and
Hi Ulrich. I've had considerable success in this process. I've
now reached the point where I seem to have a correctly
generated config.h in libiberty and correct auto-host.h in gcc,
which is one of the aims in order to get an eventual link on
MVS.
However, it meant that I could look at the
Paul Edwards wrote:
Hi Ulrich. I've had considerable success in this process. I've
now reached the point where I seem to have a correctly
generated config.h in libiberty and correct auto-host.h in gcc,
which is one of the aims in order to get an eventual link on
MVS.
OK, good to hear
Hi Ulrich.
I'll try out some of those things. I have some initial
comments.
Hmmm, the access() use probably needs to be guarded by a configure
check. Or else you might provide a MVS-specific implementation of
access (if that is possible), and compile it into libiberty by
providing an
Paul Edwards wrote:
Maybe a more generic way to work around the missing assembler and linker
would be to provide dummy scripts i370-mvspdp-as
I created one of them, but as far as I can tell it didn't pick it up.
Ah, you'll probably have to re-run configure and rebuild the cross compiler.
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
where prefix points to the directory where the cross-compiler
should be installed, and sysroot points to the directory where
the MVS libraries and header are installed.
Ok, I used
Paul Edwards wrote:
Ok, I used
../configure --target=i370-mvspdp --prefix=/devel/mvscross
--with-sysroot=/devel/mvshead
--enable-languages=c
plus make and make install
then I went to
mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
and replaced it with a script
Huh. I've never seen this before. Is this with your patches to
generate a single executable or without?
My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.
I could try taking it back to raw 3.4.6 though and see if that has
the same problem.
Would you be able to give me the two suggested configure
commands so that I can find out the answer to the above, one
way or another?
For step 2 (building the cross-compiler), you'd need something
along the lines of
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
Paul Edwards:
The failure (on 3.4.6, but not on 3.2.3) is that after the successful
build, when I do an xgcc -S, it produces the assembler file, and then
hangs. I traced this to gcc.c which was in a loop doing this:
pid = pwait (commands[i].pid, status, 0);
getting a return of 0 all
The failure (on 3.4.6, but not on 3.2.3) is that after the successful
build, when I do an xgcc -S, it produces the assembler file, and then
hangs. I traced this to gcc.c which was in a loop doing this:
pid = pwait (commands[i].pid, status, 0);
getting a return of 0 all the time, while the
Paul Edwards wrote:
Huh. I've never seen this before. Is this with your patches to
generate a single executable or without?
My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.
I could try taking it back to raw 3.4.6 though and see if that
Paul Edwards wrote:
Would you be able to give me the two suggested configure
commands so that I can find out the answer to the above, one
way or another?
For step 2 (building the cross-compiler), you'd need something
along the lines of
.../configure --target=i370-mvs --prefix=...
Hi,
On Sun, 4 Oct 2009, Paul Edwards wrote:
With 3.4.6, I have a script called compile, which looks like this:
call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
Thanks Ulrich. That's very different from the concept I had of
how the build process was meant to work.
Ignoring the cross stuff, if this is all you need I would suggest calling
make in the
Hi,
On Tue, 6 Oct 2009, Paul Edwards wrote:
Thanks Michael. That's exactly the sort of thing I was after. Just
one thing - I'll need more than cc1. I need the files that normally
go into gcc as well. So a combination of those two sets of source,
so that I can get a single standalone
Paul Edwards mutazi...@gmail.com writes:
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but it is still insisting that I have an
Paul Edwards wrote:
I'm not sure whether to call MVS a target or host.
Maybe it helps to take a step back and look at how the process
of initially getting a compiler for a system B built, starting
on an existing system A, usually works.
Each of the following steps can be identified by three
In step 3, configure will use the A-B cross-compiler (from step 2)
to do the trial compiles. This compiler, if built correctly, will
use host *B* header files and libraries from its sysroot, and thus
configure will detect properties of system *B* (which again is correct,
as in step 3, host ==
Paul Edwards mutazi...@gmail.com writes:
* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross
* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-compiler.
Ok.
* Write a
I tried again but I'm not making much progress.
Maybe I need to go further than Canada, let's say Alaska.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so
Paul Edwards mutazi...@gmail.com writes:
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this
Hi Ian, thanks for your reply.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this xgcc was
2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way. I was just wondering
if the proper way was to incorporate the logic into a Makefile
rule and get that rule repeatedly executed rather than just
having a simple echo. It seems
I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP
I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks
Paul Edwards mutazi...@gmail.com writes:
the gcc build system working. Trying to bootstrap gcc there seems
like a lot
of pain for no real benefit.
The effort is mostly in the Canadian Cross. The changes to get it to
bootstrap from that point are relatively small.
I think you are
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards mutazi...@gmail.com wrote:
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like). Note that
David Edelsohn wrote:
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards mutazi...@gmail.com wrote:
But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP
1 - 100 of 161 matches
Mail list logo
