public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work
@ 2006-01-15 7:02 dick_guertin at yahoo dot com
2006-01-15 10:01 ` [Bug c/25791] -O2 execution fails, " ebotcazou at gcc dot gnu dot org
` (26 more replies)
0 siblings, 27 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-15 7:02 UTC (permalink / raw)
To: gcc-bugs
~> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
@ 2006-01-15 10:01 ` ebotcazou at gcc dot gnu dot org
2006-01-16 23:16 ` dick_guertin at yahoo dot com
` (25 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-15 10:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
2006-01-15 10:01 ` [Bug c/25791] -O2 execution fails, " ebotcazou at gcc dot gnu dot org
@ 2006-01-16 23:16 ` dick_guertin at yahoo dot com
2006-01-16 23:20 ` [Bug rtl-optimization/25791] " pinskia at gcc dot gnu dot org
` (24 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-16 23:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
2006-01-15 10:01 ` [Bug c/25791] -O2 execution fails, " ebotcazou at gcc dot gnu dot org
2006-01-16 23:16 ` dick_guertin at yahoo dot com
@ 2006-01-16 23:20 ` pinskia at gcc dot gnu dot org
2006-01-17 1:19 ` dick_guertin at yahoo dot com
` (23 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-16 23:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (2 preceding siblings ...)
2006-01-16 23:20 ` [Bug rtl-optimization/25791] " pinskia at gcc dot gnu dot org
@ 2006-01-17 1:19 ` dick_guertin at yahoo dot com
2006-01-17 4:35 ` dick_guertin at yahoo dot com
` (22 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-17 1:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (3 preceding siblings ...)
2006-01-17 1:19 ` dick_guertin at yahoo dot com
@ 2006-01-17 4:35 ` dick_guertin at yahoo dot com
2006-01-17 6:59 ` ebotcazou at gcc dot gnu dot org
` (21 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-17 4:35 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (4 preceding siblings ...)
2006-01-17 4:35 ` dick_guertin at yahoo dot com
@ 2006-01-17 6:59 ` ebotcazou at gcc dot gnu dot org
2006-01-17 8:33 ` dick_guertin at yahoo dot com
` (20 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-17 6:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (5 preceding siblings ...)
2006-01-17 6:59 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-17 8:33 ` dick_guertin at yahoo dot com
2006-01-17 8:47 ` ebotcazou at gcc dot gnu dot org
` (19 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-17 8:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (6 preceding siblings ...)
2006-01-17 8:33 ` dick_guertin at yahoo dot com
@ 2006-01-17 8:47 ` ebotcazou at gcc dot gnu dot org
2006-01-17 19:01 ` dick_guertin at yahoo dot com
` (18 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-17 8:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (7 preceding siblings ...)
2006-01-17 8:47 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-17 19:01 ` dick_guertin at yahoo dot com
2006-01-17 20:55 ` dick_guertin at yahoo dot com
` (17 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-17 19:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (8 preceding siblings ...)
2006-01-17 19:01 ` dick_guertin at yahoo dot com
@ 2006-01-17 20:55 ` dick_guertin at yahoo dot com
2006-01-18 3:10 ` dick_guertin at yahoo dot com
` (16 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-17 20:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (9 preceding siblings ...)
2006-01-17 20:55 ` dick_guertin at yahoo dot com
@ 2006-01-18 3:10 ` dick_guertin at yahoo dot com
2006-01-18 13:31 ` ebotcazou at gcc dot gnu dot org
` (15 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-18 3:10 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (10 preceding siblings ...)
2006-01-18 3:10 ` dick_guertin at yahoo dot com
@ 2006-01-18 13:31 ` ebotcazou at gcc dot gnu dot org
2006-01-18 13:38 ` ebotcazou at gcc dot gnu dot org
` (14 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-18 13:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (11 preceding siblings ...)
2006-01-18 13:31 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-18 13:38 ` ebotcazou at gcc dot gnu dot org
2006-01-19 4:00 ` dick_guertin at yahoo dot com
` (13 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-18 13:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (12 preceding siblings ...)
2006-01-18 13:38 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-19 4:00 ` dick_guertin at yahoo dot com
2006-01-19 4:04 ` pinskia at gcc dot gnu dot org
` (12 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 4:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (13 preceding siblings ...)
2006-01-19 4:00 ` dick_guertin at yahoo dot com
@ 2006-01-19 4:04 ` pinskia at gcc dot gnu dot org
2006-01-19 4:50 ` dick_guertin at yahoo dot com
` (11 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-19 4:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (14 preceding siblings ...)
2006-01-19 4:04 ` pinskia at gcc dot gnu dot org
@ 2006-01-19 4:50 ` dick_guertin at yahoo dot com
2006-01-19 6:41 ` dick_guertin at yahoo dot com
` (10 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 4:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (15 preceding siblings ...)
2006-01-19 4:50 ` dick_guertin at yahoo dot com
@ 2006-01-19 6:41 ` dick_guertin at yahoo dot com
2006-01-19 6:51 ` pinskia at gcc dot gnu dot org
` (9 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 6:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (16 preceding siblings ...)
2006-01-19 6:41 ` dick_guertin at yahoo dot com
@ 2006-01-19 6:51 ` pinskia at gcc dot gnu dot org
2006-01-19 6:55 ` ebotcazou at gcc dot gnu dot org
` (8 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-19 6:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (17 preceding siblings ...)
2006-01-19 6:51 ` pinskia at gcc dot gnu dot org
@ 2006-01-19 6:55 ` ebotcazou at gcc dot gnu dot org
2006-01-19 7:46 ` dick_guertin at yahoo dot com
` (7 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-19 6:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (18 preceding siblings ...)
2006-01-19 6:55 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-19 7:46 ` dick_guertin at yahoo dot com
2006-01-19 8:26 ` dick_guertin at yahoo dot com
` (6 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 7:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (19 preceding siblings ...)
2006-01-19 7:46 ` dick_guertin at yahoo dot com
@ 2006-01-19 8:26 ` dick_guertin at yahoo dot com
2006-01-19 8:39 ` ebotcazou at gcc dot gnu dot org
` (5 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 8:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (20 preceding siblings ...)
2006-01-19 8:26 ` dick_guertin at yahoo dot com
@ 2006-01-19 8:39 ` ebotcazou at gcc dot gnu dot org
2006-01-19 12:16 ` pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-19 8:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (21 preceding siblings ...)
2006-01-19 8:39 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-19 12:16 ` pinskia at gcc dot gnu dot org
2006-01-19 17:54 ` dick_guertin at yahoo dot com
` (3 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-19 12:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (22 preceding siblings ...)
2006-01-19 12:16 ` pinskia at gcc dot gnu dot org
@ 2006-01-19 17:54 ` dick_guertin at yahoo dot com
2006-01-19 18:23 ` dick_guertin at yahoo dot com
` (2 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 17:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (23 preceding siblings ...)
2006-01-19 17:54 ` dick_guertin at yahoo dot com
@ 2006-01-19 18:23 ` dick_guertin at yahoo dot com
2006-01-19 18:33 ` ebotcazou at gcc dot gnu dot org
2006-01-21 8:17 ` dick_guertin at yahoo dot com
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-19 18:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (24 preceding siblings ...)
2006-01-19 18:23 ` dick_guertin at yahoo dot com
@ 2006-01-19 18:33 ` ebotcazou at gcc dot gnu dot org
2006-01-21 8:17 ` dick_guertin at yahoo dot com
26 siblings, 0 replies; 28+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-01-19 18:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
` (25 preceding siblings ...)
2006-01-19 18:33 ` ebotcazou at gcc dot gnu dot org
@ 2006-01-21 8:17 ` dick_guertin at yahoo dot com
26 siblings, 0 replies; 28+ messages in thread
From: dick_guertin at yahoo dot com @ 2006-01-21 8:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2006-01-21 8:17 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-15 7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, -O and -g work dick_guertin at yahoo dot com
2006-01-15 10:01 ` [Bug c/25791] -O2 execution fails, " ebotcazou at gcc dot gnu dot org
2006-01-16 23:16 ` dick_guertin at yahoo dot com
2006-01-16 23:20 ` [Bug rtl-optimization/25791] " pinskia at gcc dot gnu dot org
2006-01-17 1:19 ` dick_guertin at yahoo dot com
2006-01-17 4:35 ` dick_guertin at yahoo dot com
2006-01-17 6:59 ` ebotcazou at gcc dot gnu dot org
2006-01-17 8:33 ` dick_guertin at yahoo dot com
2006-01-17 8:47 ` ebotcazou at gcc dot gnu dot org
2006-01-17 19:01 ` dick_guertin at yahoo dot com
2006-01-17 20:55 ` dick_guertin at yahoo dot com
2006-01-18 3:10 ` dick_guertin at yahoo dot com
2006-01-18 13:31 ` ebotcazou at gcc dot gnu dot org
2006-01-18 13:38 ` ebotcazou at gcc dot gnu dot org
2006-01-19 4:00 ` dick_guertin at yahoo dot com
2006-01-19 4:04 ` pinskia at gcc dot gnu dot org
2006-01-19 4:50 ` dick_guertin at yahoo dot com
2006-01-19 6:41 ` dick_guertin at yahoo dot com
2006-01-19 6:51 ` pinskia at gcc dot gnu dot org
2006-01-19 6:55 ` ebotcazou at gcc dot gnu dot org
2006-01-19 7:46 ` dick_guertin at yahoo dot com
2006-01-19 8:26 ` dick_guertin at yahoo dot com
2006-01-19 8:39 ` ebotcazou at gcc dot gnu dot org
2006-01-19 12:16 ` pinskia at gcc dot gnu dot org
2006-01-19 17:54 ` dick_guertin at yahoo dot com
2006-01-19 18:23 ` dick_guertin at yahoo dot com
2006-01-19 18:33 ` ebotcazou at gcc dot gnu dot org
2006-01-21 8:17 ` dick_guertin at yahoo dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).