GCC 3.2.3 has been built for MVS 3.8, MVS/XA, OS/390, Z/OS and VM/CMS.
You can find the modified source and binaries here:
http://www.softlib.org/GCCMVS/gccmvs.html
Only the C compiler has been ported.
BFN. Paul.
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
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
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
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
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
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
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.
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
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
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
(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;
br
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)
{
But sometimes r_or_s_operand is being used as a source, in
which case, the constant is fine. But when it is used as a
destination, it is not fine.
What is the *simplest* way of changing the setup so that the
code generation remains the same, but the warning is eliminated?
Well, I guess you nee
I then found out that even with old versions of the machine definition,
I can have the warning removed by simply not defining CONST_INT
in the PREDICATE_CODES, even though it is allowed when the
function is called. ie it seems to have no effect on the code
generation, but succeeds in eliminating
This probably is not gimp (the graphics editor) but gmp (the
multi-precision integer operation library) and mpfr (same for
floating-point). To build any recent GCC you'll indeed need
these two libraries. Fortunately, they're already available
on s390(x) on Linux, and shouldn't really contain any
That depends a bit on the compiler version and optimization level,
but (in particular in the 3.x time frame) GCC may output assembler
code on a function-by-function basis, without necessarily reading
in the whole source file first.
Ok, actually it doesn't matter if it doesn't work all the time.
Thanks guys for your reply.
As Paolo mentioned, the -dA flag is an option to the *compiler* that
causes it to place additional information into its output stream
(the assembler source code).
[from Paolo]
Only DWARF-2 output supports it currently, but if you want to use it say
together with S
GCC relies on the libiberty "pex" family of routines, which are
much more narrow in scope, and have in fact been ported to several
non-UNIX systems, including even MS-DOS. Providing a port of "pex"
to MVS should be much easier that porting a full Unix "system" or
"fork" feature.
Ok. But I don'
Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3). I don't think there is any
way in 3.2.3 to check whether there is a "main" function in the file
before it is process
> That depends a bit on the compiler version and optimization level,
> but (in particular in the 3.x time frame) GCC may output assembler
> code on a function-by-function basis, without necessarily reading
> in the whole source file first.
Ok, actually it doesn't matter if it doesn't work all the
> Hmm, it seems 3.2.x would *always* operate on a function-by-function
> basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
> recall if it was already present in 3.3). I don't think there is any
> way in 3.2.3 to check whether there is a "main" function in the file
> before it
> How does this work? ASM_FORMAT_PRIVATE_NAME is not supposed
> to completely ignore the NAME argument, the function may well
> be called with the same LABELNO but different NAME strings,
> and this must not result in conflicting symbols ...
I have compiled the entire GCC and not come up with an
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more. If there are other problems related to MVS host
I think the EBCDIC support is largely theoretical and not tested on any
actual EBCDIC host (
2. I am unable to do an optimized compile even as a cross-compile,
I get an internal error in this function:
gcse.c:
static void
compute_hash_table_work (struct hash_table *table)
{
...
if (!current_bb) /* +++ why are we getting NULL here? */
It appears I have misdiagnosed this. The code wil
I'm making quite good progress with cleaning up the 3.4.6 i370
port. I've even got optimization working to some degree.
Meanwhile, on a different machine (a Linux machine I program
on on the way to/from work), I have managed to build 4.4.0,
which means I have an environment to work on a more mod
It was dropped from GCC 4 when there was supposedly no
maintainer available. Actually, Dave Pitts and myself were
both maintaining it at that time, but we were both still working
on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
last time it was included in the normal GCC distribut
Therefore, the i370_branch_dest routine needs to handle
those as well. Probably something along the following lines:
if (GET_CODE (dest) == IF_THEN_ELSE)
{
if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
dest = XEXP (dest, 1);
else
dest = XEXP (dest, 2);
}
gcc_assert (GET_CODE (des
Hi Ulrich.
Good news is that I have now gotten GCC 3.4.6 to recompile
itself with full optimization on. The compilation time on the
(emulated) mainframe is only 2.5 hours as only a single pass
is required. GCC 3.4.6 requires 49 MB to recompile c-common!
I assume with GCC 3.4.6 it is doing glob
> The combination of predicates and constraints on this insn is broken.
>
> Before reload, the predicate "immediate_operand" explicitly allows
> *any* SImode immediate value. However, during reload, the "K"
> constraint accepts only a subset of values.
Is there a way to give a predicate that jus
> As an alternative to the operand predicate, you might also add
> an extra check to the insn condition. For example, something
> along the following lines should work:
>
> (define_insn ""
> [(set (match_operand:SI 0 "register_operand" "=d")
> (mult:SI (match_operand:SI 1 "register_oper
That's a bit hard to diagnose without some further information ...
What insn it is failing on? (To find out, use a debugger, or maybe
add a "debug_rtx (insn)" statement before the abort in
instantiate_virtual_regs_lossage)?
I did the latter.
C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ans
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 have a theory that if both displacements in the S-type (ie register plus
displacement) address are non-zero, that something fails. So the
next thing I will do is see if I can detect just that situation, and stop
it going into the CLC.
I now have that detection in place, and done a self-compil
Ulrich, here's one of the workarounds I mentioned. The other one is
pretty similar to this one as well.
After my investigation, I've come to the conclusion that this never
worked, and was not noticed before, because the optimizer mustn't
have ever used it before.
As such, it's appropriate to si
What is the best way to go from this:
Makefile:
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)
OBJS-common = \
^Iinsn-attrtab.o \
^Iinsn-
What is the best way to go from this:
Makefile:
The easy way to convert a Makefile to a shell script is "make -n". That
will print out all of the commands that make would run. From there it's a
Mere Matter of Programming to have perl (or whatever) edit that down into
your JCL scripts.
Hi
> 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 s
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 l
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
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
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
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
* 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
* 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
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" ==
.../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
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=... \
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
> 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.
.../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
../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
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
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_
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-
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,
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
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
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
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
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
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
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-
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 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
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
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
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 ...
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
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
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
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, 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
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.
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
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
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
: 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
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
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
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
Hello GCC maintainers.
There used to be an i370 target for GCC. It was written in 1989,
and put into GCC 2.5 in 1993.
It has always been semi-working, but never good enough to
actually use.
It was dropped from GCC 4 when there was supposedly no
maintainer available. Actually, Dave Pitts and m
We were both maintaining it, and continue to maintain it,
because MVS doesn't have any alternate free C compiler
available.
To merge back into FSF GCC, the people who have made changes that would be
merged back will need to have copyright assignments on file at the FSF
(and disclaimers from any
The port is to a pure C90 environment (ie not posix, not unix). It was a
major effort to achieve that, and it has only just been completed to the
point where the compiler recompiles itself with full optimization. The
environment where it runs is not set up to run shell scripts or makes
or test s
Wow, what a lot of responses. Last time I tried making
contact, I didn't get a single response!
In addition, that code has been ported to GCC 3.4.6, which is now
working as a cross-compiler at least. It's still some months away
from working natively though. It takes a lot of effort to convert
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more. If there are other problems related to MVS host
I think the EBCDIC support is largely theoretical and not tested on any
actual EBCDIC host (
I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more.
It looks that way from what I've seen of 3.4.6 so far. However, I
won't know for sure until it's on the host and self-generating.
Why are y
3.4.6 made some revamps to the i370 port (compared to 3.2.3), and I
need to make sure those changes have been digested, and no code
has been lost, so that I can pick up the final i370 port and move it.
But there were probably also (mechanical) changes to the port between when
3.4 branched (long
Why are you migrating to 3.4.6 now, instead of to a current version?
If you want to include this in mainline some day, then eventually it
has to be caught up - and 3.4.6 is older than it may appear from the
release date, since it branched off of mainline five years ago. A lot
has changed since th
Hi guys.
The last class of warning I have from the machine definition is this:
./config/i370/i370.md:784: warning: destination operand 0 allows non-lvalue
which is because I have used r_or_s_operand like this:
;
; movdi instruction pattern(s).
;
(define_insn ""
[(set (match_operand:DI 0 "r_o
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
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
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
, 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
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
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
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
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
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
1 - 100 of 138 matches
Mail list logo
