Ata@system-m.phx.bull.com (John G. Ata) (03/01/91)
Manx knows about this bug but chose not to fix it. You can get around
this problem by optimizing (-so). It still exists in 5.0d, but haven't
tried 5.0e yet.
Johnchucks@pnet51.orb.mn.org (Erik Funkenbusch) (03/03/91)
Ata@system-m.phx.bull.com (John G. Ata) writes: >Manx knows about this bug but chose not to fix it. You can get around >this problem by optimizing (-so). It still exists in 5.0d, but haven't >tried 5.0e yet. > > John funny, the 5.0e release is just a cc replacement, and it still says 5.0d when you run it. wonders will be wonders. speaking of Aztec 5.0. I'm trying to write some pure code. i understand not to reference any globabl variables such as stdin, stdout, errno, etc. the old aztec had a resident startup code, this is missing now, however going through the supplied startup code i notice many things that are allocated dynamically. is this startup code also re-entrant? i see a problem with the global device table. even though the space is allocated dynamically, the reference is still global. does this mean i can't use any manx dos routines if i want re-entrant code? anyone with some experience, help would be appreciated. UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
Ata@system-m.phx.bull.com (John G. Ata) (03/04/91)
There is a Manx 5.0e on the Manx BB. However, after downloading it, it
still prints out "Manx 5.0d September 30, 1990" with the only change
being the date from Sep 28 to Sep 30. It does not fix the "too complex"
problem. This problem has a simple test case where the line:
name [*cpos] = fname [*cpos]; causes the error. name and
fname are character arrays and cpos points to an integer. Doesn't sound
too complex to me, but Manx didn't see it that way. When I use the -so
option, the problem goes away. It must be either the -so option, or one
of the optimize options which makes the problem go away. Not all
optimize options will work, but only a specific one which -so includes.
Johnbj@cbmvax.commodore.com (Brian Jackson) (03/04/91)
In article <46418@nigel.ee.udel.edu> Ata@system-m.phx.bull.com (John G. Ata) writes: >There is a Manx 5.0e on the Manx BB. However, after downloading it, it >still prints out "Manx 5.0d September 30, 1990" with the only change >being the date from Sep 28 to Sep 30. It does not fix the "too complex" >problem. This problem has a simple test case where the line: > name [*cpos] = fname [*cpos]; causes the error. name and >fname are character arrays and cpos points to an integer. Doesn't sound >too complex to me, but Manx didn't see it that way. When I use the -so >option, the problem goes away. It must be either the -so option, or one >of the optimize options which makes the problem go away. Not all >optimize options will work, but only a specific one which -so includes. > > John I really don't want to play the role of Manx spokesman, here, but they told me on the phone the other day that the 5.0e1 "fix" fixed *only* the "shared library with no function arguments" problem and only that one. They said that they are working on a release that will "fix all known bugs". RSN. bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "We defy augury" | -----------------------------------------------------------------------
cgehman@hubcap.clemson.edu (Corey Gehman) (03/04/91)
Ata@system-m.phx.bull.com (John G. Ata) writes: >When I use the -so >option, the problem goes away. It must be either the -so option, or one >of the optimize options which makes the problem go away. Not all >optimize options will work, but only a specific one which -so includes. > John Well, my problem didn't get fixed with the -so option. Here's the smallest I could convert the problem down to: #define FABS(x) ((x) < 0.0 ? (0.0 - (x)) : (x)) double test() { double i,j; return (FABS ( i - j ) + FABS ( i - j ) + FABS ( i - j )); } Here's my error messages with serveral different options: 1> cc test Aztec C 5.0b Jun 18 1990 (C) 1990 by Manx Software Systems, Inc. return (FABS ( i - j ) + FABS ( i - j ) + FABS ( i - j )); test.c:8: ERROR 167: expression too complex - use -MR option: 1> cc -mr test Aztec C 5.0b Jun 18 1990 (C) 1990 by Manx Software Systems, Inc. return (FABS ( i - j ) + FABS ( i - j ) + FABS ( i - j )); test.c:8: ERROR 167: expression too complex - use -MR option: 1> cc -so test Aztec C 5.0b Jun 18 1990 (C) 1990 by Manx Software Systems, Inc. } test.c:8: ERROR 167: expression too complex - use -MR option: 1> cc -mr -so test Aztec C 5.0b Jun 18 1990 (C) 1990 by Manx Software Systems, Inc. } test.c:8: ERROR 167: expression too complex - use -MR option: I've "fixed" the problem by using a subroutine instead of a macro but since I often port software from unix to the amiga I don't want to do that everytime. I don't know if 5.0d version with the -so option works or not. I've ordered a new version but it hasn't got here yet (I don't want to pay large phone bills OK?). -- ------------------------------------------------------------------------------- | Corey Gehman | "you will get to watch the Amiga | | cg377170@lion.eng.clemson.edu | FIREWORKS_DISPLAY mode." | | cgehman@hubcap.clemson.edu | - Intuition Reference Manual |
huver@amgraf.UUCP (Huver) (03/06/91)
cgehman@hubcap.clemson.edu (Corey Gehman) wrote: >Well, my problem didn't get fixed with the -so option. Here's the >smallest I could convert the problem down to: > > >#define FABS(x) ((x) < 0.0 ? (0.0 - (x)) : (x)) > >double test() >{ >double i,j; > > return (FABS ( i - j ) + FABS ( i - j ) + FABS ( i - j )); >} > ... > > I've "fixed" the problem by using a subroutine instead of a macro > but since I often port software from unix to the amiga I don't want > to do that everytime. I don't know if 5.0d version with the -so > option works or not. Now I'm not picking on you, but for the particular example, do: #include <math.h> #define FABS(x) fabs(x) /* rest of your code */ and it works just fine; in fact I'd change all FABS() to fabs() calls and forget about the macro form. The fabs() is a standard UNIX library function (System V) which, if you're bringing "software from unix", should've been used by the original code. Whatever your UNIX, grep fabs from <math.h> and see. The Manx bug is quite interesting though. With 5.0d/e on your posted code as is, the -f8 (881 code) option generates absolutely no problem whatsoever, all other -fX options fail. Looks like a compiler intended for 020/881 as a standard platform. :^) -huver