Menu
▾
▴
1 Attachments
#2287 Inline functions with variable argument list fails on MCS-51 --stack-auto
The attached .c file failed on mcs-51-stack-auto, but succeeded on mcs-51-small.
If the static prefixes of f1i() and f2i() were removed, then they became ordinary functions and the inline made no effect, but succeeded on both ports.
I have a lot of questions about this bug report.
First, it states this report was updated 22 hours ago. But by whom? And how? I don't get it.
Second, I don't like the way the test file is modified in the regression test suite to work around this bug. It is just changed into a whole different source by removing the inline keywords. That's no fix. And apart from the subversion history there's nothing indicating how it was when it failed.
Third, I can't seem to find the original gcc test that this file should originate from. When I search the internet for stdarg-4.c I only find files without inline functions.
And finally it is unclear how the attached file actually fails. I looked through the generated asm for f1() and see no problem. So which of the 9 ASSERTions fails or does it does it produce build errors?
Maarten
Ah wait, I see, the file is duplicated in gcc-torture-execute-stdarg-5.c. We have other mechanisms for duplicating files with minor differences. It should use a keyword with values in the first comment like this:
As far as I remembered,
The original stdarg-4.c failed in host test with newer gcc (>= 4.7) if --std-c99 was specified, since a non-static inline function was wiped out in the optimization but inline code insertion was not performed. Then I added statics to all inlines in rev9051, but quickly found that this way succeeded on all ports except the mcs51-auto-stack. So in rev9052 I changed functions in stdarg-4.c to ordinary ones while created a new stdarg-5.c with statics before all inlines.
The error is easy to reproduce by removing the #if !defined(SDCC_mcs51) in stdarg-5.c.
Since I did not know the rule of duplicating a test case then, you are appreciated to correct my mistake.
If the #if !defined(__SDCC_mcs51) was removed, the gcc-torture-execute-stdarg-5.c rose error in mcs51-auto-stack on my 64-bit MacOS 10.9.4. The attachment is the error message, the .c and the generated .asm.
And once again something weird happened. I received an email from SF with a reply from Ben in this thread that is now gone. Have you deleted it afterwards Ben and sent the last reply with the zip instead?
A quote from your 'deleted' reply:
This once again proves that all those ASSERT(0) are less efficient. I still have to find the right line which changed due to the removed #define line. And the message says nothing about which test failed because that is hidden in the surrounding if-statement.
It would have been so much better if the two tests were there directly and in two in separate ASSERTs.
At least now I see what's going wrong. It totally forgets to assign to y in f2(). It seems to forget that y is global.
The code is removed between DUMP_RAW1 and DUMP_CSE in eBBlockFromiCode() in SDCCopt.c as can be seen from these dumps:
DUMP_RAW1:
DUMP_CSE:
Most probably it happens here:
The attachment in my previous reply was broken, so I deleted it and resent again with a new zip file.
Can you reproduce this bug at your side? It is easy to be produced both on my 32-bit arm board and my 64-bit MacOS 10.9.4.
If it was due to arch-independant optimization, why other ports are OK with this test case? Such as mcs51-small and mcs51-large. But only mcs51-auto-stack rises errors.
In the original version of gcc-torture-execute-stdarg-4.c, only inlines but no static were specified. And I have checked the generated code of host, stm8 and mcs51-*, that
Sorry, GCC 4.7 above and llvm rose link time error. The expected code inlining did not happen in the caller, and the caller still held a call instruction to the inline callee. While the inline callee was wiped out.
Should the computeDataFlow() and killDeadCode() be arch independent? I compiled this .c with --i-code-in-asm for mcs51-stack-auto and mcs51-small, and also found the written back to the global variable y was missing in mcs51-stack-auto while was present in mcs51-small.
mcs51-small:
～～～～
; q.c:38: y = va_arg (ap, int);
; [-------7] ic:5: iTemp5 [k12 lr5:7 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char near fixed}[r7 ] = iTemp0 [k2 lr4:5 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{unsigned-char near fixed}{ sir@ _f2_ap_1_17}[r7 ] - 0x2 {unsigned-char literal}
dec r7
dec r7
; [------67] ic:6: iTemp4 [k9 lr6:15 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{unsigned-char near fixed}{ sir@ _f2_ap_3_21}[r6 ] := iTemp5 [k12 lr5:7 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char near fixed}[r7 ]
mov ar6,r7
; [-1----67] ic:7: iTemp6 [k13 lr7:8 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int near fixed}[r1 ] = (int near fixed)iTemp5 [k12 lr5:7 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char near* fixed}[r7 ]
mov ar1,r7
; [-1---567] ic:8: iTemp7 [k14 lr8:9 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int register}[r5 r7 ] = @[iTemp6 [k13 lr7:8 so:0]{ ia1 a2p0 re0 rm0 nos0 ru0 dp0}{int near* fixed}[r1 ] + 0x0 {const-unsigned-char literal}]
mov ar5,@r1
inc r1
mov ar7,@r1
; [-----567] ic:9: _y [k11 lr0:0 so:0]{ ia1 a2p0 re0 rm0 nos0 ru0 dp0}{long-int fixed} = (long-int fixed)iTemp7 [k14 lr8:9 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int register}[r5 r7 ]
mov _y,r5
mov a,r7
mov (_y + 1),a
rlc a
subb a,acc
mov (_y + 2),a
mov (_y + 3),a
; q.c:39: y += va_arg (ap, long);
～～～～
mcs51-auto-stack:
～～～～
; q.c:38: y = va_arg (ap, int);
; [-------7] ic:5: iTemp4 [k9 lr5:8 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{unsigned-char near fixed}{ sir@ _f2_ap_3_21}[r7 ] = iTemp0 [k2 lr4:5 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{unsigned-char near fixed}{ sir@ _f2_ap_1_17}[r7 ] - 0x2 {unsigned-char literal}
dec r7
dec r7
; q.c:39: y += va_arg (ap, long);
～～～～
Last edit: Ben Shi 2016-03-28