[Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work

[Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work

[dick_guertin at yahoo dot com]

~> which gcc
/usr/pubsw/bin/gcc

elaine:~> gcc -v
Reading specs from
/afs/ir.stanford.edu/systems/@sys/pubsw/package/Languages/gcc-3.4.4/sun4x_58/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4/specs
Configured with: ../../gcc-3.4.4/configure --datadir=/lib --libexecdir=/lib
--sharedstatedir=/lib --prefix=/usr/pubsw --enable-threads --with-gnu-as
--with-as=/usr/pubsw/bin/as --with-gnu-ld --with-ld=/usr/pubsw/bin/ld
--with-libintl-

prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw
Thread model: posix
gcc version 3.4.4

vine:~> gcc -v
Reading specs from
/afs/ir.stanford.edu/systems/i386_linux24/pubsw/package/Languages/gcc-3.4.4/i386_linux24/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../../gcc-3.4.4/configure --datadir=/lib --libexecdir=/lib
--sharedstatedir=/lib --prefix=/usr/pubsw --enable-threads --with-gnu-as
--with-as=/usr/pubsw/bin/as --with-gnu-ld --with-ld=/usr/pubsw/bin/ld
--with-libintl-

prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw
Thread model: posix
gcc version 3.4.4

This 'bug' appeared with the introduction of version 3.4.4.  On all
other platforms, the code compiles and executes properly.  This includes
Mac OSX on a G3 and G4, RedHat Linux on i386, and Solaris on Sun's
sparc.  This code is also shared between another i486 and sparc machine,
as shown above.

I deleted all objects (.o), and created a new Makefile using 'xmkmf'
with an Imakefile.  I then compile and built the target program with
'make'.  The Makefile had -O2 optimization by default (created by xmkmf).

When I tried to execute the target program, it failed, as follows:

(gdb) run
Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x0021ff6c in rlookup ()
#2  0x0021fbd8 in nscan ()
#3  0x00223778 in NSCAN ()
#4  0x00026d9c in EDTBASE ()
#5  0x000277c0 in EDTCOM ()
#6  0x00224348 in signon ()
#7  0x0001c418 in startpw ()
#8  0x00102070 in main ()

I started over, deleted all objects, and changed -O2 to -O in the
Makefile.  This version compiled and executed properly.  The same was
true when I tried -g in place of -O or -O2.  So -O2 code fails to
execute properly, but -O code works just fine.  This same behaviour
occurred on BOTH the i486 and sparc machines.

The program is rather large:
   subdirectory 1:   1 .c,   1 .h
   subdirectory 2:  16 .c,  22 .h
   subdirectory 3:   6 .c,  11 .h
   maindir:         58 .c, 142 .h

The program is 3353608 bytes in size on sparc.
The program is 2928714 bytes in size on i486.

An example of where -O2 code compiles and executes PROPERLY is:

liblin1 $ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-39)

But on the i486 and sparc machines listed at the beginning,
-O2 code fails to execute properly.


-- 
           Summary: -O2 execution fails using 3.4.4, -O and -g work
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dick_guertin at yahoo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug c/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #1 from ebotcazou at gcc dot gnu dot org  2006-01-15 10:01 -------
We cannot do anything without a reproducer.  See http://gcc.gnu.org/bugs.html.

However, a segfault at runtime on several platforms with -O2 and not -O1 may
hint at an aliasing problem in the code.  You could try to recompile everything
with -O2 -fno-strict-aliasing and see what happens.  Read the -fstrict-aliasing
entry in the manual, section Optimize Options, for more information.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
           Severity|major                       |normal
             Status|UNCONFIRMED                 |WAITING
            Summary|-O2 execution fails using   |-O2 execution fails, -O and
                   |3.4.4, -O and -g work       |-g work


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug c/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #2 from dick_guertin at yahoo dot com  2006-01-16 23:16 -------
See my response below yours.

--- ebotcazou at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:

> 
> 
> ------- Comment #1 from ebotcazou at gcc dot gnu dot
> org  2006-01-15 10:01 -------
> We cannot do anything without a reproducer.  See
> http://gcc.gnu.org/bugs.html.
> 
> However, a segfault at runtime on several platforms
> with -O2 and not -O1 may
> hint at an aliasing problem in the code.  You could
> try to recompile everything
> with -O2 -fno-strict-aliasing and see what happens. 
> Read the -fstrict-aliasing
> entry in the manual, section Optimize Options, for
> more information.
> 
> 
> -- 
> 
> ebotcazou at gcc dot gnu dot org changed:
> 
>            What    |Removed                    
> |Added
>
----------------------------------------------------------------------------
>                  CC|                           
> |ebotcazou at gcc dot gnu dot
>                    |                            |org
>            Severity|major                      
> |normal
>              Status|UNCONFIRMED                
> |WAITING
>             Summary|-O2 execution fails using   |-O2
> execution fails, -O and
>                    |3.4.4, -O and -g work       |-g
> work
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> 

I tried what you said, adding -fno-strict-aliasing to
my DEFINES statement in the Imakefile.
I then removed all object decks, private libraries,
and the Makefiles, and used 'xmkmf' to
rebuild them .  I then compiled the three
sub-libraries, and then the main code.  All were done
with -O2 and -fno-strict-aliasing.  Execution then
went like this:

elaine30:~/wylsrc> gdb wylbur.ge
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Public License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run
Starting program:
/afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge


Program received signal SIGILL, Illegal instruction.
0x00297064 in hex_to_character ()
(gdb) where
#0  0x00297064 in hex_to_character ()
#1  0x00297068 in hex_to_character ()
Previous frame identical to this frame (corrupt
stack?)

As you can see, your suggested change did NOT fix the
'problem'.  What is obvious to me is that -O2 is
affecting address computations.  There shouldn't be
any way to clobber the stack unless addresses are
mis-computed or not stored into variables when they
should.  As far as I'm concerned, -O2 is a violation
of the ISO standards concerning Optimization.  If you
need the source code, I can bundle it into a tar.z
file and make it available for download over the web.
I would include a Readme file that explains what MINOR
changes you would have to make to the Imakefile
because this program expects to 'read' tables and
initialization information from files stored in
user-owned subdirectories (the user being YOU, the one
who compiles the code).  This is done so that this
cade can be transported to different sites, owned by
different users.

By the way, I will include 'Imakefile.unix' and
'Imakefile.linux' files for all three subdirectories
and the main code.  That will allow you to compare
Big-Endian to Little-Endian.  Let me know what you
want me to do next.  I'd like to see this -O2 problem fixed!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-16 23:20 -------
Yes we need the proprocessed source.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|c                           |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #4 from dick_guertin at yahoo dot com  2006-01-17 01:19 -------
I have created 'wylsrc/tgz' that you can download from the web as follows:

   http://lindy.stanford.edu/~guertin/wylsrc.tgz

Use the following to extract the 'wylsrc' directory:

gzip -d wylsrc.tgz
tar -xf wylsrc.tar
rm wylsrc.tar

Move the 'wylsrc' directory to be in your home directory.  Read the
'a.readme.txt' file that is in 'wylsrc'.
There is a 'Rmall' script that removes all objects and private (wylsrc)
libraries.  There are Imakefiles for both Unix and Linux, with Imakefile itself
set to the Unix version.  Likewise for the Makefiles.  You must make the
private libraries first, inside 'common', 'modeltrm', and 'unixport'
subdirectories.  Then you can play with 'wylsrc' itself.  All of my problems
have been occurring in 'comm.c'.  The Makefiles are all set for -O2 (three
instances in each Makefile).  If you change them to -O, and rebuild everything
(Rmall), you'll get a working version.  I can not find any 'code violations'
that would cause -O2 to fail.

If you have more questions, or need further assistance, let me know.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #5 from dick_guertin at yahoo dot com  2006-01-17 04:34 -------
Subject: Re:  -O2 execution fails, -O and -g work


I have created a 'wylsrc.tgz' file and made it
available for download over the web.
I updated the Bugzilla report # 25791 accordingly.  Be
sure to read 'a.readme.txt'.

Dick Guertin

--- pinskia at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:

> 
> 
> ------- Comment #3 from pinskia at gcc dot gnu dot
> org  2006-01-16 23:20 -------
> Yes we need the proprocessed source.
> 
> 
> -- 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>            What    |Removed                    
> |Added
>
----------------------------------------------------------------------------
>                  CC|                           
> |pinskia at gcc dot gnu dot
>                    |                            |org
>           Component|c                          
> |rtl-optimization
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #6 from ebotcazou at gcc dot gnu dot org  2006-01-17 06:59 -------
> (gdb) run
> Starting program:
> /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge
> 
> 
> Program received signal SIGILL, Illegal instruction.
> 0x00297064 in hex_to_character ()
> (gdb) where
> #0  0x00297064 in hex_to_character ()
> #1  0x00297068 in hex_to_character ()
> Previous frame identical to this frame (corrupt
> stack?)

Could you post an excerpt of the assembly code around 0x00297064?

> As you can see, your suggested change did NOT fix the 'problem'.

Well, it was not meant to, my wording was "and see what happens".

> What is obvious to me is that -O2 is affecting address computations.

What did you mean exactly?  Sure, -O2 is expected to have a negative impact on
debugging.

> There shouldn't be any way to clobber the stack unless addresses are
> mis-computed or not stored into variables when they
> should.  As far as I'm concerned, -O2 is a violation
> of the ISO standards concerning Optimization.

Well, if there is a code generation bug somewhere, things are expected to go
badly at some point.  That doesn't mean we should throw the baby with the bath
water.

> If you need the source code, I can bundle it into a tar.z
> file and make it available for download over the web.

No, we need a preprocessed testcase, preferably a runnable testcase but a
compilable one is sufficient if you can pinpoint the miscompilation.  That's
explained at the URL I previously posted: http://gcc.gnu.org/bugs.html.

Thanks in advance.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #7 from dick_guertin at yahoo dot com  2006-01-17 08:33 -------
Response to: "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>

> Program received signal SIGILL, Illegal instruction.
> 0x00297064 in hex_to_character ()
> Could you post an excerpt of the assembly code around 0x00297064?

It really doesn't do any good.  You're assuming hex_to_chararacter is 'entered'
normally.
It is NOT.  The corrupt stack causes a branch into the middle of that routine,
which is why
the system reports an illegal instruction.  Below is a NEXT-by-NEXT trace
leading to the failure.
This was accomplished with a -O2 and -g combination when compiling the source.
Note several 'backups' and 'repeated' statements, ending in the failure.

Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge 

Breakpoint 1, EDTBASE () at comm.c:3613
3613               NSCAN ();
(gdb) next
3614      L_00ECA: I_L(R14,(R11+0x08C));
(gdb) next
3615      L_00ECE: I_SH(R13,(DATA+0x020A));
(gdb) next
3614      L_00ECA: I_L(R14,(R11+0x08C));
(gdb) next
3615      L_00ECE: I_SH(R13,(DATA+0x020A));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3615      L_00ECE: I_SH(R13,(DATA+0x020A));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3615      L_00ECE: I_SH(R13,(DATA+0x020A));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3616      L_00ED2: I_MVC(4,(R14+0x028),(R13));
(gdb) next
3617      L_00ED8: I_MVC(4,(R14+0x024),(R13+0x04));
(gdb) next
3618      L_00EDE: I_MVC(4,(R14+0x020),(R13+0x08));
(gdb) next
3619      L_00EE4: I_LTR(R15,R15);
(gdb) next
3620      L_00EE6: I_L(R14,(R11+0x08C));
(gdb) next
3619      L_00EE4: I_LTR(R15,R15);
(gdb) next
3620      L_00EE6: I_L(R14,(R11+0x08C));
(gdb) next
3621      L_00EEA: I_L(R1,(R14));
(gdb) next
3622      L_00EEE: I_L(R0,(R14+0x04));
(gdb) next
3623      L_00EF2: I_SR(R14,R14);
(gdb) next
3625               SCINIT ();
(gdb) next
3626      L_00EF6: I_L(R14,(R11+0x08C));
(gdb) next
3627      L_00EFA: I_SH(R13,(DATA+0x020C));
(gdb) next
3626      L_00EF6: I_L(R14,(R11+0x08C));
(gdb) next
3627      L_00EFA: I_SH(R13,(DATA+0x020C));
(gdb) next
3628      L_00EFE: I_MVC(176,(R14),(R13));
(gdb) next
3627      L_00EFA: I_SH(R13,(DATA+0x020C));
(gdb) next
3628      L_00EFE: I_MVC(176,(R14),(R13));
(gdb) next
3627      L_00EFA: I_SH(R13,(DATA+0x020C));
(gdb) next
3628      L_00EFE: I_MVC(176,(R14),(R13));
(gdb) next
3627      L_00EFA: I_SH(R13,(DATA+0x020C));
(gdb) next
3628      L_00EFE: I_MVC(176,(R14),(R13));
(gdb) next
3629      L_00F04: I_L(R14,(R11+0x08C));
(gdb) next
3630      L_00F08: I_XC(176,(R14),(R14));
(gdb) next
3631      L_00F0E: I_SR(R14,R14);
(gdb) next
3632      L_00F10: I_LA(R1,(R11+0x0242));
(gdb) next
3633      L_00F14: I_LH(R0,(R11+0x0240));
(gdb) next
3631      L_00F0E: I_SR(R14,R14);
(gdb) next
3633      L_00F14: I_LH(R0,(R11+0x0240));
(gdb) next
3631      L_00F0E: I_SR(R14,R14);
(gdb) next
3632      L_00F10: I_LA(R1,(R11+0x0242));
(gdb) next
3633      L_00F14: I_LH(R0,(R11+0x0240));
(gdb) next
3634      L_00F18: I_L(R14,(R11+0x08C));
(gdb) next
3635      L_00F1C: I_ST(R1,(R14));
(gdb) next
3636      L_00F20: I_ST(R0,(R14+0x04));
(gdb) next
3637      L_00F24: I_SR(R14,R14);
(gdb) next
3638      L_00F26: I_L(R1,(R11+0x08C));
(gdb) next
3637      L_00F24: I_SR(R14,R14);
(gdb) next
3638      L_00F26: I_L(R1,(R11+0x08C));
(gdb) next
3639      L_00F2A: I_SR(R0,R0);
(gdb) next
3640      L_00F2C: I_L(R14,(R11+0x08C));
(gdb) next
3639      L_00F2A: I_SR(R0,R0);
(gdb) next
3640      L_00F2C: I_L(R14,(R11+0x08C));
(gdb) next
3641      L_00F30: I_MVC(4,(R13),(R14+0x028));
(gdb) next
3642      L_00F36: I_MVC(4,(R13+0x04),(R14+0x024));
(gdb) next
3643      L_00F3C: I_MVC(4,(R13+0x08),(R14+0x020));
(gdb) next
3644      L_00F42: I_LA(R13,(R13+0x0C));
(gdb) next
3645      L_00F46: I_ST(R0,(R1+0x024));
(gdb) next
3646      L_00F4A: I_ST(R0,(R1+0x020));
(gdb) next
3647               R14 = (long int)((char *)( & PRT ));
(gdb) next
3646      L_00F4A: I_ST(R0,(R1+0x020));
(gdb) next
3647               R14 = (long int)((char *)( & PRT ));
(gdb) next
3648      L_00F4E: I_ST(R14,(R1+0x028));
(gdb) next
3650               NSCAN ();
(gdb) next

Program received signal SIGILL, Illegal instruction.
0x00296fec in hex_to_character ()
(gdb) 
=======================
> We need a preprocessed testcase, preferably a runnable testcase but a
> compilable one is sufficient if you can pinpoint the miscompilation.

This program is too big for me to create a testcase.  I have no idea where
execution is going, only the final failure, which doesn't even allow 'gdb'
to know 'where' we are.  The stack is corrupted.  I was able to determine
EDTBASE was the last function in control, but have no idea what clobbers
the stack.  As you can see from the code, it is pseudo-assembler from an
IBM/360 being done in C using macros that create c-equivalent code.  In
order to run on both Big-endian and Little-endian, almost all memory
reference instructions use a complex shift/or process to combine four
bytes into a long.  That's because this code must always be treated as Big
endian, even on Little endian machines.  There's a lot of 'ntohl' or 'htonl'.

I created 'wylsrc.tgz' that you can download and extract.  Since all of this
is Open-Source, you are permitted to have it, especially if -O2 can be fixed.

http://lindy.stanford.edu/~guertin/wylsrc.tgz


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #8 from ebotcazou at gcc dot gnu dot org  2006-01-17 08:47 -------
> You're assuming hex_to_chararacter is 'entered' normally.  It is NOT.  The
> corrupt stack causes a branch into the middle of that routine, which is why
> the system reports an illegal instruction.

Ah, thanks for the clarification.  Looks pretty nasty indeed.

> Below is a NEXT-by-NEXT trace leading to the failure.

I think a real, native backtrace would be more useful, on SPARC for example.

> This program is too big for me to create a testcase.  I have no idea where
> execution is going, only the final failure, which doesn't even allow 'gdb'
> to know 'where' we are.

Then we are in a dead end because if you, developer/hacker/user of the program,
 cannot pinpoint the source of the ill-execution, we cannot either.  We have
neither the time nor the resources to debug every miscompiled program; you have
to do half of the work, we'll do the other half.  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #9 from dick_guertin at yahoo dot com  2006-01-17 19:01 -------
First, I inherited this code from a co-worker who left the University.  My
assignment was to keep this code working because the University relies on it. 
Everything was fine until we went from 3.3.1 to 3.4.4, and then -O2
compilations of this code created a module that got execution failures.  I've
been trying to "debug", but even 'gdb' is having troubles.  I don't know what
"proprocessed source" is.  All I have is true source.  I don't know how to do a
"native backtrack" on a sparc, but would be willing to learn.  I do know how to
use 'gdb' to "disas", examine variables, etc.  If you don't have the time to
track this, then help me do it.  By the way, did you notice the -O2 and -g
caused "next" executing linear (non-looping) statements to go like this:  3615,
3616, 3615, 3616, 3616, 3616, 3617, ...??  What's with that?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #10 from dick_guertin at yahoo dot com  2006-01-17 20:55 -------
I rebuilt with -O2 AND -g, and got the following trace.  Notice the while-loop
in nscan, statements 1141 thru 1147 are four single statements.  The "next"
trace by gdb shows them occuring multiple times.  This should NOT be happening.
 This may be another BUG, this time with 'gdb'.  Execution ends with the
Illegal Instruction failure at statement 1158, a call to a function called
'rlookup'.  I suppose I could try to follow that path, but I've tried 'step'
without success.  Maybe I need to set a breakpoint.

(gdb) break comm.c:3651
Breakpoint 1 at 0x269ec: file comm.c, line 3651.
(gdb) run
Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge 

Breakpoint 1, EDTBASE () at comm.c:3651
3651               NSCAN ();
(gdb) list comm.c:3650
3645      L_00F42: I_LA(R13,(R13+0x0C));
3646      L_00F46: I_ST(R0,(R1+0x024));
3647      L_00F4A: I_ST(R0,(R1+0x020));
3648               R14 = (long int)((char *)( & PRT ));
3649      L_00F4E: I_ST(R14,(R1+0x028));
3650      L_00F52: NOOP;
3651               NSCAN ();
3652      L_00F54: I_L(R14,(R11+0x08C));
3653      L_00F58: I_SH(R13,(DATA+0x020A));
3654      L_00F5C: I_MVC(4,(R14+0x028),(R13));
(gdb) break comm.c:3652
Breakpoint 2 at 0x269f4: file comm.c, line 3652.
(gdb) break nscan
Breakpoint 3 at 0x1eb3e8: file scan.c, line 1122.
(gdb) cont
Continuing.

Breakpoint 3, nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
1122             if (scancb->skip == NULL)
(gdb) where
#0  nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
#1  0x001eeb44 in NSCAN () at scanstub.c:304
#2  0x000269f4 in EDTBASE () at comm.c:3651
#3  0x00027428 in EDTCOM () at comm.c:3464
#4  0x001ef540 in signon (edit_file=0xffbef888 "") at sign.c:477
#5  0x000e82fc in main (argc=1, argv=0xffbefa04) at main.c:110
(gdb) list scanstub.c:290
285                 R15 = result;
286              }
287
288           R2 = regs[0]; R3 = regs[1]; R4 = regs[2]; R5 = regs[3]; R6 =
regs[4];
289
290           I_LTR(R15,R15);
291        }
292     void NSCAN()
293        {
294           unsigned char *token;
(gdb) 
295           long token_length;
296           long r[16];
297
298           r[3] = htonl(R2);
299           r[4] = htonl(R3);
300           r[5] = htonl(R4);
301           r[6] = htonl(R5);
302           r[7] = htonl(R6);
303
304           R15 = nscan((NSCNCB *) R1, &token, &token_length, r);
(gdb) 
305
306           R0 = token_length;
307           R1 = (long) token;
308
309           R2 = ntohl(r[3]);
310           R3 = ntohl(r[4]);
311           R4 = ntohl(r[5]);
312           R5 = ntohl(r[6]);
313           R6 = ntohl(r[7]);
314
(gdb) 
315           I_LTR(R15,R15);
316        }
317     void SETSKIP()
318        {
319           setskip((unsigned char *) R2, (unsigned char *) R1, R0);
320           R15=0;
321           I_LTR(R15,R15);
322        }
323     void SETSTOP()
324        {
(gdb) where
#0  nscan (scancb=0x0, token=0xffbef3d4, token_length=0xffbef3d0,
stack_pointer=0xffbef3d8) at scan.c:1122
#1  0x001eeb44 in NSCAN () at scanstub.c:304
#2  0x000269f4 in EDTBASE () at comm.c:3651
#3  0x00027428 in EDTCOM () at comm.c:3464
#4  0x001ef540 in signon (edit_file=0xffbef888 "") at sign.c:477
#5  0x000e82fc in main (argc=1, argv=0xffbefa04) at main.c:110
(gdb) list scan.c:1122
1117          {
1118             long result;
1119
1120             /* Set scan defaults if needed */
1121
1122             if (scancb->skip == NULL)
1123                scancb->skip = (unsigned char *) htonl((long) tblwskip);
1124
1125             if (scancb->stop == NULL)
1126                scancb->stop = (unsigned char *) htonl((long) tblwmark);
(gdb) 
1127
1128             scancb->msgl = 0;
1129
1130             if (scancb->kws)     /* Scan with keyword table */
1131                {
1132                   unsigned char *nstloc;
1133                   int nsffirst = 1;
1134
1135                   result = 0;
1136
(gdb) 
1137                   while (result == 0)
1138                      {
1139                         NKW *matched_entry;
1140
1141                         result = scntoken(scancb);
1142
1143                         result = set_token(scancb, result);
1144
1145                         result = set_type(scancb, result);
1146
(gdb) 
1147                         nstloc = (unsigned char *) ntohl((long)
scancb->tloc);
1148
1149                         if (     (result != 0)
1150                               || (     (scancb->type & NSCNFNUL)
1151                                     && (! nsffirst)
1152                                  )
1153                            )
1154                            break;
1155
1156                         nsffirst = 0;
(gdb) 
1157
1158                         matched_entry = rlookup(scancb,
1159                                                 (NKW *) ntohl((long)
scancb->kws),
1160                                                 stack_pointer,
1161                                                 &result);
1162
1163                         if (matched_entry == (NKW *) NULL)
1164                            {
1165                               result = 0;   /* Stop if no match */
1166
(gdb) 
1167                               break;
1168                            }
1169
1170                         if (result == 0)
1171                            dospecl(scancb, matched_entry, nstloc);
1172                      }
1173                }
1174
1175             else         /* Scan with no keyword table */
1176                {
(gdb) 
1177                   result = scntoken(scancb);
1178
1179                   result = set_token(scancb, result);
1180
1181                   result = set_type(scancb, result);
1182                }
1183
1184             *token = (unsigned char *) ntohl((long) scancb->tloc);
1185
1186             *token_length = ntohl(scancb->tlen);
(gdb) 
1187
1188             return result;
1189          }
1190     /*                     Call match routine
1191
1192          Function:   Call the indicated match routine in the
1193                      keyword entry.
1194
1195          Arguments:  The scan control block,
1196                      The keyword entry,
(gdb) next
1123                scancb->skip = (unsigned char *) htonl((long) tblwskip);
(gdb) next
1125             if (scancb->stop == NULL)
(gdb) next
1126                scancb->stop = (unsigned char *) htonl((long) tblwmark);
(gdb) next
1130             if (scancb->kws)     /* Scan with keyword table */
(gdb) next
1135                   result = 0;
(gdb) next
1133                   int nsffirst = 1;
(gdb) next
1141                         result = scntoken(scancb);
(gdb) next
1143                         result = set_token(scancb, result);
(gdb) next
1141                         result = scntoken(scancb);
(gdb) next
1143                         result = set_token(scancb, result);
(gdb) next
1145                         result = set_type(scancb, result);
(gdb) next
1147                         nstloc = (unsigned char *) ntohl((long)
scancb->tloc);
(gdb) next
1149                         if (     (result != 0)
(gdb) next
1145                         result = set_type(scancb, result);
(gdb) next
1149                         if (     (result != 0)
(gdb) next
1158                         matched_entry = rlookup(scancb,
(gdb) next

Program received signal SIGILL, Illegal instruction.
0x002971fc in hex_to_character ()
(gdb) 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #11 from dick_guertin at yahoo dot com  2006-01-18 03:10 -------
I think I've found the 'smoking gun'.  Here is a listing of NSCAN

void NSCAN()
   {
      unsigned char *token;
      long token_length;
      long r[16];

      r[3] = htonl(R2);
      r[4] = htonl(R3);
      r[5] = htonl(R4);
      r[6] = htonl(R5);
      r[7] = htonl(R6);

      R15 = nscan((NSCNCB *) R1, &token, &token_length, r);

      R0 = token_length;
      R1 = (long) token;

      R2 = ntohl(r[3]);
      R3 = ntohl(r[4]);
      R4 = ntohl(r[5]);
      R5 = ntohl(r[6]);
      R6 = ntohl(r[7]);

      I_LTR(R15,R15);
   }

Later, I've included a 'disassem' of this code compiled with -O2.
Here is what happened when the program was executed:

This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) break comm.c:3651
Breakpoint 1 at 0x269ec: file comm.c, line 3651.
(gdb) run
Starting program: /afs/ir.stanford.edu/users/g/u/guertin/wylsrc/wylbur.ge 

Breakpoint 1, EDTBASE () at comm.c:3651
3651               NSCAN ();
(gdb) x/4bx &r1
0x2d6a0c <r1>:  0x00    0x31    0x17    0x80
(gdb) break nscan
Breakpoint 2 at 0x1eb3e8: file scan.c, line 1122.
(gdb) cont
Continuing.

Breakpoint 2, nscan (scancb=0x0, token=0xffbef3dc, token_length=0xffbef3d8,
stack_pointer=0xffbef3e0) at scan.c:1122
1122             if (scancb->skip == NULL)
(gdb) where
#0  nscan (scancb=0x0, token=0xffbef3dc, token_length=0xffbef3d8,
stack_pointer=0xffbef3e0) at scan.c:1122
#1  0x001eeb44 in NSCAN () at scanstub.c:304
#2  0x000269f4 in EDTBASE () at comm.c:3651
#3  0x00027428 in EDTCOM () at comm.c:3464
#4  0x001ef540 in signon (edit_file=0xffbef890 "") at sign.c:477
#5  0x000e82fc in main (argc=1, argv=0xffbefa0c) at main.c:110
(gdb) x/4bx &scancb
Address requested for identifier "scancb" which is in register $l0
(gdb) disas NSCAN
Dump of assembler code for function NSCAN:
0x001eeaec <NSCAN+0>:   save  %sp, -184, %sp
0x001eeaf0 <NSCAN+4>:   sethi  %hi(0x2d6800), %l1
0x001eeaf4 <NSCAN+8>:   ld  [ %l1 + 0x1fc ], %o2        ! 0x2d69fc <r2>
0x001eeaf8 <NSCAN+12>:  sethi  %hi(0x2d6800), %l2
0x001eeafc <NSCAN+16>:  ld  [ %l2 + 0x1d4 ], %o3        ! 0x2d69d4 <r3>
0x001eeb00 <NSCAN+20>:  sethi  %hi(0x2d6800), %l3
0x001eeb04 <NSCAN+24>:  ld  [ %l3 + 0x1e4 ], %o4        ! 0x2d69e4 <r4>
0x001eeb08 <NSCAN+28>:  sethi  %hi(0x2d6800), %l4
0x001eeb0c <NSCAN+32>:  ld  [ %l4 + 0x208 ], %o5        ! 0x2d6a08 <r5>
0x001eeb10 <NSCAN+36>:  sethi  %hi(0x2d6800), %l5
0x001eeb14 <NSCAN+40>:  ld  [ %l5 + 0x1e0 ], %g1        ! 0x2d69e0 <r6>
0x001eeb18 <NSCAN+44>:  sethi  %hi(0x2d6800), %l0
0x001eeb1c <NSCAN+48>:  st  %o2, [ %fp + -68 ]
0x001eeb20 <NSCAN+52>:  st  %o3, [ %fp + -64 ]
0x001eeb24 <NSCAN+56>:  st  %o4, [ %fp + -60 ]
0x001eeb28 <NSCAN+60>:  st  %o5, [ %fp + -56 ]
0x001eeb2c <NSCAN+64>:  st  %g1, [ %fp + -52 ]
0x001eeb30 <NSCAN+68>:  add  %fp, -80, %o3
0x001eeb34 <NSCAN+72>:  ld  [ %l0 + 0x20c ], %o0
0x001eeb38 <NSCAN+76>:  add  %fp, -84, %o1
0x001eeb3c <NSCAN+80>:  call  0x1eb3e4 <nscan>
0x001eeb40 <NSCAN+84>:  add  %fp, -88, %o2
0x001eeb44 <NSCAN+88>:  sethi  %hi(0x2d6800), %o3
0x001eeb48 <NSCAN+92>:  st  %o0, [ %o3 + 0x204 ]        ! 0x2d6a04 <r15>
0x001eeb4c <NSCAN+96>:  ld  [ %fp + -88 ], %o4
0x001eeb50 <NSCAN+100>: sethi  %hi(0x2d6800), %g1
0x001eeb54 <NSCAN+104>: st  %o4, [ %g1 + 0x1e8 ]        ! 0x2d69e8 <r0>
0x001eeb58 <NSCAN+108>: ld  [ %fp + -84 ], %o5
0x001eeb5c <NSCAN+112>: st  %o5, [ %l0 + 0x20c ]
0x001eeb60 <NSCAN+116>: ld  [ %fp + -68 ], %g1
0x001eeb64 <NSCAN+120>: st  %g1, [ %l1 + 0x1fc ]
0x001eeb68 <NSCAN+124>: ld  [ %fp + -64 ], %o5
0x001eeb6c <NSCAN+128>: st  %o5, [ %l2 + 0x1d4 ]
0x001eeb70 <NSCAN+132>: ld  [ %fp + -60 ], %g1
0x001eeb74 <NSCAN+136>: st  %g1, [ %l3 + 0x1e4 ]
0x001eeb78 <NSCAN+140>: ld  [ %fp + -56 ], %o5
0x001eeb7c <NSCAN+144>: st  %o5, [ %l4 + 0x208 ]
0x001eeb80 <NSCAN+148>: ld  [ %fp + -52 ], %g1
0x001eeb84 <NSCAN+152>: st  %g1, [ %l5 + 0x1e0 ]
0x001eeb88 <NSCAN+156>: ld  [ %o3 + 0x204 ], %o5
0x001eeb8c <NSCAN+160>: st  %o5, [ %o3 + 0x204 ]
0x001eeb90 <NSCAN+164>: ld  [ %o3 + 0x204 ], %o4
0x001eeb94 <NSCAN+168>: sethi  %hi(0x2d0400), %g1
0x001eeb98 <NSCAN+172>: sethi  %hi(0x2d0400), %o5
0x001eeb9c <NSCAN+176>: st  %o4, [ %g1 + 0x354 ]
0x001eeba0 <NSCAN+180>: clr  [ %o5 + 0x350 ]
0x001eeba4 <NSCAN+184>: ret 
0x001eeba8 <NSCAN+188>: restore 
End of assembler dump.
(gdb) print &r1
$1 = (volatile long unsigned int *) 0x2d6a0c
(gdb) print &r2
$2 = (volatile long unsigned int *) 0x2d69fc
(gdb) maintenance print raw-registers
 Name         Nr  Rel Offset    Size  Type            Raw value
 g0            0    0      0       4 int32_t         0x00000000
 g1            1    1      4       4 int32_t         0x00000000
 g2            2    2      8       4 int32_t         0x00000000
 g3            3    3     12       4 int32_t         0x00000000
 g4            4    4     16       4 int32_t         0x00000000
 g5            5    5     20       4 int32_t         0x00000000
 g6            6    6     24       4 int32_t         0x00000000
 g7            7    7     28       4 int32_t         0x00000000
 o0            8    8     32       4 int32_t         0x00000000
 o1            9    9     36       4 int32_t         0x00000000
 o2           10   10     40       4 int32_t         0x00000000
 o3           11   11     44       4 int32_t         0x00000000
 o4           12   12     48       4 int32_t         0x00000000
 o5           13   13     52       4 int32_t         0x00000000
 sp           14   14     56       4 *1              0xffbef300
 o7           15   15     60       4 int32_t         0x00000000
 l0           16   16     64       4 int32_t         0x00000000
 l1           17   17     68       4 int32_t         0x00000000
 l2           18   18     72       4 int32_t         0x00000000
 l3           19   19     76       4 int32_t         0x00000000
 l4           20   20     80       4 int32_t         0x00000000
 l5           21   21     84       4 int32_t         0x00000000
 l6           22   22     88       4 int32_t         0x00000000
 l7           23   23     92       4 int32_t         0x00000000
 i0           24   24     96       4 int32_t         0x00311780
 i1           25   25    100       4 int32_t         0xffbef3dc
 i2           26   26    104       4 int32_t         0xffbef3d8
 i3           27   27    108       4 int32_t         0xffbef3e0
 i4           28   28    112       4 int32_t         0x00000066
 i5           29   29    116       4 int32_t         0x00311932
 fp           30   30    120       4 *1              0xffbef378
 i7           31   31    124       4 int32_t         0x001eeb3c
 y            64   64    256       4 int32_t         0x00000000
 psr          65   65    260       4 int32_t         0xfe401002
 pc           68   68    272       4 *1              0x001eb3e8
 npc          69   69    276       4 *1              0x001eb3ec
*1: Register type's name NULL.
(gdb) disas nscan
Dump of assembler code for function nscan:
0x001eb3e4 <nscan+0>:   save  %sp, -120, %sp
0x001eb3e8 <nscan+4>:   ld  [ %i0 + 0x24 ], %g1
0x001eb3ec <nscan+8>:   cmp  %g1, 0
0x001eb3f0 <nscan+12>:  bne  0x1eb404 <nscan+32>
0x001eb3f4 <nscan+16>:  mov  %i0, %l0
0x001eb3f8 <nscan+20>:  sethi  %hi(0x2c2800), %g1
0x001eb3fc <nscan+24>:  or  %g1, 0x138, %g1     ! 0x2c2938 <tblwskip>
0x001eb400 <nscan+28>:  st  %g1, [ %i0 + 0x24 ]
0x001eb404 <nscan+32>:  ld  [ %l0 + 0x20 ], %g1
0x001eb408 <nscan+36>:  cmp  %g1, 0
0x001eb40c <nscan+40>:  bne,a   0x1eb424 <nscan+64>
0x001eb410 <nscan+44>:  ld  [ %l0 + 0x28 ], %g1
0x001eb414 <nscan+48>:  sethi  %hi(0x2c2800), %g1
0x001eb418 <nscan+52>:  or  %g1, 0x38, %g1      ! 0x2c2838 <tblwmark>
0x001eb41c <nscan+56>:  st  %g1, [ %l0 + 0x20 ]
0x001eb420 <nscan+60>:  ld  [ %l0 + 0x28 ], %g1
0x001eb424 <nscan+64>:  cmp  %g1, 0
0x001eb428 <nscan+68>:  be  0x1eb564 <nscan+384>
0x001eb42c <nscan+72>:  clr  [ %l0 + 0x5c ]
0x001eb430 <nscan+76>:  clr  [ %fp + -20 ]
0x001eb434 <nscan+80>:  b  0x1eb448 <nscan+100>
0x001eb438 <nscan+84>:  mov  1, %l2
0x001eb43c <nscan+88>:  cmp  %i0, 0
0x001eb440 <nscan+92>:  bne,a   0x1eb598 <nscan+436>
0x001eb444 <nscan+96>:  ld  [ %l0 + 0x10 ], %o2
0x001eb448 <nscan+100>: call  0x1eae64 <scntoken>
0x001eb44c <nscan+104>: mov  %l0, %o0
0x001eb450 <nscan+108>: mov  %o0, %o1
0x001eb454 <nscan+112>: st  %o0, [ %fp + -20 ]
0x001eb458 <nscan+116>: call  0x1ea4e0 <set_token>
0x001eb45c <nscan+120>: mov  %l0, %o0
0x001eb460 <nscan+124>: mov  %o0, %o1
0x001eb464 <nscan+128>: st  %o0, [ %fp + -20 ]
0x001eb468 <nscan+132>: call  0x1ea5a0 <set_type>
0x001eb46c <nscan+136>: mov  %l0, %o0
0x001eb470 <nscan+140>: ld  [ %l0 + 0x10 ], %o2
0x001eb474 <nscan+144>: mov  %o0, %i0
0x001eb478 <nscan+148>: st  %o0, [ %fp + -20 ]
---Type <return> to continue, or q <return> to quit---

Notice that 'nscan' expects 'scancb' in %l0, but it is ZERO.
It does NOT contain the value in R1 (aka: r1).
(gdb) x/4bx &r1
0x2d6a0c <r1>:  0x00    0x31    0x17    0x80

Notice the assembly code in NSCAN just before the 'call nscan'
at NSCAN+80.  r1 never gets loaded into %l0.  Therefore, it is
NOT passed to 'nscan' properly.  This is the point of failure.
A portion of 'nscan' code matching the disassemb above is:

   long nscan(NSCNCB *scancb,
              unsigned char **token,
              long *token_length,
              long stack_pointer[])
      {
         long result;

         /* Set scan defaults if needed */

         if (scancb->skip == NULL)
            scancb->skip = (unsigned char *) htonl((long) tblwskip);
         if (scancb->stop == NULL)
            scancb->stop = (unsigned char *) htonl((long) tblwmark);
         scancb->msgl = 0;
etc.

R1 is defined as an alias of r1,
and r1 is a global value, like this:

define.vars.h:#define R1 r1
define.vars.h:volatile unsigned long r1;

Can you dispute my findings?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #12 from ebotcazou at gcc dot gnu dot org  2006-01-18 13:31 -------
> I rebuilt with -O2 AND -g, and got the following trace.  Notice the while-loop
> in nscan, statements 1141 thru 1147 are four single statements.  The "next"
> trace by gdb shows them occuring multiple times.  This should NOT be
> happening.  This may be another BUG, this time with 'gdb'.

That is expected because -O2 seriously breaks the source code apart and
reorders things.  Use "nexti" in that case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-01-18 13:38 -------
> Notice that 'nscan' expects 'scancb' in %l0, but it is ZERO.

Better not trust GDB at -O2 on that one, it is easily fooled.

> It does NOT contain the value in R1 (aka: r1).
> (gdb) x/4bx &r1
> 0x2d6a0c <r1>:  0x00    0x31    0x17    0x80

That value is in %i0.

> Notice the assembly code in NSCAN just before the 'call nscan'
> at NSCAN+80.  r1 never gets loaded into %l0.  Therefore, it is
> NOT passed to 'nscan' properly.

The value is loaded into %o0 before 'call nscan' and end up in %i0 after the
save register window instruction.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #14 from dick_guertin at yahoo dot com  2006-01-19 04:00 -------
Good news, I think I found the problem.  Bad news, I can't think of any
solution.  Please read my comments at the end of this information:

typedef struct nkw
   {
      char tok[16];                /* TOKEN, BLANK PADDED */
      short tokl;                  /* TOKEN LENGTH */
      unsigned char flg1;          /* FIELD FLAGS */
#define NKWFP1   0x80              /* PARM1 */
#define NKWFP2   0x40              /* PARM2 */
#define NKWFMAT  0x20              /* MATCH ROUTINE */
#define NKWFRTN  0x10              /* PROCESSING ROUTINE */

      unsigned char flg2;          /* MISC FLAGS */
#define NKWFPUSH 0x80              /* PUSH */
#define NKWFEND  0x40              /* LAST KEYWORD ENTRY IN LIST */

      unsigned char flg3;          /* MATCH SPECS,SPECIAL ACTIONS */
#define NKWFABBV 0x80              /* ABBREVIATE  (3 CHAR MIN) */
#define NKWFAB1  0x40              /* ABBREVIATE  (1 CHAR MIN) */
#define NKWFSET  0x20              /* SAVE KEYWORD IN CP */
#define NKWFNOBK 0x10              /* DO NOT BLANK */

#define NKWFCRTN 0x04              /* rtn is in C */
#define NKWFINIT 0x02              /* Convert string to EBCDIC */

      unsigned char flg4;          /* INTEGER MATCH SPECS */
      unsigned char flg5;
      unsigned char flg6;

      long parm1;                  /* MATCH PARM 1 */
      long parm2;                  /* MATCH PARM 2 */
      void (*mat)();
      long (*rtn)(NSCNCB *,
                  REG,
                  REG);
      unsigned char stuffing[24];
   } NKW;

struct sckw {
  unsigned char stuff[32];
  void (*nkwmat)();
  void (*nkwrtn)();
  unsigned char more_stuff[24];
};

======================================

static struct sckw CDEFPRT = {
0xE2,0xC5,0xE3,0x40,0x40,0x40,0x40,0x40,    /* SET */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,3,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFSET };
static struct sckw sckw1 = {
0xE2,0xC8,0xD6,0xE6,0x40,0x40,0x40,0x40,    /* SHOW */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,4,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFSHOW };
static struct sckw sckw2 = {
0xC4,0xE4,0xD4,0xD7,0x40,0x40,0x40,0x40,    /* DUMP */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,4,48,0,
128,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, CDEFDUMP };
/* - - - - - - - - - - */
static struct sckw sckw268 = {
0xD6,0xD3,0xC4,0xE6,0xE8,0xD3,0x40,0x40,    /* OLDWYL */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,6,48,64,
32,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, XCTL };

======================================

As you can see from the numbering of these items, there are 269 of them, all
layed out in sequence within the C-source.  It is possible to start with any
entry, and scanning is then supposed to go until the last is encountered,
signified by the '64' in the '0,6,48,64' line.  That is 0x40 in flg2.  The
scan.c code for rlookup looks something like this:

======================================

   NKW *rlookup(NSCNCB *scancb,
                NKW keyword_table[],
                long stack_ptr[],
                long *routine_result)
      {
         if (keyword_table)
            {
               NKW *kwp = keyword_table;
               long match_result;
               REG r[2];

               while (kwp)
                  {

                     if (kwp->flg3 & NKWFINIT)    /* Convert to EBCDIC */
                        {
                           memset(kwp->tok + ntohs(kwp->tokl),
                                  ' ',
                                  sizeof kwp->tok - ntohs(kwp->tokl));

                           ascii_to_ebcdic(kwp->tok, sizeof kwp->tok);

                           kwp->flg3 &= ~NKWFINIT;
                        }

                     if (kwp->flg2 & NKWFPUSH)
                        {

                           if (kwp->flg3 & NKWFCRTN)
                              {
                                 long saved_regs[2];

                                 r[0].as_long = R0;
                                 r[1].as_long = R1;

                                 saved_regs[0] = R2;
                                 saved_regs[1] = R3;

                                 R2 = (long) scancb;

                                 R3 = (long) stack_ptr;

                                 R15 = (*(kwp->rtn))(scancb, r[0], r[1]);

                                 R2 = saved_regs[0];
                                 R3 = saved_regs[1];
                              }

                            else
                              {
                                 struct sckw *sckwp = (struct sckw *) kwp;
                                 long saved_regs[2];

                                 saved_regs[0] = R2;
                                 saved_regs[1] = R3;

                                 R2 = (long) scancb;

                                 R3 = (long) stack_ptr;

                                 (*(sckwp->nkwrtn))();

                                 R2 = saved_regs[0];
                                 R3 = saved_regs[1];
                              }

                           /* If match found and processed, we're done */

                           if (R0 == 0)
                              {
                                 *routine_result = R15;

                                 return kwp;
                              }
                        }

                     match_result = call_match(scancb, kwp, &r[0], &r[1],
stack_ptr);

                     if (match_result < 0)   /* Error */
                        {
                           *routine_result = match_result;

                           return kwp;
                        }

                     if (match_result == 0)  /* Call processing routine */
                        {
                           *routine_result = callrtn(scancb, r[0], r[1], kwp,
stack_ptr);

                           return kwp;
                        }

                     if (kwp->flg2 & NKWFEND)
                        kwp = (NKW *) NULL;

                     else
                        kwp += 1;
                  }
            }

         /* If we get here, there was no match... */

         return((NKW *) NULL);
      }

======================================

The keyword_table parm passed to rlookup is the 1st in the series of sckw
objects to be scanned, and then "kwp += 1;" advances to the next.  But the
kwp->flg2 & NKWFEND test is supposed to stop the loop on the last object.

What I've discovered is that the -O2 option causes these sckw static objects to
be placed randomly in memory, NOT in the order they are declared.  In all
previous instances of the gcc compiler, input order was preserved for static
objects.  This is the 'problem'.  With -O2 in gcc 3.4.4, order is not
preserved.  So the scan falls off the end when the ending sckw is misplaced.

My question is this:  Is there some option that can be used with -O2 that will
preserve the input-order of static and/or global objects?  It would be handy if
global objects were also kept in order, such as:

long r1;
long r2;
long r3;
etc.

Alternatively, is there some way I can force the input-order of sckw objects?

By the way, I placed a 'break' at the if-test for flg2, but it never sprung. 
Another 'break' at the increment statement {kwp += 1;} was sprung.  That's how
I found these sckw objects were in random order.  'gdb' has problems with -O2
and -g combined.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2006-01-19 04:04 -------
I wonder if this is at all related to PR 25654 and PR 25130.

Can you try "-O2 -fno-gcse"?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #16 from dick_guertin at yahoo dot com  2006-01-19 04:50 -------
I recompiled with -O2 -fno-gcse and got this:

Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0,
stack_ptr=0xffbef3d8, routine_result=0xffbef35c)
    at scan.c:1452
1452                            kwp += 1;
(gdb) 
Continuing.

Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0,
stack_ptr=0xffbef3d8, routine_result=0xffbef35c)
    at scan.c:1452
