wehr@fmeed1.UUCP (Bruce Wehr) (11/08/89)
We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running
HP-UX 6.5 with the optimizer caused the compiler to hang on these files:
eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had
to be manually compiled without the optimizer (we told Configure to use
-O).
Has anyone else experienced this, or should I start looking for
something I did wrong? Any help would be appreciated.
--
Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
(...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu)
Ford Motor Company - Electronics Division
17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039piet@cs.ruu.nl (Piet van Oostrum) (11/09/89)
In article <4413@fmeed1.UUCP>, wehr@fmeed1 (Bruce Wehr) writes:
`We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running
`HP-UX 6.5 with the optimizer caused the compiler to hang on these files:
`eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had
`to be manually compiled without the optimizer (we told Configure to use
`-O).
`
I can't remember exactly, but in my Makefile I have +O1 rather than -O. I
think it was because -O didn't work. I have also used gcc with -O, but that
seemed to generate slower code!!.
--
Piet* van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806 Uucp: uunet!mcsun!hp4nl!ruuinf!piet
Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')wehr@fmeed1.UUCP (Bruce Wehr) (11/10/89)
I would like to thank everyone who responded to my plea for HP optimizer
help with Perl 3.0. These steps are what I did to get off the ground:
1) edit config.sh: change optimize from -O to +O1
2) edit config.sh: change d_pwage from define to undef
(This actually fixes a bug not related to the optimizer)
3) re-run all .SH files (including x2p/*.SH)
4) re-make the whole thing
I now have Perl 3.0 Patchlevel 1 up and running. Again, thanks!
--
Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
(...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu)
Ford Motor Company - Electronics Division
17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039edwin@praxis.cs.ruu.nl (Edwin Kremer) (11/10/89)
In article <4413@fmeed1.UUCP> wehr@fmeed1.UUCP (Bruce Wehr) writes: > We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running > HP-UX 6.5 with the optimizer caused the compiler to hang on these files: > eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had > to be manually compiled without the optimizer (we told Configure to use > -O). Refer to the chapter of about the C optimizer in your HP-UX 6.5 Upgradenotes file. The -O flag causes the peephole optimizer to use the highest implemented optimize level. This is not properly implemented; I've a few pieces of C code that either crash or hang the compiler. I always use "+O1", that causes the compiler to use the usual (6.2) optimize level. --[ Edwin ]-- -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone : +31 - 30 - 534104 | Telefax: +31 - 30 - 513791 E-Mail: edwin@cs.ruu.nl | UUCP to: ...!hp4nl!ruuinf!edwin
mart@ele.tue.nl (Mart van Stiphout) (11/10/89)
In article <4413@fmeed1.UUCP> wehr@fmeed1.UUCP (Bruce Wehr) writes: >We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running >HP-UX 6.5 with the optimizer caused the compiler to hang on these files: >eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had >to be manually compiled without the optimizer (we told Configure to use >-O). Hi, I've had some problems too on our HP 9000/800, athough only file eval.c had to be compiled manually without the -O option. All other files compiled correct. After compiling all the files I got an error message from ld: /bin/ld: Target of conditional branch is out of range Reference from: /lib/libc.a(syscall.o)(0x3c) /bin/ld: Invalid fixups exist *** Error code 1 Anyone got an explanation for this one? Can I avoid this error? (BTW: Configure thought HPUX was somekind of bsd) -- Mart van Stiphout mart@ele.tue.nl (It's not the fall that kills you, it's the sudden stop)
mjs@hpfcso.HP.COM (Marc Sabatella) (11/11/89)
>Refer to the chapter of about the C optimizer in your HP-UX 6.5 >Upgradenotes file. The -O flag causes the peephole optimizer to >use the highest implemented optimize level. This is not properly >implemented; I've a few pieces of C code that either crash or hang >the compiler. I always use "+O1", that causes the compiler to use >the usual (6.2) optimize level. Don't blame the peephole optimizer, the global optimizer invoked by -O is an entirely new product for 6.5 And yes, there are known bugs, which have been fixed for 7.0. But it is not so bad (at 6.5) that you should should always use +O1. -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder) (11/11/89)
In article <4432@fmeed1.UUCP> wehr@fmeed1.UUCP (Bruce Wehr) writes: > 1) edit config.sh: change optimize from -O to +O1 I have had problems too with using the -O flag and could fix them by going to +O1. What am I actually loosing by not getting the +O2 optimizations? I noticed that the difference between -g and -O can be amazing when it comes to speed, so I am reluctant to give up any optimizations. Concretely the problems have been errors of the form: cc: Ncolor: Out of memory: get_wbset. (6284) cc: Bit vectors: Set out of memory. (6355) cc: Ncolor: Out of memory: init. (6281) cc: Aliaser: Out of memory. (6200) cc: Local dataflow: Out of memory. (6270) (One time the compiler actually printed something to the effect that I should call HP...) What do these mean? I noticed in the man page for cc that for the 300 series you can set various obscure limits inside cc with command line switches (and we used those at times to compile very large things) but apparently these switches are not supported on the 800 (which is what I am using, version 3.1). Are the hidden switches that could help me to get around problems of the above kind? BTW, all these errors occured when building cfront 2.0, if you are interested in more details, mail me. Thanks for your help! Peter peter@media-lab.media.mit.edu
wehr@fmeed1.UUCP (Bruce Wehr) (11/11/89)
In article <379@euteal.ele.tue.nl>, mart@ele.tue.nl (Mart van Stiphout) writes: > athough only file eval.c had to be compiled > manually without the -O option. All other files compiled correct. > After compiling all the files I got an error message from ld: > [msg deleted] > Anyone got an explanation for this one? Can I avoid this error? You might try compiling everything with +O1 instead of -O, or without optimization at all. > (BTW: Configure thought HPUX was somekind of bsd) Strictly because SIGTSTP is in <sys/signal.h>. HP-UX is more SysV than BSD (from an applications point of view), but it has a *lot* of BSD extensions. I had to comment out the d_pwage stuff, but things went fine after that. I don't know if this will cause other problems for anyone else. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039
msa@rwing.UUCP (Mark Anacker) (11/11/89)
In article <4413@fmeed1.UUCP>, wehr@fmeed1.UUCP (Bruce Wehr) writes: > We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running > HP-UX 6.5 with the optimizer caused the compiler to hang on these files: > eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had > to be manually compiled without the optimizer (we told Configure to use > -O). > Has anyone else experienced this, or should I start looking for > something I did wrong? Any help would be appreciated. Yup, did the same thing to me, with the same workaround. Only on our system, x2p/walk.c did compile (at least I think it did... :). I guess some things were not meant to optimize :)... -- Mark Anacker, Seattle WA msa@toybox -or- msa@rwing "...I'd like to lie, shipwrecked and comatose, drinking fresh mango juice..." - theme from Red Dwarf
paul@mecazh.UUCP (Paul Breslaw) (11/14/89)
wehr@fmeed1.UUCP (Bruce Wehr) writes: > We just got Perl 3.0 from c.s.u. Making it on our HP 9000/370 running > HP-UX 6.5 with the optimizer caused the compiler to hang on these files: > eval.c (&& teval.c), toke.c (&& ttoke.c), x2p/walk.c. These files had > to be manually compiled without the optimizer (we told Configure to use > -O). > Has anyone else experienced this, or should I start looking for > something I did wrong? Any help would be appreciated. I think the easiest advice is NEVER EVER to compile PD software (or anything that you do not know initimately) with the HP pessimiser. For example, the following programs will run correctly under HP-UX6.5 when compiled without the -O switch, and will break here and there with the -O switch:- xdvi thack gnu emacs 18.52 perl 3.0 I am not interested in people offering advice about:- "module foo.c being the culprit, and the rest of the program compiles nicely with -O, oh as long as it is not the first Friday of the month, and there are no black cats on the way to work" Either an optimiser works correctly as often as the rest of the compiler, or you can forget about it. There is nothing worse than trying to debug a program whose bugs disappear with the -g switch (== ~-O). Paul Breslaw -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Paul Breslaw, Mecasoft SA, | telephone : 41 1 362 2040 Guggachstrasse 10, CH-8057 Zurich, | e-mail : mcvax!mecazh!paul Switzerland. | paul@mecazh.UUCP
daryl@hpcllla.HP.COM (Daryl Odnert) (11/14/89)
Peter Schroeder writes: > I have had problems too with using the -O flag and could fix them by > going to +O1. What am I actually loosing by not getting the +O2 optimizations? On the s800, Level one optimization is "local" optimization. Local optimizations are limited in scope to a single basic block of code (i.e. straight-line sequence of instructions.) Level two optimization (what you get when you use -O) is "global" optimization. In this case, the compiler considers the entire procedure to enable optimizations that cross basic block boundaries. Typically, the most important level 2 optimizations (that don't get done at level 1) are the loop optimizations, coloring register allocation, and register promotion of variables. > cc: Ncolor: Out of memory: get_wbset. (6284) <etc> > cc: Local dataflow: Out of memory. (6270) > > What do these mean? I noticed in the man page for cc that for the 300 > series you can set various obscure limits inside cc with command line > switches (and we used those at times to compile very large things) but > apparently these switches are not supported on the 800 (which is what > I am using, version 3.1). Are the hidden switches that could help me > to get around problems of the above kind? These messages mean the compiler is running out of virtual memory. (Surprise, surprise :-) How much swap space do you have configured on your system? You may be able to fix this problem by increasing your swap space. No, there are no hidden switches on the s800 to help you expand the optimizer's data structures. Regards, Daryl Odnert daryl@hpda.hp.com HP California Language Lab
wehr@fmeed1.UUCP (Bruce Wehr) (11/16/89)
In article <368@node17.mecazh.UUCP>, paul@mecazh.UUCP (Paul Breslaw) writes: > I think the easiest advice is NEVER EVER to compile PD software (or > anything that you do not know initimately) with the HP pessimiser. That's good :-) I'll have to remember that one. > Either an optimiser works correctly as often as the rest of the compiler, > or you can forget about it. I couldn't agree more. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, ETC Room LN081, Dearborn, Michigan 48121 (313)845-3039
hwt@.uucp (Henry Troup) (11/21/89)
In article <7370029@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes: >Don't blame the peephole optimizer, the global optimizer invoked by -O is an >entirely new product for 6.5 > >And yes, there are known bugs, which have been fixed for 7.0. > >But it is not so bad (at 6.5) that you should should always use +O1. I'd beg to differ... an optimizer (level) known to be bad is not something I want to mess with. The creation of undebuggable failures is less than pleasant. We found out about this optimizer when one compile looped forever - as the code being compiled was another company's very proprietary product (the representative of that company brought the source tape, supervised loading, we tried it, sealed the tape and sent it to the vault) - I could not usefully report this. Anyway, can you say 'beta test' ? Henry Troup - BNR owns but does not share my opinions ..utgpu!bnr-vpa!bnr-fos!hwt%bmerh490 or HWT@BNR.CA
hans@inmic.se (Hans Berggren) (11/24/89)
There is a bug in the C-optimizer distributed with HP-UX 6.5. Ask your
SE for a patched version.
A temporarily work around can be to compile with a lower optimizer
level, +01, or no optimization at all.
--
Hans Berggren
Swedish Institute of Microelectronics, IM
PO Box 1184, S-164 21 KISTA, SWEDEN
Tel: +46 8 752 11 44 Telex: 128 75 INMIC S Fax: +46 8 750 54 30
UUCP: {uunet,mcvax,munnari,ukc,unido}!sunic!inmic.se!hans
Internet: hans@inmic.semjs@hpfcso.HP.COM (Marc Sabatella) (11/28/89)
>>But it is not so bad (at 6.5) that you should should always use +O1. > >I'd beg to differ... an optimizer (level) known to be bad is not something >I want to mess with. The creation of undebuggable failures is less than >pleasant. I disagree. If your program fails with optimization turned on, but not when turned off, at least you can be fairly certain the problem is due to the optimizer, and modify your makefile to use +O1. Seems to me this is easier than spending hours setting breakpoints, watching variables, etc. In any case, "bad" is a relative term; I know of no optimizers with a better track record for the first release, and there are probably no completely bug-free optimizers out there even now. And as I said earlier, all bugs which were reported on 6.5 have been fixed for 7.0. >Anyway, can you say 'beta test' ? We can, and we do. Our beta sites uncovered several problems which we diligently fixed. We spend a lot of time per release in QA (this is one thing that differentiates HP from many of our competitors). Our biggest problem (as a company) may be the long delay between a bug report and a fix reaching the customer; this is in part due to our long release cycle - often code is frozen months before a release. We do welcome your bug reports. The STARS system is the normal way of reporting bugs, and we encourage customers to use it. comp.sys.hp often provides a faster channel directly to the engineers, but it is not usually the best way to submit bug reports. -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
darrylo@hpnmdla.HP.COM (Darryl Okahata) (11/28/89)
In comp.sys.hp, mjs@hpfcso.HP.COM (Marc Sabatella) writes: > >Anyway, can you say 'beta test' ? > > We can, and we do. Our beta sites uncovered several problems which we > diligently fixed. We spend a lot of time per release in QA (this is > one thing that differentiates HP from many of our competitors). Our > biggest problem (as a company) may be the long delay between a bug > report and a fix reaching the customer; this is in part due to our > long release cycle - often code is frozen months before a release. I would also like to say that forthcoming compilers are being beta-tested by a number of HP divisions, across North America and, quite possibly, the world (I imagine that HP divisions in Australia, Japan, England (& Scotland), and Germany are taking part in the test, but I have no proof of this -- it's just that it is so easy to get a beta copy of a compiler in minutes via HP's internal internet network, that I have trouble imagining that no one at one of these divisions has grabbed a copy). -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hpcea.HP.COM DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.