| Summary: | gcc generates illegal AVX aligned moves | ||
|---|---|---|---|
| Product: | gcc | Reporter: | David Greene <greened> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gcc-bugs, greened |
| Priority: | P3 | ||
| Version: | 4.5.1 | ||
| Target Milestone: | --- | ||
| Host: | x86_64-unknown-linux-gnu | Target: | x86_64-unknown-linux-gnu |
| Build: | x86_64-unknown-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
| Attachments: | Reduced testcase | ||
|
Description
David Greene
2010-09-08 16:08:12 UTC
Compile with -c -mavx reduced.c. Created attachment 21740 [details]
Reduced testcase
I think this code is undefined with respect of alignment requirements. Yes this is invalid with respect of alignment requirements. It becomes obvious from the optimized at -O0 on the trunk. v4df llvm_cbe_r5585; v4df llvm_cbe_r5584; struct l_DV1 llvm_cbe__24__StackDv_P53; unsigned int * D.3215; struct l_DV1 * llvm_cbe__24__StackDv_P53.0; <bb 2>: llvm_cbe__24__StackDv_P53.0_1 = &llvm_cbe__24__StackDv_P53; MEM[(v4df *)llvm_cbe__24__StackDv_P53.0_1] = llvm_cbe_r5584_2(D); // requires v4df alignment D.3215_3 = &llvm_cbe__24__StackDv_P53.field1.field5; MEM[(struct *)D.3215_3].data = llvm_cbe_r5585_4(D); // requires v4df alignment Why is the code undefined? Can you explain in terms of the original test source? I don't immediately see anything undefined there. The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting to a greater aligned type and then dereferencing it. That being said, the LLVM C back-end produces crazy c code that is also undefined because of aliasing. (In reply to comment #5) > Why is the code undefined? Can you explain in terms of the original test > source? I don't immediately see anything undefined there. Ah, the cast from int field5 to v4df? Yes, that doesn't look right to me. Is this what you're talking about? It seems to me that gcc should emit a warning about this and/or not assume that &field5 is aligned to 32 bytes, as there is nothing in the source specifying such alignment. If it's an illegal program, gcc should at least emit a warning, if not an error. (In reply to comment #6) > The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting to > a greater aligned type and then dereferencing it. I didn't know that typing something as a vector guaranteed alignment. I don't see anything in the gcc manual about that. Isn't that why we have __attribute(aligned())__? >If it's an illegal program, gcc should at least emit a warning, if not an
error.
It is not an invalid program, it is just undefined at runtime. There was a defect report against the C standard asking if a diagnostic can be required for undefined behavior and it was rejected. Oh there is a patch to enable warnings for this case already.
vector types are naturally aligned just like integer types. That is they are aligned on their size. (In reply to comment #9) > >If it's an illegal program, gcc should at least emit a warning, if not an > error. > > > It is not an invalid program, Yes, you are quite right. I will take this up with the LLVM folks. :) |