aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-21libgomp/gcn: fix/improve struct outputTobias Burnus4-21/+27
output.printf_data.(value union) contains text[128], which has the size of 128 bytes, sufficient for 16 uint64_t variables; hence value_u64[2] could be extended to value_u64[6] - sufficient for all required arguments to gomp_target_rev. Additionally, next_output.printf_data.(msg union) contained msg_u64 which then is no longer needed and also caused 32bit vs 64bit alignment issues. libgomp/ * config/gcn/libgomp-gcn.h (struct output): Remove 'msg_u64' from the union, change value_u64[2] to value_u64[6]. * config/gcn/target.c (GOMP_target_ext): Update accordingly. * plugin/plugin-gcn.c (process_reverse_offload, console_output): Likewise. (cherry picked from commit 6edcb5dc42625cb0cf84b19c6fe4f944f6322ea0)
2022-11-21i386: Uglify some local identifiers in *intrin.h [PR107748]Jakub Jelinek4-48/+49
While reporting PR107748 (where is a problem with non-uglified names, but I've left it out because it needs fixing anyway), I've noticed various spots where identifiers in *intrin.h headers weren't uglified. The following patch fixed those that are related to unions (I've grepped for [a-zA-Z]\.[a-zA-Z] spots). The reason we need those to be uglified is the same as why the arguments of the inlines are __ prefixed and most of automatic vars in the inlines - say a, v or u aren't part of implementation namespace and so users could #define u whatever->something #include <x86intrin.h> and it should still work, as long as u is not e.g. one of the names of the functions/macros the header provides (_mm* etc.). 2022-11-21 Jakub Jelinek <jakub@redhat.com> PR target/107748 * config/i386/avx512fp16intrin.h (_mm512_castph512_ph128, _mm512_castph512_ph256, _mm512_castph128_ph512, _mm512_castph256_ph512, _mm512_set1_pch): Uglify names of local variables and union members. * config/i386/avx512fp16vlintrin.h (_mm256_castph256_ph128, _mm256_castph128_ph256, _mm256_set1_pch, _mm_set1_pch): Likewise. * config/i386/smmintrin.h (_mm_extract_ps): Likewise. * config/i386/avx512bf16intrin.h (_mm_cvtsbh_ss): Likewise. (cherry picked from commit ec8ec09f9414be871e322fecf4ebf53e3687bd22)
2022-11-21Daily bump.GCC Administrator5-1/+76
2022-11-20reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183]Jakub Jelinek2-21/+77
As the following testcase shows, the swap_rtx_condition function in reg-stack can result in different code generation between -g and -g0. The function is doing the changes as it goes, so does analysis and changes together, which makes it harder to deal with DEBUG_INSNs, where normally analysis phase ignores them and the later phase doesn't. swap_rtx_condition walks instructions two different ways, one is using next_flags_user function which stops on non-call instructions that mention the flags register, and the other is a loop on fnstsw where it stops on instructions mentioning it and tries to find sahf instruction that uses it (in both cases calls stop it and so does end of basic block). Now both of these currently stop on DEBUG_INSNs that mention the flags register resp. the fnstsw result register. On success the function recurses on next flags user instruction if still live and if the recursion failed, reverts the changes it did too and fails. If it were just for the next_flags_user case, the fix could be just not doing INSN_CODE (insn) = -1; if (recog_memoized (insn) == -1) fail = 1; on DEBUG_INSNs (assuming all changes to those are fine), swap_rtx_condition_1 just changes one comparison to a different one. But due to the possibility of fnstsw result being used in theory before sahf in some DEBUG_INSNs, this patch takes a different approach. swap_rtx_condition has now a new argument and two modes. The first mode is when debug_seen is >= 0, in this case both next_flags_user and the loop for fnstsw -> sahf will ignore but note DEBUG_INSNs (that mention flags register or fnstsw result). If no such DEBUG_INSN is found during the whole call including recursive invocations (so e.g. for -g0 but probably most often for -g as well), it behaves as before, if it returns true all the changes are done and nothing further needs to be done later. If any DEBUG_INSNs are seen along the way, even when returning success all the changes are reverted, so it just reports that the function would be successful if DEBUG_INSNs were ignored. In this case, compare_for_stack_reg needs to call it again in debug_seen = -1 mode, which tells the function to update everything including DEBUG_INSNs. For the fnstsw -> sahf case which I hope will be very rare I just reset the DEBUG_INSNs, I don't really know how to express it easily otherwise. For the rest swap_rtx_condition_1 is done even on the DEBUG_INSNs. 2022-11-20 Jakub Jelinek <jakub@redhat.com> PR target/107183 * reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument. If >= 0 and a DEBUG_INSN would be otherwise returned, set DEBUG_SEEN to 1 and ignore it. (swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0 mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs were seen and revert all changes on success in that case. Don't try to recog_memoized DEBUG_INSNs. (compare_for_stack_reg): Adjust swap_rtx_condition caller. If it returns true and debug_seen is 1, call swap_rtx_condition again with debug_seen -1. * gcc.dg/ubsan/pr107183.c: New test. (cherry picked from commit 6b5c98c1c0003bd470a4428bede6c862637a94b8)
2022-11-20c++: Fix a typo in function nameJakub Jelinek3-4/+4
I've noticed I've made a typo in the name of the function. Fixed thusly. 2022-11-15 Jakub Jelinek <jakub@redhat.com> * cp-tree.h (next_common_initial_seqence): Rename to ... (next_common_initial_sequence): ... this. * typeck.cc (next_common_initial_seqence): Rename to ... (next_common_initial_sequence): ... this. (layout_compatible_type_p): Call next_common_initial_sequence rather than next_common_initial_seqence. * semantics.cc (is_corresponding_member_aggr): Likewise. (cherry picked from commit 87c4057b3fc7fe2c2f8914d2755024ca890a3bc1)
2022-11-20libatomic: Handle AVX+CX16 AMD like Intel for 16b atomics [PR104688]Jakub Jelinek1-2/+4
We got a response from AMD in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10 so the following patch starts treating AMD with AVX and CMPXCHG16B ISAs like Intel by using vmovdqa for atomic load/store in libatomic. We still don't have confirmation from Zhaoxin and VIA (anything else with CPUs featuring AVX and CX16?). 2022-11-15 Jakub Jelinek <jakub@redhat.com> PR target/104688 * config/x86/init.c (__libat_feat1_init): Don't clear bit_AVX on AMD CPUs. (cherry picked from commit 4a7a846687e076eae58ad3ea959245b2bf7fdc07)
2022-11-19libgomp/gcn: Prepare for reverse-offload callback handlingTobias Burnus4-22/+133
libgomp/ChangeLog: * config/gcn/libgomp-gcn.h: New file; contains struct output, declared previously in plugin-gcn.c. * config/gcn/target.c: Include it. (GOMP_ADDITIONAL_ICVS): Declare as extern var. (GOMP_target_ext): Handle reverse offload. * plugin/plugin-gcn.c: Include libgomp-gcn.h. (struct kernargs): Replace struct def by the one from libgomp-gcn.h for output_data. (process_reverse_offload): New. (console_output): Call it. (cherry picked from commit 8c05d8cd4300f74bf2698f0a6b96464b5be571be)
2022-11-19nvptx: In 'STARTFILE_SPEC', fix 'crt0.o' for '-mmainkernel'Thomas Schwinge1-1/+1
A recent nvptx-tools change: commit 886a95faf66bf66a82fc0fe7d2a9fd9e9fec2820 "ld: Don't search for input files in '-L'directories" (of <https://github.com/MentorEmbedded/nvptx-tools/pull/38> "Match standard 'ld' "search" behavior") in GCC/nvptx target testing generally causes linking to fail with: error opening crt0.o collect2: error: ld returned 1 exit status compiler exited with status 1 Indeed per GCC '-v' output, there is an undecorated 'crt0.o' on the linker ('collect2') command line: [...]/build-gcc/./gcc/collect2 -o [...] crt0.o [...] This is due to: gcc/config/nvptx/nvptx.h:#define STARTFILE_SPEC "%{mmainkernel:crt0.o}" ..., and the fix, as used by numerous other GCC targets, is to instead use 'crt0.o%s'; for '%s' means, per 'gcc/gcc.cc', "The Specs Language": %s current argument is the name of a library or startup file of some sort. Search for that file in a standard list of directories and substitute the full name found. With that, we get the expected path to 'crt0.o'. gcc/ * config/nvptx/nvptx.h (STARTFILE_SPEC): Fix 'crt0.o' for '-mmainkernel'. (cherry picked from commit dda43e1ef0c9f6c32ad022d3a08ce7651e42a129)
2022-11-19LoongArch: Fix atomic_exchange expanding [PR107713]Jinyang He3-2/+84
We used to expand atomic_exchange_n(ptr, new, mem_order) for subword types into something like: { __typeof__(*ptr) t = atomic_load_n(ptr, mem_order); atomic_compare_exchange_n(ptr, &t, new, true, mem_order, mem_order); return t; } It's incorrect because another thread may store a different value into *ptr after atomic_load_n. Then atomic_compare_exchange_n will not store into *ptr, but atomic_exchange_n should always perform the store. gcc/ChangeLog: PR target/107713 * config/loongarch/sync.md (atomic_cas_value_exchange_7_<mode>): New define_insn. (atomic_exchange): Use atomic_cas_value_exchange_7_si instead of atomic_cas_value_cmp_and_7_si. gcc/testsuite/ChangeLog: PR target/107713 * gcc.target/loongarch/pr107713-1.c: New test. * gcc.target/loongarch/pr107713-2.c: New test. (cherry picked from commit f0024bfb228f94e60e06dc32a4983e40a9b90be5)
2022-11-18Daily bump.GCC Administrator3-1/+18
2022-11-18Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus21-78/+516
Merge up to r12-8916-g14faa5f585f6025df1e04c8c8b34340ff5e4d494 (18th Nov 2022)
2022-11-18gcn: Add __builtin_gcn_kernarg_ptrTobias Burnus5-5/+46
Add __builtin_gcn_kernarg_ptr to avoid using hard-coded register values and permit future ABI changes while keeping the API. gcc/ChangeLog: * config/gcn/gcn-builtins.def (KERNARG_PTR): Add. * config/gcn/gcn.cc (gcn_init_builtin_types): Change siptr_type_node, sfptr_type_node and voidptr_type_node from FLAT to ADDR_SPACE_DEFAULT. (gcn_expand_builtin_1): Handle GCN_BUILTIN_KERNARG_PTR. (gcn_oacc_dim_size): Return in ADDR_SPACE_FLAT. libgomp/ChangeLog: * config/gcn/team.c (gomp_gcn_enter_kernel): Use __builtin_gcn_kernarg_ptr instead of asm ("s8"). Co-Authored-By: Andrew Stubbs <ams@codesourcery.com> (cherry picked from commit 6f83861cc1c4d09425aa6539877bfa50ef90f183)
2022-11-17c++: constinit on pointer to function [PR104066]Marek Polacek2-1/+13
[dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test. (cherry picked from commit 7b3b2f50953c5143d4b14b59d322d8a793f411dd)
2022-11-17Daily bump.GCC Administrator3-1/+35
2022-11-16aarch64: Add support for Ampere-1A (-mcpu=ampere1a) CPUPhilipp Tomsich6-3/+178
This patch adds support for Ampere-1A CPU: - recognize the name of the core and provide detection for -mcpu=native, - updated extra_costs, - adds a new fusion pair for (A+B+1 and A-B-1). Ampere-1A and Ampere-1 have more timing difference than the extra costs indicate, but these don't propagate through to the headline items in our extra costs (e.g. the change in latency for scalar sqrt doesn't have a corresponding table entry). gcc/ChangeLog: * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add ampere1a. * config/aarch64/aarch64-cost-tables.h: Add ampere1a_extra_costs. * config/aarch64/aarch64-fusion-pairs.def (AARCH64_FUSION_PAIR): Define a new fusion pair for A+B+1/A-B-1 (i.e., add/subtract two registers and then +1/-1). * config/aarch64/aarch64-tune.md: Regenerate. * config/aarch64/aarch64.cc (aarch_macro_fusion_pair_p): Implement idiom-matcher for the new fusion pair. * doc/invoke.texi: Add ampere1a. (cherry picked from commit 590a06afbf0e96813b5879742f38f3665512c854)
2022-11-16SRA: Limit replacement creation for accesses propagated from LHSsMartin Jambor2-0/+34
PR 107206 is fallout from the fix to PR 92706 where we started propagating accesses across assignments also from LHS to RHS of assignments so that we would not do harmful total scalarization of the aggregates on the RHS. But this can lead to new scalarization of these aggregates and in the testcase of PR 107206 these can appear in superfluous uses of un-initialized values and spurious warnings. Fixed by making sure the the accesses created by propagation in this direction are only used as a basis for replacements when the structure would be totally scalarized anyway. gcc/ChangeLog: 2022-10-18 Martin Jambor <mjambor@suse.cz> PR tree-optimization/107206 * tree-sra.cc (struct access): New field grp_result_of_prop_from_lhs. (analyze_access_subtree): Do not create replacements for accesses with this flag when not toally scalarizing. (propagate_subaccesses_from_lhs): Set the new flag. gcc/testsuite/ChangeLog: 2022-10-18 Martin Jambor <mjambor@suse.cz> PR tree-optimization/107206 * g++.dg/tree-ssa/pr107206.C: New test. (cherry picked from commit f6c168f8c06047bfaa3005e570126831b8855dcc)
2022-11-16nvptx/mkoffload.cc: Fix "$nohost" checkTobias Burnus2-2/+12
If lhd_set_decl_assembler_name is invoked - in particular if !TREE_PUBLIC (decl) && !DECL_FILE_SCOPE_P (decl) - the '.nohost' suffix might change to '.nohost.2'. This happens for the existing reverse offload testcases via cgraph_node::analyze and is a side effect of r13-3455-g178ac530fe67e4f2fc439cc4ce89bc19d571ca31 for some reason. The solution is to not only check for a tailing '$nohost' but also for '$nohost$' in nvptx/mkoffload.cc. gcc/ChangeLog: * config/nvptx/mkoffload.cc (process): Recognize '$nohost$...' besides tailing '$nohost' as being for reverse offload. (cherry picked from commit d59858f6ee7f356f27ccc2d29129826781f9483f)
2022-11-16Daily bump.GCC Administrator1-1/+1
2022-11-15Daily bump.GCC Administrator2-1/+40
2022-11-14libstdc++: Fix std::move_only_function for incomplete parameter typesJonathan Wakely2-4/+12
The std::move_only_function::__param_t alias template attempts to optimize argument passing for the invoker, by passing by rvalue reference for types that are non-trivial or large. However, the precondition for is_trivally_copyable makes it unsuitable for using here, and can cause ODR violations. Just use is_scalar instead, and pass all class types (even small, trivial ones) by value. libstdc++-v3/ChangeLog: * include/bits/mofunc_impl.h (move_only_function::__param_t): Use __is_scalar instead of is_trivially_copyable. * testsuite/20_util/move_only_function/call.cc: Check parameters involving incomplete types.
2022-11-14libstdc++: Fix wstring conversions in filesystem::path [PR95048]Jonathan Wakely4-67/+203
In commit r9-7381-g91756c4abc1757 I changed filesystem::path to use std::codecvt<CharT, char, mbstate_t> for conversions from all wide strings to UTF-8, instead of using std::codecvt_utf8<CharT>. This was done because for 16-bit wchar_t, std::codecvt_utf8<wchar_t> only supports UCS-2 and not UTF-16. The rationale for the change was sound, but the actual fix was not. It's OK to use std::codecvt for char16_t or char32_t, because the specializations for those types always use UTF-8 , but std::codecvt<wchar_t, char, mbstate_t> uses the current locale's encodings, and the narrow encoding is probably ASCII and can't support non-ASCII characters. The correct fix is to use std::codecvt only for char16_t and char32_t. For 32-bit wchar_t we could have continued using std::codecvt_utf8 because that uses UTF-32 which is fine, switching to std::codecvt broke non-Windows targets with 32-bit wchar_t. For 16-bit wchar_t we did need to change, but should have changed to std::codecvt_utf8_utf16<wchar_t> instead, as that always uses UTF-16 not UCS-2. I actually noted that in the commit message for r9-7381-g91756c4abc1757 but didn't use that option. Oops. This replaces the unconditional std::codecvt<CharT, char, mbstate_t> with a type defined via template specialization, so it can vary depending on the wide character type. The code is also simplified to remove some of the mess of #ifdef and if-constexpr conditions. libstdc++-v3/ChangeLog: PR libstdc++/95048 * include/bits/fs_path.h (path::_Codecvt): New class template that selects the kind of code conversion done. (path::_Codecvt<wchar_t>): Select based on sizeof(wchar_t). (_GLIBCXX_CONV_FROM_UTF8): New macro to allow the same code to be used for Windows and POSIX. (path::_S_convert(const EcharT*, const EcharT*)): Simplify by using _Codecvt and _GLIBCXX_CONV_FROM_UTF8 abstractions. (path::_S_str_convert(basic_string_view<value_type>, const A&)): Simplify nested conditions. * include/experimental/bits/fs_path.h (path::_Cvt): Define nested typedef controlling type of code conversion done. (path::_Cvt::_S_wconvert): Use new typedef. (path::string(const A&)): Likewise. * testsuite/27_io/filesystem/path/construct/95048.cc: New test. * testsuite/experimental/filesystem/path/construct/95048.cc: New test. (cherry picked from commit b331bf303bdc1edead41e2b3d11d1a7804b433cf)
2022-11-14libstdc++: Set active union member in constexpr std::string [PR103295]Nathaniel Shead1-2/+2
Clang still complains about using std::string in constexpr contexts due to the changes made in commit 98a0d72a. This patch ensures that we set the active member of the union as according to [class.union.general] p6. libstdc++-v3/ChangeLog: PR libstdc++/103295 * include/bits/basic_string.h (_M_use_local_data): Set active member to _M_local_buf. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> (cherry picked from commit 52672be7d328df50f9a05ce3ab44ebcae50fee1b)
2022-11-14Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus20-58/+218
Merge up to r12-8907-g58da1386d2233b8e01aaac8f7c4a61a2ccf52743 (14th Nov 2022)
2022-11-14libgomp: Fix up build on mingw [PR107641]Jakub Jelinek2-1/+10
Pointers should be first casted to intptr_t/uintptr_t before casting them to another integral type to avoid warnings. Furthermore, the function has code like else if (upper <= UINT_MAX) something; else something_else; so it seems using unsigned type for upper where upper <= UINT_MAX is always true is not intended. 2022-11-12 Jakub Jelinek <jakub@redhat.com> PR libgomp/107641 * env.c (parse_unsigned_long): Cast params[2] to uintptr_t rather than unsigned long. Change type of upper from unsigned to unsigned long. (cherry picked from commit 2a193e9df82917eaf440a20f99a3febe91dcb5fe)
2022-11-14Daily bump.GCC Administrator1-1/+1
2022-11-13Daily bump.GCC Administrator1-1/+1
2022-11-12Daily bump.GCC Administrator1-1/+1
2022-11-11Daily bump.GCC Administrator1-1/+1
2022-11-10Daily bump.GCC Administrator3-1/+10
2022-11-09Add guality testcase for RTL alias analysis fixEric Botcazou1-0/+20
gcc/testsuite/ * gcc.dg/guality/param-6.c: New test.
2022-11-09Restore RTL alias analysis for hard frame pointerEric Botcazou1-7/+12
The change: 2021-07-28 Bin Cheng <bin.cheng@linux.alibaba.com> alias.c (init_alias_analysis): Don't skip prologue/epilogue. broke the alias analysis for the hard frame pointer (when it is used as a frame pointer, i.e. when the frame pointer is not eliminated) described in the large comment at the top of the file, because static_reg_base_value is set for it and, consequently, new_reg_base_value too. When the instruction saving the stack pointer into the hard frame pointer in the prologue is processed, it is viewed as a second set of the hard frame pointer and to a different value by record_set, which then proceeds to reset new_reg_base_value to 0 and the game is over. gcc/ * alias.cc (init_alias_analysis): Do not record sets to the hard frame pointer if the frame pointer has not been eliminated.
2022-11-09Daily bump.GCC Administrator4-1/+27
2022-11-08Always use TYPE_MODE instead of DECL_MODE for vector fieldH.J. Lu2-2/+40
e034c5c8957 re PR target/78643 (ICE in convert_move, at expr.c:230) fixed the case where DECL_MODE of a vector field is BLKmode and its TYPE_MODE is a vector mode because of target attribute. Remove the BLKmode check for the case where DECL_MODE of a vector field is a vector mode and its TYPE_MODE isn't a vector mode because of target attribute. gcc/ PR target/107304 * expr.cc (get_inner_reference): Always use TYPE_MODE for vector field with vector raw mode. gcc/testsuite/ PR target/107304 * gcc.target/i386/pr107304.c: New test. (cherry picked from commit 1c64aba8cdf6509533f554ad86640f274cdbe37f)
2022-11-08libstdc++: Remove empty <author> elements in manualJonathan Wakely3-15/+5
This fixes a spurious comma before the list of authors in the PDF version of the libstdc++ manual. Also fix the commented-out examples which should show <personblurb> not <authorblurb>. libstdc++-v3/ChangeLog: * doc/xml/authors.xml: Remove empty author element. * doc/xml/manual/spine.xml: Likewise. * doc/html/manual/index.html: Regenerate. (cherry picked from commit 4596339d9fabdcbd66b5a7430fa56544f75ecef1)
2022-11-08Daily bump.GCC Administrator2-1/+8
2022-11-07amdgcn: Fix expansion of GCN_BUILTIN_LDEXPV builtinKwok Cheung Yeung2-1/+6
2022-11-07 Kwok Cheung Yeung <kcy@codesourcery.com> gcc/ * config/gcn/gcn.cc (gcn_expand_builtin_1): Expand first argument of GCN_BUILTIN_LDEXPV to V64DFmode.
2022-11-07amdgcn: Various fixes for SIMD math libraryKwok Cheung Yeung3-21/+22
Fix an error if VECTOR_RETURN is used on a constant. Simplify the implementation of ilogb by removing VECTOR_IFs with a trivial body. 2022-11-07 Kwok Cheung Yeung <kcy@codesourcery.com> libgcc/ * config/gcn/simd-math/amdgcnmach.h (VECTOR_RETURN): Store value of return value in a local variable first. * config/gcn/simd-math/v64df_ilogb.c (ilogb): Simplify.
2022-11-07amdgcn: Fixed intermittent failure in vectorized version of rintKwok Cheung Yeung3-17/+16
The lane mask was not being updated properly in nested conditionals. Also fixed an issue causing inaccuracy in double-precision rint. 2022-11-07 Kwok Cheung Yeung <kcy@codesourcery.com> libgcc/ * config/gcn/simd-math/v64df_rint.c (rint): Simplified. Fixed bug in nested VECTOR_IF. Fixed issue with signed right-shift. * config/gcn/simd-math/v64sf_rint.c (rintf): Simplified. Fixed bug in nested VECTOR_IF.
2022-11-07Remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDSCui,Lili3-16/+12
gcc/ChangeLog: * config/i386/driver-i386.cc (host_detect_local_cpu): Move sapphirerapids out of AVX512_VP2INTERSECT. * config/i386/i386.h: Remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS * doc/invoke.texi: Remove AVX512_VP2INTERSECT from SAPPHIRERAPIDS
2022-11-07Daily bump.GCC Administrator1-1/+1
2022-11-06Daily bump.GCC Administrator3-1/+22
2022-11-05doc: Document correct -fwide-exec-charset defaults [PR41041]Jonathan Wakely1-3/+4
As shown in the PR, the default is not UTF-32 but rather UTF-32BE or UTF-32LE, avoiding the need for a byte order mark in literals. gcc/ChangeLog: PR c/41041 * doc/cppopts.texi: Document -fwide-exec-charset defaults correctly. (cherry picked from commit e50ea3a42f058c14ee29327d5277ab0435e3d36b)
2022-11-04Fix recent thinko in operand_equal_pEric Botcazou5-14/+61
There is a thinko in a recent improvement made to operand_equal_p where the code just looks at operand 2 of COMPONENT_REF, if it is present, to compare addresses. That's wrong because operand 2 contains the number of DECL_OFFSET_ALIGN-bit-sized words so, when DECL_OFFSET_ALIGN > 8, not all the bytes are included and some of them are in DECL_FIELD_BIT_OFFSET, see get_inner_reference for the model computation. In other words, you would need to compare operand 2 and DECL_OFFSET_ALIGN and DECL_FIELD_BIT_OFFSET in this situation, but I'm not sure this is worth the hassle in practice so the fix just removes this alternate handling. gcc/ * fold-const.cc (operand_compare::operand_equal_p) <COMPONENT_REF>: Do not take into account operand 2. (operand_compare::hash_operand) <COMPONENT_REF>: Likewise. gcc/testsuite/ * gnat.dg/opt99.adb: New test. * gnat.dg/opt99_pkg1.ads, gnat.dg/opt99_pkg1.adb: New helper. * gnat.dg/opt99_pkg2.ads: Likewise.
2022-11-04Align with: "OpenMP/Fortran: 'target update' with DT components"Tobias Burnus4-15/+19
This commit partially undos the OG12 commit cb934e37962eeccc8641982b9a9855408979c767 OpenMP/Fortran: 'target update' with strides + DT components to match the mainline (GCC 13) version: r13-3625-g6629444170f85e9b1e243aa07e3e07a8b9f8fce5 OpenMP/Fortran: 'target update' with DT components The difference is that strides are not permitted in the mainline version; for the reason and to-do, see: https://gcc.gnu.org/PR107517 Interdiff changelog: 2022-11-04 Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ChangeLog.omp Partial Revert: 2022-11-02 Tobias Burnus <tobias@codesourcery.com> * openmp.cc (resolve_omp_clauses):Accept noncontiguous arrays. libgomp/ChangeLog.omp * testsuite/libgomp.fortran/target-13.f90: Remove strides to match mainline (GCC 13) version. (cherry picked from commit 6629444170f85e9b1e243aa07e3e07a8b9f8fce5)
2022-11-04Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus13-5/+256
Merge up to r12-8891-g14a92220a2f061328aae32ee6b5cdc7f62375902 (4th Nov 2022) Note: This includes in principle some OpenMP/libgomp commits, but those have been cherry picked already.
2022-11-04Daily bump.GCC Administrator6-1/+141
2022-11-03i386: Fix uninitialized register after peephole2 conversion [PR107404]Uros Bizjak2-1/+55
The eliminate reg-reg move by inverting the condition of a cmove #2 peephole2 converts the following sequence: 473: bx:DI=[r14:DI*0x8+r12:DI] 960: r15:DI=r8:DI 485: {flags:CCC=cmp(r15:DI+bx:DI,bx:DI);r15:DI=r15:DI+bx:DI;} 737: r15:DI={(geu(flags:CCC,0))?r15:DI:bx:DI} to: 1110: {flags:CCC=cmp(r8:DI+bx:DI,bx:DI);r8:DI=r8:DI+bx:DI;} 1111: r15:DI=[r14:DI*0x8+r12:DI] 1112: r15:DI={(geu(flags:CCC,0))?r8:DI:r15:DI} Please note that(insn 1110) uses register BX, but its initialization was eliminated. Avoid conversion if eliminated move intialized a register, used in the moved instruction. 2022-11-03 Uroš Bizjak <ubizjak@gmail.com> gcc/ChangeLog: PR target/107404 * config/i386/i386.md (eliminate reg-reg move by inverting the condition of a cmove #2 peephole2): Check if eliminated move initialized a register, used in the moved instruction. gcc/testsuite/ChangeLog: PR target/107404 * g++.target/i386/pr107404.C: New test. (cherry picked from commit 553b1d3dd5b9253ebdf66ee3260c717d5b807dd1)
2022-11-03c, c++: Fix up excess precision handling of scalar_to_vector conversion ↵Jakub Jelinek2-2/+32
[PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek <jakub@redhat.com> PR c++/107358 gcc/c/ * c-typeck.cc (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. (cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)
2022-11-03c++: Fix up constexpr handling of char/signed char/short pre/post ↵Jakub Jelinek2-0/+27
inc/decrement [PR105774] signed char, char or short int pre/post inc/decrement are represented by normal {PRE,POST}_{INC,DEC}REMENT_EXPRs in the FE and only gimplification ensures that the {PLUS,MINUS}_EXPR is done in unsigned version of those types: case PREINCREMENT_EXPR: case PREDECREMENT_EXPR: case POSTINCREMENT_EXPR: case POSTDECREMENT_EXPR: { tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0)); if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type)) { if (!TYPE_OVERFLOW_WRAPS (type)) type = unsigned_type_for (type); return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type); } break; } This means during constant evaluation we need to do it similarly (either using unsigned_type_for or using widening to integer_type_node). The following patch does the latter. 2022-10-24 Jakub Jelinek <jakub@redhat.com> PR c++/105774 * constexpr.cc (cxx_eval_increment_expression): For signed types that promote to int, evaluate PLUS_EXPR or MINUS_EXPR in int type. * g++.dg/cpp1y/constexpr-105774.C: New test. (cherry picked from commit da8c362c4c18cff2f2dfd5c4706bdda7576899a4)
2022-11-03libgomp: Fix up creation of artificial teamsJakub Jelinek6-6/+117
When not in explicit parallel/target/teams construct, we in some cases create an artificial parallel with a single thread (either to handle target nowait or for task reduction purposes). In those cases, it handled again artificially created implicit task (created by gomp_new_icv for cases where we needed to write to some ICVs), but as the testcases show, didn't take into account possibility of this being done from explicit task(s). The code would destroy/free the previous task and replace it with the new implicit task. If task is an explicit task (when teams is NULL, all explicit tasks behave like if (0)), it is a pointer to a local stack variable, so freeing it doesn't work, and additionally we shouldn't lose the explicit tasks - the new implicit task should instead replace the ancestor task which is the first implicit one. 2022-10-12 Jakub Jelinek <jakub@redhat.com> * task.c (gomp_create_artificial_team): Fix up handling of invocations from within explicit task. * target.c (GOMP_target_ext): Likewise. * testsuite/libgomp.c/task-7.c: New test. * testsuite/libgomp.c/task-8.c: New test. * testsuite/libgomp.c-c++-common/task-reduction-17.c: New test. * testsuite/libgomp.c-c++-common/task-reduction-18.c: New test. (cherry picked from commit a58a965eb73253759f6a3e1c7380392557da89c8)
generated by cgit v1.1 at 2025-09-22 21:08:20 +0000