[Bug rtl-optimization/23650] New: Scheduler does not handle zero_extract correctly

[Bug rtl-optimization/23650] New: Scheduler does not handle zero_extract correctly

[Erwin dot Unruh at fujitsu-siemens dot com]

/*
 * compile with GCC 3.3.2 on s390-ibm-linux
 * options: -O3
 *
 * instruction 61 and 71 will be switched by the scheduler, although they
 * access overlapping memory
 *

(insn 71 317 72 2 ff1f1500 (parallel [
            (set (reg/v:SI 53) 
                (zero_extract:SI (mem/f:QI (plus:SI (reg/f:SI 34 %fp)
                            (const_int 96 [0x60])) [9 S1 A16])
                    (const_int 15 [0xf])
                    (const_int 0 [0x0])))
            (clobber (reg:CC 33 %cc))
        ]) 89 {*extracthi} (insn_list 317 (nil))
    (expr_list:REG_UNUSED (reg:CC 33 %cc)
        (nil)))

(insn 61 67 63 2 ff1f1500 (set (mem/s:QI (plus:SI (reg/f:SI 34 %fp)
                (const_int 97 [0x61])) [0 <variable>.string_2+1 S1 A8])
        (mem/s:QI (plus:SI (reg/v/f:SI 49)
                (const_int 3 [0x3])) [0 <variable>.mem2.string_2+1 S1 A8])) 59 
        
        {movqi} (insn_list 56 (insn_list:REG_DEP_OUTPUT 317 
        (insn_list:REG_DEP_ANTI 312 (insn_list:REG_DEP_ANTI 315 (nil)))))
    (nil))

 * The reason is probably in sched_analyze_2 which does not handle zero_extract
 * correctly. It just hands the (mem:QI ...) subexpression to another
 * incarnation of sched_analyze_2. The fact that 2 bytes were accessed is lost.
 *
 */


typedef struct {
    char string_2 [2];
} Char2;


typedef struct { 
    char string_4 [4];
} Char4;


typedef struct
{
   void *mem4;
   void *mem5;
   Char4 mem6; 
   Char2 mem7;
   Char2 mem8;

} Type2;


typedef struct {
   Char2 mem1;
   Char2 mem2;
   Char2 mem3;
} Type1;

typedef void *Pointer;

unsigned char Erwin
(
   Type2 *par1,
   Type1 *par2,
   Type1 *par3,

   Type1 **par4,
   Char2 **par5,
   unsigned char *par6,
   Char4 *par7
)
{
   int var1;
   Pointer var2;
   Pointer var3;
   Pointer var4;
   int var5;
   int var6;
   int var7;

   unsigned short var8;

   Char2 var9;
   Char2 var10;

   unsigned char var11;

   var2 = (Pointer) par2;
   var4 = (Pointer) par2;
   var11 = 0;

   while ((var2 < par3) && (!var11))
   {
      if (memcmp( (Char2 *) var2, &par1->mem7, sizeof(Char2)) == 0)
      {
         *par4 = (Type1 *) var2;
         ((Char2 * ) &var8)->string_2[0] = ((Type1 *) var2)->mem2.string_2[0];;
         ((Char2 * ) &var8)->string_2[1] = ((Type1 *) var2)->mem2.string_2[1];;

         var2 = (Pointer) ((char *) var2 + ((sizeof (Type1) - sizeof 
(Char2))));
         var3 = var2;

         var5 = 0;
         var6 = ((int) var8) / sizeof(Char2);


         while (var5 != var6)
         {
            var7 = (var5 + var6) / sizeof(Char2);
            var2 = ( (Pointer) ( (char *) (var3) + ((var7 * sizeof
(Char2))) ) );

            var1 = memcmp ( (Char2 *) var2, &par1->mem8, sizeof(Char2));

            if (var1 < 0)
            {
               var5 = var7 + 1;
            }
            else if (var1 > 0)
            {
               var6 = var7;
            }
            else
            {
               var6 = var7;
               var5 = var7;
            }
          }
          if ( var1 == 0)
          {
            var11 = (!0);
            *par5 = ((Char2 *) var2);

            if (( (Pointer) ( (char *) (var2) + (sizeof(Char2)) ) ) == par3)
            {

               *par6 = (!0);

               if (( (Pointer) ( (char *) (*par4) +
                               ((sizeof (Type1) - sizeof (Char2))) ) ) == var2)
               {
                  if (var4 == *par4)
                  {
                     memset(&var9, 0x00, sizeof(Char2));
                     memset(&var10, 0x00, sizeof(Char2));
                  }
                  else
                  {
                     memcpy (&var9, var4, sizeof(Char2)); 
                     *((Char2 * ) &var8) = ((Type1 *) var4)->mem2;;
                     var2 = ((Pointer) ((char *) var4 + ((var8 +
                        (sizeof (Type1) - sizeof (Char2)) - sizeof
(Char2))) ) );

                     memcpy (&var10, var2, sizeof(Char2));
                  }
               }
               else
               {
                  var2 = ( (Pointer) ( (char *) (var2) - (sizeof(Char2)) ) );
                  memcpy (&var10, var2, sizeof(Char2));
                  var9 = par1->mem7;
               }
               memcpy(&(par7->string_4[0]), &var9, sizeof(Char2));
               memcpy(&(par7->string_4[2]), &var10, sizeof(Char2));
            }
            else
            {
               *par6 = 0;
            }
         }
         else
         {
            var11 = 0;
            break;
         }
      }
      else
      {
         var4 = var2;
         *((Char2 * ) &var8) = ((Type1 *) var2)->mem2;;
         var2 = ( (Pointer) ( (char *) (var2) + ((var8 +
                        (sizeof (Type1) - sizeof (Char2)) )) ) );
      }
   }
   return(var11);
}