1452                            kwp += 1;
(gdb) 
Continuing.

Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0,
stack_ptr=0xffbef3d8, routine_result=0xffbef35c)
    at scan.c:1452
1452                            kwp += 1;
(gdb) 
Continuing.

Breakpoint 4, rlookup (scancb=0x341da8, keyword_table=0x0,
stack_ptr=0xffbef3d8, routine_result=0xffbef35c)
    at scan.c:1452
1452                            kwp += 1;
(gdb) 
Continuing.

Program received signal SIGILL, Illegal instruction.
0x002b7884 in hex_to_character ()

Problem persists!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #17 from dick_guertin at yahoo dot com  2006-01-19 06:41 -------
I went back and recompiled all modules with -O -g to see what effect this has
on the order of static data.  What I found was that all static data occurred in
memory in the order declared in the source code.  This was NOT true with -O2,
where static data was moved around in some unknown order.  I read through the
'man gcc' pages very carefully, and could NOT see any -option that would
control static data placement.  Therefore, -O2 is a show-stopper for this
program because static data is NOT laid out in memory in the order declared in
the program source.  Given this fact, it should be possible for me to create a
testcase that shows static data moves around with -O2, and stays in declared
order with -O.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-01-19 06:51 -------
Oh, you are depending on the order of the static/global variables.  That is
undefined C.
Try -O2 -fno-unit-at-a-time.  If that works this is NOT, I will repeat NOT a
GCC bug as you are depending on undefined code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #19 from ebotcazou at gcc dot gnu dot org  2006-01-19 06:55 -------
> Good news, I think I found the problem.  Bad news, I can't think of any
> solution.  Please read my comments at the end of this information:

