mf@ircam.ircam.fr (Michel Fingerhut) (08/26/90)
Several public domain large packages of software fail to run correctly when compiled with any of the -O options of cc (under ultrix 3.1 that I know of, and 4.0 according to reports in this group). This is notably true of TeX, and true (according to my experience) with perl. I had reported my problem (perl) to the local Dec branch several months ago, but there still seems to be a major problem around: IS THE OPTIMIZED OUTPUT OF CC W R O N G ? That's important to know, no? So please Dec, if you hear me, what is the situation? Did you compile your kernel, for instance, with optimization or without? Is it safe? PS: We had also reported a cryptic error message from the compiler (in another situation) namely: libmld: Internal: st_pdn_idn: idn (-8) less than 0 or greater than max (3170) and never got a reply what it was all about.
emv@math.lsa.umich.edu (Edward Vielmetti) (08/27/90)
In article <1990Aug25.231005.29864@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:
Several public domain large packages of software fail to run correctly
when compiled with any of the -O options of cc (under ultrix 3.1 that I
know of, and 4.0 according to reports in this group). This is notably
true of TeX, and true (according to my experience) with perl.
There are some known limitations of the mips c compiler, including
the way it deals with volatile & some non-ansi behavior. You have
not yet convinced me that it is the optimizer which is at fault.
Perl compiled here under Ultrix 4.0, fully optimized, after I dealt
with a few small problems (like not having enough memory....)
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>D. Allen [CGL]) (08/27/90)
>Perl compiled here under Ultrix 4.0, fully optimized, after I dealt >with a few small problems (like not having enough memory....) Perl compiled here on a DECsystem 5400 under Ultrix 3.1C using -O -DLANGUAGE_C fails self-tests op.eval #7 and op.s #40. It works fine if I remove the -O. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
hooft@finch.prl.philips.nl (Peter van Hooft 44327) (08/27/90)
In <1990Aug26.214532.17118@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >>Perl compiled here under Ultrix 4.0, fully optimized, after I dealt >>with a few small problems (like not having enough memory....) >Perl compiled here on a DECsystem 5400 under Ultrix 3.1C using -O >-DLANGUAGE_C fails self-tests op.eval #7 and op.s #40. It works fine >if I remove the -O. >-- >-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu > [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada You should ``undef'' volatile in config.sh. The optimizer obviously does funny things with volatile variables. There's the connection :-) Peter van Hooft (hooft@apolloway.prl.philips.nl)
mf@ircam.ircam.fr (Michel Fingerhut) (08/27/90)
I mentioned the problems with PERL UNDER ULTRIX 3.1 (confirmed by at least one other message in this newsgroup) and TEX UNDER 4.0 (according to a report in this group). Your response about PERL UNDER ULTRIX 4.0 did not convince me yet that the compiler is not at fault. Moveover, you write that "Perl compiled here under Ultrix 4.0 fully optimized". Well, it "compiled" here too, WITHOUT ANY ERROR MESSAGES, nothing, it merely failed some of the validation tests. Without any optimizations, it compiled yet again without any error messages, but passed all the tests. I think I can safely infer that there is a SERIOUS problem with the optimizer or some other part of the mips compiler. Finally you mention that "There are some known limitations of the mips c compiler, including the way it deals with volatile & some non-ansi behavior." Either there are limitations, in which case the compiler should complain if these are exceeded, or else there are bugs (e.g.: different behaviors with different main memory sizes).
evans@decvaxdec.com (Marc Evans) (08/28/90)
|> I mentioned the problems with PERL UNDER ULTRIX 3.1 (confirmed by at least |> one other message in this newsgroup) and TEX UNDER 4.0 (according to a report |> in this group). Your response about PERL UNDER ULTRIX 4.0 did not convince |> me yet that the compiler is not at fault. |> |> Moveover, you write that "Perl compiled here under Ultrix 4.0 fully |> optimized". Well, it "compiled" here too, WITHOUT ANY ERROR MESSAGES, |> nothing, it merely failed some of the validation tests. Without any |> optimizations, it compiled yet again without any error messages, but |> passed all the tests. I think I can safely infer that there is a |> SERIOUS problem with the optimizer or some other part of the mips |> compiler. |> |> Finally you mention that "There are some known limitations of the mips c |> compiler, including the way it deals with volatile & some non-ansi behavior." |> Either there are limitations, in which case the compiler should complain if |> these are exceeded, or else there are bugs (e.g.: different behaviors with |> different main memory sizes). Who are you quoting? I know that I posted anm article about the DEC compiler for the MIPS architecture. I don't have a copy of the article handy, but I intended to say that the version of the compiler which is successful is 2.1, which cooresponds to the mipsco version 2.10. The *standard* version of the compiler shipped with ULTRIX 4.0 is 2.0. One way to determine which version you are using is to 'ls -l /usr/bin/cc' and see where the symbolic link points. The way that you get the 2.1 compiler is to order the XPG3 patches for ULTRIX 4.0, which should be available soon (at the very least in field test). I will agree that the 2.0 version of the compiler has many problems when it comes to -O* compilation. Perl tends to find some of these problems. As far as certain ANSI features, yes, it does complain about the ones it doesn't know how to handle, such as 'const'. 'volatile' however, it does attempt to handle, but appears to have problems. Therefore, when building perl set the volatile flag in config.sh to undef and you shouldn't have any problems. - Marc -- ======================================================================== ==== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876 Unix and X Software Contractor | 21 Hinds Ln, Pelham, NH 03076 ======================================================================== ====