Bug 1199041 - libgcrypt test-suite fails on big endians when compiled with -O2
Summary: libgcrypt test-suite fails on big endians when compiled with -O2
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeff Law
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ZedoraTracker PPCTracker
TreeView+ depends on / blocked
 
Reported: 2015-03-05 11:29 UTC by Dan Horák
Modified: 2015-03-23 07:14 UTC (History)
7 users (show)

(edit)
Clone Of:
: 1201219 (view as bug list)
(edit)
Last Closed: 2015-03-23 07:14:07 UTC


Attachments (Terms of Use)
preprocessed source (239.62 KB, text/plain)
2015-03-06 08:39 UTC, Dan Horák
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 65401 None None None Never

Description Dan Horák 2015-03-05 11:29:43 UTC
The test-suite in libcrypt fails when the library is built with -O2 on big endian arches (ppc64, s390x), but passes on eg. ppc64le. And because they pass when -O1 is used, I suspect gcc produces incorrect machine code.

Version-Release number of selected component (if applicable):
gcc-5.0.0-0.18.fc22.ppc64
gcc-5.0.0-0.18.fc22.s390x

libgcrypt-1.6.2-4.fc23


see eg http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1749932 for full build.log, but it was retested locally on F-22 s390x and ppc64 with the latest gcc.

Comment 1 Dan Horák 2015-03-05 11:42:37 UTC
from build.log

...
make  check-TESTS
make[2]: Entering directory '/builddir/build/BUILD/libgcrypt-1.6.2/tests'
version:1.6.2:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch::
mpi-asm:generic/mpih-add1.c:generic/mpih-sub1.c:generic/mpih-mul1.c:generic/mpih-mul2.c:generic/mpih-mul3.c:generic/mpih-lshift.c:generic/mpih-rshift.c:
threads:none:
hwflist:
fips-mode:n:n:
rng-type:standard:1:
PASS: version
PASS: mpitests
PASS: tsexp
PASS: t-convert
PASS: t-mpi-bit
PASS: t-mpi-point
PASS: curves
PASS: t-lock
PASS: prime
RFC2268 selftest failed (RFC2268 encryption test 1 failed.).
pass 0, algo 307, mode 1, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 2, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 5, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 6, gcry_cipher_setkey failed: Selftest failed
FAIL: basic
PASS: keygen
...

Comment 2 Dan Horák 2015-03-05 23:18:39 UTC
when working with upstream (http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=summary)

[sharkcz@tyan-openpower-01 libgcrypt]$ ./tests/basic 
selftest for CFB failed - see syslog for details
pass 0, algo 4, mode 1, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 2, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 5, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 6, gcry_cipher_setkey failed: Selftest failed

syslog/journal contains
Libgcrypt warning: BLOWFISH-CFB-64 test failed (plaintext mismatch)

it seems when functions do_encrypt() and do_encrypt_block() (http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob_plain;f=cipher/blowfish.c;hb=HEAD) both have __attribute__((optimize("O0"))) then the test passes

More info tomorrow.

Comment 3 Dan Horák 2015-03-06 08:39:09 UTC
Created attachment 998718 [details]
preprocessed source

Comment 4 Marek Polacek 2015-03-06 23:41:00 UTC
For the ppc64 issue (comment 2) it appears the code is violating C aliasing rules.  With -fno-strict-aliasing the test passes; adding __attribute__ ((optimize("no-strict-aliasing"))) to buf_xor_n_copy helps as well.  I think buf_xor_n_copy_2 accesses "unsigned char *" as a "uintptr_t *".

Comment 5 Jakub Jelinek 2015-03-12 09:56:27 UTC
So, I had a quick look at the s390x tests/basic issue, and bisected that to
http://gcc.gnu.org/r220249 - miscompiled? source is cipher/rfc2268.c in that case.

