Avoid MariaDB Connector/C Windows vectorization crash

[quinnj]

Summary

• publish a fixed MariaDB Connector/C JLL rebuild as 3.4.9+1
• keep the upstream Connector/C source version at 3.4.9
• add -fno-tree-vectorize to MariaDB Connector/C MinGW builds

Rationale

JuliaDatabases/MySQL.jl#236 reproduces a Windows crash in the released MariaDB_Connector_C_jll 3.4.9+0 artifact during prepared statement execution. Diagnostics in JuliaDatabases/MySQL.jl#237 showed:

• the released JLL 3.4.9+0 artifact fails on both windows-2022 and windows-2025
• the official MariaDB Connector/C 3.4.9 Windows DLL passes on both images
• a Yggdrasil rebuild with -fno-tree-vectorize passes on both images
• disassembly of the released DLL shows GCC vectorized the Connector/C statement request type-info loop into aligned SSE stores; that loop writes into a protocol packet buffer that is not guaranteed to be 16-byte aligned

The diagnostic run with the passing -fno-tree-vectorize rebuild is here: https://github.com/JuliaDatabases/MySQL.jl/actions/runs/27571414885

Testing

• julia --startup-file=no -e 's = read("M/MariaDB_Connector_C/build_tarballs.jl", String); Meta.parseall(s); println("parse ok")'
• git diff --check
• JuliaDatabases/MySQL.jl Actions run 27571414885: released JLL fails on both Windows images; yggdrasil-fno-tree-vectorize passes on both Windows images

Co-authored by Codex

[vchuravy]

Is there an upstream bug report for this miss-compilation?

[quinnj]

Is there an upstream bug report for this miss-compilation?

No, but I think I'll open something. The Connector/C Windows path defines int2store as a typed uint16* store, and ma_stmt_execute_generate_simple_request uses it while writing parameter types into a protocol packet byte buffer whose offset is not guaranteed to be aligned. MinGW GCC’s vectorizer appears to expose that by emitting aligned SSE stores, which then fault on Windows.

Let me look into making an upstream report.

[quinnj]

Upstream report: https://jira.mariadb.org/browse/CONC-825