Discussion:
[Bug binutils/19311] New: arm-linux-as build on Mac OS X with Xcode7 fails to assemble code from FreePascal cross-compiler
tonne1.schindler at web dot de
2015-11-30 17:30:20 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

Bug ID: 19311
Summary: arm-linux-as build on Mac OS X with Xcode7 fails to
assemble code from FreePascal cross-compiler
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: tonne1.schindler at web dot de
Target Milestone: ---

arm-linux-as build on Mac OS X with the command line tools from Xcode 7 fails
to assemble code from FreePascal cross-compiler, whereas everything goes
smooth, if the binutils are built with Xcode 6.

This is the relevant part of the log:

/BlaBla/fpc_fixes_3_0/compiler/ppcrossarm -Ur -Tlinux -Parm -XParm-linux- -Xr
-Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE.
-FU/BlaBla/fpc_fixes_3_0/rtl/units/arm-linux -ap -darm -dRELEASE -Us -Sg
system.pp
system.inc(1824,8) Warning: Implicit string type conversion from
"RawByteString" to "UnicodeString"
{standard input}: Assembler messages:
{standard input}:69: Error: invalid constant (7f) after fixup

and many more so.

simply executing "arm-linux-as string.s" yields the same error or not depending
on the version of xcode.

I checked config.status and config.log in gas and could not find any relevant
difference. The binutils are built with --target=arm-linux and --disable-werror
--disable-nls. I tried some modications of the configure options, but they did
not make any difference.

Karl-Michael Schindler
--
You are receiving this mail because:
You are on the CC list for the bug.
tonne1.schindler at web dot de
2015-11-30 17:31:43 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

Kar-Michael Schindler <tonne1.schindler at web dot de> changed:

What |Removed |Added
----------------------------------------------------------------------------
Target| |arm-linux
Host| |darwin
--
You are receiving this mail because:
You are on the CC list for the bug.
tonne1.schindler at web dot de
2015-11-30 22:47:11 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #1 from Kar-Michael Schindler <tonne1.schindler at web dot de> ---
A test with gcc5 produces a working arm-linux-as. Therefore, i suspect whacky
code in as, which accidentally works with some compilers and not with others.
Some hints point to defines of subarchs or thumb vs arm code or similar, but
this is too involved for me to resolve it.

Michael.
--
You are receiving this mail because:
You are on the CC list for the bug.
nickc at redhat dot com
2015-12-04 11:31:34 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

Nick Clifton <nickc at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi Kar-Michael,

Please could you upload the assembler source that is produced by the
ppccrossarm tool, so that we can try assembling it locally ? Capturing the
assembler command line would also help.

This may be a Mac OS specific bug, which will make it very hard for me to
track down (since I do not have access to a Mac OS system). But maybe we will
be lucky...

Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-24 08:46:06 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

Loria <Loria at phantasia dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |Loria at phantasia dot org

--- Comment #3 from Loria <Loria at phantasia dot org> ---
Created attachment 8921
--> https://sourceware.org/bugzilla/attachment.cgi?id=8921&action=edit
assembler source created by armv6-rpi-linux-gnueabihf-gcc (4.9.3)
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-24 09:16:16 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #4 from Loria <Loria at phantasia dot org> ---
I do encounter the same while trying to build a toolchain on OSX 10.10.5 and
Xcode 7.2
crosstool-ng 1.22.1
binutils-2.25.1
gcc-4.9.3
glibc-2.22

CT_ARCH_CPU="arm1176jzf-s"
CT_ARCH_FPU="vfp"
CT_EXTRA_CFLAGS_FOR_BUILD="-fbracket-depth=1024"
CT_EXTRA_CFLAGS_FOR_HOST="-fbracket-depth=1024"


I already could generated the assembler text:
libc-start.s: Assembler messages:
libc-start.s:70: Error: invalid constant (af) after fixup
libc-start.s:145: Error: invalid constant (ff) after fixup

