public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dick_guertin at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/25791] -O2 execution fails, -O and -g work
Date: Thu, 19 Jan 2006 04:00:00 -0000	[thread overview]
Message-ID: <20060119040020.9176.qmail@sourceware.org> (raw)
In-Reply-To: <bug-25791-12018@http.gcc.gnu.org/bugzilla/>



------- 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


  parent reply	other threads:[~2006-01-19  4:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-15  7:02 [Bug c/25791] New: -O2 execution fails using 3.4.4, " 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060119040020.9176.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).