richd@emperor.scs.com (Richard Doherty) (05/09/91)
I have a large program (that loads several other large libraries) that dies with a segmentation violation. If I shut off the optimizer with the -dba flag, the program works flawlessly. Apollo customer support could provide no clues. Question: Has anyone discovered optimizer problems? Details: The program is ported from a Sun system, where it works fine on full optimization. Saber-C passed the program with no errors or warnings running in full interprative mode (for those who don't have this good tool -- this process will find things such as uninitialized variables and memory at wanders). Again, the program runs correctly with optimization turned off on the Apollo. Machine: HP 400t OS: SR10.3.2 CC Version: 5.7 The customer rep suggested several things: 1) Trying the compilation at several different levels of optimization. I have not done this yet, as it will not likely give me any clues. 2) Look for uninitialized variables. I believe I have this covered. I ran dde on the optimized code, and it reported all sorts of optimizations that were somewhat hard to believe. Several library routine calls were merged, when in fact they were referencing different routines. Lines of code were reported merged that made no sense. I decided dde was lying and ignored it. Dde often contradicted itself. Dbx produces a segmentation fault so often as to make the tool useless on the apollo. I would like to distill the code to a very simple program that would produce the same results, so I can send it to apollo. This may be difficult. --Rich
rehrauer@apollo.HP.COM (Steve Rehrauer) (05/09/91)
In article <1520@fang.dsto.oz> agq@itd1.dsto.oz (Ashley Quick) writes: >richd@emperor.scs.com (Richard Doherty) writes: >>Question: Has anyone discovered optimizer problems? > >Yes. > >I have had a program which uses DOMAIN/OS mailbox calls, >and have had exactly the problem you describe. These calls >take a pointer to some storage, and fill that spot up with stuff. > >With the optimiser on, the program (only about 50 lines long) crashes >with a segmentation violation. When off, works fine. I tried >the various different optimiser levels, and found that it broke >at levels 3 and above (I think... it was a year ago). >No I have not reported this to HaPollo :-) SIGH. Please DO report such problems. We *LOVE* APRs with 50-line programs that fail in simple ways. :-) Seriously, I know many of you have aired complaints about response-time -- I'm just a poor engineer on the receiving end, and sometimes for whatever reason I don't always receive -- but PLEASE don't just ignore a problem. Your short little program may've already been fixed in the latest compiler, or it may have serendipitously uncovered a bug that causes the latest 50,000-line Fortran monster on my platter to fail. -- "The goons are riding motorcycles, but WE'VE | (Steve) rehrauer@apollo.hp.com got a whole big metal car! This will be like | Hewlett-Packard stepping on ants..." -- Freelance Police | Massachusetts Languages Lab
agq@itd1.dsto.oz (Ashley Quick) (05/10/91)
richd@emperor.scs.com (Richard Doherty) writes: >I have a large program (that loads several other large libraries) >that dies with a segmentation violation. If I shut off the optimizer >with the -dba flag, the program works flawlessly. Apollo customer >support could provide no clues. >Question: Has anyone discovered optimizer problems? Yes. I have had a program which uses DOMAIN/OS mailbox calls, and have had exactly the problem you describe. These calls take a pointer to some storage, and fill that spot up with stuff. With the optimiser on, the program (only about 50 lines long) crashes with a segmentation violation. When off, works fine. I tried the various different optimiser levels, and found that it broke at levels 3 and above (I think... it was a year ago). To add to HaPollos embarrasment, one of the domain example programs used to break in the same way. (Dont know if it still does... that was under SR10.1). I tried: 1. Examine the assembler code from the C compiler. The optimiser puts lots of things into registers, and it was all so hard to follow I gave up. 2. Compile the equivalent Pascal program with different levels of optimisation. They all worked fine. Eventually, I gave up. I decided that the optimser did not matter a lot to me!!!!! No I have not reported this to HaPollo :-) Regards... Ashleigh Quick | ACSnet: AGQ@dstos3.dsto.oz Defence Science and Technology Organisation| Internet: AGQ@dstos3.dsto.oz.au PO Box 1600 | Phone: (Intl) (+61 8) 259 6975 Salisbury 5108 AUSTRALIA | (Local) (08) 259 6975
volf@ebs.eb.ele.tue.nl (frank volf) (05/10/91)
In article <51760d86.20b6d@apollo.HP.COM> rehrauer@apollo.HP.COM (Steve Rehrauer) writes > [stuff deleted] > SIGH. Please DO report such problems. We *LOVE* APRs with 50-line > programs that fail in simple ways. :-) Seriously, I know many of Well in that case, here is a pascal compiler optimizer problem. The program is very small (Yes, I know it is not a useful program!) and it fails in a very simple way: the pascal compiler keeps optimizing for ever and never returns my shell prompt!. Here it is: ebs{volf}[//ebg/users/volf/temp] 11 > cat test.pas program test; begin repeat until false; end. ebs{volf}[//ebg/users/volf/temp] 12 > pas test.pas -opt 0 No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.8(159) ebs{volf}[//ebg/users/volf/temp] 13 > pas test.pas -opt 1 Compiler backend failure while processing routine "test" ^ ! This messages appears if you kill the process after several {minutes, hours}. BTW: we run SR10.3 and release 8.8 of the pascal compiler. Frank Volf (volf@eb.ele.tue.nl) Eindhoven University of Technology Digital Systems Group, Room EH10.16 P.O. 513, 5600 MB Eindhoven, The Netherlands
rehrauer@apollo.HP.COM (Steve Rehrauer) (05/11/91)
In article <1142@eba.eb.ele.tue.nl> volf@ebs.eb.ele.tue.nl (frank volf) writes: >Well in that case, here is a pascal compiler optimizer problem. The program is very small >(Yes, I know it is not a useful program!) and it fails in a very simple way: the pascal >compiler keeps optimizing for ever and never returns my shell prompt!. (I hope no one takes it the wrong way when I say "thanks for the laugh". :-) Pretty silly behaviour, yes. Okay, it's been fixed. (You needn't bother to file an APR for *this* one, thanks. :-) -- "The goons are riding motorcycles, but WE'VE | (Steve) rehrauer@apollo.hp.com got a whole big metal car! This will be like | Hewlett-Packard stepping on ants..." -- Freelance Police | Massachusetts Languages Lab
agq@fang.dsto.oz (Ashleigh Quick) (05/14/91)
In article <51760d86.20b6d@apollo.HP.COM> rehrauer@apollo.HP.COM (Steve Rehrauer) writes: >In article <1520@fang.dsto.oz> agq@itd1.dsto.oz (Ashley Quick) writes: !>richd@emperor.scs.com (Richard Doherty) writes: !>>Question: Has anyone discovered optimizer problems? !> !>Yes. !> !>I have had a program which uses DOMAIN/OS mailbox calls, !>and have had exactly the problem you describe. These calls !>take a pointer to some storage, and fill that spot up with stuff. !> !>With the optimiser on, the program (only about 50 lines long) crashes !>with a segmentation violation. When off, works fine. I tried !>the various different optimiser levels, and found that it broke !>at levels 3 and above (I think... it was a year ago). ! !>No I have not reported this to HaPollo :-) > >SIGH. Please DO report such problems. We *LOVE* APRs with 50-line >programs that fail in simple ways. :-) Seriously, I know many of >you have aired complaints about response-time -- I'm just a poor >engineer on the receiving end, and sometimes for whatever reason >I don't always receive -- but PLEASE don't just ignore a problem. >Your short little program may've already been fixed in the latest >compiler, or it may have serendipitously uncovered a bug that causes >the latest 50,000-line Fortran monster on my platter to fail. >-- >"The goons are riding motorcycles, but WE'VE | (Steve) rehrauer@apollo.hp.com > got a whole big metal car! This will be like | Hewlett-Packard > stepping on ants..." -- Freelance Police | Massachusetts Languages Lab A thousand humble apologies. As I said in my original posting, the problems I saw were under SR10.1 and I cannot remember which version of the C compiler. I have just checked the offending programs (mbx_server.c and mbx_client.c) under SR10.3 and C compiler 68K Rev 6.7(316). They run fine! (But: I had to remove the fudges in mbx_client.c which explicity redefined NULL and then included stdio which promptly redefined it....... Perhaps the DOMAIN EXAMPLES could be revised?) So... Sorry for leading you up the garden path! :-) It appears the problem has been cured. Regards Ashleigh Quick AGQ@dstos3.dsto.oz.au