Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | patches for sparc linux gcc-3.3 spreadsheet crashes | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | porting | Reporter: | sparcmoz <sparcmoz> | ||||||
Component: | code | Assignee: | Martin Hollmichel <nesshof> | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@porting <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P3 | CC: | issues, ooo | ||||||
Version: | OOo 1.1 RC2 | ||||||||
Target Milestone: | OOo 2.0 | ||||||||
Hardware: | Other | ||||||||
OS: | Linux, all | ||||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Issue Depends on: | |||||||||
Issue Blocks: | 17420 | ||||||||
Attachments: |
|
Description
sparcmoz
2003-08-02 09:24:00 UTC
Created attachment 8218 [details]
cellsuno patch
Created attachment 8219 [details]
token.cxx patch
these patches needed to prevent spreadsheet crashes when building with gcc-3.3 on sparc linux sparc linux retarget to ooo2 moving from gcc-3.2.3 up to gcc-3.3 finds more spreadsheet files need compile with no optimisation. as these errors only show up at runtime when performing various operations in spreadsheet, i wonder if there are more of these crashes that i have not found yet. there must be a better way to prevent these things, not just wait for a crash and then rebuild with no optimisation? does this affect other platforms or is it just a sparc linux compiler issue? and what about sw and sd - i have not tested those much yet... retarget sparc linux ooo2 i have to confirm this myself, since there is no-one else building on sparc linux? I gave you the "can confirm" privileges. As no-one else builds linux sparc yet, I confirm this issue based on my stacktraces above. The problem goes away when those two files are compiled without optimisation. Perhaps this is a compiler issue as it seems to affect linux sparc more, but i notice other platforms have some NOOPT files too, different ones. Much testing will be needed to see if other files have this problem. Meanwhile the first contrib version has all of sc module compiled without optimisation, to be safer for users. I would like advice - would it be OK to also release a "test" version having sc module compiled WITH optimisation so users can help find more problems? Would it be best to keep these patches out of the cvs until the answer is known? Just a question: was the gcc -fno-strict-aliasing option used? If not, please do so and try again. Hi, i have made -fno-strict-aliasing my default in solenv/inc/unxlngs.mk ever since your very helpful advice in issue 17301, and that is used for sc too. Here are some later NOOPT files i have added but i have not gone back yet to check in case some earlier ones are no longer needed. I notcice some NOOPT files for all platforms too. (1)changed from gcc-3.2.3 to gcc-3.3.1 (list filter) unobj/cellsuno core/tool/token (2) changed from -O1 to -O2 (goal seek) core/tool/interpr2 Now i am using gcc-3.3.2 (debian) and -O3. Please note i get very many warning messages - for example about the overloaded == functions. Are these important? So far almost every compiler had some optimization problems now and then, in different places of course, so there are some NOOPT entries for most platforms, except Windows where you can toggle optimization by means of a #pragma on function level. However, I have not the slightest idea what may cause all the sudden crashes with your new gcc-3.3 version, this would have to be inspected on an assembler level. Only that I don't have the time nor the machine to do so. I guess there is a common cause for most optimization crashes, similar to the aliasing problem we had. What warnings about overloaded == functions are you referring to? Could you give an example please? This message appears for very many files when compiling sc In file included from ../../../inc/document.hxx:95, from ../inc/docsh.hxx:87, from /usr/local/oo_src/sc/source/ui/unoobj/cellsuno.cxx:121: ../../../inc/tabopparams.hxx: At global scope: ../../../inc/tabopparams.hxx:124: warning: ISO C++ forbids declaration of `operator==' with no type Now i see this in tabopparams.hxx: return *this; } operator ==( const ScInterpreterTableOpParams& r ) { return bValid && r.bValid && aOld1 == r.aOld1 && Just for an experiment i did guess BOOL and recompiled: BOOL operator ==( const ScInterpreterTableOpParams& r ) and the messages went away and sc seemed to work OK (but it did not fix the NOOPTS problem). There are some other operator== without types too. I suppose the warnings might become errors in some future gcc but it is OK for now. I only mention these warnings in case it means something to you, i am not asking anything to be done. The other one with no type is from far away... In file included from /usr/local/oo_src/sc/source/ui/app/seltrans.cxx:75: /usr/local/oo_src/solver/645/unxlngs.pro/inc/sfx2/docfile.hxx:157: warning: `class SfxPoolCancelManager' only defines a private destructor and has no friends In file included from /usr/local/oo_src/solver/645/unxlngs.pro/inc/svx/svdotext.hxx:74, from /usr/local/oo_src/solver/645/unxlngs.pro/inc/svx/svdorect.hxx:66, from /usr/local/oo_src/solver/645/unxlngs.pro/inc/svx/svdograf.hxx:69, from /usr/local/oo_src/sc/source/ui/app/seltrans.cxx:77: /usr/local/oo_src/solver/645/unxlngs.pro/inc/svx/svdtrans.hxx:90: warning: ISO C++ forbids declaration of `nWinkDiv' with no type Sigh.. yes, of course the operator== should return a BOOL. in fact I'm quite surprised that not any compiler treats the missing return type as an error. The nWinkDiv seems to be intended as an int. However, if used as shown in the example given in svx/inc/svdtrans.hxx (nWinkDiv*double) it should be a double in order to not produce wrong roundoff errors. This should be clarified with the Graphics project's team, who are probably users of that stuff, if any at all. With a short grep I didn't find any further operator== declarations without return type information within Calc. Could you please file separate issues against the projects where this happens or any missing type information occurs? Thank you. There are no more ==operator warnings, sorry i was mixed up. I have now filed issue 18988 to manage the warnings about functions with no types. Thanks. May I asume that all Calc patches went there and this issue here now is superfluous and may be closed? OK, this issue is closed as the NOOPT patches have gone to issue 18988. close issue. |