[AI] Bunch of bugs found by autonomous scanner
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Estrai l’archivio allegato e scegli un candidato dalla tabella, iniziando dal file indicato, ad esempio back/write.rs, builder.rs, type_of.rs, intrinsic/simd.rs, int.rs o intrinsic/llvm.rs. Riproduci il comportamento segnalato sul percorso interessato e verifica che il fallimento dichiarato del candidato sia risolto senza introdurre il crash, il risultato errato o il problema di sicurezza della memoria descritti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I’m developing a project locally that verifies whether a given CPU correctly handles AVX/SSE and other SIMD operations, and it contains a table of reference results generated on my own CPU (hopefully without any errors), which can then be used to validate the results obtained on other hardware.
I thought that testing against these reference results might be useful for this project, as it could help increase the test coverage.
With the help of AI, I automatically generated a list of potential issues from such tool, along with test code, bug explanations and possible solutions, and I hope that this can be useful and help with the project - rustc_codegen_gcc_bughunt_20260902_142949.zip
| # | Class | Candidate | Fix lines | Root cause | Introduced by |
|---|---|---|---|---|---|
| 001 | crash | back/write.rs fat-LTO codegen path SIGSEGVs instead of erroring when liblto_plugin.so is missing | n/a | -fuse-linker-plugin added unconditionally for fat LTO with no check the plugin is available; GCC's driver fails cleanly but rustc then SIGSEGVs inside libgccjit |
c92f0540 |
| 004 | logic | builder.rs atomic_extremum CAS-loop comparison has no signed/unsigned variant | +18/-6 | atomic_rmw routes both signed and unsigned fetch_max/fetch_min through one comparison typed by atomic_load's fixed builtin return type, so unsigned compares silently run as signed across the sign bit | afae271 |
| 005 | memory-safety | builder.rs shuffle_vector mask-padding branch reads v2 past its length | +18/-9 | broadcasting a short vector to more than double its lanes reads v2 out of bounds in the padding loop; harmless since the mask never selects the overrun slots, but a genuine UBSan-flagged OOB read | faebf739 |
| 006 | crash | type_of.rs type_uint_from_ty returns signed GCC types for unsigned Rust types | +6/-6 | every UintTy variant mapped to the signed GCC type instead of unsigned, so simd_scatter's pointer-cast target mismatches its stored value's sign and libgccjit hard-rejects the assignment at compile time | fac57d9a |
| 008 | memory-safety | intrinsic/simd.rs gather() touches every SIMD lane's pointer even when masked off | +51/-36 | gather() dereferenced/wrote through every lane's pointer unconditionally before masking the result via shuffle_vector, so a disabled lane's null/dangling pointer got touched anyway in simd_gather and simd_scatter | not determined |
| 010 | logic | int.rs u128-to-f32 cast via __floatuntisf gets miscompiled by GCC's optimizer under a black_box barrier | n/a | u128 as f32 computes the correct runtime result via the extern __floatuntisf call, but GCC's optimizer (-O, opt-level>=1) statically folds away the assert_eq check against f32::INFINITY - an upstream GCC optimizer bug, not a backend cast-lowering bug | not determined |
| 018 | logic | builder.rs lshr/ashr share gcc_lshr's native >> with no sign-forcing cast |
+26/-4 | a value whose GCC-declared type ends up wrongly signed (e.g. via ptrtoint bridging a pointer-to-usize transmute through a signed isize) gets an arithmetic shift where a logical one (or vice versa) was required | afae271 |
| 025 | logic | intrinsic/simd.rs simd_saturating_sub negates rhs to reuse the saturating-add algorithm | +14/-11 | negating the element type's minimum value (e.g. i8::MIN) overflows and wraps back to itself instead of its true negation, corrupting the sum the borrowed saturating-add overflow check is based on, so a MIN-valued rhs lane returns a wrong, non-saturated result | d725cfb |
| 026 | logic | int.rs int_to_float_cast native branch casts using the operand's own declared sign instead of the caller-requested one | +12/-0 | uitofp/sitofp share a native-type cast with no sign-forcing cast, so a value whose GCC type ends up wrongly signed (e.g. via a pointer-to-usize transmute) converts to float using the wrong sign interpretation | 41f20fa |
| 030 | logic | std::arch::x86_64 _mm_subs_epi8/_mm_subs_epi16 return wrong values for i8::MIN/i16::MIN operands | +14/-11 (candidate 025's patch) | the pinned toolchain's stdarch implements these intrinsics via simd_saturating_sub, so this is candidate 025's negate-of-MIN saturating-sub bug reached through a different Rust API surface, not a separate libgccjit-builtin dispatch bug as originally hypothesized | d725cfb |
| 031 | crash | intrinsic/llvm.rs intrinsic() missing explicit mappings for 5 of 6 rdrand/rdseed builtins | +25/-2 | only llvm.x86.rdrand.64 had an explicit override + out-parameter repacking; its five siblings fell through to archs.rs's generated unimplemented!() catch-all and panicked instead of compiling | 68ac3a4 |
| 032 | crash | builder.rs atomic lowering always emits a _atomic*_16 libcall with no -latomic link flag | +395/-1 | every atomic op (including 16-byte cmpxchg/RMW) unconditionally calls the sized _atomic*_{size} GCC builtin instead of inlining cmpxchg16b when the feature is enabled, and the backend never adds -latomic at link time, leaving the libcall reference dangling | afae271d |
- Lingua principale
- Rust
- Stelle
- 1.2k
- Fork
- 105
- Merge medio
- 6h 28m
- PR unite (30g)
- 14
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rust-lang/rustc_codegen_gcc
-
Re-enable -fno-lto testApertatests
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
rust-lang/rustc_codegen_gcc#993 ·
I maintainer di solito rispondono entro 1 giorno
-
tests
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
rust-lang/rustc_codegen_gcc#992 ·
I maintainer di solito rispondono entro 1 giorno
-
Support `#[no_builtin]`Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
rust-lang/rustc_codegen_gcc#943 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 3/5 1-2 giorni Idoneità per principianti 64/100
rust-lang/rustc_codegen_gcc#930 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
tests
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
rust-lang/rustc_codegen_gcc#922 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di rust-lang/rustc_codegen_gcc
Issue simili
-
[Bug]:设置的关于页面,“系统信息”部分排版异常Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
metasequoiaime/msime#7328 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
eclipse-opensovd/classic-diagnostic-adapter#616 ·
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
track: content
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
0xAndersen/witness-log#10 ·
-
follow-up main-defect wave-A
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
carrick-sh/carrick#249 ·
I maintainer di solito rispondono entro 1 giorno