[Clang] sse optimization error

[Garux]

See prints, mat3x3 element 0 is erroneously 0 after Clang optimizations.
https://godbolt.org/z/KrEKK7v1b

[keinflue]

The code accesses memory out-of-bounds and therefore as undefined behavior. Removing the offending line

    mat3 m3_t1 = matrix_transpose2(m3);

the behavior is as expected.

See https://godbolt.org/z/WhM8PsYqT:

=================================================================
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x701907e00187 at pc 0x5fd54276fc12 bp 0x7ffe0888a010 sp 0x7ffe0888a008
READ of size 16 at 0x701907e00187 thread T0
    #0 0x5fd54276fc11 in matrix_transpose2(mat3 const&) /app/example.cpp:36:16
    #1 0x5fd542771317 in main /app/example.cpp:179:18
    #2 0x741909c29d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)
    #3 0x741909c29e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)
    #4 0x5fd542686374 in _start (/app/output.s+0x2e374)

Address 0x701907e00187 is located in stack of thread T0 at offset 391 in frame
    #0 0x5fd542771077 in main /app/example.cpp:162

  This frame has 6 object(s):
    [64, 128) 'm4_t0' (line 192)
    [192, 256) 'm4_t1' (line 193)
    [288, 304) 'm2_t0' (line 167)
    [320, 336) 'm2_t1' (line 168)
    [352, 388) 'm3' (line 171) <== Memory access at offset 391 overflows this variable
    [432, 468) 'm3_t1' (line 179)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /app/example.cpp:36:16 in matrix_transpose2(mat3 const&)
Shadow bytes around the buggy address:
  0x701907dfff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907dfff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907e00000: f1 f1 f1 f1 f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8
  0x701907e00080: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8
  0x701907e00100: f2 f2 f2 f2 00 00 f2 f2 00 00 f2 f2 00 00 00 00
=>0x701907e00180:[04]f2 f2 f2 f2 f2 00 00 00 00 04 f3 f3 f3 f3 f3
  0x701907e00200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907e00280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907e00300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907e00380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x701907e00400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1==ABORTING

[Garux]

That's right.
Line _mm_storeu_ps(&r.data[2][0], r2); is supposed to restore affected memory, so it's unclear why behavior is 'bugged'.
Here is minimalistic sample https://godbolt.org/z/Mr4hd1TYq.

[keinflue]

Line _mm_storeu_ps(&r.data[2][0], r2); is supposed to restore affected memory

Both the earlier read and this store cause undefined behavior. Two undefined behavior can't cancel one another.

[Garux]

Ok, UB is UB, there is nothing to fix technically.