thats the file I attached
taking a look at the sourcefile shows (I marked the lines the assembler
dislikes):
.L3:
ldr r2, [r0], #4
cmp r2, #0
bne .L3
bl _dl_aux_init
ldr r3, .L49+16
ldr r2, .L49+20
ldr r3, [r3]
cmp r2, #0
clz r3, r3
mov r1, #1
moveq r1, r2
mov r3, r3, lsr #5
tst r3, r1
beq .L4
ldr r3, .L49+20
ldrh r2, [r3, #42]
cmp r2, #32
beq .L6
ldr r0, .L49+24
ldr r1, .L49+28
============================
mov r2, #175
============================
ldr r3, .L49+32
bl __assert_fail
[145]
.L9:
bl __pthread_initialize_minimal
ldr r3, .L49+68
ldr ip, .L49+72
ldr r1, [r3]
ldr r3, [sp, #332]
ldrb r0, [r1, #1] @ zero_extendqisi2
ldrb r2, [r1] @ zero_extendqisi2
cmp r3, #0
ldrb r3, [r1, #2] @ zero_extendqisi2
orr r2, r2, r0, asl #8
ldrb r0, [r1, #3] @ zero_extendqisi2
orr r3, r2, r3, asl #16
orr r3, r3, r0, asl #24
============================
bic r3, r3, #255
============================
str r3, [ip]
ldr r0, [r1, #4] @ unaligned
str r0, [sp, #24] @ unaligned
ldr r3, [sp, #24]
str r3, [ip, #4]
beq .L20
mov r1, #0
ldr r0, [sp, #332]
mov r2, r1
bl __cxa_atexit
----
it looks to me the two instructions
mov r2, #175
(mov r2, #0xAF)
and
bic r3, r3, #255
(bic r3, r3, 0xFF)
are correct (immediate value fits into 8 bits, rotate i would expect to be 0 in
both cases)
--
You are receiving this mail because:
You are on the CC list for the bug.
nickc at redhat dot com
2016-01-25 10:07:45 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
Hi Loria,
Post by Loria at phantasia dot org
I do encounter the same while trying to build a toolchain on OSX 10.10.5 and
Xcode 7.2
binutils-2.25.1
libc-start.s:70: Error: invalid constant (af) after fixup
libc-start.s:145: Error: invalid constant (ff) after fixup
I am unable to reproduce these failures. The test case you uploaded assembles
without any problems on my machine (an x86_64 Linux box). I tried using the
current mainline binutils sources as well as the 2.25 branch sources, and I
tried using a 64-bit cross-assembler and a 32-bit cross-assembler. They all
worked.

It seems to me that this might be a problem with the compiler used to build the
assembler. If that compiler mis-compiles the assembler then that might explain
this discrepancy.

You may be able to investigate the problem yourself. The error message comes
from gas/config/tc-arm.c:md_apply_fix(). Although I suspect that the problem
actually lies in the arm_encode_immediate() function. If you investigate these
you may discover the cause of the bug.

Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-25 23:29:24 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #6 from Loria <Loria at phantasia dot org> ---
The Toolchain used to build the binutils...
<gcc --version>
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
</gcc --version>
This seems to be an 4.2.1 ...

Investigation so far shows evidence of some problem with loop optimization of
the construct used in "encode_arm_immediate"
doing output of newimm & value after
newimm = encode_arm_immediate (value);
leaves some interesting values if the loop in "encode_arm_immediate" should
exit with i=0 .. but it seems to exit and checks with i=2 ...
<some samples>
0xE13 = encode_arm_immediate (0x130)
0x100 = encode_arm_immediate (0x0)
0x180 = encode_arm_immediate (0x20)
0xFFFFFFFF = encode_arm_immediate (0xAF)
<some samples>
<loop>
#define rotate_left(v, n) (v << n | v >> (32 - n))
for (i = 0; i < 32; i += 2)
if ((a = rotate_left (val, i)) <= 0xff)
return a | (i << 7); /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
</loop>
If I add an output of "i" before the check is done everything seems ok ..
<loop>
for (i = 0; i < 32; i += 2){
printf("%u\n",i);
if ((a = rotate_left (val, i)) <= 0xff)
return a | (i << 7); /* 12-bit pack: [shift-cnt,const]. */
}
return FAIL;
</loop>
I am looking for a way to either add a workaround or set some optimzerflag to
stop the broken code from beeing submitted.
--
You are receiving this mail because:
You are on the CC list for the bug.
nickc at redhat dot com
2016-01-26 10:10:16 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #7 from Nick Clifton <nickc at redhat dot com> ---
Hi Loria,
Post by Loria at phantasia dot org
Investigation so far shows evidence of some problem with loop optimization
of the construct used in "encode_arm_immediate"
So this *is* a host compiler bug. Phew!
Post by Loria at phantasia dot org
#define rotate_left(v, n) (v << n | v >> (32 - n))
for (i = 0; i < 32; i += 2)
if ((a = rotate_left (val, i)) <= 0xff)
return a | (i << 7); /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
I am looking for a way to either add a workaround or set some optimzerflag
to stop the broken code from beeing submitted.
You could try turning rotate_left into an inline function.

Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-26 10:36:01 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #8 from Loria <Loria at phantasia dot org> ---
I found a LLVM Bug, which seems to be at least correlated with the problem I a
encountered:
https://llvm.org/bugs/show_bug.cgi?id=24688
I will do some more checks, if it really is.

since it is unknown how many times this bug hits the compiler generated, I
would actually like to disable that type of optimization instead of changing
the correct code to circumwent such compiler issue :/ you never know where it
hits again :/

If the following change would help (will test):
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;

for (i = 0; i < 32; i += 2)
if ((a = rotate_left (val, i)) <= 0xff)
return a | (i << 7); /* 12-bit pack: [shift-cnt,const]. */

return FAIL;
}
changed to:
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;

for (i = 0; i < 16; i++)
if ((a = rotate_left (val, i*2)) <= 0xff)
return a | (i << 8); /* 12-bit pack: [shift-cnt,const]. */

return FAIL;
}
or using the inline funktion instead of a macro ...
Will test those.
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-26 23:15:41 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #9 from Loria <Loria at phantasia dot org> ---
Well, how related it is with the named bug is unclear, but it seems the unroll
loops just does not work ...
on x86_64 I get the following disassemble:
_encode_arm_immediate: ## @encode_arm_immediate
.cfi_startproc
## BB#0:
pushq %rbp
Ltmp4:
.cfi_def_cfa_offset 16
Ltmp5:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp6:
.cfi_def_cfa_register %rbp
movl %edi, %ecx
roll $2, %ecx
movl $256, %edx ## imm = 0x100
cmpl $255, %ecx
jbe LBB1_1
## BB#3:
movl %edi, %ecx
roll $4, %ecx
movl $512, %edx ## imm = 0x200
cmpl $256, %ecx ## imm = 0x100
jb LBB1_1
.....
## BB#16:
roll $30, %edi
movl $-1, %eax
movl $3840, %edx ## imm = 0xF00
cmpl $256, %edi ## imm = 0x100
movl %edi, %ecx
jae LBB1_2
LBB1_1:
orl %edx, %ecx
movl %ecx, %eax
LBB1_2: ## %.loopexit5
popq %rbp
retq
----
well it looks like its definitly not a bug of binutils ... its caused by bad
unroll-loops of Apple LLVM version 7.0.2 (clang-700.1.81).
I think the save workaround would be to add -fno-unroll-loops to the flags for
building a toolchain .. with Apple Xcode 7.2

How do you think ?

(hopefully they fixed it with the upcoming Xcode 7.3 which unfortunatly wont
build for 10.10 anymore.
--
You are receiving this mail because:
You are on the CC list for the bug.
nickc at redhat dot com
2016-01-27 11:17:01 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #10 from Nick Clifton <nickc at redhat dot com> ---
Hi Loria,
Post by Loria at phantasia dot org
well it looks like its definitly not a bug of binutils ... its caused by bad
unroll-loops of Apple LLVM version 7.0.2 (clang-700.1.81).
How do you think ?
Did any of the workarounds that you tried have any effect ?

If not then maybe it is necessary to compile the assembler with CFLAGS set to
-O1 or possibly even -O0. If that works then we could add a note to the
binutils/README file that might possibly catch the attention of other OSX
users.

Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-27 18:37:41 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #11 from Loria <Loria at phantasia dot org> ---
Created attachment 8926
--> https://sourceware.org/bugzilla/attachment.cgi?id=8926&action=edit
testcase for trying to find workarounds
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-27 18:56:51 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #12 from Loria <Loria at phantasia dot org> ---
Well the optimzer removed all my tries to tell the optimizer to not unrolling
the loop the way it did. adding print("%d",i) will stop the loop unroller.
(I tryed all sorts of things, also your sugestion using an inline function
instead of the macro. The clang optimizer completly removed the inlinefunction
to form the same as with the macro ...)

I also crosschecked with 32bit which has the same issue.

I was successful with the following, which actually pulls us around the bug,
since we exit the funktion befor entering the loop.
<-
unsigned int
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;

if(val <= 0xFF)
return val;

for (i = 0; i < 32 ; i += 2)
if((a = rotate_left (val, i)) <= 0xFF)
return a | (i << 7) ; /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
}
<-
this would now work as we need it. It wont stop the clang bug to hit somewhere
else.
I also was successful in compiling the original function with:
gcc -O2 -fno-unroll-loops -fbracket-depth=1024 test.c
if ppl want to be on the safe side, they should add -fno-unroll-loops all
others could use the "risky" version and only use the workaround ..

I could produce a patch to binutils 2.25.1 or head of git ... if you would like
to have the workaround within binutils .. it seems to have been done with
encode_thumb32_immediate (unsigned int val) already. The main loop is similar.

I filed a bugreport at the LLVM.Org ..
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-27 20:22:41 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #13 from Loria <Loria at phantasia dot org> ---
<QUOTE https://llvm.org/bugs/show_bug.cgi?id=26344 <>
$ clang -fsanitize=undefined test.c -o test && ./test
test.c:11:13: runtime error: shift exponent 32 is too large for 32-bit type
'unsigned int'
0xA7 0xA7
0x1 0x1
0x0 0x0

line 11 has:
if((a = rotate_left (val, i)) <= 0xFF)

expands to:
if((a = (val << i | val >> (32 - i))) <= 0xFF)

when i == 0, we will compute:
if((a = (val << 0 | val >> (32 - 0))) <= 0xFF)

val >> 32 is undefined behavior.
</QUOTE>
I am unsure if that is correct, since I never experienced on any machine any
problem doing >>32 (resulted in 0 as expected on all machines i did it)
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-28 08:33:35 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #14 from Loria <Loria at phantasia dot org> ---
I did some further investigateion about the issue of the shiftoperator. It is
no violation on the syntaxlevel of C & C++ for (uint32 VAL; uint32 X = VAL >>
32;), the behaviour of the shiftoperation >= bitsize of the value is
undefinied.
At least Microsoft does state it in their documentation
https://msdn.microsoft.com/en-us/library/336xbhcz.aspx#Anchor_5
There are more places, which state the same.
So it seems the use of ">>32" confuses clangs optimizer.

But I now think the behaviour of the current version of
encode_arm_immediate to be undefined and should be fixed.

I sugest the code to be changed to:
<--
unsigned int
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;

if(val <= 0xFF)
return val;

for (i = 2; i < 32 ; i += 2)
if((a = rotate_left (val, i)) <= 0xFF)
return a | (i << 7) ; /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
}
<--

shall I produce an patchfile ?
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-28 08:35:56 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #15 from Loria <Loria at phantasia dot org> ---
I did some further investigateion about the issue of the shiftoperator. It is
no violation on the syntaxlevel of C & C++ for (uint32 VAL; uint32 X = VAL >>
32;), the behaviour of the shiftoperation >= bitsize of the value is
undefinied.
At least Microsoft does state it in their documentation
https://msdn.microsoft.com/en-us/library/336xbhcz.aspx#Anchor_5
There are more places, which state the same.
So it seems the use of ">>32" confuses clangs optimizer.

But I now think the behaviour of the current version of
encode_arm_immediate to be undefined and should be fixed.

I sugest the code to be changed to:
<--
unsigned int
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;

if(val <= 0xFF)
return val;

for (i = 2; i < 32 ; i += 2)
if((a = rotate_left (val, i)) <= 0xFF)
return a | (i << 7) ; /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
}
<--

shall I produce a patchfile ?
--
You are receiving this mail because:
You are on the CC list for the bug.
Loria at phantasia dot org
2016-01-31 23:16:36 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #16 from Loria <Loria at phantasia dot org> ---
Created attachment 8947
--> https://sourceware.org/bugzilla/attachment.cgi?id=8947&action=edit
sugested patch to /gas/config/tc-arm.c

This fixes the use of the undefined use of shiftoperator in tc-arm.c .
if X is an unsigned int32, then X>>32 has undefined behaviour.
--
You are receiving this mail because:
You are on the CC list for the bug.
cvs-commit at gcc dot gnu.org
2016-02-01 14:33:33 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

--- Comment #17 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nick Clifton <***@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4f1d62057fa4894e504458027ac3228404144f7d

commit 4f1d62057fa4894e504458027ac3228404144f7d
Author: Loria <***@phantasia.org>
Date: Mon Feb 1 14:32:25 2016 +0000

Fix a problem building the ARM assembler using LLVM.

PR target/19311
* config/tc-arm.c (encode_arm_immediate): Recode to improve
efficiency and avoid an LLVM loop optimization bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
nickc at redhat dot com
2016-02-01 14:51:19 UTC
Permalink
https://sourceware.org/bugzilla/show_bug.cgi?id=19311

Nick Clifton <nickc at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED

--- Comment #18 from Nick Clifton <nickc at redhat dot com> ---
OK - patch checked in.

Thanks for persevering with your investigation of this problem.

Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Loading...