Hello Richard, I see it the same way.
The existing code in optimize_bit_field_compare looks wrong. It is very asymmetric, and handles lvolatilep and rvolatilep differently. And the original handling of flag_strict_volatile_bitfields also was asymmetric. However this optimize-bit-field-compare check at the beginning of that function was not introduced because of volatile issues I think: There was a discussion in April 2012 on this thread: "Continue strict-volatile-bitfields fixes" http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01094.html The result was that this optimization seems to break other possible optimizations later on, when -fstrict-volatile-bitfields was enabled on the SH target. Even when the bit fields are NOT volatile. (Of course you should not touch volatile bit fields at all) And this was added to optimize_bit_field_compare as a result: /* In the strict volatile bitfields case, doing code changes here may prevent other optimizations, in particular in a SLOW_BYTE_ACCESS setting. */ if (flag_strict_volatile_bitfields> 0) return 0; Well, I dont know if that still applies to the trunk, and probably this was the completely wrong way to fix this issue it here. Maybe that had to do with the other place in stor-layout.c, which also could be solved differently. I think it could be possible to remove the flag_strict_volatile_bitfields special case also there, and instead use the DECL_BIT_FIELD_TYPE instead of DECL_BIT_FIELD in get_inner_reference IF we have flag_strict_volatile_bitfields and that field is really volatile. At least this helped in the portable volatiliy patch. What do you think? Anyway, here is my patch for review. OK for trunk after regression testing? Thanks Bernd.
2013-10-18 Bernd Edlinger <bernd.edlin...@hotmail.de>
Fix volatile issues in optimize_bit_field_compare.
* fold-const.c (optimize_bit_field_compare): Bail out if
lvolatilep or rvolatilep.
patch-bitfield-compare.diff
Description: Binary data
