aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-19Fortran: F2018 rounding modes changesFrancois-Xavier Coudert9-12/+88
Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets, but could be supported by glibc and AIX as part of the C2x proposal. Testing for now is minimal. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support radices other than 2. 2022-08-31 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> gcc/fortran/ * libgfortran.h: Declare GFC_FPE_AWAY. gcc/testsuite/ * gfortran.dg/ieee/rounding_2.f90: New test. libgfortran/ * ieee/ieee_arithmetic.F90: Add RADIX argument to IEEE_SET_ROUNDING_MODE and IEEE_GET_ROUNDING_MODE. * config/fpu-387.h: Add IEEE_AWAY mode. * config/fpu-aarch64.h: Add IEEE_AWAY mode. * config/fpu-aix.h: Add IEEE_AWAY mode. * config/fpu-generic.h: Add IEEE_AWAY mode. * config/fpu-glibc.h: Add IEEE_AWAY mode. * config/fpu-sysv.h: Add IEEE_AWAY mode.
2022-09-19Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit intsGeorg-Johann Lay1-50/+0
this patch fixed PR target/99184 which incorrectly rounded during 64-bit (long) double to 16-bit and 32-bit integers. The patch just removes the respective roundings from libf7-asm.sx::to_integer and ::to_unsigned. Luckily, LibF7 does nowhere use respective functions internally, the only user is in libf7.c::f7_exp which reads f7_round (qq, qq); int16_t q = f7_get_s16 (qq); so that f7_get_s16() operates on an already rounded value, and therefore this code works unaltered with or without rounding in to_integer. PR target/99184 libgcc/config/avr/libf7/ * libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit and 32-bit integers.
2022-09-19Daily bump.GCC Administrator4-1/+83
2022-09-18OpenMP: Push attaches to end of clause list in "target" regionsJulian Brown2-2/+37
This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes to the end of the clause list, for offload regions. This ensures that when we do the attach operation, both the "attachment point" and the target region have both already been mapped on the target. This avoids a pathological case that can otherwise happen with struct sibling-list handling. This version of the patch moves the attach-node motion to gimplify_adjust_omp_clauses. 2022-09-15 Julian Brown <julian@codesourcery.com> gcc/ * gimplify.cc (omp_segregate_mapping_groups): Update comment. (gimplify_adjust_omp_clauses): Move ATTACH and ATTACH_ZERO_LENGTH_ARRAY_SECTION nodes to the end of the clause list for offloaded OpenMP regions. gcc/testsuite/ * g++.dg/gomp/target-lambda-1.C: Adjust expected scan output.
2022-09-18Remove dependency on uintptr_t in libgccThomas Neumann2-42/+45
uintptr_t is no available for all targets, use __UINTPTR_TYPE__ instead. libgcc/ChangeLog: * unwind-dw2-fde.c: Replace uintptr_t with typedef for __UINTPTR_TYPE__. * unwind-dw2-btree.h: Likewise.
2022-09-18RISC-V: Don't try to vectorize tree-ssa/gen-vect-34.cPalmer Dabbelt1-1/+1
We don't yet support vectorization on RISC-V. gcc/testsuite/ChangeLog * gcc.dg/tree-ssa/gen-vect-34.c: Skip RISC-V targets.
2022-09-18[PR106831] Avoid propagating long doubles that may have multiple ↵Jakub Jelinek1-0/+15
representations. Long doubles are tricky when it comes to considering singletons because small numbers and +-INF can have multiple representations for the same number. So we need to be very careful not to treat those as singletons, lest they be incorrectly propagated by VRP. This is similar to the -0.0 and +0.0 duality. In long doubles +INF can be represented with +INF in the MSB and either -0.0 or +0.0 in the LSB. Similarly for numbers that are exactly representable in DF. For example, 1.0 can be represented as either (1.0, +0.0) or (1.0, -0.0). This patch avoids treating these numbers as singletons. Note that NANs in long double format have a LSB of don't care, but this is irrelevant for singleton_p, because NANs are never considered singletons. Also, internally in the frange we store NANs as a pair of boolean flags indicating whether they are +NAN or -NAN, so we don't need any special treatment here for comparing range equality etc. We never see anything but the boolean flags. PR middle-end/106831 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Avoid propagating long doubles that may have multiple representations.
2022-09-18Rewrite NAN and sign handling in frangeAldy Hernandez9-485/+481
The attatched patch rewrites the NAN and sign handling, dropping both tristates in favor of a pair of boolean flags for NANs, and nothing at all for signs. The signs are tracked in the range itself, so now it's possible to describe things like [-0.0, +0.0] +NAN, [+0, +0], [-5, +0], [+0, 3] -NAN, etc. Here is an example of the various ranges and how they are displayed: [frange] float VARYING NAN ;; Varying includes NAN [frange] UNDEFINED ;; Empty set as always [frange] float [] +-NAN ;; Unknown sign NAN [frange] float [] -NAN ;; -NAN [frange] float [] +NAN ;; +NAN [frange] float [-0.0, 0.0] ;; All zeros. [frange] float [-0.0, -0.0] +-NAN ;; -0 or NAN. [frange] float [-5.0e+0, -1.0e+0] +NAN ;; [-5, -1] or +NAN [frange] float [-5.0e+0, -0.0] +-NAN ;; [-5, -0] or NAN [frange] float [-5.0e+0, -0.0] ;; [-5, -0] [frange] float [5.0e+0, 1.0e+1] ;; [5, 10] Notice the NAN signs are decoupled from the range, so we can represent a negative range with a positive NAN. For this range, frange::signbit_p() would return false, as only when the signs of the NANs and range agree can we be certain. There is no longer any pessimization of ranges for intersects involving NANs. Also, union and intersect work with signed zeros: // [-0, x] U [+0, x] => [-0, x] // [ x, -0] U [ x, +0] => [ x, +0] // [-0, x] ^ [+0, x] => [+0, x] // [ x, -0] ^ [ x, +0] => [ x, -0] The special casing for signed zeros in the singleton code is gone in favor of just making sure the signs in the range agree, that is [-0, -0] for example. I have removed the idea that a known NAN is a "range", so a NAN is no longer in the endpoints itself. Requesting the bound of a known NAN is a hard fail. For that matter, we don't store the actual NAN in the range. The only information we have are the set of boolean flags. This way we make sure nothing seeps into the frange. This also means it's explicit that we don't track anything but the sign in NANs. We can revisit this if we desire to track signalling or whatever concoction y'all can imagine. Regstrapped with mpfr tests on x86-64 and ppc64le Linux. Selftests were also run with -ffinite-math-only on x86-64. At Jakub's suggestion, I built lapack with associated tests. They pass on x86-64 and ppc64le Linux with no regressions from mainline. As a sanity check, I also ran them for -ffinite-math-only on x86 which (as expected) returned: NaN arithmetic did not perform per the ieee spec Otherwise, all tests pass for -ffinite-math-only. gcc/ChangeLog: * range-op-float.cc (frange_add_zeros): Replace set_signbit with union of zero. * value-query.cc (range_query::get_tree_range): Remove set_signbit use. * value-range-pretty-print.cc (vrange_printer::print_frange_prop): Remove. (vrange_printer::print_frange_nan): New. * value-range-pretty-print.h (print_frange_prop): Remove. (print_frange_nan): New. * value-range-storage.cc (frange_storage_slot::set_frange): Set kind and NAN fields. (frange_storage_slot::get_frange): Restore kind and NAN fields. * value-range-storage.h (class frange_storage_slot): Add kind and NAN fields. * value-range.cc (frange::update_nan): Remove. (frange::set_signbit): Remove. (frange::set): Adjust for NAN fields. (frange::normalize_kind): Remove m_props. (frange::combine_zeros): New. (frange::union_nans): New. (frange::union_): Handle new NAN fields. (frange::intersect_nans): New. (frange::intersect): Handle new NAN fields. (frange::operator=): Same. (frange::operator==): Same. (frange::contains_p): Same. (frange::singleton_p): Remove special case for signed zeros. (frange::verify_range): Adjust for new NAN fields. (frange::set_zero): Handle signed zeros. (frange::set_nonnegative): Same. (range_tests_nan): Adjust tests. (range_tests_signed_zeros): Same. (range_tests_signbit): Same. (range_tests_floats): Same. * value-range.h (class fp_prop): Remove. (FP_PROP_ACCESSOR): Remove. (class frange_props): Remove (frange::lower_bound): NANs don't have endpoints. (frange::upper_bound): Same. (frange_props::operator==): Remove. (frange_props::union_): Remove. (frange_props::intersect): Remove. (frange::update_nan): New. (frange::clear_nan): New. (frange::undefined_p): New. (frange::set_nan): New. (frange::known_finite): Adjust for new NAN representation. (frange::maybe_isnan): Same. (frange::known_isnan): Same. (frange::signbit_p): Same. * gimple-range-fold.cc (range_of_builtin_int_call): Rename known_signbit_p into signbit_p.
2022-09-18Daily bump.GCC Administrator4-1/+31
2022-09-17Fix unsigned comparison warningJan-Benedict Glaw1-1/+1
When -mfloat-abi=hard support was added, a cast went missing that used to silence a warning in common code: /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o builtins.o -MT builtins.o -MMD -MP -MF ./.deps/builtins.TPo ../../gcc/gcc/builtins.cc In file included from ./tm.h:21, from ../../gcc/gcc/backend.h:28, from ../../gcc/gcc/builtins.cc:27: ../../gcc/gcc/builtins.cc: In function 'int apply_args_size()': ../../gcc/gcc/config/csky/csky.h:421:13: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits] 421 | (((REGNO) >= CSKY_FIRST_PARM_REGNUM \ ../../gcc/gcc/builtins.cc:1444:13: note: in expansion of macro 'FUNCTION_ARG_REGNO_P' 1444 | if (FUNCTION_ARG_REGNO_P (regno)) | ^~~~~~~~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors make[1]: *** [Makefile:1146: builtins.o] Error 1 The needed (int) cast is even mentioned in the comment above, so reinstate it here. gcc/ChangeLog: * config/csky/csky.h (FUNCTION_ARG_REGNO_P): Cast REGNO to (int) to prevent warning.
2022-09-17c++: modules ICE with typename friendPatrick Palka3-2/+20
A couple of xtreme-header-* modules tests began ICEing in C++23 mode ever since r13-2650-g5d84a4418aa962 which introduced into <ranges> a dependently scoped friend declaration: friend /* typename */ _OuterIter::value_type; This happens because the streaming code assumes a TYPE_P friend must be a class type, but here it's a TYPENAME_TYPE, which doesn't have a TEMPLATE_INFO or CLASSTYPE_BEFRIENDING_CLASSES. This patch tries to correct this in a minimal way. gcc/cp/ChangeLog: * module.cc (friend_from_decl_list): Don't consider CLASSTYPE_TEMPLATE_INFO for a TYPENAME_TYPE friend. (trees_in::read_class_def): Don't add to CLASSTYPE_BEFRIENDING_CLASSES for a TYPENAME_TYPE friend. gcc/testsuite/ChangeLog: * g++.dg/modules/typename-friend_a.C: New test. * g++.dg/modules/typename-friend_b.C: New test.
2022-09-17reassoc: Fix up recent regression in optimize_range_tests_cmp_bitwise [PR106958]Jakub Jelinek2-3/+19
As the following testcase reduced from glibc fmtmsg.c shows (it doesn't ICE on x86_64/i686 unfortunately, but does on various other arches), my last optimize_range_tests_cmp_bitwise change wasn't fully correct. The intent was to let all pointer operands be cast to pointer_sized_int_node first in addition to the other casts (to type1) which are done for id >= l cases. But one spot I've touched used always cast to type1 (note, the (b % 4) == 3 case is impossible for pointer operands because that is for !TYPE_UNSIGNED operands and pointers are TYPE_UNSIGNED) and in the other spot the cast would be done only for id >= l if not useless, but for pointers we need to cast it always. 2022-09-17 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/106958 * tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): If id >= l, cast op to type1, otherwise to pointer_sized_int_node. If type has pointer type, cast exp to pointer_sized_int_node even when id < l. * gcc.c-torture/compile/pr106958.c: New test.
2022-09-17Daily bump.GCC Administrator6-1/+162
2022-09-16Fix for an AutoFDO test.Eugene Rozenfeld1-3/+3
After https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c17975d81aaed49ff759c20c68b31304a6953d58 the expected inlining in indir-call--prof-2.c test happens during afdo phase instead of einline. This patch adjusts the test accordingly. gcc/testsuite/ChangeLog: * gcc.dg/tree-prof/indir-call-prof-2.c: Fix dg-final-use-autofdo.
2022-09-17eliminate mutex in fast path of __register_frameThomas Neumann3-51/+1098
The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is somewhat expensive even if single-threaded. There was already a fast-path that avoided taking the mutex if no frame was registered at all. This commit eliminates both the mutex and the sorted list from the atomic fast path, and replaces it with a btree that uses optimistic lock coupling during lookup. This allows for fully parallel unwinding and is essential to scale exception handling to large core counts. libgcc/ChangeLog: * unwind-dw2-fde.c (release_registered_frames): Cleanup at shutdown. (__register_frame_info_table_bases): Use btree in atomic fast path. (__deregister_frame_info_bases): Likewise. (_Unwind_Find_FDE): Likewise. (base_from_object): Make parameter const. (classify_object_over_fdes): Add query-only mode. (get_pc_range): Compute PC range for lookup. * unwind-dw2-fde.h (last_fde): Make parameter const. * unwind-dw2-btree.h: New file.
2022-09-16libstdc++: Add preprocessor conditions for freestanding [PR106953]Jonathan Wakely15-52/+114
This adds checks for _GLIBCXX_HOSTED to a number of headers which are not currently installed for freestanding, but need to be for P1642R11 support. For example, <iterator> needs to be installed for C++23 freestanding mode, but without stream iterators and streambuf iterators. Similarly, <memory> needs to be installed, but without std::allocator and std::shared_ptr. This change disables the non-freestanding parts of those headers. libstdc++-v3/ChangeLog: PR libstdc++/106953 * include/backward/auto_ptr.h [!_GLIBCXX_HOSTED]: Do not define shared_ptr members. * include/bits/alloc_traits.h [!_GLIBCXX_HOSTED]: Do not declare std::allocator_traits<std::allocator<T>> specializations for freestanding. * include/bits/memoryfwd.h [!_GLIBCXX_HOSTED] (allocator): Do not declare for freestanding. * include/bits/stl_algo.h [!_GLIBCXX_HOSTED] (stable_partition): Do not define for freestanding. [!_GLIBCXX_HOSTED] (merge, stable_sort): Do not use temporary buffers for freestanding. * include/bits/stl_algobase.h [!_GLIBCXX_HOSTED]: Do not declare streambuf iterators and overloaded algorithms using them. * include/bits/stl_uninitialized.h [!_GLIBCXX_HOSTED]: Do not define specialized overloads for std::allocator. * include/bits/unique_ptr.h [!_GLIBCXX_HOSTED] (make_unique) (make_unique_for_overwrite, operator<<): Do not define for freestanding. * include/c_global/cstdlib [!_GLIBCXX_HOSTED] (_Exit): Declare. Use _GLIBCXX_NOTHROW instead of throw(). * include/debug/assertions.h [!_GLIBCXX_HOSTED]: Ignore _GLIBCXX_DEBUG for freestanding. * include/debug/debug.h [!_GLIBCXX_DEBUG]: Likewise. * include/std/bit [!_GLIBCXX_HOSTED]: Do not use the custom __int_traits if <ext/numeric_traits.h> is available. * include/std/functional [!_GLIBCXX_HOSTED]: Do not include headers that aren't valid for freestanding. (boyer_moore_searcher, boyer_moore_horspool_searcher): Do not define for freestanding. * include/std/iterator [!_GLIBCXX_HOSTED]: Do not include headers that aren't valid for freestanding. * include/std/memory [!_GLIBCXX_HOSTED]: Likewise. * include/std/ranges [!_GLIBCXX_HOSTED] (istream_view): Do not define for freestanding. (views::__detail::__is_basic_string_view) [!_GLIBCXX_HOSTED]: Do not define partial specialization for freestanding.
2022-09-16libstdc++: Move allocator-related helpers to <bits/alloc_traits.h>Jonathan Wakely3-54/+48
The __alloc_swap and __shrink_to_fit_aux helpers are not specific to std::allocator, so don't belong in <bits/allocator.h>. This also simplifies enabling <memory> for freestanding, as now we can just omit the whole of <bits/allocator.h> for freestanding. libstdc++-v3/ChangeLog: * include/bits/alloc_traits.h (__alloc_swap) (__shrink_to_fit_aux): Move here, from ... * include/bits/allocator.h: ... here. * include/ext/alloc_traits.h: Do not include allocator.h.
2022-09-16libstdc++: Make more internal headers include their own dependenciesJonathan Wakely5-2/+8
This adds required headers to a few internal headers that currently assume their deps will be included first. It's more robust to make them include their own dependencies, so that later refactoring or reuse of those headers in new contexts doesn't break. libstdc++-v3/ChangeLog: * include/bits/stl_algo.h: Include <bits/stl_algobase.h>. * include/bits/stl_tempbuf.h: Include headers for __try and __catch macros, std::pair, and __gnu_cxx::__numeric_traits. * include/bits/stream_iterator.h: Include <iosfwd> and headers for std::addressof and std::iterator. * include/bits/streambuf_iterator.h: Include header for std::iterator. * include/std/iterator: Do not include <iosfwd>.
2022-09-16libstdc++: Fix compare_exchange_padding.cc test for std::atomic_refJonathan Wakely1-5/+6
This test was written assuming that std::atomic_ref clears its target's padding on construction, but that could introduce data races. Change the test to store a value after construction and check that its padding is cleared by the store. libstdc++-v3/ChangeLog: * testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc: Store value with non-zero padding bits after construction.
2022-09-16c++: 'mutable' member within constexpr [PR92505]Patrick Palka3-4/+32
This patch permits accessing 'mutable' members of local objects during constexpr evaluation, while continuing to reject it for global objects (as in the last line of cpp0x/constexpr-mutable1.C). To distinguish between the two cases, it looks like it suffices to just check CONSTRUCTOR_MUTABLE_POSION in cxx_eval_component_reference before deciding to reject a DECL_MUTABLE_P member access. PR c++/92505 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_component_reference): Check non_constant_p sooner. In C++14 or later, reject a DECL_MUTABLE_P member access only if CONSTRUCTOR_MUTABLE_POISION is also set. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-mutable3.C: New test. * g++.dg/cpp1y/constexpr-mutable1.C: New test.
2022-09-16libstdc++: Fix tr1::variate_generator::engine_value_typeJonathan Wakely3-83/+83
The tr1/5_numerical_facilities/random/variate_generator/37986.cc test fails for strict -std=c++98 mode because _Adaptor(const _Engine&) is ill-formed in C++98 when _Engine is a reference type. Rather than attempt to make the _Adaptor handle references and pointers, just strip references and pointers from the _Engine type before we adapt it. That removes the need for the _Adaptor<_Engine*> partial specialization and avoids the reference-to-reference problem for c++98 mode. While looking into this I noticed that the TR1 spec requires the variate_generator<E,D>::engine_value_type to be the underlying engine type, whereas we make it the _Adaptor<E> type that wraps the engine. libstdc++-v3/ChangeLog: * include/tr1/random.h (__detail::_Adaptor::_BEngine): Remove. (__detail::_Adaptor::_M_g): Make public. (__detail::_Adaptor<_Engine*, _Dist>): Remove partial specialization. (variate_generate::_Value): New helper to simplify handling of _Engine* and _Engine& template arguments. (variate_generate::engine_value_type): Define to underlying engine type, not adapted type. (variate_generate::engine()): Return underlying engine instead of adaptor. * testsuite/tr1/5_numerical_facilities/random/variate_generator/37986.cc: Fix comment. * testsuite/tr1/5_numerical_facilities/random/variate_generator/requirements/typedefs.cc: Check member typedefs have the correct types.
2022-09-16libstdc++: Do not use nullptr in C++03-compatible codeJonathan Wakely1-2/+1
This has to be valid as C++98/C++03. libstdc++-v3/ChangeLog: * include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE] (_Error_formatter): Use 0 as null pointer constant.
2022-09-16libstdc++: Remove __alloc_neq helperJonathan Wakely2-20/+2
This class template and partial specialization were added 15 years ago to optimize allocator equality comparisons in std::list. I think it's safe to assume that GCC is now capable of optimizing an inline operator!= that just returns false at least as well as an inline member function that just returns false. libstdc++-v3/ChangeLog: * include/bits/allocator.h (__alloc_neq): Remove. * include/bits/stl_list.h (list::_M_check_equal_allocators): Compare allocators directly, without __alloc_neq.
2022-09-16libstdc++: Fix Doxygen commandsJonathan Wakely2-1/+3
Remove the bogus -D__allocator_base=std::__new_allocator macro definition for Doxygen, because that's an alias template for C++11 and later, not a macro. Fix the @cond/@endcond pair that span the end of an @addtogroup group. Add another @endcond inside the group, and another @cond after it. libstdc++-v3/ChangeLog: * doc/doxygen/user.cfg.in (PREDEFINED): Remove __allocator_base. * include/bits/allocator.h: Fix nesting of Doxygen commands.
2022-09-16c++: member fn in omp loc list [PR106858]Jason Merrill4-5/+18
this-f names a member function, which isn't an addressable lvalue. Give a helpful error instead of crashing. The first hunk makes the error range cover the whole expression. PR c++/106858 gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_var_list_no_open): Pass the initial token location down. * semantics.cc (finish_omp_clauses): Check invalid_nonstatic_memfn_p. * typeck.cc (invalid_nonstatic_memfn_p): Handle null TREE_TYPE. gcc/testsuite/ChangeLog: * g++.dg/gomp/map-3.C: New test.
2022-09-16libstdc++: Document new libstdc++.so symbol versionsJonathan Wakely2-1/+3
libstdc++-v3/ChangeLog: * doc/xml/manual/abi.xml: Document GLIBCXX_3.4.30 and GLIBCXX_3.4.31 versions. * doc/html/manual/abi.html: Regenerate.
2022-09-16Modernize ix86_builtin_vectorized_function with corresponding expanders.liuhongt2-181/+84
For ifloor/lfloor/iceil/lceil/irint/lrint/iround/lround when size of in_mode is not equal out_mode, vectorizer doesn't go to internal fn way,still left that part in the ix86_builtin_vectorized_function. Remove others builtins and add corresponding expanders. gcc/ChangeLog: PR target/106910 * config/i386/i386-builtins.cc (ix86_builtin_vectorized_function): Modernized with corresponding expanders. * config/i386/sse.md (lrint<mode><sseintvecmodelower>2): New expander. (floor<mode>2): Ditto. (lfloor<mode><sseintvecmodelower>2): Ditto. (ceil<mode>2): Ditto. (lceil<mode><sseintvecmodelower>2): Ditto. (btrunc<mode>2): Ditto. (lround<mode><sseintvecmodelower>2): Ditto. (exp2<mode>2): Ditto.
2022-09-16Daily bump.GCC Administrator14-1/+160
2022-09-15libstdc++: Remove unnecessary header from <memory>Jonathan Wakely1-1/+0
Previously <memory> included <bits/stl_algobase.h> so that std::copy, std::fill etc. could be used by <bits/stl_uninitialized.h>. But that includes it explicitly now, so that it can be compiled as a header unit. There's no need to include it in <memory>, where its purpose isn't obvious. libstdc++-v3/ChangeLog: * include/std/memory: Do not include <bits/stl_algobase.h>.
2022-09-15Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857]Harald Anlauf2-1/+13
gcc/fortran/ChangeLog: PR fortran/106857 * simplify.cc (gfc_simplify_pack): Check for NULL pointer dereferences while walking through constructors (error recovery). gcc/testsuite/ChangeLog: PR fortran/106857 * gfortran.dg/pr106857.f90: New test.
2022-09-15Fortran: error recovery for bad deferred character length assignment [PR104314]Harald Anlauf2-0/+10
gcc/fortran/ChangeLog: PR fortran/104314 * resolve.cc (deferred_op_assign): Do not try to generate temporary for deferred character length assignment if types do not agree. gcc/testsuite/ChangeLog: PR fortran/104314 * gfortran.dg/pr104314.f90: New test. Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
2022-09-15float.h: Do not define INFINITY for C2x when infinities not supportedJoseph Myers3-3/+14
C2x has changed the rules for defining INFINITY in <float.h> so it is no longer defined when float does not support infinities, instead of being defined to an expression that overflows at translation time. Thus, make the definition conditional on __FLT_HAS_INFINITY__ (this is already inside a C2x-conditional part of <float.h>, because previous C standard versions only had this macro in <math.h>). Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also did a spot test of the case of no infinities supported by building cc1 for vax-netbsdelf and testing compiling the new c2x-float-11.c test with it. gcc/ * ginclude/float.h (INFINITY): Define only if [__FLT_HAS_INFINITY__]. gcc/testsuite/ * gcc.dg/c2x-float-2.c: Require inff effective-target. * gcc.dg/c2x-float-11.c: New test.
2022-09-15libstdc++: Tweak TSan annotations for std::atomic<shared_ptr<T>>Jonathan Wakely1-11/+15
Do not use the __tsan_mutex_not_static flag for annotation functions where it's not a valid flag. Also use the try_lock and try_lock_failed flags to more precisely annotate the CAS loop used to acquire a lock. libstdc++-v3/ChangeLog: * include/bits/shared_ptr_atomic.h (_GLIBCXX_TSAN_MUTEX_PRE_LOCK): Replace with ... (_GLIBCXX_TSAN_MUTEX_TRY_LOCK): ... this, add try_lock flag. (_GLIBCXX_TSAN_MUTEX_TRY_LOCK_FAILED): New macro using try_lock_failed flag (_GLIBCXX_TSAN_MUTEX_POST_LOCK): Rename to ... (_GLIBCXX_TSAN_MUTEX_LOCKED): ... this. (_GLIBCXX_TSAN_MUTEX_PRE_UNLOCK): Remove invalid flag. (_GLIBCXX_TSAN_MUTEX_POST_UNLOCK): Remove invalid flag. (_Sp_atomic::_Atomic_count::lock): Use new macros.
2022-09-15libstdc++: Implement ranges::chunk_by_view from P2443R1Patrick Palka4-37/+290
libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__adjacent_find_fn, adjacent_find): Move to ... * include/bits/ranges_util.h: ... here. * include/std/ranges (chunk_by_view): Define. (chunk_by_view::_Iterator): Define. (__detail::__can_chunk_by_view): Define. (_ChunkBy, chunk_by): Define. * testsuite/std/ranges/adaptors/chunk_by/1.cc: New test.
2022-09-15libstdc++: [_GLIBCXX_INLINE_VERSION] Fix test dg-prune-outputFrançois Dumont1-1/+1
libstdc++-v3/ChangeLog: * testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc: Adapt dg-prune-output to _GLIBCXX_INLINE_VERSION mode.
2022-09-15libstdc++: [_GLIBCXX_INLINE_VERSION] Cleanup gnu-versioned-namespace.verFrançois Dumont1-11/+0
Remove expressions for symbols in std::__detail::__8 namespace, they are obsolete since version namespace applies only at std:: level, not at sub-levels. libstdc++-v3/ChangeLog: * config/abi/pre/gnu-versioned-namespace.ver: Remove obsolete std::__detail::__8 symbols.
2022-09-15MAINTAINERS: Add myself to Write After ApprovalTorbjörn SVENSSON1-0/+1
ChangeLog: * MAINTAINERS (Write After Approval): Add myself.
2022-09-15tree-optimization/106922 - PRE and virtual operand translationRichard Biener2-6/+103
PRE implicitely keeps virtual operands at the blocks incoming version but the explicit updating point during PHI translation fails to trigger when there are no PHIs at all in a block. Later lazy updating then fails because of a too lose block check. A similar issues plagues reference invalidation when checking the ANTIC_OUT to ANTIC_IN translation. The following fixes both and makes the lazy updating work. The diagnostic testcase unfortunately requires boost so the testcase is the one I reduced for a missed optimization in PRE. The testcase fails with -m32 on x86_64 because we optimize too much before PRE which causes PRE to not trigger so we fail to eliminate a full redundancy. I'm going to open a separate bug for this. Hopefully the !lp64 selector is good enough. PR tree-optimization/106922 * tree-ssa-pre.cc (translate_vuse_through_block): Only keep the VUSE if its def dominates PHIBLOCK. (prune_clobbered_mems): Rewrite logic so we check whether a value dies in a block when the VUSE def doesn't dominate it. * g++.dg/tree-ssa/pr106922.C: New testcase.
2022-09-15Move void_list_node init to common codeRichard Biener11-31/+3
All frontends replicate this, so move it. gcc/ * tree.cc (build_common_tree_nodes): Initialize void_list_node here. gcc/ada/ * gcc-interface/trans.cc (gigi): Do not initialize void_list_node. gcc/c-family/ * c-common.h (build_void_list_node): Remove. * c-common.cc (c_common_nodes_and_builtins): Do not initialize void_list_node. gcc/c/ * c-decl.cc (build_void_list_node): Remove. gcc/cp/ * decl.cc (cxx_init_decl_processing): Inline last build_void_list_node call. (build_void_list_node): Remove. gcc/d/ * d-builtins.cc (d_build_c_type_nodes): Do not initialize void_list_node. gcc/fortran/ * f95-lang.cc (gfc_init_decl_processing): Do not initialize void_list_node. gcc/go/ * go-lang.cc (go_langhook_init): Do not initialize void_list_node. gcc/jit/ * dummy-frontend.cc (jit_langhook_init): Do not initialize void_list_node. gcc/lto/ * lto-lang.cc (lto_build_c_type_nodes): Do not initialize void_list_node.
2022-09-15Fix c-c++-common/gomp/target-50.c testJulian Brown1-1/+1
The expected scan dump output for this test will change after the following patch is committed: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html But for now, this patch reverts to the old expected pattern so the test passes. I will apply as obvious. 2022-09-15 Julian Brown <julian@codesourcery.com> gcc/testsuite/ * c-c++-common/gomp/target-50.c: Modify scan pattern.
2022-09-15Fix c-c++-common/goacc/mdc-2.c and g++.dg/goacc/mdc.C testsJulian Brown2-0/+4
These testsuite hunks got left attached to the wrong patch in the series I just posted. I will apply as obvious. 2022-09-15 Julian Brown <julian@codesourcery.com> gcc/testsuite/ * c-c++-common/goacc/mdc-2.c: Update expected errors. * g++.dg/goacc/mdc.C: Likewise.
2022-09-15rs6000: Using pli(paddi) and rotate to build 64bit constantsJiufu Guo3-0/+71
Hi, Test cases are updated/added, and code is refined as the comments in the review for previous version: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600768.html As mentioned in PR106550, since pli could support 34bits immediate, we could use less instructions(3insn would be ok) to build 64bits constant with pli. For example, for constant 0x020805006106003, we could generate it with: asm code1: pli 9,101736451 (0x6106003) sldi 9,9,32 paddi 9,9, 2130000 (0x0208050) or asm code2: pli 10, 2130000 pli 9, 101736451 rldimi 9, 10, 32, 0 The asm code2 would be better. This patch generates the asm code2 in split1 pass, this patch also supports to generate asm code1 when splitter is only after RA. This patch pass boostrap and regtest on ppc64. P10 testing is running. Thanks for any comments! BR, Jeff(Jiufu) PR target/106550 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Use pli. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106550.c: New test. * gcc.target/powerpc/pr106550_1.c: New test.
2022-09-15Daily bump.GCC Administrator8-1/+309
2022-09-14libstdc++: Add TSan annotations to std::atomic<shared_ptr<T>>Jonathan Wakely1-0/+38
This adds annotations to std::atomic<shared_ptr<T>> to enable TSan to understand the custom locking. Without this, TSan reports data races for accesses to the _M_ptr member, even though those are correctly synchronized using atomic operations on the tagged pointer. libstdc++-v3/ChangeLog: * include/bits/shared_ptr_atomic.h (_GLIBCXX_TSAN_MUTEX_DESTROY) (_GLIBCXX_TSAN_MUTEX_PRE_LOCK, _GLIBCXX_TSAN_MUTEX_POST_LOCK) (_GLIBCXX_TSAN_MUTEX_PRE_UNLOCK, _GLIBCXX_TSAN_MUTEX_POST_UNLOCK) (_GLIBCXX_TSAN_MUTEX_PRE_SIGNAL, _GLIBCXX_TSAN_MUTEX_POST_SIGNAL): Define macros for TSan annotation functions. (_Sp_atomic::_Atomic_count): Add annotations.
2022-09-14libstdc++: Add missing <new> header to <bits/stl_tempbuf.h>Jonathan Wakely1-0/+1
This is needed for std::nothrow and the nothrow operator new overload, so should be included explicitly. libstdc++-v3/ChangeLog: * include/bits/stl_tempbuf.h: Include <new>.
2022-09-14libstdc++: Add comment to 17_intro/names.cc testJonathan Wakely1-0/+2
libstdc++-v3/ChangeLog: * testsuite/17_intro/names.cc: Explain why poison pragma can't be used.
2022-09-14libstdc++: Add assertion to std::promise::set_exception (LWG 2276)Jonathan Wakely2-0/+19
Without this assertion, the shared state is made ready, but contains neither a value nor an exception. Add an assertion to prevent users from accessing a value that was never initialized in the shared state. libstdc++-v3/ChangeLog: * include/std/future (_State_baseV2::__setter(exception_ptr&, promise&)): Add assertion for LWG 2276 precondition. * testsuite/30_threads/promise/members/set_exception_neg.cc: New test.
2022-09-14libstdc++: Document LWG 1203 API change in manualJonathan Wakely4-1/+20
libstdc++-v3/ChangeLog: * doc/xml/manual/intro.xml: Document LWG 1203. * doc/html/*: Regenerate.
2022-09-14libstdc++: Add pretty printer for std::stringstreamsPhilipp Fent4-0/+101
To display (o-,i-)stringstreams in the common case, we just print the underlying stringbuf, without the many ios_base members. In the unconventional case that the underlying streambuf was redirected, we report the redirected target. Signed-off-by: Philipp Fent <fent@in.tum.de> libstdc++-v3/ChangeLog: * python/libstdcxx/v6/printers.py (access_streambuf_ptrs): New helper function. (StdStringBufPrinter, StdStringStreamPrinter): New printers. (build_libstdcxx_dictionary): Register stringstream printers. * testsuite/libstdc++-prettyprinters/debug.cc: Check string streams. * testsuite/libstdc++-prettyprinters/simple.cc: Likewise. * testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
2022-09-14frange: add both zeros to ranges when there's the possiblity of equality.Aldy Hernandez1-6/+25
Every time there's equality at play, we must be careful that any equality with zero matches both -0.0 and +0.0 when honoring signed zeros. We were doing this correctly for the == and != op1_range operators (albeit inefficiently), but aren't doing it at all when building >= and <=. This fixes the oversight. There is change in functionality here for the build_* functions. This is the last "simple" patch I submit before overhauling NAN and sign tracking. And that will likely be after Cauldron because it will need further testing (lapack, ppc64le, -ffinite-math-only, etc). Regstrapped on x86-64 Linux, plus I ran selftests for -ffinite-math-only. gcc/ChangeLog: * range-op-float.cc (frange_add_zeros): New. (build_le): Call frange_add_zeros. (build_ge): Same. (foperator_equal::op1_range): Same. (foperator_not_equal::op1_range): Same.
generated by cgit v1.1 at 2025-09-22 22:45:21 +0000