On Wed, Jan 25, 2017 at 01:11:49PM +0100, Sebastian Huber wrote:
> I still get a lot of ICEs with the attached two patches (examples):
> /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function
> '__multc3':
> /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: error:
> unrecognizable insn:
> }
> ^
> (insn 59 58 60 2 (set (reg:CCFP 219)
> (compare:CCFP (reg/v:TF 193 [ x ])
> (reg/v:TF 193 [ x ])))
> "/home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c":1990 -1
> (nil))
> /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:2035:1: internal
> compiler error: in extract_insn, at recog.c:2311
The IEEE128 code almost certainly has some bugs on non-Linux configurations.
You could try debugging it, or you could avoid it (for now) by e.g. making
long double the same as double.
> /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/src/c++98/mt_allocator.cc:
> In function 'void {anonymous}::_M_destroy_thread_key(void*)':
> /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/src/c++98/mt_allocator.cc:82:57:
>
> error: cast from 'void*' to 'uintptr_t {aka unsigned int}' loses precision
> [-fpermissive]
> uintptr_t _M_id = reinterpret_cast<uintptr_t>(__id);
> ^
This sounds like your uintptr_t is a 32-bit type? That won't work.
> >>/home/EB/sebastian_h/archive/gcc-git/libgcc/emutls.c:171:13: note:
> >>include '<stdlib.h>' or provide a declaration of 'realloc'
> >>/tmp/ccoZ1J0W.s: Assembler messages:
> >>/tmp/ccoZ1J0W.s:125: Error: can't resolve `.got' {.got section} -
> >>`.LCTOC1' {*UND* section}
> >Your TLS is misconfigured. Or something.
>
> I compared the linux64.h and freebsd64.h and as a wild guess I added:
>
> +#undef TARGET_AIX
> +#define TARGET_AIX TARGET_64BIT
> +
>
> This seems to fix this issue. I don't know why.
Me neither.
> The resulting objects look not completely bad:
> Flags: 0x2, abiv2
Yup, looks correct.
Segher
