[Bug target/59573] New: aarch64: commit 07ca5686e64 broken glibc-2.17

[Bug target/59573] New: aarch64: commit 07ca5686e64 broken glibc-2.17

[dennis.yxun at gmail dot com]

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

            Bug ID: 59573
           Summary: aarch64: commit 07ca5686e64 broken glibc-2.17
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dennis.yxun at gmail dot com

Created attachment 31498
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31498&action=edit
glibc build error

I'm using qemu-aarch64[1], and trying to build rootfs with gcc-4.9.0,
glibc-2.17, binutils-2.24.51.0.1 

following commit[2] result in un-usable glibc (2.17), I haven't trace to the
root cause, but detail error can be seen in "glibc.error"[4]

btw, I'm using "git bisect" to find this commit[2]. and also tested passed with
latest commit[3], but with this commit[2] reverted.



[1] git://github.com/susematz/qemu.git, branch aarch64-1.6
[2] gcc offended commit:
commit 07ca5686e64d32f7df4ccf4205d0b914f120da5e
Author: yroux <yroux@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Sep 26 09:09:30 2013 +0000

    2013-09-26  Yvan Roux  <yvan.roux@linaro.org>

        * config/aarch64/aarch64.opt (mlra): New option.
        * config/aarch64/aarch64.c (aarch64_lra_p): New function.
        (TARGET_LRA_P): Define.



    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@202940
138bc75d-0d04-0410-961f-82ee72b054a4

[3] gcc commit: 33c503bd9001b6fe823aa9be319a09df500a6b40

[4] glibc build error, a) trigger unknown insns b) result int ld-*.so
un-usable. this two error won't happen with the commit[2] reverted
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/sln
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/symlink.list
rm -f
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/symlink.list
make[1]: Leaving directory
'/var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17'
 * Defaulting /etc/host.conf:multi to on
unallocated encoding at line: 3465
Unknown instruction: 0x5ee09800
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
/usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 21: 28605
Illegal instruction     (core dumped) ./ld-*.so --library-path . ${x} >
/dev/null
 * ERROR: sys-libs/glibc-2.17::gentoo failed (preinst phase):
 *   simple run test (/bin/date) failed
 * 
 * Call stack:
 *           ebuild.sh, line   93:  Called pkg_preinst
 *         environment, line 3108:  Called eblit-run 'pkg_preinst'
 *         environment, line  944:  Called eblit-glibc-pkg_preinst
 *   pkg_preinst.eblit, line   48:  Called glibc_sanity_check
 *   pkg_preinst.eblit, line   27:  Called die
 * The specific snippet of code:
 *           ./ld-*.so --library-path . ${x} > /dev/null \
 *               || die "simple run test (${x}) failed"
 *

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
You need to fix qemu to implement insn 0x5ee09800 (cmeq d0, d0, #0).

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[dennis.yxun at gmail dot com]

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

Dennis.Yxun <dennis.yxun at gmail dot com> changed:

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

--- Comment #2 from Dennis.Yxun <dennis.yxun at gmail dot com> ---

1) I still don't get why with this commit, it will lead to generate "cmeq"
instruction, is this really necessary?

2) yes, I'd admit that the qemu I built did *not* support cmeq scalar mode, but
I do have a patch which implemented this insn. and it still result at an
un-usable system, very weird error.,, also I will ping qemu maintainer for
suggestion.

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Dennis.Yxun from comment #2)
> 1) I still don't get why with this commit, it will lead to generate "cmeq"
> instruction, is this really necessary?

Well the register allocator changed which leads to a different alternative
being selected here so most likely.

> 
> 2) yes, I'd admit that the qemu I built did *not* support cmeq scalar mode,
> but I do have a patch which implemented this insn. and it still result at an
> un-usable system, very weird error.,, also I will ping qemu maintainer for
> suggestion.

Can you try using ARM's foundation model (or another simulator) which should be
easier to compare against?

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[dennis.yxun at gmail dot com]

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

--- Comment #4 from Dennis.Yxun <dennis.yxun at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> Can you try using ARM's foundation model (or another simulator) which should
> be easier to compare against?

Yes, I've tried with foundation_v8, and not only it extremely slow, but also it
fails here. compiling gcc in qemu takes 5hours, but takes one week (someone
told me) in foudation model.