Thanks for your efforts.

> What I've discovered is that the -O2 option causes these sckw static objects
> to be placed randomly in memory, NOT in the order they are declared.  In all
> previous instances of the gcc compiler, input order was preserved for static
> objects.  This is the 'problem'.  With -O2 in gcc 3.4.4, order is not
> preserved.  So the scan falls off the end when the ending sckw is misplaced.

OK, that makes sense.  See http://gcc.gnu.org/gcc-3.4/changes.html, Caveats
section, bullet #13.  Note that this reordering is permitted by ISO C (or more
precisely, it is not forbidden by ISO C).

> My question is this:  Is there some option that can be used with -O2 that will
> preserve the input-order of static and/or global objects?  It would be handy
> if global objects were also kept in order, such as:
> 
> long r1;
> long r2;
> long r3;
> etc.

Yes, the workaround is given on the aforementioned page.

> Alternatively, is there some way I can force the input-order of sckw objects?

Yes, by using an array of such structures.

> By the way, I placed a 'break' at the if-test for flg2, but it never sprung. 
> Another 'break' at the increment statement {kwp += 1;} was sprung.  That's how
> I found these sckw objects were in random order.  'gdb' has problems with -O2
> and -g combined.

Yes, debugging code compiled with -O2 -g is not for the fainthearted. :-)  GDB
is primarily aimed at debugging user code so generally used on code compiled
with -O0 -g.  It is indeed not really tuned for debugging the compiler itself.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #20 from dick_guertin at yahoo dot com  2006-01-19 07:45 -------
Created an attachment (id=10672)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10672&action=view)
Contains a testcase in source code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #21 from dick_guertin at yahoo dot com  2006-01-19 08:26 -------
>From what I can tell with the testcase, any static data that is not
'referenced' is eliminated.  This is terribly non-transparent in programs that
create tables by using static data to define table members.  Only those members
specifically referenced are retained by -O2.  That destroys the tables.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #22 from ebotcazou at gcc dot gnu dot org  2006-01-19 08:39 -------
> From what I can tell with the testcase, any static data that is not
> 'referenced' is eliminated.  This is terribly non-transparent in programs that
> create tables by using static data to define table members.  Only those members
> specifically referenced are retained by -O2.  That destroys the tables.

