Paul.
On Wed, Mar 19, 2025 at 5:30 PM Paul Edwards wrote:
>
> Hi.
>
> I already have a mini-clone of Windows (two actually -
> PDOS/386 and PDOS-generic), but both are ASCII.
>
> I now wish to create an EBCDIC version.
>
> I have an i370 EBCDIC version already (z/PDO
Hi.
I already have a mini-clone of Windows (two actually -
PDOS/386 and PDOS-generic), but both are ASCII.
I now wish to create an EBCDIC version.
I have an i370 EBCDIC version already (z/PDOS and
z/PDOS-generic), and the end result is that I have been
able to compile the gcc 3.2.3 source code o
> But I have a new emulator called mfemul.c, and it
> isn't very mature and almost certainly has a bug in
> it that is affecting gcc 3.2.3. And since that is the only
> Any suggestions on where to stick some printfs so that
> I can start looking for a divergence, given that the
> generated code is
Hello.
I have a mainframe operating system called z/PDOS-generic
available from https://pdos.org
I have ported a slightly modified gcc 3.2.3 (called
gccmvs) to it, and when run under Hercules/380
(mainframe emulator) it works fine and gccmvs is
able to reproduce itself byte-exact.
But I have a n
t is doing Win64 ABI:
D:\devel\gcc\gcc>gcc-new -O2 -S foo.c
D:\devel\gcc\gcc>type foo.s
.file "foo.c"
.text
.p2align 2,,3
.globl foo
foo:
.LFB1:
movsbl -1(%rcx),%eax
ret
.LFE1:
D:\devel\gcc\gcc>
Thanks for your help.
BFN. Paul.
O
(replying to Joe Monk)
> It appears that this is not an issue that this version of GCC is
> architected to be able to solve.
> The first 64-bit PC processor, the AMD opteron series, was launched on
> April 22, 2003.
> GCC 3.2.3 was released on April 25, 2003.
Jakub has already shown correct x64
ntf("bbb piss4\n");
folded = fold (result);
if (folded == result)
TREE_CONSTANT (folded) = TREE_CONSTANT (ptrop) & TREE_CONSTANT (intop);
return folded;
}
On Sat, 10 Feb 2024 at 05:38, Paul Edwards wrote:
> Oh - I switched to -2 to make debugging easier:
>
> D:\devel\gcc\g
Oh - I switched to -2 to make debugging easier:
D:\devel\gcc\gcc>type foo.c
int foo(char *in)
{
return in[-2];
}
D:\devel\gcc\gcc>
Note that my flavor of gcc 3.2.3 can be found in gcc-stage*.zip
in custom.zip at http://pdos.org
On Sat, 10 Feb 2024 at 05:34, Paul Edwards wrote:
&g
On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek wrote:
On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
>> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
> Don't, gcc 3.2.3 is not supported for more than 20 years already.
And the i370 targ
Hi.
I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
int fff(char *x)
{
return (x[-1]);
}
It is generating:
.globl fff
fff:
.LFB2:
movl$4294967295, %eax
movsbl (%rax,%rcx),%eax
ret
My understanding is that that move of -1 into eax
does NOT s
I normally use gcc 3.2.3 to build executables that
work with msvcrt.dll, which has 32-bit int, long and ptr.
I tried changing long to 64 bits and the new compiler
encountered the following issue when attempting to
build itself. Documented and fixed below, unless
someone has a better fix. Note that
I have a slightly modified gcc 3.2.3.
Source is available in gcc-stage* in custom.zip at http://pdos.org
Executables are available in customb.zip but everything that
is really needed is in pdos.zip
gccdos.txt has instructions to run windows.mak which
produces the gccx64.exe that I use, but has t
POO page 3-6.
>
> I dont see 32 bits anywhere in that process. Unless and until IBM changes
> the architecture definition to include 32 bits in address sizes, there is
> no need for a -m32 switch.
>
> Joe
>
> On Sat, Jan 28, 2023 at 12:51 PM Paul Edwards wrote:
>
>>
ded back in, for
that too, given that that is the correct technical nature
of the GCC-generated code?
Thanks. Paul.
"Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
Prove it on real hardw
On Fri, 3 Sept 2021 at 20:12, Ulrich Weigand
wrote:
> "Paul Edwards" wrote on 03.09.2021 13:35:10:
> > > Specifically, if you try to run AMODE64 with Pmode equals
> > > SImode, the compiler will not be aware that the hardware
> > > uses the high
Hi.
In certain places, the i370 target of GCC 3.2.3 will use a
base + index + displacement operand.
How can I add a constraint to say that the index must be
between 0 and 0x7fff?
I want to stop 0x from being generated when I have:
char *p
p[-1];
Thanks. Paul.
--
This email has be
20:K:06=000C0001 8050327A
.&.:
18:03:13 R:0030:K:06=
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Friday, October 1, 2021 8:01 AM
To: gcc@gcc.gnu.org
Cc: m...@suse.de
Hi Michael.
Thanks for picking up this issue. I have been working
with Jesus on this.
m31 is semantically the same as the m32 option.
The m31 option allows for 32 bit addressing and that is confusing since
the m31 option in S390 would mean 2 GiB space addressing
Indeed that's exactly what
Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
Prove it on real hardware, not hercules. Hercules doesnt count.
Real mainframe hardware is not easily accessible.
Hercules is the most convenient way
lias for
"-m31", but I would like to add as a request for it to
work with optimization on.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Friday, September 3, 2021 11:12 PM
To: Jakub Jelinek
Cc: Ulrich Weigand ; gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
Hi Joe.
Thanks for your comments.
> It is unclear how this would even work.
> For instance, the LA instruction clears the top bit.
In AM64, LA does not clear any bits.
> Also, instructions like LPR, LNR,
These operate on data registers, not addresses,
and will continue to work unchanged.
>
> This is not in one single place, but spread throughout the
> compiler, both common code and back-end. I do not think it will
> be possible to get the compiler to generate correct code if
> you do not specify the address size correctly.
1. Is there any way to put a constraint on index
registe
>> > Also, the compiler
>> > will assume the base + index (+ displacement) arithmetic
>> > will operate in 32 bits -- I'm pretty sure this is
>> > actually the root cause of your "negative index" problem.
>> Where is this logic please? Can I do a #if 0 or similar
>> to disable it?
> This is n
> - AMODE64 means the native address size is 64 bits. This
> implies that Pmode has to be DImode, since Pmode tells
> the compiler what the native address size is.
> Specifically, if you try to run AMODE64 with Pmode equals
> SImode, the compiler will not be aware that the hardware
> uses th
Hi Ulrich. Thanks for your detailed reply.
>> > Therefore again my question, what is the actual goal
>> > you want to achieve? I'm still not sure I understand
>> > that ...
>> I would like to know what is required to implement
>> “-m32” in the S/390 target. I realize that z/Arch
>> doesn’t have
.
From: Ulrich Weigand
Sent: Friday, September 3, 2021 12:34 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the
>> I just checked my copy of s390.md and I don’t see
>> LA being used for arithmetic.
> This would be the "*la_31" and "*la_31_and" patterns.
Sorry, I did a grep for “LA”, forgetting that
s390.md doesn’t use uppercase instructions.
> (Note that the addition is implicit in the use of
> the "addres
: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to addr
make[1]: *** [Makefile:406: all-recursive] Error 1
make[1]: Leaving directory '/home/robertapengelly/Desktop/UDOS'
make: *** [Makefile:326: all] Error 2
-Original Message-
From: Paul Edwards
Sent: Thursday, September 2, 2021 6:15 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subjec
000444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown
Any idea what we can do?
Thanks. Paul.
-Original Message-
From: Ulrich Weigand
Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
In addition, tha
Actually, what I want is a processor with ECS,
EDS and EES, as new registers, and for GCC
to target that, supporting near, far and huge
code pointers and data pointers.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Tuesday, March 16, 2021 12:55 AM
To: GCC Development
Would it be possible for GCC to generate code
that reserves ESI and EDI as "extended segment"
registers to hold a source and destination
"extended segment" of any operation.
This will be the upper 32-bits of a 64-bit address.
When run on a normal 80386, such code will work
fine, and ESI and EDI
Paul.
-Original Message-
From: Paul Edwards
Sent: Sunday, March 14, 2021 7:12 PM
To: gcc@gcc.gnu.org ; Richard Biener
Subject: Re: negative indexes
Hi Richard. Thanks for your reply, but if I understand
you correctly, you are saying this fix is for situations
where the size of an integ
eally understand
your answer. :-) ).
Thanks. Paul.
-Original Message-
From: Richard Biener
Sent: Sunday, March 14, 2021 7:05 PM
To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc.gnu.org
Subject: Re: negative indexes
On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc
wrote:
If I have code like this:
char foo(char *p)
{
return (p[-1]);
}
It generates a negative index, like this:
* Function foo code
L 2,=F'-1'
L 3,0(11)
SLR 15,15
IC15,0(2,3)
* Function foo epilogue
See that (2,3) - that is adding both R2 + R3.
R3 is
Hi.
On the i370 port of GCC 3.2.3, I am
getting the following issue.
This code:
C:\scratch\bug>type bug.c
const char *p;
void foo(void)
{
printf("p-1 is %x\n", p[-1]);
}
generates:
...
L 2,=F'-1'
...
IC4,0(2,3)
ie it is using a value of x’’ in R2 as an index.
This work
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 2225-1.c
C:\devel\gcc\gcc\config\i3
oessenkool
Sent: Friday, September 23, 2016 6:21 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: gcc 3.4.6 asm charset error
On Thu, Sep 22, 2016 at 05:35:22PM +1000, Paul Edwards wrote:
GCC 3.4.6 natively handles different character
sets for source and target. It actually works
fin
GCC 3.4.6 natively handles different character
sets for source and target. It actually works
fine, writing source code in ASCII targeting
an EBCDIC destination.
However, __asm() doesn't seem to be working.
As seen below, it is generating EBCDIC data
in the ASCII assembler output. Those funny
char
Hi.
On the i370 target of a slightly modified
GCC 3.2.3, I am getting this strange padding:
DC46X'00'
I asked Dave Pitts about it, and he
told me it is not related to the i370
machine definition and I should ask
the group for advice instead.
Note that one variable needs a padding
o
Hi.
On the i370 port of GCC 3.2.3 (which
can be run in 31-bit mode on z/OS),
we have the below code to do a
builtin_memcpy().
But as per description in i370.md, it
is restricted to moving LESS than
16 MiB.
If we have 16 MiB or more, I am happy
to just call the memcpy() function.
I have tried v
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
It seems to me that in addition to doing a strcmp to cc1, I would
also have needed to do a strcmp to cccp. Can someone confirm
that GCC 2.8.1 and GCC 3.4.6 differ in that respect - ie there
was an extra executable (cccp) in GCC 2.8.1 when doing that
task of converting from C to assember (ie compil
In GCC 3.4.6, in order to create a single executable called "gcc" that
takes C code and produces assembler, I needed to put this code into gcc.c:
#ifdef SINGLE_EXECUTABLE
{
int cnt = 0;
while (commands[i].argv[cnt] != NULL)
{
cnt++;
}
if (s
The revision history of the FSF version of GCC between the EGCS split
and the merge was retained on premerge-fsf-branch. That lets me see
that this change was committed by Richard Kenner on 1998-10-04.
Thanks Ian. I contacted Richard but unfortunately he had no
evidence of communicating with me
Hello.
During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or
some similar list) with patches. I have found evidence of the
patches being applied:
http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog
527 Sun Oct 4 08:37:36 1998 Paul Edwards
528
529
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
recog.c:2083
#endif
void foo(int c)
{
int x[3];
int y[3];
int i;
for (i = 0; i < 2; i++)
{
if (c == 1) x[i] &= y[i];
else if (c == 2) x[i] |= y[i];
}
return;
}
C:\devel\gcc\gcc>
-Original Message-----
From: Paul Edwards
Sent: Friday, Ap
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
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
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
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
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
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
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
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
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 chan
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
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
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 ...
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
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
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
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-
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
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
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
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,
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_
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
../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
.../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.
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
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=... \
.../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
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" ==
* 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
* 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
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
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
1 - 100 of 138 matches
Mail list logo
