aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2024-04-02fortran: Ignore use statements on error [PR107426]Mikael Morin6-2/+65
This fixes an access to freed memory on the testcase from the PR. The problem comes from an invalid subroutine statement in an interface, which is ignored and causes the following statements forming the procedure body to be rejected. One of them use-associates the intrinsic ISO_C_BINDING module, which imports new symbols in a namespace that is freed at the time the statement is rejected. However, this creates dangling pointers as ISO_C_BINDING is special and its import creates a reference to the imported C_PTR symbol in the return type of the global intrinsic symbol for C_LOC (see the function create_intrinsic_function). This change saves and restores the list of use statements, so that rejected use statements are removed before they have a chance to be applied to the current namespace and create dangling pointers. PR fortran/107426 gcc/fortran/ChangeLog: * gfortran.h (gfc_save_module_list, gfc_restore_old_module_list): New declarations. * module.c (old_module_list_tail): New global variable. (gfc_save_module_list, gfc_restore_old_module_list): New functions. (gfc_use_modules): Set module_list and old_module_list_tail. * parse.c (next_statement): Save module_list before doing any work. (reject_statement): Restore module_list to its saved value. gcc/testsuite/ChangeLog: * gfortran.dg/pr89943_3.f90: Update error pattern. * gfortran.dg/pr89943_4.f90: Likewise. * gfortran.dg/use_31.f90: New test. (cherry picked from commit a44d7e8a52007c2d45217709ca02947c6600de87)
2024-04-02Daily bump.GCC Administrator1-1/+1
2024-04-01Daily bump.GCC Administrator2-1/+11
2024-03-31Objective-C, NeXT: Fix messenging non-aggregate return-in-memory.Iain Sandoe1-13/+16
When a method returns a type that the platform ABI says should be returned in memory, and that is done by a hidden 'sret' parameter, the message send calls must be adjusted to inform the runtime that the sret parameter is present. As reported in the PR, this is not working for non-aggregate types that use this mechanism. The fix here is to adjust the logic such that all return values that flag 'in memory' are considered to use the mechanism *unless* they provide a struct_value_rtx *and* the return object is an aggregate. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR objc/101718 - Objective-C frontend emits wrong code to call methods returning scalar types returned in memory PR objc/101718 gcc/objc/ChangeLog: * objc-next-runtime-abi-02.c (build_v2_build_objc_method_call): Revise for cases where scalar objects use an sret parameter. (next_runtime_abi_02_build_objc_method_call): Likwise. (cherry picked from commit 1cef3039b880a21fbdf4153e6fc42026619fd4ad)
2024-03-31Daily bump.GCC Administrator1-1/+1
2024-03-30Daily bump.GCC Administrator3-1/+17
2024-03-29Fortran: fix NULL pointer dereference on overlapping initialization [PR50410]Harald Anlauf2-1/+17
gcc/fortran/ChangeLog: PR fortran/50410 * trans-expr.c (gfc_conv_structure): Check for NULL pointer. gcc/testsuite/ChangeLog: PR fortran/50410 * gfortran.dg/data_initialized_4.f90: New test. (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)
2024-03-29Daily bump.GCC Administrator1-1/+1
2024-03-28Daily bump.GCC Administrator3-1/+33
2024-03-27asan: Handle poly-int sizes in ASAN_MARK [PR97696]Richard Sandiford2-5/+33
This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.c (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test. (cherry picked from commit fca6f6fddb22b8665e840f455a7d0318d4575227)
2024-03-27aarch64: Fix vld1/st1_x4 intrinsic definitionsRichard Sandiford1-135/+334
The vld1_x4 and vst1_x4 patterns use XI registers for both 64-bit and 128-bit vectors. This has the nice property that each individual vector is within a separate 16-byte subreg of the XI, which should reduce the number of memory spills needed. However, it means that the 64-bit vector forms must convert between the native 4x64-bit structure layout and the padded 4x128-bit XI layout. The vld4 and vst4 functions did this correctly. But the vld1x4 and vst1x4 functions used a union between the native and padded layouts, even though the layouts are different sizes. This patch makes vld1x4 and vst1x4 use the same approach as vld4 and vst4. It also fixes some uses of variables in the user namespace. gcc/ * config/aarch64/arm_neon.h (vld1_s8_x4, vld1_s16_x4, vld1_s32_x4): (vld1_u8_x4, vld1_u16_x4, vld1_u32_x4, vld1_f16_x4, vld1_f32_x4): (vld1_p8_x4, vld1_p16_x4, vld1_s64_x4, vld1_u64_x4, vld1_p64_x4): (vld1_f64_x4): Avoid using a union of a 256-bit structure and 512-bit XImode integer. Instead use the same approach as the vld4 intrinsics. (vst1_s8_x4, vst1_s16_x4, vst1_s32_x4, vst1_u8_x4, vst1_u16_x4): (vst1_u32_x4, vst1_f16_x4, vst1_f32_x4, vst1_p8_x4, vst1_p16_x4): (vst1_s64_x4, vst1_u64_x4, vst1_p64_x4, vst1_f64_x4, vld1_bf16_x4): (vst1_bf16_x4): Likewise for stores. (vst1q_s8_x4, vst1q_s16_x4, vst1q_s32_x4, vst1q_u8_x4, vst1q_u16_x4): (vst1q_u32_x4, vst1q_f16_x4, vst1q_f32_x4, vst1q_p8_x4, vst1q_p16_x4): (vst1q_s64_x4, vst1q_u64_x4, vst1q_p64_x4, vst1q_f64_x4) (vst1q_bf16_x4): Rename val parameter to __val.
2024-03-27Daily bump.GCC Administrator1-1/+1
2024-03-26Daily bump.GCC Administrator1-1/+1
2024-03-25Daily bump.GCC Administrator1-1/+1
2024-03-24Daily bump.GCC Administrator1-1/+1
2024-03-23Daily bump.GCC Administrator1-1/+1
2024-03-22Daily bump.GCC Administrator1-1/+1
2024-03-21Daily bump.GCC Administrator3-1/+18
2024-03-20Fortran: error recovery in frontend optimization [PR103715]Harald Anlauf2-0/+15
gcc/fortran/ChangeLog: PR fortran/103715 * frontend-passes.c (check_externals_expr): Prevent invalid read in case of mismatch of external subroutine with function. gcc/testsuite/ChangeLog: PR fortran/103715 * gfortran.dg/pr103715.f90: New test. (cherry picked from commit 3be2b8f475f22c531d6cef1b041c0573b3ea5133)
2024-03-20Daily bump.GCC Administrator1-1/+1
2024-03-19Daily bump.GCC Administrator1-1/+1
2024-03-18Daily bump.GCC Administrator2-1/+14
2024-03-17Darwin, Objective-C: Support -fconstant-cfstrings [PR108743].Iain Sandoe2-7/+24
This support the -fconstant-cfstrings option as used by clang (and expect by some build scripts) as an alias to the target-specific -mconstant-cfstrings. The documentation is also updated to reflect that the 'f' option is only available on Darwin, and to add the 'm' option to the Darwin section of the invocation text. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR target/108743 gcc/ChangeLog: * config/darwin.opt: Add fconstant-cfstrings alias to mconstant-cfstrings. * doc/invoke.texi: Amend invocation descriptions to reflect that the fconstant-cfstrings is a target-option alias and to add the missing mconstant-cfstrings option description to the Darwin section. (cherry picked from commit cdd4b3c0f0f428678c24de74b1f626628450799c)
2024-03-17Daily bump.GCC Administrator1-1/+1
2024-03-16Daily bump.GCC Administrator1-1/+1
2024-03-15Daily bump.GCC Administrator1-1/+1
2024-03-14Daily bump.GCC Administrator1-1/+1
2024-03-13Daily bump.GCC Administrator1-1/+1
2024-03-12Daily bump.GCC Administrator1-1/+1
2024-03-11Daily bump.GCC Administrator1-1/+1
2024-03-10Daily bump.GCC Administrator1-1/+1
2024-03-09Daily bump.GCC Administrator1-1/+1
2024-03-08Daily bump.GCC Administrator3-1/+11
2024-03-07Fix bogus error on allocator for array type with Dynamic_PredicateEric Botcazou2-2/+15
This is a regression present on all active branches: the compiler gives a bogus error on an allocator for an unconstrained array type declared with a Dynamic_Predicate because Apply_Predicate_Check is invoked directly on a subtype reference, which it cannot handle. This moves the check to the resulting access value (after dereference) like in Expand_Allocator_Expression. gcc/ada/ PR ada/113979 * exp_ch4.adb (Expand_N_Allocator): In the subtype indication case, remove call to Apply_Predicate_Check. gcc/testsuite/ * gnat.dg/predicate15.adb: New test.
2024-03-07Daily bump.GCC Administrator1-1/+1
2024-03-06Daily bump.GCC Administrator1-1/+1
2024-03-05Daily bump.GCC Administrator1-1/+1
2024-03-04Daily bump.GCC Administrator4-1/+24
2024-03-03SH: Fix 101737Oleg Endo1-1/+2
gcc/ChangeLog: PR target/101737 * config/sh/sh.c (sh_is_nott_insn): Handle case where the input is not an insn, but e.g. a code label.
2024-03-03d: Fix gdc -O2 -mavx generates misaligned vmovdqa instruction [PR114171]Iain Buclaw2-0/+30
PR d/114171 gcc/d/ChangeLog: * d-codegen.cc (lower_struct_comparison): Keep alignment of original type in reinterpret cast for comparison. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr114171.d: New test. (cherry picked from commit 623f52775e677bb3d6e9e7ef97196741dd904b1e)
2024-03-03Daily bump.GCC Administrator3-1/+39
2024-03-03d: Fix callee destructor call invalidates the live object [PR113758]Iain Buclaw3-6/+50
When generating the argument, check the isCalleeDestroyingArgs hook, and force a TARGET_EXPR to be created if true, so that a reference to the live object isn't passed directly to the function that runs dtors. When instead dealing with caller running destructors, two temporaries were being generated, one explicit temporary generated by the D front-end, and another implicitly by the code generator. This has been reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to bind it to the implicit slot created for the TARGET_EXPR, as that has the shorter lifetime of the two. PR d/113758 gcc/d/ChangeLog: * d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee destorys its arguments. * decl.cc (DeclVisitor::visit (VarDeclaration *)): Set SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder for the TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr113758.d: New test. (cherry picked from commit 3c57b1c12a8e34d50bdf6aaf44146760db6d1b33)
2024-03-03d: Fix internal compiler error: in make_import, at d/imports.cc:48 [PR113125]Iain Buclaw3-0/+11
The cause of the ICE was that TYPE_DECLs were only being generated for structs with members, not opaque structs. PR d/113125 gcc/d/ChangeLog: * types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL and apply UDAs to opaque struct declarations. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr113125.d: New test. * gdc.dg/pr113125.d: New test. (cherry picked from commit b0efb1c35724e3332ee5993976efb98200c1a154)
2024-03-02Daily bump.GCC Administrator1-1/+1
2024-03-01Daily bump.GCC Administrator1-1/+1
2024-02-29Daily bump.GCC Administrator1-1/+1
2024-02-28Daily bump.GCC Administrator3-1/+46
2024-02-27x86: Properly implement AMX-TILE load/store intrinsicsH.J. Lu5-2/+101
ldtilecfg and sttilecfg take a 512-byte memory block. With _tile_loadconfig implemented as extern __inline void __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _tile_loadconfig (const void *__config) { __asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void **)__config))); } GCC sees: (parallel [ (asm_operands/v ("ldtilecfg %X0") ("") 0 [(mem/f/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars) (const_int -64 [0xffffffffffffffc0])) [1 MEM[(const void * *)&tile_data]+0 S8 A128])] [(asm_input:DI ("m"))] (clobber (reg:CC 17 flags))]) and the memory operand size is 1 byte. As the result, the rest of 511 bytes is ignored by GCC. Implement ldtilecfg and sttilecfg intrinsics with a pointer to XImode to honor the 512-byte memory block. gcc/ChangeLog: PR target/114098 * config/i386/amxtileintrin.h (_tile_loadconfig): Use __builtin_ia32_ldtilecfg. (_tile_storeconfig): Use __builtin_ia32_sttilecfg. * config/i386/i386-builtin.def (BDESC): Add __builtin_ia32_ldtilecfg and __builtin_ia32_sttilecfg. * config/i386/i386-expand.c (ix86_expand_builtin): Handle IX86_BUILTIN_LDTILECFG and IX86_BUILTIN_STTILECFG. * config/i386/i386.md (ldtilecfg): New pattern. (sttilecfg): Likewise. gcc/testsuite/ChangeLog: PR target/114098 * gcc.target/i386/amxtile-4.c: New test. (cherry picked from commit 4972f97a265c574d51e20373ddefd66576051e5c)
2024-02-26rs6000: Don't allow AltiVec address in movoo & movxo pattern [PR110411]Jeevitha4-5/+38
There are no instructions that do traditional AltiVec addresses (i.e. with the low four bits of the address masked off) for OOmode and XOmode objects. The solution is to modify the constraints used in the movoo and movxo pattern to disallow these types of addresses, which assists LRA in resolving this issue. Furthermore, the mode size 16 check has been removed in vsx_quad_dform_memory_operand to allow OOmode and XOmode, and quad_address_p already handles less than size 16. 2023-08-31 Jeevitha Palanisamy <jeevitha@linux.ibm.com> gcc/ PR target/110411 * config/rs6000/mma.md (define_insn_and_split movoo): Disallow AltiVec address operands. (define_insn_and_split movxo): Likewise. * config/rs6000/predicates.md (vsx_quad_dform_memory_operand): Remove redundant mode size check. gcc/testsuite/ PR target/110411 * gcc.target/powerpc/pr110411-1.c: New testcase. * gcc.target/powerpc/pr110411-2.c: New testcase. (cherry picked from commit 9ea1248604d7b65009af32103814332f35bd33e2)
2024-02-27Daily bump.GCC Administrator3-1/+17