When compiling with the optimalisation level to 6 in place of 2 the code generated isn't valid. It introduce an segmentation fault. The main code line: Line 548: zipname = allocMem_system(j - i + 1); I did compile with -O2 see MYDEBUG, it works! But the -O6 flag (see MYRELEASE) did not work... (the value of parm j and i are changed in and after function call!) MYDEBUG: -O2 2058 .loc 1 548 0 2059 .L158: 2060 1473 89F3 movl %esi, %ebx 2061 1475 29FB subl %edi, %ebx 2062 1477 8D4301 leal 1(%ebx), %eax 2063 147a 89442404 movl %eax, 4(%esp) 2064 147e A1000000 movl W_Realm_system, %eax 2064 00 2065 1483 890424 movl %eax, (%esp) 2066 1486 E8FCFFFF call _allocMem_realm 2066 FF 2067 148b A3000000 movl %eax, zipname 2067 00 2068 1490 89C2 movl %eax, %edx 2069 .loc 1 549 0 MYRELEASE -O6 2100 .loc 1 548 0 2101 .L167: 2102 1575 89F3 movl %esi, %ebx 2103 1577 A1000000 movl W_Realm_system, %eax 2103 00 2104 157c 29FB subl %edi, %ebx 2105 157e 8D5301 leal 1(%ebx), %edx 2106 1581 89542404 movl %edx, 4(%esp) 2107 1585 890424 movl %eax, (%esp) 2108 1588 E8FCFFFF call _allocMem_realm 2108 FF 2109 158d A3000000 movl %eax, zipname 2109 00 2110 1592 89C6 movl %eax, %esi 2111 .loc 1 549 0 Release: gcc 3.2.2 Environment: Linux / Pentium 4 How-To-Repeat: precompiled file and build command is included in attachment. (you can also download wonka and try out)
Fix: do not use -O6
State-Changed-From-To: open->feedback State-Changed-Why: Hi, Thanks for the problem report. Unfortunately, I am unable to reproduce the bug with the code you attached: 1) The RELEASE and DEBUG codes you talk about are not in the preprocessed source. 2) The code you provided seems to rely on other compilation units, i.e. there are undefined references at link time. Can you produce a smaller test case, or at least one without external references? Oh, and I suppose you see this problem with -O3 as well? The highest optimization level for GCC is -O3, if you do -On, n>3, nothing extra happens. Greetz Steven
From: Erik Oosterom <erik.oosterom@chess.nl> To: steven@gcc.gnu.org, eoo@chess.nl, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: optimization/10221: gcc -O9 will introduce wrong asembler? Date: Wed, 26 Mar 2003 15:17:48 +0100 Hi Steven, Thanks for looking to the problem! The codes I did provided are the output of the compiler. (which is different) The source line in the preprocessed source is line 9087, this will be compiled (wrong). I shall try to make an simple example.. Best Regards, Erik steven@gcc.gnu.org wrote: > > Synopsis: gcc -O9 will introduce wrong asembler? > > State-Changed-From-To: open->feedback > State-Changed-By: steven > State-Changed-When: Wed Mar 26 14:02:34 2003 > State-Changed-Why: > Hi, > > Thanks for the problem report. Unfortunately, I > am unable to reproduce the bug with the code you > attached: > > 1) The RELEASE and DEBUG codes you talk about are > not in the preprocessed source. > 2) The code you provided seems to rely on other > compilation units, i.e. there are undefined > references at link time. > > Can you produce a smaller test case, or at least one > without external references? > > Oh, and I suppose you see this problem with -O3 as > well? The highest optimization level for GCC is -O3, > if you do -On, n>3, nothing extra happens. > > Greetz > Steven > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10221 -- Met vriendelijke groet, Erik Oosterom Chess embedded Technology Nieuwe Gracht 13/78 P.O.Box 5021 2000 CA Haarlem, The Netherlands Phone : +31-23-5 149 249 (indirect) Fax : +31-23-5 149 191 Web : http://www.chess.nl Email : mailto:erik.oosterom@chess.nl
Eric, Could you check whether your problem still occurs with gcc 3.3? There have been a number of P- IV optimizing bugs that have been fixed. Also, please note the any optimization level above -O3 is identical to -O3, so -O6 or -O9 will make no difference whatsoever (beyond -O3). Thanks, Dara
Subject: Re: gcc -O9 will introduce wrong asembler? Hi Dara, I shall try the snapshot 20030526, (but i do have not much time), does this include your changes? I understand that 09 is the same as 03, but the make script did use that. I let you know the results. Redgards, Erik
Eric, just a reminder that this bug is still WAITING for feedback. Have you had a chance to check this problem with gcc 3.3? If you want, I can e-mail you the assembly from 3.3 for you to check. Thanks, Dara
Subject: Re: gcc -O9 will introduce wrong asembler? Next week i will have time to look at it. Erik
Subject: Re: gcc -O9 will introduce wrong asembler? Thanks to you but the bugs seems to be solved. :) The problem is a combination of P4 instructions and the -O3 flag.
Just to verify: the problem no longer occurs with gcc 3.3?
Subject: Re: gcc -O9 will introduce wrong asembler? I'am very sorry, i can't work futer on this project. :( Erik
Bug seems to be fixed, and no feedback forthcoming otherwise. W.