gcc：从硬件寄存器读取时，“-fno-strict-aliasing”行为异常

Question

I am trying to debug a C program using gdb.The compile flags that I am using are as below

-fno-strict-aliasing -Wall -DHAVE_CONFIG_H -DNO_OLD_ERF_TYPES -Werror  -Wredundant-decls -O2 -DNDEBUG -DBYTESWAP -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g 

The version of the compiler that I am using is

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The disputed code is the following line

spm->num_streams = (uint16_t)((MkIV->stream_counts >> 16 ) & 0xfff);

Value of num_streams with -fno-strict-aliasing

 0xffff (4095)

Value of num_streams WITHOUT-fno-strict-aliasing

 0x1 (1)

Now it is worth noting the actual value of mkIV->stream_counts is 0x10020 .This is read from a HARDWARE REGISTER

the value we are interested in is spm->num_streams is BIT27:BIT16 .Therefore the expected value is '1'

If I were to replace

spm->num_streams = (uint16_t)((MkIV->stream_counts >> 16 ) & 0xfff);

with

spm->num_streams = (uint16_t)((MkIV->stream_counts & 0xfff0000) >> 16);

then I get the value of 0x1(1) with and without -fno-strict-aliasing

The stream_counts in MkIV structure ( MkIV->stream_counts is of uint32_t type )

spm->num_streams is of type uint16_t

Can someone explain why this is happening?

Answer 1

You are a victim of the 'as-if' rule. The compiler has no idea you're reading from a hardware register. When you write:

spm->num_streams = (uint16_t)((MkIV->stream_counts & 0xfff0000) >> 16);

The compiler has every right to do this:

uint16_t j = MkIV->stream_counts;
MkIV->stream_counts &= 0xfff0000;
MkIV->stream_counts >>= 16;
sp->num_streams = MKIV->stream_counts;
MkIV->stream_counts = j;

Most likely, you can work around the problem by making stream_counts volatile or "laundering" the read through a volatile pointer.

Instead of MkIV->stream_counts , use *(volatile uint16_t *)&MkIV->stream_counts .

Answer 2

Since qualifying stream_counts with volatile fixes the problem then it would seem that you were impacted by the as-if rule which basically says that if the compiler can modify the program as long as it can determine that it will not effect the observable behavior . cppreference has a nice explanation here and although it is written with respect to C++ most of it applies to C as well. The code examples are especially instructive.

Unlike the draft C++ standard the C99 draft standard only explicitly refers to the as-if rule in the index which points to section 5.1.2.3 Program execution in paragraph 3 it says( emphasis mine ):

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

it does use the as if phrase in some of the examples, from paragraph 11 we have the following example:

float f1, f2;
double d;
/* ... */
f1 = f2 * d;

and the following text says( emphasis mine ):

the multiplication may be executed using single-precision arithmetic if the implementation can ascertain that the result would be the same as if it were executed using double-precision arithmetic

and if we look at section 6.7.3 Type qualifiers paragraph 6 says( emphasis mine ):

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine , as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.116)[...]

which puts restrictions on the short cuts a compiler can take with respect to volatile qualified objects. Section 5.1.2.3 paragraph 5 covers the The least requirements on a conforming implementation are .