On Wed, 12 Aug 2015 13:14:07 +1000, Dave Chinner wrote:
> To close the loop, what code do the other versions GCC produce for
> this macro? Evidence so far says that the result depends on the
> compiler version, so I would like to have confirmation that other
> versions of the compiler generate working code. There are other
> XFS_DADDR_TO_FSB() calls in the XFS code, too - do they demonstrate
> the same problem, maybe with different compiler versions?
>
> Basically I'm asking what is the scope of the problem you've found?
> i.e. when was the bug introduced, what compilers expose it, etc
> so that when ARM users report XFS corruptions we have some idea of
> whether their kernel/compiler combination might have caused the
> issue they are seeing...
I have the following versions of GCC now.
4.5.1
4.6.4
4.7.2
# Sorry I don't have the recent versions of GCC.
And the results are:
4.5.1 (-O2) OK.
4.6.4 (-O2) BAD.
4.7.2 (-O2) BAD.
But even using gcc 4.7, this bug does not happen with -Os instead of -O2.
It means that when CONFIG_CC_OPTIMIZE_FOR_SIZE Kernel option is used, it does
not happen.
As for the version of kernel, I am using 3.10 now. At least. it is the same as
2.6.32.
--
The following are codes generated by GCCs.
GCC 4.5.1 with -O2 (OK)
178: 41a00003 movmi r0, r3
17c: 51a00057 asrpl r0, r7, r0
180: e58da02c str sl, [sp, #44] ; 0x2c
184: ebfffffe bl 0 <__do_div64>
188: e1cd26f8 strd r2, [sp, #104] ; 0x68
18c: e3a08000 mov r8, #0
190: e5d51175 ldrb r1, [r5, #373] ; 0x175
194: e59d2068 ldr r2, [sp, #104] ; 0x68
198: e251e020 subs lr, r1, #32
19c: e5d5308c ldrb r3, [r5, #140] ; 0x8c
1a0: e261c020 rsb ip, r1, #32
1a4: e1a00136 lsr r0, r6, r1
1a8: e1800c17 orr r0, r0, r7, lsl ip
1ac: e2634020 rsb r4, r3, #32
1b0: 51a00e57 asrpl r0, r7, lr
1b4: e253c020 subs ip, r3, #32
1b8: e1a0b432 lsr fp, r2, r4
1bc: e1a0a312 lsl sl, r2, r3
1c0: 51a0bc12 lslpl fp, r2, ip
1c4: e59dc024 ldr ip, [sp, #36] ; 0x24
1c8: e5954064 ldr r4, [r5, #100] ; 0x64
1cc: e1a01157 asr r1, r7, r1
1d0: e58d804c str r8, [sp, #76] ; 0x4c
1d4: e58dc048 str ip, [sp, #72] ; 0x48
1d8: ebfffffe bl 0 <__do_div64>
GCC 4.6.4 with -O2 (BAD)
19c: 51a0025e asrpl r0, lr, r2
1a0: e3a0a001 mov sl, #1
1a4: ebfffffe bl 0 <__do_div64>
1a8: e1a0bb32 lsr fp, r2, fp
1ac: e2553020 subs r3, r5, #32
1b0: e1a01008 mov r1, r8
1b4: e58d704c str r7, [sp, #76] ; 0x4c
1b8: e1a0800b mov r8, fp
1bc: e58d7060 str r7, [sp, #96] ; 0x60
1c0: 51a08312 lslpl r8, r2, r3
1c4: e1a02512 lsl r2, r2, r5
1c8: e58d8034 str r8, [sp, #52] ; 0x34
1cc: e1a0500a mov r5, sl
1d0: e58d2030 str r2, [sp, #48] ; 0x30
1d4: e28d8048 add r8, sp, #72 ; 0x48
1d8: ebfffffe bl 0 <__do_div64>
GCC 4.7.2 with -Os (OK)
1a0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28
1a4: e1a0200b mov r2, fp
1a8: ebfffffe bl 0 <__aeabi_lasr>
1ac: e5954064 ldr r4, [r5, #100] ; 0x64
1b0: ebfffffe bl 0 <__do_div64>
1b4: e3a01000 mov r1, #0
1b8: e1a00002 mov r0, r2
1bc: e5d5208c ldrb r2, [r5, #140] ; 0x8c
1c0: ebfffffe bl 0 <__aeabi_llsl>
1c4: e1a0200b mov r2, fp
1c8: e1a06000 mov r6, r0
1cc: e1a07001 mov r7, r1
1d0: e1cd02d8 ldrd r0, [sp, #40] ; 0x28
1d4: ebfffffe bl 0 <__aeabi_lasr>
1d8: e58da040 str sl, [sp, #64] ; 0x40
1dc: ebfffffe bl 0 <__do_div64>
Thank you,
--
UWATOKO
|