Comment 6 Dan Horák 2015-03-12 10:55:40 UTC
(In reply to Marek Polacek from comment #4)
> For the ppc64 issue (comment 2) it appears the code is violating C aliasing
> rules.  With -fno-strict-aliasing the test passes; adding __attribute__
> ((optimize("no-strict-aliasing"))) to buf_xor_n_copy helps as well.  I think
> buf_xor_n_copy_2 accesses "unsigned char *" as a "uintptr_t *".

thanks for looking, Marek, I will clone this bug for libgcrypt itself

Comment 7 Jakub Jelinek 2015-03-12 11:11:38 UTC
Self-contained testcase for the s390x rfc2268 issue:

struct S { unsigned short s[64]; };

__attribute__((noinline, noclone)) void
foo (struct S *x)
{
  unsigned int i;
  unsigned char *s;

  s = (unsigned char *) x->s;
  for (i = 0; i < 64; i++)
    x->s[i] = s[i * 2] | (s[i * 2 + 1] << 8);
}  

int
main ()
{
  unsigned int i;
  struct S s;
  for (i = 0; i < 64; i++)
    s.s[i] = i + ((64 - i) << 8);
  foo (&s);
  for (i = 0; i < 64; i++)
    if (s.s[i] != (64 - i) + (i << 8))
      __builtin_abort ();
  return 0;
}

I believe this is ok wrt. strict aliasing, as it is read using a character type.

Comment 8 Jakub Jelinek 2015-03-12 11:12:18 UTC
Forgot -m64 -march=z9-109 -mtune=z10 -O2 -fPIC options.

Comment 9 Jakub Jelinek 2015-03-12 11:55:21 UTC
The problem seems to be that combine_simplify_rtx "simplifies"
(set (mem:HI (plus:DI (reg/v/f:DI 126 [ x ])
            (reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41, offset: 0B]+0 S2 A16])
    (ior:HI (subreg:HI (and:SI (subreg:SI (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
                            (reg:DI 125 [ ivtmp.11 ])) [0 MEM[base: s_4, index: ivtmp.11_41, offset: 0B]+0 S1 A8]) 0)
                (const_int 255 [0xff])) 2)
        (subreg:HI (reg:SI 128 [ D.1536 ]) 2)))
into:
(set (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
            (reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41, offset: 0B]+0 S1 A16])
    (subreg:QI (lshiftrt:SI (reg:SI 128 [ D.1536 ])
            (const_int 8 [0x8])) 3))
Perhaps some hardcoded little endian assumption somewhere?

Comment 10 Jeff Law 2015-03-12 13:32:51 UTC
Sounds like make_extraction or one of its friends.  Given I was just in this code a month or so ago, I'm happy to take it since it's probably my goof.

jeff

Comment 11 Jakub Jelinek 2015-03-12 13:41:01 UTC
Tracking upstream now.
If you want to take it, sure.

Comment 12 Dan Horák 2015-03-14 07:29:28 UTC
when using gcc-5.0.0-0.19.fc22 with http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc5-pr65401.patch applied, the libgcrypt test suite passes on s390x.

Comment 13 George R. Goffe 2015-03-19 23:38:27 UTC
Hi,

Sorry to barge in here but I'm running the latest Fedora 21 x86_64 libgcrypt and am getting messages like this:

libgcrypt selftest: pubkey RSA (1): mismatch (encrypt)
libgcrypt selftest: pubkey RSA (1): Selftest failed

Could this be related to what you guys are doing or should I make a new bug report?

Regards,

George...

rpm -q libgcrypt
libgcrypt-1.6.3-1.fc21.x86_64
libgcrypt-1.6.3-1.fc21.i686

Comment 14 Peter Robinson 2015-03-20 00:19:06 UTC
> Could this be related to what you guys are doing or should I make a new bug
> report?

Not related, the bug is about Big Endian architectures (ie not x86_64). I suggest you search mailing list archives first, it's been discussed there

Comment 15 Fedora Update System 2015-03-20 10:57:42 UTC
gcc-5.0.0-0.21.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/gcc-5.0.0-0.21.fc22

Comment 16 Fedora Update System 2015-03-21 04:48:09 UTC
Package gcc-5.0.0-0.21.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gcc-5.0.0-0.21.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4214/gcc-5.0.0-0.21.fc22
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2015-03-23 07:14:07 UTC
gcc-5.0.0-0.21.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.