aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-08nvptx/mkoffload.cc: Add dummy proc for OpenMP rev-offload table [PR108098]Tobias Burnus1-0/+14
Seemingly, the ptx JIT of CUDA <= 10.2 replaces function pointers in global variables by NULL if a translation does not contain any executable code. It works with CUDA 11.1. The code of this commit is about reverse offload; having NULL values disables the side of reverse offload during image load. Solution is the same as found by Thomas for a related issue: Adding a dummy procedure. Cf. the PR of this issue and Thomas' patch "nvptx: Support global constructors/destructors via 'collect2'" https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607749.html As that approach also works here: Co-authored-by: Thomas Schwinge <thomas@codesourcery.com> gcc/ PR libgomp/108098 * config/nvptx/mkoffload.cc (process): Emit dummy procedure alongside reverse-offload function table to prevent NULL values of the function addresses. (cherry picked from commit 4359724cba31b2645f6106266bef019c3d6ef16a)
2023-05-08Daily bump.GCC Administrator2-1/+13
2023-05-07[GCC 13] Fix aarch64/109762: push_options/push_options does not work sometimesAndrew Pinski2-3/+3
aarch64_isa_flags (and aarch64_asm_isa_flags) are both aarch64_feature_flags (uint64_t) but since r12-8000-g14814e20161d, they are saved/restored as unsigned long. This does not make a difference for LP64 targets but on ILP32 and LLP64IL32 targets, it means it does not get restored correctly. This patch changes over to use aarch64_feature_flags instead of unsigned long. Committed as obvious to gcc 13 branch after a bootstrap/test. gcc/ChangeLog: PR target/109762 * config/aarch64/aarch64-builtins.cc (aarch64_simd_switcher::aarch64_simd_switcher): Change argument type to aarch64_feature_flags. * config/aarch64/aarch64-protos.h (aarch64_simd_switcher): Change constructor argument type to aarch64_feature_flags. Change m_old_asm_isa_flags to be aarch64_feature_flags. (cherry picked from commit a1a9ce2441df0675540faee8476523164e12578b)
2023-05-07Daily bump.GCC Administrator2-1/+9
2023-05-06libffi: fix handling of homogeneous float128 structs (#689)Dan Horák1-1/+1
If there is a homogeneous struct with float128 members, they should be copied to vector register save area. The current code incorrectly copies only the value of the first member, not increasing the pointer with each iteration. Fix this. Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0 2023-05-03 Dan Horák <dan@danny.cz> libffi/ PR libffi/109447 * src/powerpc/ffi_linux64.c (ffi_prep_args64): Update arg.f128 pointer. (cherry picked from commit 043550bceea7881163bba5d8a0486bb100a05809)
2023-05-06Daily bump.GCC Administrator5-1/+83
2023-05-05c++: Add testcase for already fixed PR [PR109506]Patrick Palka1-0/+22
The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR. PR c++/109506 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template26.C: New test. (cherry picked from commit 9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e)
2023-05-05OpenACC: Further attach/detach clause fixes for Fortran [PR109622]Julian Brown8-4/+132
This patch moves several tests introduced by the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7 into the proper location for OpenACC testing (thanks to Thomas for spotting my mistake!), and also fixes a few additional problems -- missing diagnostics for non-pointer attaches, and a case where a pointer was incorrectly dereferenced. Tests are also adjusted for vector-length warnings on nvidia accelerators. 2023-04-29 Julian Brown <julian@codesourcery.com> PR fortran/109622 gcc/fortran/ * openmp.cc (resolve_omp_clauses): Add diagnostic for non-pointer/non-allocatable attach/detach. * trans-openmp.cc (gfc_trans_omp_clauses): Remove dereference for pointer-to-scalar derived type component attach/detach. Fix attach/detach handling for descriptors. gcc/testsuite/ * gfortran.dg/goacc/pr109622-5.f90: New test. * gfortran.dg/goacc/pr109622-6.f90: New test. libgomp/ * testsuite/libgomp.fortran/pr109622.f90: Move test... * testsuite/libgomp.oacc-fortran/pr109622.f90: ...to here. Ignore vector length warning. * testsuite/libgomp.fortran/pr109622-2.f90: Move test... * testsuite/libgomp.oacc-fortran/pr109622-2.f90: ...to here. Add missing copyin/copyout variable. Ignore vector length warnings. * testsuite/libgomp.fortran/pr109622-3.f90: Move test... * testsuite/libgomp.oacc-fortran/pr109622-3.f90: ...to here. Ignore vector length warnings. * testsuite/libgomp.oacc-fortran/pr109622-4.f90: New test. (cherry picked from commit 0a26a42b237bada32165e61867a2bf4461c5fab2)
2023-05-05OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]Julian Brown5-9/+135
This patch fixes several cases where multiple attach or detach mapping nodes were being created for stand-alone attach or detach clauses in Fortran. After the introduction of stricter checking later during compilation, these extra nodes could cause ICEs, as seen in the PR. The patch also fixes cases that "happened to work" previously where the user attaches/detaches a pointer to array using a descriptor, and (I think!) the "_data" field has offset zero, hence the same address as the descriptor as a whole. 2023-04-27 Julian Brown <julian@codesourcery.com> PR fortran/109622 gcc/fortran/ * trans-openmp.cc (gfc_trans_omp_clauses): Attach/detach clause fixes. gcc/testsuite/ * gfortran.dg/goacc/attach-descriptor.f90: Adjust expected output. libgomp/ * testsuite/libgomp.fortran/pr109622.f90: New test. * testsuite/libgomp.fortran/pr109622-2.f90: New test. * testsuite/libgomp.fortran/pr109622-3.f90: New test. (cherry picked from commit cacf65d74463600815773255e8b82b4043432bd7)
2023-05-05[libstdc++] [testsuite] xfail double-prec from_chars for ldblAlexandre Oliva2-1/+6
When long double is wider than double, but from_chars is implemented in terms of double, tests that involve the full precision of long double are expected to fail. Mark them as such on aarch64-*-vxworks. for libstdc++-v3/ChangeLog * testsuite/20_util/from_chars/4.cc: Skip long double test06 on aarch64-vxworks. * testsuite/20_util/to_chars/long_double.cc: Xfail run on aarch64-vxworks. (cherry picked from commit e383fc69d2a3eab37319ea41543ee09c8cdd6e57)
2023-05-05Daily bump.GCC Administrator4-1/+143
2023-05-04libstdc++: Document new library version in manualJonathan Wakely2-3/+5
libstdc++-v3/ChangeLog: * doc/xml/manual/abi.xml (abi.versioning.history): Document libstdc++.so.6.0.32 and GLIBCXX_3.4.32 version. * doc/html/manual/abi.html: Regenerate. (cherry picked from commit 2eadfb5c7e26fc362eb76a2d834eea0194e4a6f2)
2023-05-04libstdc++: Mention recent libgcc_s symbol versions in manualFlorian Weimer1-0/+5
GCC_11.0 is an aarch64-specific outlier. libstdc++-v3/ChangeLog: * doc/xml/manual/abi.xml (abi.versioning.history): Add GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for libgcc_s. (cherry picked from commit 9cb3f25460a335a7d150d5de21b9ef4cde2b7dd2)
2023-05-04tree-optimization/109724 - new testcaseRichard Biener1-0/+32
The following adds a testcase for PR109724 which was caused by backporting r13-2375-gbe1b42de9c151d and fixed by r11-199-g2b42509f8b7bdf. PR tree-optimization/109724 * g++.dg/torture/pr109724.C: New testcase. (cherry picked from commit ee99aaae4aeecd55f1d945a959652cf07e3b2e9e)
2023-05-04i386: Fix up handling of debug insns in STV [PR109676]Jakub Jelinek2-4/+51
The following testcase ICEs because STV replaces there (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1 (nil)) with (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1 (nil)) which is invalid because of the mode mismatch. STV has fix_debug_reg_uses function which is supposed to fix this up and adjust such debug insns into (debug_insn 114 47 51 8 (var_location:TI D#3 (subreg:TI (reg:V1TI 91 [ p ]) 0)) -1 (nil)) but it doesn't trigger here. The IL before stv1 has: (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1 (nil)) ... (insn 63 62 64 8 (set (mem/c:TI (reg/f:DI 89 [ .result_ptr ]) [0 <retval>.mStorage+0 S16 A32]) (reg:TI 91 [ p ])) "pr109676.C":4:48 87 {*movti_internal} (expr_list:REG_DEAD (reg:TI 91 [ p ]) (nil))) in bb 8 and (insn 97 96 98 9 (set (reg:TI 91 [ p ]) (mem/c:TI (plus:DI (reg/f:DI 19 frame) (const_int -32 [0xffffffffffffffe0])) [0 p+0 S16 A128])) "pr109676.C":26:12 87 {*movti_internal} (nil)) (insn 98 97 99 9 (set (mem/c:TI (plus:DI (reg/f:DI 19 frame) (const_int -64 [0xffffffffffffffc0])) [0 tmp+0 S16 A128]) (reg:TI 91 [ p ])) "pr109676.C":26:12 87 {*movti_internal} (nil)) in bb9. PUT_MODE on a REG is done in two spots in timode_scalar_chain::convert_insn, one is: switch (GET_CODE (dst)) { case REG: if (GET_MODE (dst) == TImode) { PUT_MODE (dst, V1TImode); fix_debug_reg_uses (dst); } if (GET_MODE (dst) == V1TImode) when seeing the REG in SET_DEST and another one the hunk the patch adjusts. Because bb 8 comes first in the order the pass walks the bbs, we first notice the TImode pseudo on insn 63 where it is SET_SRC, use PUT_MODE there unconditionally, so for a shared REG it changes all other uses in the IL, and then don't call fix_debug_reg_uses because DF_REG_DEF_CHAIN (REGNO (src)) is non-NULL - the REG is set in insn 97 but we haven't processed it yet. Later on we process insn 97, but because the REG in SET_DEST already has V1TImode, we don't do anything, even when the src handling code earlier relied on it being done. The following patch fixes this by using similar code for both dst and src, in particular calling fix_debug_reg_uses once when we actually change REG mode from TImode to V1TImode, and not later on. 2023-05-04 Jakub Jelinek <jakub@redhat.com> PR debug/109676 * config/i386/i386-features.cc (timode_scalar_chain::convert_insn): If src is REG, change its mode to V1TImode and call fix_debug_reg_uses for it only if it still has TImode. Don't decide whether to call fix_debug_reg_uses based on whether SRC is ever set or not. * g++.target/i386/pr109676.C: New test. (cherry picked from commit 3a715d3e136fc4dfdc42cb6a3ee1a7df3e2a171a)
2023-05-04libstdc++: Fix up abi.exp FAILs on powerpc64le-linuxJakub Jelinek3-0/+28
This is an ABI problem on powerpc64le-linux, introduced in 13.1. When libstdc++ is configured against old glibc, the _ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31 _ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31 symbols are exported from the library, while when it is configured against new enough glibc, those symbols aren't exported and we export instead _ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 _ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29 together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and @@CXXABI_IEEE128_1.3.13 symbols. The idea was that those *IEEE128* symbol versions (similarly to *LDBL* symbol versions) are optional (but if it appears, all symbols from it up to the version of the library appears), but the base appears always. My _Float128 from_chars/to_chars changes unfortunately broke this. I believe nothing really uses those symbols if libstdc++ has been configured against old glibc, so if 13.1 wasn't already released, it might be best to make sure they aren't exported on powerpc64le-linux. But as they were exported, I think the best resolution for this ABI difference is to add those 4 symbols as aliases to the GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch does. 2023-05-03 Jakub Jelinek <jakub@redhat.com> * src/c++17/floating_from_chars.cc (_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to _ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format. * src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to _ZSt8to_charsPcS_u9__ieee128. (_ZSt8to_charsPcS_DF128_St12chars_format): New alias to _ZSt8to_charsPcS_u9__ieee128St12chars_format. (_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to _ZSt8to_charsPcS_u9__ieee128St12chars_formati. * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated. (cherry picked from commit b51e2fd65e47e61c09b5fab70d9bb9bfffd0d61e)
2023-05-04libstdc++: Fix up abi.exp FAILs on powerpc64-linuxJakub Jelinek3-275/+6653
As discussed on IRC, my _Float128/_Float64x support changes broke abi.exp testing on powerpc64-linux. The _ZTIDF128_@@CXXABI_1.3.14 _ZTIDF64x@@CXXABI_1.3.14 _ZTIPDF128_@@CXXABI_1.3.14 _ZTIPDF64x@@CXXABI_1.3.14 _ZTIPKDF128_@@CXXABI_1.3.14 _ZTIPKDF64x@@CXXABI_1.3.14 symbols only appear on powerpc64le-linux (both when building against very old glibcs as well as contemporary glibcs), while they don't appear on powerpc64-linux, because the latter never has _Float128 or _Float64x support. But we were using the same baseline_symbols.txt file for both powerpc64-linux and powerpc64le-linux, even when it contained quite a lot of stuff specific to the latter; but that was just the IEEE128 related stuff that appears only when configured against not very old glibc. The following patch keeps those exports as is and just splits the config/abi/post/ files, copies the current one to powerpc64le-linux unmodified and removes the above mentioned symbols plus all GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols from the powerpc64-linux version. 2023-05-03 Jakub Jelinek <jakub@redhat.com> * configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu rather than powerpc64-linux-gnu for powerpc64le*-linux*. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove _ZTI*DF128_, _ZTI*DF64x symbols and symbols in GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol versions. * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New file. (cherry picked from commit a13ea34c6ed45c0c56c256ade77bf5a660365072)
2023-05-04libstdc++: Regenerate baseline_symbols.txt files for LinuxJakub Jelinek8-0/+16
The following patch regenerates the ABI files (I've only changed the Linux files which were updated recently (last month)). 2023-05-02 Jakub Jelinek <jakub@redhat.com> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update. (cherry picked from commit 1d003da715a5cb4bc80e6ecf560f2be1ecd602e0)
2023-05-04ibstdc++: Shut up -Wattribute-alias warning [PR109694]Jakub Jelinek1-0/+2
I've followed what other files do, using attribute alias with not really matching function type (after all, it isn't really possible when it is a constructor), but seems I've missed it warns: ../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void +(std::ios_base::Init::)()’ [-Wattribute-alias=] 203 | void ios_base_library_init (void) | ^~~~~~~~~~~~~~~~~~~~~ ../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here 78 | ios_base::Init::Init() | ^~~~~~~~ The PR talks about clang++ warning there (which I think isn't really supported, libstdc++ sources ought to be built by GCC), but it warns when built with GCC too. The following patch fixes it by doing what other libstdc++ sources do in those cases. 2023-05-02 Jakub Jelinek <jakub@redhat.com> PR libstdc++/109694 * src/c++98/ios_init.cc: Add #pragma GCC diagnostic ignored for -Wattribute-alias. (cherry picked from commit 87de39e4c3686535728f3a347f772e73af4cf262)
2023-05-04libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc ↵Jakub Jelinek6-3/+15
13.2+ libstdc++.so.6 [PR108969] GCC used to emit an instance of an empty ios_base::Init class in every TU which included <iostream> to ensure it is std::cout etc. is initialized, but thanks to Patrick work on some targets (which have init_priority attribute support) it is now initialized only inside of libstdc++.so.6/libstdc++.a. This causes a problem if people do something that has never been supported, try to run GCC 13 compiled C++ code against GCC 12 or earlier libstdc++.so.6 - std::cout etc. are then never initialized because code including <iostream> expects the library to initialize it and the library expects code including <iostream> to do that. The following patch is second attempt to make this work cheaply as the earlier attempt of aliasing the std::cout etc. symbols with another symbol version didn't work out due to copy relocation breaking the aliases appart. The patch forces just a _ZSt21ios_base_library_initv undefined symbol into all *.o files which include <iostream> and while there is no runtime relocation against that, it seems to enforce the right version of libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/ is builddir of trunk without this patch, system g++ is GCC 12.1.1. $ cat /tmp/hw.C #include <iostream> int main () { std::cout << "Hello, world!" << std::endl; } $ cd /home/jakub/src/gcc/obj08i/usr/local/bin $ ./g++ -o /tmp/hw /tmp/hw.C $ readelf -Wa /tmp/hw 2>/dev/null | grep initv 4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4) 71: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 $ /tmp/hw /tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw) $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw /tmp/hw: /home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw) $ g++ -o /tmp/hw /tmp/hw.C $ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw Hello, world! $ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw Hello, world! On sparc-sun-solaris2.11 one I've actually checked a version which had defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but init_priority attribute doesn't seem to be supported there and so I couldn't actually test how this works there. Using gas and Sun ld, Rainer, does one need to use gas + gld for init_priority or something else? 2023-04-28 Jakub Jelinek <jakub@redhat.com> PR libstdc++/108969 * config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export _ZSt21ios_base_library_initv. * testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.32 symver and make it the latestp. * src/c++98/ios_init.cc (ios_base_library_init): New alias. * acinclude.m4 (libtool_VERSION): Change to 6:32:0. * include/std/iostream: If init_priority attribute is supported and _GLIBCXX_SYMVER_GNU, force undefined _ZSt21ios_base_library_initv symbol into the object. * configure: Regenerated. (cherry picked from commit 9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b)
2023-05-04Docs: Add vector register constarint for asm operandsKito Cheng1-0/+9
`vr`, `vm` and `vd` constarint for vector register constarint, those 3 constarint has implemented on LLVM as well. gcc/ChangeLog: * doc/md.texi (RISC-V): Add vr, vm, vd constarint. (cherry picked from commit e8511cbba692a9f3ff4d9c74e902fab03f154bbd)
2023-05-04RISC-V: Fix wrong check of register occurrences [PR109535]Ju-Zhe Zhong3-1/+168
count_occurrences will conly count same RTX (same code and same mode), but what we want to track is the occurrence of a register, a register might appeared in the insn with different mode or contain in SUBREG. Testcase coming from Kito. gcc/ChangeLog: PR target/109535 * config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function. (pass_vsetvl::cleanup_insns): Fix bug. gcc/testsuite/ChangeLog: PR target/109535 * g++.target/riscv/rvv/base/pr109535.C: New test. * gcc.target/riscv/rvv/base/pr109535.c: New test. Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai> Co-authored-by: kito-cheng <kito.cheng@sifive.com> (cherry picked from commit a2d12abedc89a9439fd6aadc38730fdadca0684f)
2023-05-04Daily bump.GCC Administrator3-1/+31
2023-05-03Revert "c++: reorganize friend template matching [PR91618]"Jason Merrill3-49/+61
This patch was just a cleanup after the actual bugfix, so let's revert it on the branch. PR c++/109649 This reverts commit e9d2adc17d0dbe46db67e1b618dea888d5c7aca3.
2023-05-03libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]Kefu Chai1-1/+1
This always sets _M_string_length in the constructor for ranges of input iterators, such as stream iterators. We copy from the source range to the local buffer, and then repeatedly reallocate a larger one if necessary. When disposing the old buffer, _M_is_local() is used to tell if the buffer is the local one or not (and so must be deallocated). In addition to comparing the buffer address with the local buffer, _M_is_local() has an optimization hint so that the compiler knows that for a string using the local buffer, there is an invariant that _M_string_length <= _S_local_capacity (added for PR109299 via r13-6915-gbf78b43873b0b7). But we failed to set _M_string_length in the constructor taking a pair of iterators, so the invariant might not hold, and __builtin_unreachable() is reached. This causes UBsan errors, and potentially misoptimization. To ensure the invariant holds, _M_string_length is initialized to zero before doing anything else, so that _M_is_local() doesn't see an uninitialized value. This issue only surfaces when constructing a string with a range of input iterator, and the uninitialized _M_string_length happens to be greater than _S_local_capacity, i.e., 15 for the std::string specialization. libstdc++-v3/ChangeLog: PR libstdc++/109703 * include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)): Initialize _M_string_length. Signed-off-by: Kefu Chai <kefu.chai@scylladb.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com> (cherry picked from commit cbf6c7a1d16490a1e63e9a5ce00e9a5c44c4c2f2)
2023-05-03c++: Fix up VEC_INIT_EXPR gimplification after r12-7069Jakub Jelinek1-9/+9
During patch backporting, I've noticed that while most cp_walk_tree calls with cp_fold_r callback callers were changed from &pset to cp_fold_data &data, the VEC_INIT_EXPR gimplifications has not, so it still passes just address of a hash_set<tree> and so if during the folding we ever touch data->flags, we use uninitialized data there. The following patch changes it to do the same thing as cp_fold_function because the VEC_INIT_EXPR gimplifications will happen on function bodies only. 2023-05-03 Jakub Jelinek <jakub@redhat.com> * cp-gimplify.cc (cp_fold_data): Move definition earlier. (cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false constructed data rather than &pset to cp_walk_tree with cp_fold_r. (cherry picked from commit 8d193b12d6f07ae0196db8296a49c881c1638c01)
2023-05-03Daily bump.GCC Administrator5-1/+60
2023-05-02Revert "c++: *this folding in constexpr call"Jason Merrill1-6/+5
The earlier commit wasn't fixing a known bug, so let's revert it on the branch. PR c++/109678 This reverts commit 1189c03859cefef4fc4fd44d57eb3d4d3348b562.
2023-05-02c++: array DMI and member fn [PR109666]Jason Merrill5-41/+58
Here it turns out I also needed to adjust cfun when stepping out of the member function to instantiate the DMI. But instead of adding that tweak, let's unify with instantiate_body and just push_to_top_level instead of trying to do the minimum subset of it. There was no measurable change in compile time on stdc++.h. This should also resolve 109506 without yet another tweak. PR c++/109666 gcc/cp/ChangeLog: * name-lookup.cc (maybe_push_to_top_level) (maybe_pop_from_top_level): Split out... * pt.cc (instantiate_body): ...from here. * init.cc (maybe_instantiate_nsdmi_init): Use them. * name-lookup.h: Declare them.. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-array2.C: New test.
2023-05-02c++: fix 'unsigned typedef-name' extension [PR108099]Jason Merrill4-7/+81
In the comments for PR108099 Jakub provided some testcases that demonstrated that even before the regression noted in the patch we were getting the semantics of this extension wrong: in the unsigned case we weren't producing the corresponding standard unsigned type but another distinct one of the same size, and in the signed case we were just dropping it on the floor and not actually returning a signed type at all. The former issue is fixed by using c_common_signed_or_unsigned_type instead of unsigned_type_for, and the latter issue by adding a (signed_p && typedef_decl) case. This patch introduces a failure on std/ranges/iota/max_size_type.cc due to the latter issue, since the testcase expects 'signed rep_t' to do something sensible, and previously we didn't. Now that we do, it exposes a bug in the __max_diff_type::operator>>= handling of sign extension: when we evaluate -1000 >> 2 in __max_diff_type we keep the MSB set, but leave the second-most-significant bit cleared. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also handle 'signed typedef'. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-8.C: New test. * g++.dg/ext/unsigned-typedef2.C: New test. * g++.dg/ext/unsigned-typedef3.C: New test.
2023-05-02c++: Move -Wdangling-reference to -Wextra [PR109642]Marek Polacek2-2/+3
Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving the warning in -Wall in 14 where I think I can write code to detect std::span-like classes. PR c++/109642 PR c++/109640 PR c++/109671 gcc/c-family/ChangeLog: * c.opt (Wdangling-reference): Move from -Wall to -Wextra. gcc/ChangeLog: * doc/invoke.texi: Document that -Wdangling-reference is enabled by -Wextra.
2023-05-02testsuite: adjust NOP expectations for RISC-VJan Beulich3-3/+6
RISC-V will emit ".option nopic" when -fno-pie is in effect, which matches the generic pattern. Just like done for Alpha, special-case RISC-V. gcc/testsuite/ * c-c++-common/patchable_function_entry-decl.c: Special-case RISC-V. * c-c++-common/patchable_function_entry-default.c: Likewise. * c-c++-common/patchable_function_entry-definition.c: Likewise.
2023-05-02Daily bump.GCC Administrator1-1/+1
2023-05-01Daily bump.GCC Administrator1-1/+1
2023-04-30Daily bump.GCC Administrator1-1/+1
2023-04-29Daily bump.GCC Administrator3-1/+96
2023-04-28libstdc++: Fix __max_diff_type::operator>>= for negative valuesPatrick Palka2-3/+12
This patch fixes sign bit propagation when right-shifting a negative __max_diff_type value by more than one, a bug that our existing test coverage didn't expose until r14-159-g03cebd304955a6 fixed the front end's 'signed typedef-name' handling that the test relies on (which is a non-standard extension to the language grammar). libstdc++-v3/ChangeLog: * include/bits/max_size_type.h (__max_diff_type::operator>>=): Fix propagation of sign bit. * testsuite/std/ranges/iota/max_size_type.cc: Avoid using the non-standard 'signed typedef-name'. Add some compile-time tests for right-shifting a negative __max_diff_type value by more than one. (cherry picked from commit 83470a5cd4c3d233e1d55b5e5553e1b9c553bf28)
2023-04-28libstdc++: Improve doxygen docs for <random>Jonathan Wakely2-6/+132
Add @headerfile and @since tags. Add gamma_distribution to the correct group (poisson distributions). Add a group for the sampling distributions and add the missing definitions of their probability functions. Add uniform_int_distribution back to the uniform distributions group. libstdc++-v3/ChangeLog: * include/bits/random.h (gamma_distribution): Add to the right doxygen group. (discrete_distribution, piecewise_constant_distribution) (piecewise_linear_distribution): Create a new doxygen group and fix the incomplete doxygen comments. * include/bits/uniform_int_dist.h (uniform_int_distribution): Add to doxygen group. (cherry picked from commit d711f8f81fc5f3a5a0420337f414bce93e1cad1e)
2023-04-28libstdc++: Minor fixes to doxygen commentsJonathan Wakely6-11/+10
libstdc++-v3/ChangeLog: * include/bits/uses_allocator.h: Add missing @file comment. * include/bits/regex.tcc: Remove stray doxygen comments. * include/experimental/memory_resource: Likewise. * include/std/bit: Tweak doxygen @cond comments. * include/std/expected: Likewise. * include/std/numbers: Likewise. (cherry picked from commit 30f6aace7fe5c535af41a1f08ab00dc14fedf02d)
2023-04-28libstdc++: Strip absolute paths from files shown in Doxygen docsJonathan Wakely1-1/+2
This avoids showing absolute paths from the expansion of @srcdir@/libsupc++/ in the doxygen File List view. libstdc++-v3/ChangeLog: * doc/doxygen/user.cfg.in (STRIP_FROM_PATH): Remove prefixes from header paths. (cherry picked from commit 975e8e836ead0e9055a125a2a23463db5d847cb3)
2023-04-28libstdc++: Simplify preprocessor/namespace nesting in <bits/move.h>Jonathan Wakely1-9/+2
There's no good reason to conditionally close and reopen namespace std within an #if block. Just include the <type_traits> header at the top instead. libstdc++-v3/ChangeLog: * include/bits/move.h: Simplify opening/closing namespace std. (cherry picked from commit 5c8b154c56a65faf64dfc5f8852e801150cb2f26)
2023-04-28libstdc++: Improve doxygen docs for <memory_resource>Jonathan Wakely2-0/+75
libstdc++-v3/ChangeLog: * include/bits/memory_resource.h: Improve doxygen comments. * include/std/memory_resource: Likewise. (cherry picked from commit afcf2b09b8317d2777f44e830c3b8de1791312d5)
2023-04-28libstdc++: Add @headerfile and @since to doxygen comments [PR40380]Jonathan Wakely16-8/+87
libstdc++-v3/ChangeLog: PR libstdc++/40380 * include/bits/basic_string.h: Improve doxygen comments. * include/bits/cow_string.h: Likewise. * include/bits/forward_list.h: Likewise. * include/bits/fs_dir.h: Likewise. * include/bits/fs_path.h: Likewise. * include/bits/quoted_string.h: Likewise. * include/bits/stl_bvector.h: Likewise. * include/bits/stl_map.h: Likewise. * include/bits/stl_multimap.h: Likewise. * include/bits/stl_multiset.h: Likewise. * include/bits/stl_set.h: Likewise. * include/bits/stl_vector.h: Likewise. * include/bits/unordered_map.h: Likewise. * include/bits/unordered_set.h: Likewise. * include/std/filesystem: Likewise. * include/std/iomanip: Likewise. (cherry picked from commit 865869dc6943eb5dee855bc1ea88b09b7dabc641)
2023-04-28amdgcn: Fix addsub bugAndrew Stubbs1-8/+15
The vec_fmsubadd instuction actually had add twice, by mistake. Also improve code-gen for all the complex patterns by using properly undefined values. Mostly this just prevents the compiler reserving space in the stack frame. gcc/ChangeLog: * config/gcn/gcn-valu.md (cmul<conj_op><mode>3): Use gcn_gen_undef. (cml<addsub_as><mode>4): Likewise. (vec_addsub<mode>3): Likewise. (cadd<rot><mode>3): Likewise. (vec_fmaddsub<mode>4): Likewise. (vec_fmsubadd<mode>4): Likewise, and use sub for the odd lanes. (cherry picked from commit b17c57b06d90f2ca12ea0395046c4ea7d439065f)
2023-04-28Daily bump.GCC Administrator5-1/+72
2023-04-27Update gcc .po filesJoseph Myers19-37123/+37682
* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po, ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.
2023-04-27libstdc++: Fix typos in doxygen commentsJonathan Wakely2-4/+3
libstdc++-v3/ChangeLog: * include/bits/mofunc_impl.h: Fix typo in doxygen comment. * include/std/format: Likewise. (cherry picked from commit 481281ccf41aa2bc596e548edaad4e57833f3340)
2023-04-27libstdc++: Reduce Doxygen output for PDFJonathan Wakely6-1/+11
Including the header source code in the doxygen-generated PDF file makes it too large, and causes pdflatex to run out of memory. If we only set SOURCE_BROWSER=YES for the HTML docs then we won't include the sources in the PDF file. There are several macros defined for std::valarray that are only used to generate repetitive code and then #undef'd. Those aren't useful in the doxygen docs, especially the ones that reuse the same name in different files. Omitting them avoids warnings about duplicate labels in the refman.tex file. libstdc++-v3/ChangeLog: * doc/doxygen/user.cfg.in (SOURCE_BROWSER): Only set to YES for HTML docs. * include/bits/gslice_array.h (_DEFINE_VALARRAY_OPERATOR): Omit from doxygen docs. * include/bits/indirect_array.h (_DEFINE_VALARRAY_OPERATOR): Likewise. * include/bits/mask_array.h (_DEFINE_VALARRAY_OPERATOR): Likewise. * include/bits/slice_array.h (_DEFINE_VALARRAY_OPERATOR): Likewise. * include/std/valarray (_DEFINE_VALARRAY_UNARY_OPERATOR) (_DEFINE_VALARRAY_AUGMENTED_ASSIGNMENT) (_DEFINE_VALARRAY_EXPR_AUGMENTED_ASSIGNMENT) (_DEFINE_BINARY_OPERATOR): Likewise. (cherry picked from commit afa69618d1627435841c9164b019ef98000e0365)
2023-04-27c: Fix up error-recovery on non-empty VLA initializers [PR109409]Jakub Jelinek2-4/+17
On the following testcase we ICE, because after we emit the variable-sized object may not be initialized except with an empty initializer error we don't really reset the initializer to error_mark_node and then at -Wformat checking time we ICE on seeing STRING_CST initializer for a VLA. The following patch just arranges for error_mark_node to be returned after the error diagnostics. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/109409 * c-parser.cc (c_parser_initializer): Move diagnostics about initialization of variable sized object with non-empty initializer after c_parser_expr_no_commas call and ret.set_error (); after it. * gcc.dg/pr109409.c: New test. (cherry picked from commit d8842271ebf9a81128df9ae80e1d3b688749eac8)
2023-04-27c: Fix up error-recovery on functions initialized as variables [PR109412]Jakub Jelinek2-0/+25
The change to allow empty initializers in C broke error-recovery on the following testcase. We are emitting function %qD is initialized like a variable error early; if the initializer is non-empty, we just emit another error that the initializer is invalid. Previously if it was empty, we'd emit another error that scalar is being initialized by empty initializer (not really correct), but now we instead just try to build_zero_cst for the FUNCTION_TYPE and ICE on it. The following patch just emits the same diagnostics for the empty initializers as we emit for the non-empty ones. 2023-04-27 Jakub Jelinek <jakub@redhat.com> PR c/107682 PR c/109412 * c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE, reject empty initializer as invalid. * gcc.dg/pr109412.c: New test. (cherry picked from commit a1030fbf70eef5b635e4fbb904ec7209ebd137ca)
generated by cgit v1.1 at 2025-09-24 07:23:10 +0000