Dear Joakim Tjernlund,
In message OF102CC99D.B86B21B6-ONC125787C.007CB439-C125787C.0080F875@transmode.se you wrote:
Well, your gcc is different from mine and I know nothing about it as you won't say anything about it.
If in doubt, use ELDK. All examples were compiled with ELDK 4.2 (GCC 4.2.2) for ppc_8xx.
## 4.4.5 has been patched to support msingle-pic-base CROSS_COMPILE=powerpc-4.4.5_softfloat-linux-gnu- ./MAKEALL TQM855L TQM860L Configuring for TQM855L board... text data bss dec hex filename 267022 5284 27200 299506 491f2 ./u-boot Configuring for TQM860L board... text data bss dec hex filename 267043 5284 27200 299527 49207 ./u-boot
I don't have gcc 4.4.x here for testing.
So I strongly suspect that as soon as you move your gcc version upwards, it will break these boards too.
Yes, but for other reasons.
Recent versions of GCC (gcc 4.5.x) cannot be used to build this code at all until they get fixed, as -Os is not working, and the code size explodes completely. See GCC bugs 43810, 48278, and 45053.
I will not apply either of these commits - neither the reverted one, nor this additional one, as both of them grow the memory footprint instead of redusing it as you promised in the commit message.
You should read the commit msg again. It requires a gcc which supports -msingle-pic-base.
As the majority of gcc versions outthere does not support this feature, we are trading a (slight?) advantage for a very limited group against disadvantages for a very large group (probably everyone else but you).
I still don't know why it broke with your gcc but I suspect it is due to -fno-jump-tables(which is in the msingle-pic-base patch). Seems like that option in your case makes the code bigger.
Indeed. As I cannot see any advantages, I reject this stuff, at least for now.
Best regards,
Wolfgang Denk