for another simulator, do you have any suggestion?

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[yvan.roux at linaro dot org]

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

Yvan Roux <yvan.roux at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yvan.roux at linaro dot org

--- Comment #5 from Yvan Roux <yvan.roux at linaro dot org> ---

> Yes, I've tried with foundation_v8, and not only it extremely slow, but also
> it fails here. compiling gcc in qemu takes 5hours, but takes one week
> (someone told me) in foudation model.
> 
> for another simulator, do you have any suggestion?

is the foundation model failing for the same reason here (i.e. not recognizing
the cmeq instruction) ?

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[dennis.yxun at gmail dot com]

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

--- Comment #6 from Dennis Lan (dlan) <dennis.yxun at gmail dot com> ---
 (In reply to Yvan Roux from comment #5)
> is the foundation model failing for the same reason here (i.e. not
> recognizing the cmeq instruction) ?

Not exactly, the foundation_v8 got abort while compiling gcc..
and yes, it does recognize the cmeq instruction.

to clarify, the former gcc build log[1] I provided was generated in qemu which
have *no* cmeq support.

I do have a patch[2] for qemu which implement cmeq support (which I tested
passed), yes, could if anyone can review those patches[3]

for the qemu which implement cmeq, it does pass the glibc compilation and
install successfully, but with the new glibc, gcc fail to build executable
image[4]


[1] http://gcc.gnu.org/bugzilla/attachment.cgi?id=31498
[2]
https://github.com/dlanx/qemu/commit/1a9b3a40917c416125f10accba9e531ed91677d4
[3] git://github.com/dlanx/qemu (branch aarch64-1.6, top four patches)

[4] following output from qemu with cmeq implemented
(202940) insn # gcc -v
Using built-in specs.
COLLECT_GCC=/usr/aarch64-unknown-linux-gnu/gcc-bin/4.9.0-pre9999/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/4.9.0-pre9999/lto
-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.9.0_pre9999/work/gcc-4.9.0-999
9/configure --prefix=/usr
--bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/4.9.0-
pre9999
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre9999/includ
e --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre9999
--mandir
=/usr/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre9999/man
--infodir=/usr/
share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre9999/info
--with-gxx-include-d
ir=/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre9999/include/g++-v4
--host=aa
rch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --disable-altivec
--di
sable-fixed-point --without-cloog --disable-lto --enable-nls
--without-included-
gettext --with-system-zlib --enable-obsolete --disable-werror
--enable-secureplt
 --disable-multilib --disable-libmudflap --disable-libssp --enable-libgomp
--wit
h-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre9999/python
--en
able-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-language
s=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit
--$
nable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gento
o 4.9.0_pre9999'
Thread model: posix
gcc version 4.9.0-pre9999 20130926 (experimental) commit
07ca5686e64d32f7df4ccf4
205d0b914f120da5e (Gentoo 4.9.0_pre9999)

(202940) insn # cat cmeq_test.c
#include <stdio.h>                                                     
#include <stdlib.h>

long long fn(long long val)
{
        asm volatile(
        "fmov   d0, x0\n\t"
        "cmeq   d0, d0, #0\n\t"
        "fmov   x0, d0\n\t"
        );
}

int main(int argc, char *argv[])
{
        long long v = strtoul(argv[1], NULL, 0);
        printf("result: 0x%lx, 0x%lx\n", v, fn(v));
        return 0;
}
(202940) insn # ./cmeq_test 1
result: 0x1, 0x0
(202940) insn # ./cmeq_test 0
result: 0x0, 0xffffffffffffffff
(202940) insn # ./cmeq_test 0xffff000000
result: 0xffff000000, 0x0
(202940) insn # gcc -o mytest_v4 mytest_v4.c

/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre9999/../../../../aarch64-unknown-linux-gnu/bin/ld:
error: Cannot change output format whilst linking AArch64 binaries.
collect2: error: ld returned 1 exit status

(the above cmeq_test was built with sane gcc - with 07ca5686e64 reverted)

[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17

[dennis.yxun at gmail dot com]

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

--- Comment #7 from Dennis Lan (dlan) <dennis.yxun at gmail dot com> ---
Ok, it's qemu problem, not gcc.

I've built rootfs in qemu (with cmeq insn implemented), then deploy the rootfs
into foudation_v8 emulator. test to compiles code with gcc, and it works fine,
without the linker error.