[U-Boot] U-Boot and gcc 4.9.0

[Renaud Barbier <renaud.barbier@ge.com>]

I compiled the P1010RDB boot loader using the PowerPC gcc version 4.9.0.
The binary failed to boot with a DATA TLB exception. After investigating
and producing an objdump, I saw the following in the function
cpu_init_early_f:

void cpu_init_early_f(void *fdt)
{
...
#ifdef CONFIG_A003399_NOR_WORKAROUND
	ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR;
	u32  *dst, *src;
	void (*setup_ifc_sram)(void);
#endif
...
       init_laws();
...

setup_ifc_sram = (void *)SRAM_BASE_ADDR;
	dst = (u32 *) SRAM_BASE_ADDR;
	src = (u32 *) setup_ifc;
	for (i = 0; i < 1024; i++)
		*dst++ = *src++;

	setup_ifc_sram();

	/* CLEANUP */
	clrbits_be32(&l2cache->l2ctl,
			(MPC85xx_L2CTL_L2E |
			 MPC85xx_L2CTL_L2SRAM_ENTIRE));
	out_be32(&l2cache->l2srbar0, 0x0);
#endif

	invalidate_tlb(1);
...
	init_tlbs();
}

The GCC powerpc objdump gives:
eff433f4:   4b ff ec 0d     bl      eff42000 <init_laws>
eff433f8:   3c 80 80 00     lis     r4,-32768
eff433fc:   3c 60 10 09     lis     r3,4105
eff43400:   60 84 15 00     ori     r4,r4,5376
eff43404:   38 a0 00 08     li      r5,8
eff43408:   38 c0 00 15     li      r6,21
eff4340c:   38 e0 00 00     li      r7,0
eff43410:   4b ff e0 91     bl      eff414a0 <write_tlb>
eff43414:   3d 40 ff e2     lis     r10,-30
eff43418:   39 20 00 00     li      r9,0
eff4341c:   61 4a 01 00     ori     r10,r10,256
eff43420:   7c 00 04 ac     msync
eff43424:   91 2a 00 00     stw     r9,0(r10)
eff43428:   39 00 00 0c     li      r8,12
eff4342c:   7c 00 04 ac     msync
eff43430:   91 0a 0d 44     stw     r8,3396(r10)
eff43434:   3d 00 80 01     lis     r8,-32767
eff43438:   3d 40 ff e2     lis     r10,-30
eff4343c:   7c 00 04 ac     msync
eff43440:   91 0a 00 00     stw     r8,0(r10)
eff43444:   91 29 00 00     stw     r9,0(r9)
eff43448:   7f e0 00 08     trap

invalidate_tlb and init_tlbs are NOT present and the function ends with
a trap instruction instead of blr.

The line of code "dst = (u32 *) SRAM_BASE_ADDR;" seems to be the
problem. If removed, the object dump shows the call for the last two
functions and returns.
Also the compiler options -fno-delete-null-pointer-checks or using
memcpy fixes the problem.

Likely related to the following options found in the documentation
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Maybe related to the following:
-fisolate-erroneous-paths-attribute
Detect paths which trigger erroneous or undefined behaviour due a NULL
value being used in a way which is forbidden by a returns_nonnull or
nonnull attribute. Isolate those paths from the main control flow and
turn the statement with erroneous or undefined behaviour into a trap.
This is not currently enabled, but may be enabled by -O2 in the future.

Any thoughts?

Renaud