Bug 447212
| Summary: | Macros with For Next loops broken in OpenOffice.org. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Pitonyak <andrew> | ||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | caolanm, jakub, jnavrati | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-29 16:53:00 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
groan, some optimization problem
void ImpPutDouble( SbxValues* p, double n, BOOL bCoreString )
{
SbxValues aTmp;
start:
switch( +p->eType )
{
...
case SbxINTEGER:
aTmp.pInteger = &p->nInteger; goto direct;
...
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
Can I get preprocessed source for the file in question, and command line options used? If the arch really ia64, or x86_64? Created attachment 305916 [details]
test-case
this seems to reproduce this for me g++ -O2 -fno-strict-aliasing test.ii ./a.out error g++ -O2 test.ii ./a.out 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. Does this reproduce for you standalone ? 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 published. 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. 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 ? Closing as upstream. Whenever I update gcc in rawhide and/or in Fedora 9, it will get the fix. |
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" Next 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.