STM32F7 HAL CRC模块类型双关指针编译警告的解决方法

我之前在-Os/-O2优化级别下编译STM32F7 HAL库时也碰到过这个警告，本质是**编译器严格别名规则（strict-aliasing）**在起作用——你把CRC_TypeDef结构体中DR成员的地址强制转换成__IO uint16_t*类型来赋值，这违反了C标准中“不同类型指针不能互相别名访问”的规则，高优化级别下编译器会严格校验这个点。下面给你几个不破坏CRC功能的代码修改方案：

方案一：用memcpy绕过类型转换 #

memcpy是编译器明确允许的内存操作方式，不会触发严格别名警告，而且行为和原代码完全一致：

// 先计算要写入的16位数据
uint16_t crc_write_data = (uint16_t)(((uint16_t)(pBuffer[4*i]) << 8) | (uint16_t)(pBuffer[4*i+1]));
// 用memcpy将16位数据写入DR寄存器的低16位（和原代码行为一致）
memcpy(&hcrc->Instance->DR, &crc_write_data, sizeof(crc_write_data));

方案二：使用Union类型合法别名 #

C标准允许通过Union的不同成员访问同一块内存，这是合规的别名方式，可读性也更好：

首先定义一个对应CRC_DR寄存器的Union：

typedef union {
    __IO uint32_t dr_32;  // 对应原DR寄存器的32位类型
    __IO uint16_t dr_16;  // 用于16位写入的成员
} CRC_DR_Union;

然后修改原赋值代码：

uint16_t crc_write_data = (uint16_t)(((uint16_t)(pBuffer[4*i]) << 8) | (uint16_t)(pBuffer[4*i+1]));
// 通过Union的16位成员写入DR寄存器
((CRC_DR_Union*)&hcrc->Instance->DR)->dr_16 = crc_write_data;

方案三：给CRC模块文件单独禁用严格别名检查 #

如果不想修改代码，可以在编译stm32f7xx_hal_crc.c时添加编译选项-fno-strict-aliasing，这样只会关闭该文件的严格别名校验，不影响其他代码的优化效果。比如在Makefile中可以这样配置：

stm32f7xx_hal_crc.o: CFLAGS += -fno-strict-aliasing

注意事项 #

• 三个方案都能保证和原代码的功能完全一致，都是向CRC的DR寄存器写入16位数据，不会影响CRC计算结果。
• 优先选择方案一或方案二，因为它们是代码层面的标准解决方案，不依赖编译配置；方案三更适合不想改动HAL库代码的场景。

内容的提问来源于stack exchange，提问作者iamJP