Lỗi GCC có thể xảy ra khi trả về struct từ hàm

Tôi tin rằng tôi đã tìm thấy một lỗi trong GCC khi triển khai PCG PRNG của O'Neill. ( Mã ban đầu trên Godbolt's Compiler Explorer )

Sau khi nhân oldstatevới MULTIPLIER, (kết quả được lưu trữ trong rdi), GCC không thêm kết quả đó vào INCREMENT, INCREMENTthay vào đó, hãy chuyển sang ndx, sau đó được sử dụng làm giá trị trả về của rand32_ret.state

Một ví dụ tái sản xuất tối thiểu ( Trình biên dịch Explorer ):

#include <stdint.h>

struct retstruct {
    uint32_t a;
    uint64_t b;
};

struct retstruct fn(uint64_t input)
{
    struct retstruct ret;

    ret.a = 0;
    ret.b = input * 11111111111 + 111111111111;

    return ret;
}

Lắp ráp được tạo (GCC 9.2, x86_64, -O3):

fn:
  movabs rdx, 11111111111     # multiplier constant (doesn't fit in imm32)
  xor eax, eax                # ret.a = 0
  imul rdi, rdx
  movabs rdx, 111111111111    # add constant; one more 1 than multiplier
     # missing   add rdx, rdi   # ret.b=... that we get with clang or older gcc
  ret
# returns RDX:RAX = constant 111111111111 : 0
# independent of input RDI, and not using the imul result it just computed

Thật thú vị, sửa đổi cấu trúc để có uint64_t là thành viên đầu tiên tạo mã chính xác , cũng như thay đổi cả hai thành viên thành uint64_t

x86-64 System V không trả về các cấu trúc nhỏ hơn 16 byte trong RDX: RAX, khi chúng có thể sao chép một cách tầm thường. Trong trường hợp này, thành viên thứ 2 nằm trong RDX vì một nửa RAX cao là phần đệm để căn chỉnh hoặc .bkhi nào .alà loại hẹp hơn. ( sizeof(retstruct)là 16 theo cách nào đó; chúng tôi không sử dụng __attribute__((packed))vì vậy nó tôn trọng alignof (uint64_t) = 8.)

Mã này có chứa bất kỳ hành vi không xác định nào sẽ cho phép GCC phát ra cụm "không chính xác" không?

Nếu không, điều này sẽ được báo cáo trên https://gcc.gnu.org/ormszilla/

Tôi không thấy bất kỳ UB nào ở đây; các loại của bạn không được ký nên UB không tràn được ký là không thể, và không có gì lạ. (Và ngay cả khi đã ký, nó sẽ phải tạo đầu ra chính xác cho các đầu vào không gây ra tràn UB, như rdi=1). Nó cũng bị hỏng với front-end C ++ của GCC.

Ngoài ra, GCC8.2 biên dịch chính xác cho AArch64 và RISC-V (thành một maddhướng dẫn sau khi sử dụng movkđể xây dựng các hằng số, hoặc RISC-V mul và thêm sau khi tải các hằng số). Nếu đó là UB mà GCC đang tìm kiếm, chúng tôi thường mong đợi nó sẽ tìm thấy nó và phá vỡ mã của bạn cho các ISA khác, ít nhất là các mã có độ rộng loại và độ rộng đăng ký tương tự.

Clang cũng biên dịch nó một cách chính xác.

Điều này dường như là một hồi quy từ GCC 5 đến 6; Biên dịch GCC5.4 là chính xác, 6.1 trở lên thì không. ( Thần thánh ).

Bạn có thể báo cáo điều này trên bugzilla của GCC bằng cách sử dụng MCVE từ câu hỏi của bạn.

Nó thực sự trông giống như đó là một lỗi trong xử lý trả lại cấu trúc System V x86-64, có lẽ là các cấu trúc có chứa phần đệm. Điều đó sẽ giải thích tại sao nó hoạt động khi nội tuyến và khi mở rộng athành uint64_t (tránh đệm).

Điều này đã được cố định vào trunk/ master.

Đây là cam kết có liên quan .

Và đây là một bản vá để khắc phục vấn đề.

Dựa trên một nhận xét trong bản vá, reload_combine_recognize_patternchức năng đã cố gắng điều chỉnh nội dung USE .

Mã này có chứa bất kỳ hành vi không xác định nào sẽ cho phép GCC phát ra cụm "không chính xác" không?

Hành vi của mã được trình bày trong câu hỏi được xác định rõ đối với các tiêu chuẩn ngôn ngữ C99 và sau này. Cụ thể, C cho phép các hàm trả về giá trị cấu trúc mà không bị hạn chế.