On 23/10/2019 15:21, Richard Earnshaw (lists) wrote:
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.
As you have noticed, I have created PR92207 to help understand this.
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?
qemu complains with:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
'end with' because my automated validation builds do not keep the full
execution traces (that would need too much disk space)
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.
yes, qemu traces are 'incomplete'.
^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
.
