Bug 447212 - Macros with For Next loops broken in OpenOffice.org.
Macros with For Next loops broken in OpenOffice.org.
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-18 16:39 EDT by Andrew Pitonyak
Modified: 2008-05-29 12:53 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-29 12:53:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test-case (273.66 KB, text/plain)
2008-05-19 05:31 EDT, Caolan McNamara
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 36187 None None None Never

  None (edit)
Description Andrew Pitonyak 2008-05-18 16:39:18 EDT
Description of problem:
Using the default OpenOffice.org for 64-Bit Fedora 9, the following simple macro
will not work:

Sub TestError
  Dim i As Integer
  For i = 1 To 2
    Print "Hello"
End Sub

The problem is that the Next statement generates an error. This macro should
have always worked. If For next loops do not function, then a large percentage
of macros will likely not function.
Comment 1 Caolan McNamara 2008-05-19 04:48:42 EDT
groan, some optimization problem

void ImpPutDouble( SbxValues* p, double n, BOOL bCoreString )
        SbxValues aTmp;
        switch( +p->eType )
                case SbxINTEGER:
                        aTmp.pInteger = &p->nInteger; goto direct;
                        aTmp.eType = SbxDataType( p->eType | SbxBYREF );
                        p = &aTmp; goto start;
                case SbxBYREF | SbxINTEGER:
                        *p->pInteger = (INT16) n; break;

We have a SbxINTEGER, we change the tmp to SbxBYREF | SbxINTEGER and jump to the
start of the switch but we don't get to the desired case, if I add a simple
printf after p = &aTmp to reference the changed eType then it works
Comment 2 Jakub Jelinek 2008-05-19 05:26:08 EDT
Can I get preprocessed source for the file in question, and command line options
used?  If the arch really ia64, or x86_64?
Comment 3 Caolan McNamara 2008-05-19 05:31:23 EDT
Created attachment 305916 [details]
Comment 4 Caolan McNamara 2008-05-19 05:33:23 EDT
this seems to reproduce this for me

g++ -O2 -fno-strict-aliasing test.ii

g++ -O2 test.ii

and no error. This is x86_64 of course, I only ported ia64 a month or two ago
and there are no fedora ia64 arch team builds yet.
Comment 5 Caolan McNamara 2008-05-19 05:33:55 EDT
Does this reproduce for you standalone ?
Comment 6 Andrew Pitonyak 2008-05-19 08:34:24 EDT
This is certainly x86_64...

I found this problem while writing an article for LinuxIdentity magazine about
Important software in Fedora, and I mention it in the magazine. If you have a
speculation on when this will be fixed and pushed to the repositories, I will
mention something like

"The problem was found and fixed by the Fedora team in less than a day, and the
fix should be in place in <a week or so>".

You are moving fast enough that the fix may be in place before the article is
Comment 7 Jakub Jelinek 2008-05-19 09:12:54 EDT
This has been fixed upstream already, though I don't plan a GCC errata right
now, I'd like to wait at least a month to get 4.3.1 in and gather a bunch of
other bugfixes.  I guess you can work around it in OOo by building this source
file with -fstrict-aliasing if you want to errata OOo before a new gcc will land
into dist-f9 buildroots.
Comment 8 Caolan McNamara 2008-05-19 09:29:37 EDT
Building OOo with -fstrict-aliasing in general right now is unfortunately
impossible, though of course I can force it on for that particular file. 

We've a likely OOo 2.4.1 update around June the 3rd, I guess that's too soon for
a new gcc ?
Comment 9 Jakub Jelinek 2008-05-29 12:53:00 EDT
Closing as upstream.  Whenever I update gcc in rawhide and/or in Fedora 9, it
will get the fix.

Note You need to log in before you can comment on or make changes to this bug.