Sure, but you must use arrays for tables, not seemingly contiguous objects
which have never been guaranteed to be contiguous by anyone.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2006-01-19 12:16 -------
Closing as invalid as this is depending on undefined bahvior.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #24 from dick_guertin at yahoo dot com  2006-01-19 17:54 -------
Although you have closed this, many people would disagree with you.  Laying out
static data this way has always 'worked' in the past, and continues to work
with -O, but not -O2.  Just for completeness, here is a simplfied testcase.c
that anyone can compile and execute with -O or -O2.

#include <stdio.h>

typedef struct sckw
   {
      unsigned char tok[1];
      char tag[3];
   }  NKW;

/* user sckws */

static struct sckw sckw01 = {  1, '0','1', 0 };
static struct sckw sckw02 = {  2, '0','2', 0 };
static struct sckw sckw03 = {  3, '0','3', 0 };
static struct sckw sckw04 = {  4, '0','4', 0 };
static struct sckw sckw05 = {  5, '0','5', 0 };
static struct sckw sckw06 = {  6, '0','6', 0 };
static struct sckw sckw07 = {  7, '0','7', 0 };
static struct sckw sckw08 = {  8, '0','8', 0 };
static struct sckw sckw09 = {  9, '0','9', 0 };
static struct sckw sckw10 = { 10, '1','0', 0 };
static struct sckw sckw11 = { 11, '1','1', 0 };
static struct sckw sckw12 = { 12, '1','2', 0 };
static struct sckw sckw13 = { 13, '1','3', 0 };
static struct sckw sckw14 = { 14, '1','4', 0 };
static struct sckw sckw15 = { 15, '1','5', 0 };
static struct sckw sckw16 = { 16, '1','6', 0 };
static struct sckw sckw17 = { 17, '1','7', 0 };
static struct sckw sckw18 = { 18, '1','8', 0 };
static struct sckw sckw19 = { 19, '1','9', 0 };
static struct sckw sckw20 = {  0, '2','0', 0 };

