On 23/10/2019 09:28, Christophe Lyon wrote:
On 21/10/2019 14:24, Richard Earnshaw (lists) wrote:
On 21/10/2019 12:51, Christophe Lyon wrote:
On 18/10/2019 21:48, Richard Earnshaw wrote:
Each patch should produce a working compiler (it did when it was
originally written), though since the patch set has been re-ordered
slightly there is a possibility that some of the intermediate steps
may have missing test updates that are only cleaned up later.
However, only the end of the series should be considered complete.
I've kept the patch as a series to permit easier regression hunting
should that prove necessary.
Thanks for this information: my validation system was designed in
such a way that it will run the GCC testsuite after each of your
patches, so I'll keep in mind not to report regressions (I've noticed
several already).
I can perform a manual validation taking your 29 patches as a single
one and compare the results with those of the revision preceding the
one were you committed patch #1. Do you think it would be useful?
Christophe
I think if you can filter out any that are removed by later patches
and then report against the patch that caused the regression itself
then that would be the best. But I realise that would be more work
for you, so a round-up against the combined set would be OK.
BTW, I'm aware of an issue with the compiler now generating
<alu> reg, reg, shift <reg>
in Thumb2; no need to report that again.
Thanks,
R.
.
Hi Richard,
The validation of the whole set shows 1 regression, which was also
reported by the validation of r277179 (early split most DImode
comparison operations)
When GCC is configured as:
--target arm-none-eabi
--with-mode default
--with-cpu default
--with-fpu default
(that is, no --with-mode, --with-cpu, --with-fpu option)
I'm using binutils-2.28 and newlib-3.1.0
I can see:
FAIL: g++.dg/opt/pr36449.C -std=gnu++14 execution test
(whatever -std=gnu++XX option)
That's strange. The assembler code generated for that test is unchanged
from before the patch series, so I can't see how it can't be a problem
in the test itself. What's more, I can't seem to reproduce this myself.
Similarly, in my build the code for _Znwj, malloc, malloc_r and free_r
are also unchanged, while the malloc_[un]lock functions are empty stubs
(not surprising as we aren't multi-threaded).
So the only thing that looks to have really changed are the linker
offsets (some of the library code has changed, but I don't think it's
really reached in practice, so shouldn't be relevant).
I'm executing the tests using qemu-4.1.0 -cpu arm926
The qemu traces shows that code enters main, then _Znwj (operator new),
then _malloc_r
The qemu traces end with:
What do you mean by 'end with'? What's the failure mode of the test? A
crash, or the test exiting with a failure code?
IN: _malloc_r^M
0x00019224: e3a00ffe mov r0, #0x3f8^M
0x00019228: e3a0c07f mov ip, #0x7f^M
0x0001922c: e3a0e07e mov lr, #0x7e^M
0x00019230: eafffe41 b #0x18b3c^M
^M
R00=00049418 R01=00000000 R02=00000554 R03=00040000^M
R04=00000000 R05=08000008 R06=00049418 R07=00000000^M
R08=00000000 R09=00000000 R10=000492d8 R11=fffeb4b4^M
R12=00000060 R13=fffeb460 R14=00018b14 R15=00019224^M
PSR=20000010 --C- A usr32^M
----------------^M
IN: _malloc_r^M
0x00018b3c: e59f76f8 ldr r7, [pc, #0x6f8]^M
0x00018b40: e0870000 add r0, r7, r0^M
0x00018b44: e5903004 ldr r3, [r0, #4]^M
0x00018b48: e2400008 sub r0, r0, #8^M
0x00018b4c: e1500003 cmp r0, r3^M
0x00018b50: 1a000005 bne #0x18b6c^M
But this block neither jumps to, nor falls through to ....
^M
R00=000003f8 R01=00000000 R02=00000554 R03=00040000^M
R04=00000000 R05=08000008 R06=00049418 R07=00000000^M
R08=00000000 R09=00000000 R10=000492d8 R11=fffeb4b4^M
R12=0000007f R13=fffeb460 R14=0000007e R15=00018b3c^M
PSR=20000010 --C- A usr32^M
R00=00049c30 R01=00000000 R02=00000554 R03=00049c30^M
R04=00000000 R05=08000008 R06=00049418 R07=00049840^M
R08=00000000 R09=00000000 R10=000492d8 R11=fffeb4b4^M
R12=0000007f R13=fffeb460 R14=0000007e R15=00018b54^M
PSR=60000010 -ZC- A usr32^M
----------------^M
IN: _malloc_r^M
...here. So there's some trace missing by the looks of it; or some
other problem.
0x00019120: e1a02a0b lsl r2, fp, #0x14^M
0x00019124: e1a02a22 lsr r2, r2, #0x14^M
0x00019128: e3520000 cmp r2, #0^M
0x0001912c: 1afffee7 bne #0x18cd0^M
and the same here.
^M
R00=0004b000 R01=08002108 R02=00049e40 R03=0004b000^M
R04=0004a8e0 R05=08000008 R06=00049418 R07=00049840^M
R08=08001000 R09=00000720 R10=00049e0c R11=0004b000^M
R12=0000007f R13=fffeb460 R14=00018ca0 R15=00019120^M
PSR=60000010 -ZC- A usr32^M
----------------^M
IN: _malloc_r^M
0x00019130: e5974008 ldr r4, [r7, #8]^M
0x00019134: e0898008 add r8, sb, r8^M
0x00019138: e3888001 orr r8, r8, #1^M
0x0001913c: e5848004 str r8, [r4, #4]^M
0x00019140: eaffff14 b #0x18d98^M
^M
R00=0004b000 R01=08002108 R02=00000000 R03=0004b000^M
R04=0004a8e0 R05=08000008 R06=00049418 R07=00049840^M
R08=08001000 R09=00000720 R10=00049e0c R11=0004b000^M
R12=0000007f R13=fffeb460 R14=00018ca0 R15=00019130^M
PSR=60000010 -ZC- A usr32^M
R00=0004b000 R01=08002108 R02=00000000 R03=0004b000^M
R04=0004a8e0 R05=08000008 R06=00049418 R07=00049840^M
R08=08001721 R09=00000720 R10=00049e0c R11=0004b000^M
R12=0000007f R13=fffeb460 R14=00018ca0 R15=00018d98^M
PSR=60000010 -ZC- A usr32^M
Christophe
