gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) Target: x86_64-linux-gnu Resulting binary crushes with segmentation fault if gcc compile options include -O3. Source code: #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <unistd.h> void process_buf(uint32_t *buf) { int i; uint32_t t = 0; for(i = 0; i < 16; i++) buf[i] = ++t; // segmentation fault } int main(int argc, char **argv) { char *buf = malloc(65); int n; process_buf((uint32_t*)(buf + 1)); n = write(1, buf + 1, 64); return 0; }
Created attachment 19828 [details] the preprocessed file (*.i*) that triggers the bug
Created attachment 19829 [details] output for: gcc -v -save-temps -Wall -Werror -O3 2.c -o 2
Your pointer isn't properly aligned to be accessed via uint32_t*.
(In reply to comment #3) > Your pointer isn't properly aligned to be accessed via uint32_t*. > And should it? If 'yes', then why GCC generates working code for that source without optimization or with -O2 ? Or even when some debug printf(...) inserted in the for-loop body. Strange behaviour, anyway.
The alignment requirements of uint32_t are not being satisfied. That causes undefined behavior which means it could work in one case but not the other.
> Your pointer isn't properly aligned to be accessed via uint32_t*. That's hardly satisfactory an answer. GCC has always generated working code on non-strict alignment platforms in this case and one can expect it to continue. Moreover, the psABI is explicit: "Like the Intel386 architecture, the AMD64 architecture in general does not require all data accesses to be properly aligned. Misaligned data accesses are slower than aligned accesses but otherwise behave identically. The only exception is that __m128 must always be aligned properly." and there is no __m128 in the source code.
(In reply to comment #6) > > Your pointer isn't properly aligned to be accessed via uint32_t*. > > That's hardly satisfactory an answer. GCC has always generated working code on > non-strict alignment platforms in this case and one can expect it to continue. > > Moreover, the psABI is explicit: > > "Like the Intel386 architecture, the AMD64 architecture in general does not > require all data accesses to be properly aligned. Misaligned data accesses are > slower than aligned accesses but otherwise behave identically. The only > exception is that __m128 must always be aligned properly." > > and there is no __m128 in the source code. The C language standard says such pointer invokes undefined behavior. The non-working code is vectorized, and vectorized code can have strict alignment requirements.
> The non-working code is vectorized, and vectorized code can have strict > alignment requirements. Yes, the alignment requirements are surreptitiously changed by -ftree-vectorize on x86 and x86-64. This ought to be documented in the manual.
I experienced the same issue. I'm not able to reproduce this in a short snippet, but if someone needs my whole source package then i can provide it.
Cannot we warn for this?
(In reply to comment #10) > Cannot we warn for this? As usual, if we knew the data is not aligned we'd not "miscompile" it.