[Bug other/49942] New: Wrong code generated for -O2 with target s390 on Linux

[Bug other/49942] New: Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

           Summary: Wrong code generated for -O2 with target s390 on Linux
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jphartmann@gmail.com


Created attachment 24887
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24887
Preprocessor output

Cross-compiling from Linux to S390 -m31 Generates an incorrect branch.  This is
likely a 390 problem.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #1 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 08:22:43 UTC ---
Created attachment 24888
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24888
The compiler output

Line 3664 (.LVL333:) contains jnhe.  It should have been jne, or there is code
missing to handle the other case in the following condition; it should not drop
through to iterate.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #2 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 08:26:37 UTC ---
Linux bigserv 2.6.34.8-68.fc13.x86_64 #1 SMP Thu Feb 17 15:03:58 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux

gcc -fexec-charset=IBM-1047 -Wno-format -D__ZVM__ -D__CMS__ -U __gnu_linux__ -g
 -I$HOME/src/cmsh -I$HOME/src/pdpclib -I. -m31 -march=g5 -fno-use-linker-plugin
-include cmsdefs.h -I${HOME}/include -fverbose-asm -O2 -save-temps
-funsigned-char -S num.c

The compiler was configured with:

--with-gnu-as --with-gnu-ld --prefix=/home/john/pool/360/root/usr
--with-sysroot=/home/john/pool/360/root --target=s390x-ibm-linux
--enable-languages=c --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--disable-libgomp --disable-threads --disable-tls --disable-libada
--disable-libssp --disable-shared --without-headers --disable-lto --disable-nls

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #3 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 08:37:44 UTC ---
Adding a dummy assignment to a global value that the optimiser cannot figure to
be useless fixes the problem.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-02 09:28:32 UTC ---
Why do you think so?
slr; jnhe is what you get for e.g.
void bar (void);
int foo (int x, int y)
{
  int d = x - y;
  if (d == 0)
    bar ();
  return d;
}
        slr     %r12,%r3
        jnhe    .L2
(it jumps around bar (), so the jump happens if (d != 0)).  The same code for
s/int/unsigned/g.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.08.02 09:40:30
     Ever Confirmed|0                           |1

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #5 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 09:59:44 UTC ---
Because the unoptimised code has a je at that place.  And putting anything
after the assignment generates correct code.  And debug code after the loop
shows that it falls through where it shouldn't.  Maybe it will help to show the
actual C rather than what comes out of the preprocessor, but this is the one
that works.  Remove the assignment to dummy and it fails:

      for (i = 0; NUMD - FUZZ > i; i++)
      {
         int diff = (0xff & op0->digits[i]) - (0xff & op1->digits[i]);

         DDDEBUG("i %d op %c op1 %c diff %d\n", i,
            op0->digits[i], op1->digits[i], diff);

         dummy = diff; /* cures a gcc bug */
         if (diff) return '-' == op0->sign
               ? (0 < diff ? -1 : 1)
               : (0 > diff ? -1 : 1);
      }
      DDEBUG("Fell through. %s vs %s\n", op0->digits, op1->digits);

The DDDEBUG is discarded by the preprocessor.  FUZZ is 0 and NUMD is 9 in the
case at hand.

In the case at hand the leading digits are different; that may have a bearing
since it looks like some of the loop is unrolled.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #6 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 10:16:17 UTC ---
Created attachment 24889
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24889
Stripped-down test case.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #7 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 10:18:28 UTC ---
The stripped-down test case gives this (expected) output on linux:

900000000 vs 400000000  is 1
400000000 vs 900000000  is -1

And this (faulty) output on VM:

900000000 vs 400000000  is 0    
400000000 vs 900000000  is -1

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-02 12:42:56 UTC ---
Can't reproduce on:
struct oper { char *digits; char sign; };
struct oper oper0 = {"900000000", '+'};
struct oper oper1 = {"400000000", '+'};

static int
comp (struct oper *op0, struct oper *op1)
{
  int i;
  __builtin_printf ("%s vs %s ", op0->digits, op1->digits);
  for (i = 0; 9 > i; i++)
    {
      int diff = (0xff & op0->digits[i]) - (0xff & op1->digits[i]);
      if (diff) return '-' == op0->sign ? (0 < diff ? -1 : 1) : (0 > diff ? -1
: 1);
    }
  return 0;
}