void scanner (void)
{  int token;
   NKW *kwp, *kwp2;

   kwp = (NKW*) &(sckw01);
   kwp2 = (NKW*) &(sckw20);
   token = 1;

   while (kwp)
   {
       if ((int)kwp->tok[0] == token)
       {  ++ token;
          kwp += 1;
       }
       else
       {  if ((kwp == kwp2) && (token == 20)) printf("Finished correctly\n");
          else printf("Finished at %d when tok=%d\n", token, (int)kwp->tok[0]);
          kwp = 0;
       }
   }
   return;
}

int main ()
{  scanner();
   return(0);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #25 from dick_guertin at yahoo dot com  2006-01-19 18:23 -------
In your closing arguments you said these static object need to be members of an
array.  How would I do that?  Here's a sample from comm.c where there is a
mixture of objects:
- - - -
static struct sckw sckw58 = {
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,0,48,64,
0,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MALL, QNORMAL };
static NKW PRT = SCKW_TOKEN("IF",xif,NKWFSET+NKWFCRTN);
static NKW sckw59 = SCKW_TOKEN("SET",set,NKWFSET+NKWFCRTN);
static struct sckw sckw60 = {
0xD9,0xC5,0xC1,0xC4,0x40,0x40,0x40,0x40,    /* READ */
0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,
0,4,48,0,
160,0,0,0,
0, 0, 0, 0,
0, 0, 0, 0,
MTOKEN, READ };
- - - - etc.

I'm perfectly willing to 'enclose' this entire bundle if I knew how.  But I'm
not sure how.  Specific members inside have specific names, like PRT above.
These have to be 'referenced' from outside the array.  I don't think we can
give names to array members.  Remember, we need to 'reference' certain members,
which occur at different places throughout the collection of static objects.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[ebotcazou at gcc dot gnu dot org]

------- Comment #26 from ebotcazou at gcc dot gnu dot org  2006-01-19 18:33 -------
> In your closing arguments you said these static object need to be members of
> an array.  How would I do that?

You need to use a single array for your table if all the elements have the same
type or a single big structure with a specific field for each element.

> I'm perfectly willing to 'enclose' this entire bundle if I knew how.  But I'm
> not sure how.  Specific members inside have specific names, like PRT above.
> These have to be 'referenced' from outside the array.  I don't think we can
> give names to array members.

array[0], array[1], ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791

[Bug rtl-optimization/25791] -O2 execution fails, -O and -g work

[dick_guertin at yahoo dot com]

------- Comment #27 from dick_guertin at yahoo dot com  2006-01-21 08:17 -------
Referring to Comment #26, these static objects are NOT all of one type, but
they share a common typedef struct, something like a union of different types
that share the same space.  Each type is a constructor allowing initialization
to occur different ways.  NKW and 'struct sckw" are two examples, and both
appear in Comment #25.

What I finally did was add a pointer to each object that points to another
object, usually of its own type.  But the pointer can by cast so that a
different type can be referenced.  Thus the pointer in  NKW can be cast as an
NKW pointer even though it points to a 'struct sckw' object, and vice-versa. 
To make this work, I had to reverse the declaration order so that the last is
declared first, and the first is declared last.   So the new 'first' (old
'last') has a zero pointer.  Those which follow point back to the one before
it.  This does two things:  it guarantees every object is referenced so it
isn't eliminated, and they can now be placed anywhere in memory.  Instead of
ticking through them with 'kwp += 1;',  I navigate thru them with 'kwp =
kwp->next;'.  The chain stops when kwp goes to zero (first declared, last
examined).

In cases where an array of like-kind objects was initialized, I simply point
down the list, such as:

     static NKW item[] = 
     {     SCKW_TOKEN("IF",xif,NKWFSET+NKWFCRTN, &item[1]),
           SCKW_TOKEN("SHOW",show,NKWFSET+NKWFCRTN, &item[2]),
           SCKW_TOKEN("SET",set,NKWFSET+NKWFCRTN, (NKW*)0)
     };

I'm documenting this just in case it can be useful to someone else with a
similar problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25791