summaryrefslogtreecommitdiff
path: root/compiler/rustc_codegen_gcc
Commit message (Collapse)AuthorAgeFilesLines
* Move expansion of query macros in rustc_middle to rustc_middle::queryJohn Kåre Alsaker2023-05-151-1/+1
|
* Add todo for filter landing padGary Guo2023-05-071-0/+1
|
* Use `landingpad filter` to encode aborting landing padGary Guo2023-05-071-0/+4
|
* Rollup merge of #105452 - rcvalle:rust-cfi-3, r=bjorn3Manish Goregaokar2023-05-034-24/+14
|\ | | | | | | | | | | | | | | | | | | | | | | Add cross-language LLVM CFI support to the Rust compiler This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto). Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
| * Add cross-language LLVM CFI support to the Rust compilerRamon de C Valle2023-05-034-24/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
* | rename `needs_infer` to `has_infer`Boxy2023-04-272-2/+2
| |
* | Auto merge of #101069 - zhaixiaojuan:loongarch64-inline-asm, r=Amanieubors2023-04-251-0/+5
|\ \ | | | | | | | | | Add loongarch64 asm! support
| * | Add loongarch64 asm! supportzhaixiaojuan2023-04-251-0/+5
| | |
* | | Revert "Remove #[alloc_error_handler] from the compiler and library"Matthias Krüger2023-04-253-4/+41
|/ / | | | | | | This reverts commit abc0660118cc95f47445fd33502a11dd448f5968.
* | Auto merge of #109507 - Amanieu:panic-oom-payload, r=davidtwcobors2023-04-223-41/+4
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: https://github.com/rust-lang/libs-team/issues/192 Closes #51540 Closes #51245
| * Remove #[alloc_error_handler] from the compiler and libraryAmanieu d'Antras2023-04-163-41/+4
| |
* | Add `rustc_fluent_macro` to decouple fluent from `rustc_macros`Nilstrieb2023-04-181-1/+2
|/ | | | | | | | | | Fluent, with all the icu4x it brings in, takes quite some time to compile. `fluent_messages!` is only needed in further downstream rustc crates, but is blocking more upstream crates like `rustc_index`. By splitting it out, we allow `rustc_macros` to be compiled earlier, which speeds up `x check compiler` by about 5 seconds (and even more after the needless dependency on `serde_json` is removed from `rustc_data_structures`).
* Auto merge of #109989 - ids1024:m68k-asm, r=Amanieubors2023-04-131-0/+7
|\ | | | | | | | | | | Add inline assembly support for m68k I believe this should be correct, to the extent I understand the logic around inline assembly. M68k is fairly straightforward here, other than having separate address registers.
| * Add inline assembly support for m68kIan Douglas Scott2023-04-121-0/+7
| |
* | Rollup merge of #96971 - zhaixiaojuan:master, r=wesleywiserMichael Goulet2023-04-111-0/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initial support for loongarch64-unknown-linux-gnu Hi, We hope to add a new port in rust for LoongArch. LoongArch intro LoongArch is a RISC style ISA which is independently designed by Loongson Technology in China. It is divided into two versions, the 32-bit version (LA32) and the 64-bit version (LA64). LA64 applications have application-level backward binary compatibility with LA32 applications. LoongArch is composed of a basic part (Loongson Base) and an expanded part. The expansion part includes Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX). Currently the LA464 processor core supports LoongArch ISA and the Loongson 3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit high-performance processor core. It can be used as a single core for high-end embedded and desktop applications, or as a basic processor core to form an on-chip multi-core system for server and high-performance machine applications. Documentations: ISA: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html ABI: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html More docs can be found at: https://loongson.github.io/LoongArch-Documentation/README-EN.html Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally. I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
| * Define MIN_ALIGN for loongarch64zhaixiaojuan2023-04-081-0/+1
| |
* | Update gccjit and remove libc 0.1 dependencyUlrich Weigand2023-03-301-16/+10
|/
* Use poison instead of undefNikita Popov2023-03-161-0/+5
| | | | | | | | | | | | | In cases where it is legal, we should prefer poison values over undef values. This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with. In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns.
* Remove uses of `box_syntax` in rustc and toolsclubby7892023-03-123-7/+7
|
* Simplify message pathsest312023-03-112-1/+1
| | | | | | | | | | This makes it easier to open the messages file while developing on features. The commit was the result of automatted changes: for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
* replace legacy copyright annotations in submodulesPietro Albini2023-03-091-9/+3
|
* Rollup merge of #108783 - antoyo:sync-cg_gcc-2023-03-04, r=cjgillotMatthias Krüger2023-03-0761-1121/+5741
|\ | | | | | | | | | | | | | | Sync rustc_codegen_gcc 2023/03/04 Hi. This sync all the changes from rustc_codegen_gcc. Thanks for the review.
| * Fix for diagnosticsAntoni Boucher2023-03-053-5/+18
| |
| * Update gccjitAntoni Boucher2023-03-051-2/+2
| |
| * Merge commit '08a6d6e16b5efe217123e780398969946266268f' into ↵Antoni Boucher2023-03-0561-1119/+5726
| | | | | | | | sync-cg_gcc-2023-03-04
* | Auto merge of #95317 - Jules-Bertholet:round_ties_to_even, ↵bors2023-03-071-0/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | r=pnkfelix,m-ou-se,scottmcm Add `round_ties_even` to `f32` and `f64` Tracking issue: #96710 Redux of #82273. See also #55107 Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this. Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight. Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
| * Add `round_ties_even` to `f32` and `f64`Jules Bertholet2022-12-111-0/+2
| |
* | Use `List::empty()` instead of `mk_substs(&[])`.Nicholas Nethercote2023-02-241-1/+1
| |
* | Rename many interner functions.Nicholas Nethercote2023-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
* | Auto merge of #108340 - eggyal:remove_traversal_trait_aliases, r=oli-obkbors2023-02-223-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove type-traversal trait aliases #107924 moved the type traversal (folding and visiting) traits into the type library, but created trait aliases in `rustc_middle` to minimise both the API churn for trait consumers and the arising boilerplate. As mentioned in that PR, an alternative approach of defining subtraits with blanket implementations of the respective supertraits was also considered at that time but was ruled out as not adding much value. Unfortunately, it has since emerged that rust-analyzer has difficulty with these trait aliases at present, resulting in a degraded contributor experience (see the recent [r-a has become useless](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/r-a.20has.20become.20useless) topic on the #t-compiler/help Zulip stream). This PR removes the trait aliases, and accordingly the underlying type library traits are now used directly; they are parameterised by `TyCtxt<'tcx>` rather than just the `'tcx` lifetime, and imports have been updated to reflect the fact that the trait aliases' explicitly named traits are no longer automatically brought into scope. These changes also roll-back the (no-longer required) workarounds to #107747 that were made in b409329c624b9e3bbd7d8e07697e2e9f861a45b6. Since this PR is just a find+replace together with the changes necessary for compilation & tidy to pass, it's currently just one mega-commit. Let me know if you'd like it broken up. r? `@oli-obk`
| * | Remove type-traversal trait aliasesAlan Egerton2023-02-223-3/+3
| | |
* | | various: translation resources from cg backendDavid Wood2023-02-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Extend `CodegenBackend` trait with a function returning the translation resources from the codegen backend, which can be added to the complete list of resources provided to the emitter. Signed-off-by: David Wood <david.wood@huawei.com>
* | | errors: generate typed identifiers in each crateDavid Wood2023-02-222-1/+66
|/ / | | | | | | | | | | | | | | | | Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter. Signed-off-by: David Wood <david.wood@huawei.com>
* | s/eval_usize/eval_target_usize/ for clarityOli Scherer2023-02-141-174/+233
| |
* | session: diagnostic migration lint on more fnsDavid Wood2023-01-301-0/+1
| | | | | | | | | | | | Apply the diagnostic migration lint to more functions on `Session`. Signed-off-by: David Wood <david.wood@huawei.com>
* | create and use GlobalAlloc::address_spaceErik Desjardins2023-01-251-8/+3
| |
* | abi: add `AddressSpace` field to `Primitive::Pointer`Erik Desjardins2023-01-224-8/+16
| | | | | | | | | | | | | | | | ...and remove it from `PointeeInfo`, which isn't meant for this. There are still various places (marked with FIXMEs) that assume all pointers have the same size and alignment. Fixing this requires parsing non-default address spaces in the data layout string, which will be done in a followup.
* | Change `src/test` to `tests` in source files, fix tidy and testsAlbert Larsan2023-01-111-8/+8
| |
* | Simplify some iterator combinatorsMichael Goulet2023-01-042-2/+2
| |
* | Add missing anonymous lifetimeJeremy Stucki2022-12-201-1/+1
| |
* | rustc: Remove needless lifetimesJeremy Stucki2022-12-203-3/+3
| |
* | Auto merge of #105252 - bjorn3:codegen_less_pair_values, r=nagisabors2022-12-121-7/+7
|\ \ | |/ |/| | | | | | | Use struct types during codegen in less places This makes it easier to use cg_ssa from a backend like Cranelift that doesn't have any struct types at all. After this PR struct types are still used for function arguments and return values. Removing those usages is harder but should still be doable.
| * Destruct landing_pad return value before passing it to cg_ssabjorn32022-12-031-7/+7
| |
* | Rollup merge of #105109 - rcvalle:rust-kcfi, r=bjorn3Matthias Krüger2022-12-101-0/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add LLVM KCFI support to the Rust compiler This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.) Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653). LLVM KCFI can be enabled with -Zsanitizer=kcfi. Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
| * | Add LLVM KCFI support to the Rust compilerRamon de C Valle2022-12-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.) Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653). LLVM KCFI can be enabled with -Zsanitizer=kcfi. Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
* | | Move linkage type check to HIR analysis and fix semantics issues.Peter Collingbourne2022-12-052-28/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This ensures that the error is printed even for unused variables, as well as unifying the handling between the LLVM and GCC backends. This also fixes unusual behavior around exported Rust-defined variables with linkage attributes. With the previous behavior, it appears to be impossible to define such a variable such that it can actually be imported and used by another crate. This is because on the importing side, the variable is required to be a pointer, but on the exporting side, the type checker rejects static variables of pointer type because they do not implement `Sync`. Even if it were possible to import such a type, it appears that code generation on the importing side would add an unexpected additional level of pointer indirection, which would break type safety. This highlighted that the semantics of linkage on Rust-defined variables is different to linkage on foreign items. As such, we now model the difference with two different codegen attributes: linkage for Rust-defined variables, and import_linkage for foreign items. This change gives semantics to the test src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was previously expected to fail to compile. Therefore, convert it into a test that is expected to successfully compile. The update to the GCC backend is speculative and untested.
* | | Auto merge of #97485 - bjorn3:new_archive_writer, r=wesleywiserbors2022-12-034-203/+8
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | Rewrite LLVM's archive writer in Rust This allows it to be used by other codegen backends. Fixes https://github.com/bjorn3/rustc_codegen_cranelift/issues/1155
| * | Rewrite LLVM's archive writer in Rustbjorn32022-11-264-203/+8
| |/ | | | | | | This allows it to be used by other codegen backends
* | Rollup merge of #104976 - WaffleLapkin:move_comments, r=cjgillotMatthias Krüger2022-11-271-2/+2
|\ \ | | | | | | | | | | | | | | | Prefer doc comments over `//`-comments in compiler Doc comments are generally nicer: they show up in the documentation, they are shown in IDEs when you hover other mentions of items, etc. Thus it makes sense to use them instead of `//`-comments.
| * | Prefer doc comments over `//`-comments in compilerMaybe Waffle2022-11-271-2/+2
| |/
View Lorry Controller Status