int
main ()
{
  __builtin_printf (" is %d\n", comp (&oper0, &oper1));
  __builtin_printf (" is %d\n", comp (&oper1, &oper0));
  return 0;
}

With current 4.6 branch as well as trunk, compiling with with -m31 -O{0,1,2}
on x86_64-linux -> s390x-linux cross, then running on s390 always results in:
900000000 vs 400000000  is 1
400000000 vs 900000000  is -1

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #9 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 13:18:47 UTC ---
That is good to know.  However, this problem is with -fexec-charset=IBM-1047.

You cannot run the output of that on the ASCII z/Linux.  

Can I trouble you to send me your .s file with -O2 for the ASCII platform? 
That should let me spot any differences.

Martin has assured me that jnhe generates a mask of 5, and I'm sure that is
what it does in other contexts.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-02 13:36:53 UTC ---
I think the testcase from your exec charset for Linux would map to:
struct oper { char *digits; char sign; };
struct oper oper0 = {"\xf9\xf0\xf0\xf0\xf0\xf0\xf0\xf0\xf0", 'N'};
struct oper oper1 = {"\xf4\xf0\xf0\xf0\xf0\xf0\xf0\xf0\xf0", 'N'};

static int
comp (struct oper *op0, struct oper *op1)
{
  int i;
  __builtin_printf ("%s vs %s ", op0->digits, op1->digits);
  for (i = 0; 9 > i; i++)
    {
      int diff = (0xff & op0->digits[i]) - (0xff & op1->digits[i]);
      if (diff) return '`' == op0->sign ? (0 < diff ? -1 : 1) : (0 > diff ? -1
: 1);
    }
  return 0;
}

int
main ()
{
  __builtin_printf (" is %d\n", comp (&oper0, &oper1));
  __builtin_printf (" is %d\n", comp (&oper1, &oper0));
  return 0;
}

('0' through '9' are '\xf0' through '\xf9' apparently, and '+' is 'N' and '-'
is '`'.  If I run this on Linux, I still get the expected results.

No idea about if zVM doesn't set up something differently etc., clearly it
works on Linux.  Can you use a s390x-linux targetted compiler to compile code
for the VM at all, i.e. shouldn't that be a different target?

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #11 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 14:04:29 UTC ---
With the slr, bc 5,x is the correct mask, or course.  So it must be something
else.

As I understand it s390 and s390x are exactly the same except the default -m31.
 But I might be mistaken there as well.  I certainly tried both in my struggle
with building the cross compiler.  Have you perchance a crib sheet of how yours
was built?

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-02 14:12:45 UTC ---
Just ../configure --target s390x-linux, I don't even have s390x binutils here,
so I can just compile into assembly (all that I need for compiler bugfixing).

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

jphartmann@gmail.com <jphartmann at gmail dot com> changed:

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

--- Comment #13 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 14:36:11 UTC ---
That was the first I tried, but make then gave me a slew of errors and didn't
even create xgcc.  So what did you do to build the compiler?

Anyhow, I changed the jnhe to use an explicit mask when turning gas into HLASM
and that fixed the problem, so I must have done something wrong originally. 

I assume WORKSFORME is a polite way to say user error.  If not, please change
the close code accordingly.

[Bug other/49942] Wrong code generated for -O2 with target s390 on Linux

[jphartmann at gmail dot com]

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

--- Comment #14 from jphartmann at gmail dot com <jphartmann at gmail dot com> 2011-08-02 14:45:24 UTC ---
Hello, Jakub.

Thanks for helping me regain sanity.

So was I let astray by trying to set up a separate root, which I had
to populate with all kinds of stuff.  And I also dutifully created
binutils as that was what everyone says to do.

Cheers,

   j.

On 2 August 2011 16:13, jakub at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
>
> --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-08-02 14:12:45 UTC ---
> Just ../configure --target s390x-linux, I don't even have s390x binutils here,
> so I can just compile into assembly (all that I need for compiler bugfixing).
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>