-- 
           Summary: Scheduler does not handle zero_extract correctly
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: s390-ibm-linux


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-31 12:29 -------
You are violating C aliasing rules, either use an union (which is a GCC extension) or use -fno-strict-
alias.

(Char2 * ) &var

*** This bug has been marked as a duplicate of 21920 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[Erwin dot Unruh at fujitsu-siemens dot com]

------- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com  2005-08-31 12:51 -------
With option -fno-strict-aliasing the generated code is still incorrect.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-08-31 14:39 -------
Can you please provide a testcase that can be executed and does abort() if the
outcome is wrong and has zero exit code if it is right?

Thanks,
Richard.

-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[bonzini at gcc dot gnu dot org]

------- Additional Comments From bonzini at gcc dot gnu dot org  2005-08-31 14:45 -------
Having a zero_extract that takes 16 bytes out of a QImode mem seems extremely
wrong.  Can you find out which pass generates that thing?  Just grep for

zero_extract:SI..mem[a-z/]:QI

in all the files dumped by -da.


-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-08-31 14:58 -------
Also note that gcc 3.3.2 is not exactly state of the art, but unmaintained,
and a fix would go at earliest into 3.4.5, which may be already fixed.

-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[Erwin dot Unruh at fujitsu-siemens dot com]

------- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com  2005-09-02 09:08 -------
The zero_extract is generated by the combiner pass (x.c.17.combine). Note that 
the official documentation of zero_extract requires a mem:QI (see 
http://gcc.gnu.org/onlinedocs/gccint/Bit_002dFields.html).

I just tested the case with a 4.0.1 crosscompiler. The error is still present.

-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[Erwin dot Unruh at fujitsu-siemens dot com]

------- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com  2005-09-19 12:25 -------
Created an attachment (id=9773)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9773&action=view)
testcase supplement

Here is some additional coding, which calls the function given in the bug
report. The exit code is 1 in case of error, zero otherwise.
I was able to verify my original analysis with this test.

-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[rguenth at gcc dot gnu dot org]

------- Additional Comments From rguenth at gcc dot gnu dot org  2005-09-19 17:57 -------
Created an attachment (id=9774)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9774&action=view)
complete testcase

Combining comment #1 and the testcase, declaring some functions and exchaning
printf for abort() I cannot reproduce the bug as the testcase aborts with
every optimization level, even -O0 -fno-strict-aliasing and shows this same
behavior even with the intel compiler.

Can you re-check, if the testcase is really working in some case?

-- 


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[Erwin dot Unruh at fujitsu-siemens dot com]

------- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com  2005-09-20 07:22 -------
Created an attachment (id=9780)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9780&action=view)
complete testcase (corrected)

My first try on the testcase depends on the endianess. S/390 is big endian,
intel is little endian. This revised testcase avoids this dependency. It runs
correctly on intel (-O0 or -O3).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9773 is|0                           |1
           obsolete|                            |


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

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-20 00:48:42 UTC ---
No feedback in over an year so closing.

[Bug rtl-optimization/23650] Scheduler does not handle zero_extract correctly

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-01-11
     Ever Confirmed|0                           |1

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 14:23:13 UTC ---
Is this still an issue?