FYI: gcc optimization bug affecting volatile accesses

Werner Almesberger werner at almesberger.net
Fri Jan 25 18:41:19 EST 2013


I came across a bug in gcc (4.6 or 4.7) that causes it to produce
invalid code for some accesses through volatile pointers. Such
accesses are common when using UBB.

What happens is that

	volatile int *p;

	...

	*p = 1;
	if (cond)
		*p = 2;

gets mis-compiled as if it continued with

	else
		*p = *p;

I found this in code that writes to PDFUNS, where the uncommanded
read-write upset the port D configuration such that the Ben's
keyboard subtly misbehaved/failed. The code in question looks
pretty harmless and the general pattern is not uncommon:

	PDFUNS = UBB_DAT0 | UBB_DAT1 | UBB_DAT2 | UBB_DAT3;
	if (clkout)
		PDFUNS = UBB_CLK;

This bug can be worked around in two ways:

1) by not optimizing at all (even -O1 is already too much)

2) by adding the option -fno-tree-cselim to disable the group of
   optimizations containing the troublemaker. Even -O9 is safe
   then.

In one tight loop polling some Jz47xx registers, I saw
-fno-tree-cselim produce only a third of the performance penalty
I saw when going from -O9 to -O0.

For more details:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098

- Werner



More information about the discussion mailing list


interactive