C:\devel\gcc\gcc\config\i370\test>head dotests.bat
del results.txt
call onecomp 2112-1.c
call onecomp 2113-1.c
call onecomp 2121-1.c
call onecomp 2205-1.c
call onecomp 2217-1.c
call onecomp 2223-1.c
call onecomp 2224-1.c
call onecomp 20000225-1.c
C:\devel\gcc\gcc\config\i3
Let me ask a different question.
On GCC 3.2.3, does this sequence look correct:
./configure --target=i370-mvspdp --prefix=~/devel/mvscross --with-sysroot=~/devel/mvshead
--enable-languages=c
make
make install
./configure --build=x86_64-unknown-linux-gnu --host=i370-mvspdp --target=i370-mvspdp
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 = oper
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 = opera
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".
H
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 1
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 (
ril 06, 2012 3:50 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
I have made this change:
C:\devel\gcc\gcc\config\i370>cvs diff -c -r 1.23 i370.md
Index: i370.md
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,
mode, 1);
tmp = gen_add3_insn (tmp, tmp, GEN_INT (2));
/* If we get something that isn't a simple set, or a
[(set ..) (clobber ..)], this whole function will go wrong. */
if (GET_CODE (tmp) == SET)
I tried commenting out different plus:SI rules, but that also
met with a crash in
, 8);
return \"MVC^I%O0(8,%R0),%1\";
make use of that 'W' operand.
Do I change that %1 to %W1 perhaps?
I'll give that a try tomorrow.
Thanks. Paul.
-Original Message-----
From: Ulrich Weigand
Sent: Monday, August 22, 2011 10:22 PM
To: Paul Edwar
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
Adding this code:
C:\devel\gcc\gcc\config\i370>cvs 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)
{
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;
br
(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")
hat and report that later.
BFN. Paul.
-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 (&X
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 failu
2
which looks to me like it is not seeing a register, 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.or
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 pr
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
> <
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:
> 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
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.
ng it so far already.
BFN. Paul.
- Original Message -
From: "Richard Guenther"
To: "Paul Edwards"
Cc:
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 wro
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
Well I have good news to report.
I applied most of your recommended changes, but it still crashed,
still at the same spot:
:0: internal compiler error: Segmentation fault
However, I managed to track it down to some floating point stuff
in the i370 code, and got rid of that, and now I can compil
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, but
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, rtx
: In function `acos':
:137: Internal compiler error in ?, at :724
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I might be able to trace it from a different approach, getting more
information about that internal error
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 XNEWVE
On Sat, Nov 28, 2009 at 5:35 PM, Paul Edwards 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
>> for
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
i
On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards 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 compilation failures.
>
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.
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? Note that I have never had to do the machine changes
> myself - in the past I simply waiting for Dave Pitts to do the
> upgrade to the new vers
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 target
"Paul Edwards" 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
.
Andreas.
--
Andreas Schwab, sch...@redhat.com
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 chan
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
port
On 11/13/2009 12:43 PM, Paul Edwards wrote:
I normally define PREFIX in a
common header file. However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword.
regex.c is forked from anything else, so I don't think a patch changing
PREFIX to FUNC_PREFIX will hav
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 dep
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 made
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 compil
* 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_STRCA
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:
> 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
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:
> 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 u
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 l
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 was
* 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
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
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 work
"Paul Edwards" 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 the skills to ge
There are a couple of places where I need to do something different
if I'm running on an EBCDIC host (e.g. MVS, CMS, MUSIC, VSE).
So in mvspdp.h I have put:
/* If running on MVS, need some EBCDIC-related differences */
#if defined(__MVS__) || defined(__CMS__)
#define HOST_EBCDIC 1
#endif
and c-
"Paul Edwards" 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 __SIZEOF_LONG_LONG__. It
would
I can see that ansidecl.h is a tempting place to put this, but I don't
think it is correct. ansidecl.h is used by many different programs,
including the GNU binutils and gdb. Changes that are specific to gcc
should be in gcc, probably in gcc/system.h. Changes specific to
libiberty should be in
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
i
"Paul Edwards" 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 requires t
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 al
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 Lin
C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
../include
varasm.c
(insn 117 429 118 7 (parallel [
(set (reg:SI 64)
(compare:SI (mem/s:BLK (plus:SI (reg/f:SI
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 -Wwrite-string
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 ~/gcc-build
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 dir
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:
> 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
"Paul Edwards" 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
> didn't exist.
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*) pexecute=pex-
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 EXTRA_
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'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 aut
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 compi
../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 that does:
i370-mvspdp-xxx -S $*
Maybe a more g
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
.../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
../configure
> 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.
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 se
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 pr
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
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=... \
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 e
.../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 r
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-reor
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=... --with-s
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 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 sy
* 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
fputs_unl
"Paul Edwards" 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
* 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 cross
"Paul Edwards" 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 is a cross-com
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 cr
"Paul Edwards" 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 xgcc was c
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 lo
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 the JCL has the filenames
truncated to 8 characters, listed twice, uppercased, a
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 underestimating the work involved.
? Note that I ha
David Edelsohn wrote:
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards 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
On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards 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 the JCL ha
1 - 100 of 166 matches
Mail list logo
