This project is mirrored from git://gcc.gnu.org/git/gcc.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
- 04 Mar, 2020 2 commits
-
-
Jakub Jelinek authored
-
GCC Administrator authored
-
- 03 Mar, 2020 1 commit
-
-
GCC Administrator authored
-
- 02 Mar, 2020 3 commits
-
-
Martin Liska authored
Backport from mainline 2020-02-28 Martin Liska <mliska@suse.cz> PR other/93965 * configure.ac: Improve detection of ld_date by requiring either two dashes or none. * configure: Regenerate.
-
Peter Bergner authored
r8-10096-gc68a93aa^..r8-10098-gcb7565c8 plus add entries for their reversion.
-
GCC Administrator authored
-
- 01 Mar, 2020 1 commit
-
-
GCC Administrator authored
-
- 29 Feb, 2020 4 commits
-
-
Peter Bergner authored
This reverts commit 7f85c982. See PR93974.
-
Peter Bergner authored
This reverts commit e88c006a. See PR93974.
-
Peter Bergner authored
This reverts commit 53efbfe0. See PR93974.
-
GCC Administrator authored
-
- 28 Feb, 2020 1 commit
-
-
GCC Administrator authored
-
- 27 Feb, 2020 2 commits
-
-
GCC Administrator authored
-
Carl Love authored
gcc/ChangeLog: 2020-02-26 Carl Love <cel@us.ibm.com> PR target/91276 * doc/extend.texi (PowerPC AltiVec Built-in Functions): The builtin-function name __builtin_crypto_vpmsumb is only for the vector unsigned short arguments. It is also listed as the name of the built-in for arguments vector unsigned short, vector unsigned int and vector unsigned long long built-ins. The name of the builtins for these arguments should be: __builtin_crypto_vpmsumh, __builtin_crypto_vpmsumw and __builtin_crypto_vpmsumd respectively.
-
- 26 Feb, 2020 25 commits
-
-
Jonathan Wakely authored
The deserialization functions for random number distributions fail to check the stream state before using the extracted values. In some cases this leads to using indeterminate values to resize a vector, and then filling that vector with indeterminate values. No values that affect control flow should be used without checking that a good value was read from the stream. Additionally, where reasonable to do so, defer modifying any state in the distribution until all values have been successfully read, to avoid modifying some of the distribution's parameters and leaving others unchanged. Backport from mainline 2020-01-09 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/93205 * include/bits/random.h (operator>>): Check stream operation succeeds. * include/bits/random.tcc: (operator>>): Likewise. (__extract_params): New function to fill a vector from a stream. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line.
-
Jonathan Wakely authored
Backport from mainline 2019-12-10 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/92886 * include/bits/ios_base.h (std::ios_base::trunc): Fix comment.
-
Jonathan Wakely authored
It's wrong to assume that clock_gettime is unavailable on any *-*-linux* target that doesn't have glibc 2.17 or later. Use a generic test instead of using __GLIBC_PREREQ. Only do that test when is_hosted=yes so that we don't get an error for cross targets without a working linker. This ensures that C library's clock_gettime will be used on non-glibc targets, instead of an incorrect syscall to SYS_clock_gettime. Backport from mainline 2020-01-28 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/93325 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Use AC_SEARCH_LIBS for clock_gettime instead of explicit glibc version check. * configure: Regenerate.
-
Jonathan Wakely authored
The requirements for this function are only that the deleter is swappable, but we incorrectly require that the element type is complete and that the deleter can be swapped using std::swap (which requires it to be move cosntructible and move assignable). The fix is to add __uniq_ptr_impl::swap which swaps the pointer and deleter individually, instead of using the generic std::swap on the tuple containing them. PR libstdc++/93562 * include/bits/unique_ptr.h (__uniq_ptr_impl::swap): Define. (unique_ptr::swap, unique_ptr<T[], D>::swap): Call it. * testsuite/20_util/unique_ptr/modifiers/93562.cc: New test.
-
Jonathan Wakely authored
Explicitly declare aligned alloc functions for freestanding, because <cstdlib> doesn't declare them. Backport from mainline 2020-01-17 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/92376 * libsupc++/new_opa.cc [!_GLIBCXX_HOSTED]: Declare allocation functions if they were detected by configure.
-
Jonathan Wakely authored
Backport from mainline 2019-10-09 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/78552 * src/c++98/locale_init.cc (locale::classic()): Do not construct a new locale object for every call. (locale::_S_initialize_once()): Construct C locale here.
-
Jonathan Wakely authored
The previous rule could leave an incomplete file if the build was interrupted, which would then not be remade if make was run again. This makes the rule more robust by writing to a temporary file and only moving it into place as the final step. It also simplifies the rule so that only the essential macro definitions are written to the file, not the explanatory comments and commented out #undef lines. Also, the macro for enabling LFS on Mac OS X 10.5 is now set unconditionally, which is a bug fix from upstream autoconf. Backport from mainline 2020-01-23 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/91947 * include/Makefile.am (${host_builddir}/largefile-config.h): Simplify rule. * include/Makefile.in: Regenerate. -
Jonathan Wakely authored
Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to be used by default. We do not want to define those macros in the public headers that users include. The values of the macros are copied to a separate file that is only included by the filesystem sources during the build, and then the macros in <bits/c++config.h> are renamed so that they don't have any effect in user code including our headers. Also use larger type for result of filesystem::file_size to avoid truncation of large values on 32-bit systems (PR 91947). Backport from mainlne 2019-10-04 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/81091 PR libstdc++/91947 * configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs. * config.h.in: Regenerate: * configure: Regenerate: * include/Makefile.am (${host_builddir}/largefile-config.h): New target to generate config header for filesystem library. (${host_builddir}/c++config.h): Rename macros for large file support. * include/Makefile.in: Regenerate. * src/c++17/fs_dir.cc: Include new config header. * src/c++17/fs_ops.cc: Likewise. (filesystem::file_size): Use uintmax_t for size. * src/filesystem/dir.cc: Include new config header. * src/filesystem/ops.cc: Likewise. (experimental::filesystem::file_size): Use uintmax_t for size. -
Jakub Jelinek authored
The following testcase is miscompiled in 8+. The problem is that check_no_overlap has a special case for INTEGER_CST marked stores (i.e. stores of constants), if both all currenly merged stores and the one under consideration for merging with them are marked that way, it anticipates that other INTEGER_CST marked stores that overlap with those and precede those (have smaller info->order) could be merged with those and doesn't punt for them. In PR86844 and PR87859 fixes I've then added quite large code that is performed after check_no_overlap and tries to find out if we need and can merge further INTEGER_CST marked stores, or need to punt. Unfortunately, that code is there only in the overlapping case code and the testcase below shows that we really need it even in the adjacent store case. After sort_by_bitpos we have: bitpos width order rhs_code 96 32 3 INTEGER_CST 128 32 1 INTEGER_CST 128 128 2 INTEGER_CST 192 32 0 MEM_REF Because of the missing PR86844/PR87859-ish code in the adjacent store case, we merge the adjacent (memory wise) stores 96/32/3 and 128/32/1, and then we consider the 128-bit store which is in program-order in between them, but in this case we punt, because the merging would extend the merged store region from bitpos 96 and 64-bits to bitpos 96 and 160-bits and that has an overlap with an incompatible store (the MEM_REF one). The problem is that we can't really punt this way, because the 128-bit store is in between those two we've merged already, so either we manage to merge even that one together with the others, or would need to avoid already merging the 96/32/3 and 128/32/1 stores together. Now, rather than copying around the PR86844/PR87859 code to the other spot, we can actually just use the overlapping code, merge_overlapping is really a superset of merge_into, so that is what the patch does. If doing adjacent store merge for rhs_code other than INTEGER_CST, I believe the current code is already fine, check_no_overlap in that case doesn't make the exception and will punt if there is some earlier (smaller order) non-mergeable overlapping store. There is just one case that could be problematic, if the merged_store has BIT_INSERT_EXPRs in them and the new store is a constant store (INTEGER_CST rhs_code), then check_no_overlap would do the exception and still would allow the special case. But we really shouldn't have the special case in that case, so this patch also changes check_no_overlap to just have a bool whether we should have the special case or not. Note, as I said in the PR, for GCC11 we could consider performing some kind of cheap DSE during the store merging (perhaps guarded with flag_tree_dse). And another thing to consider is only consider as problematic non-mergeable stores that not only have order smaller than last_order as currently, but also have order larger than first_order, as in this testcase if we actually ignored (not merged with anything at all) the 192/32/0 store, because it is not in between the other stores we'd merge, it would be fine to merge the other 3 stores, though of course the testcase can be easily adjusted by putting the 192/32 store after the 128/32 store and then this patch would be still needed. Though, I think I'd need more time thinking this over. 2020-02-26 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/93820 * gimple-ssa-store-merging.c (check_no_overlap): Change RHS_CODE argument to ALL_INTEGER_CST_P boolean. (imm_store_chain_info::try_coalesce_bswap): Adjust caller. (imm_store_chain_info::coalesce_immediate_stores): Likewise. Handle adjacent INTEGER_CST store into merged_store->only_constants like overlapping one. * gcc.dg/pr93820.c: New test.
-
Jakub Jelinek authored
The following testcase is rejected in 8.3, but was accepted in 8.2 and is in 9.x. This started with my PR87934 * constexpr.c (cxx_eval_constant_expression) <case CONSTRUCTOR>: Do re-process TREE_CONSTANT CONSTRUCTORs if they aren't reduced constant expressions. backport, where the NSDMI CONSTRUCTOR that contains CONST_DECLs is now constexpr evaluated so that it doesn't contain them. The difference from 9.x is that 9.x doesn't call get_target_expr if we got a CONSTRUCTOR for a class type for something that has been originally a CONSTRUCTOR too. This patch cherry-picks just that hunk of the r9-3835 change. 2020-02-26 Jakub Jelinek <jakub@redhat.com> PR c++/93905 Backported from mainline 2018-11-04 Jason Merrill <jason@redhat.com> * constexpr.c (cxx_eval_outermost_constant_expr): Don't wrap a CONSTRUCTOR if one was passed in. * g++.dg/cpp0x/pr93905.C: New test.
-
Marek Polacek authored
After r269667 which introduced joust_maybe_elide_copy, in C++17 we can elide a constructor if it uses a conversion function that returns a prvalue, and use the conversion function in its stead. This eliding means that if we have a candidate that previously didn't have ->second_conv, it can have it after the elision. This confused the -Wconversion warning because it was assuming that if cand1->second_conv is non-null, so is cand2->second_conv. Here cand1->second_conv was non-null but cand2->second_conv remained null, so it crashed in compare_ics. I checked with clang that both compilers call A::operator B() in C++17 and B::B(A const &) otherwise. gcc/cp/ChangeLog 2020-02-26 Marek Polacek <polacek@redhat.com> PR c++/90998 - ICE with copy elision in init by ctor and -Wconversion. * call.c (joust): Don't attempt to warn if ->second_conv is null. gcc/testsuite/ChangeLog 2020-02-26 Marek Polacek <polacek@redhat.com> PR c++/90998 - ICE with copy elision in init by ctor and -Wconversion. * g++.dg/cpp0x/overload-conv-4.C: New test.
-
Jason Merrill authored
This is an overlooked case in C++17 mandatory copy elision: We want overload resolution to reflect that initializing an object from a prvalue does not involve a copy or move constructor even when [over.match.ctor] says that only constructors are candidates. Here I implement that by looking through the copy/move constructor in joust. gcc/cp/ChangeLog 2020-02-26 Jason Merrill <jason@redhat.com> PR c++/86521 - C++17 copy elision in initialization by constructor. * call.c (joust_maybe_elide_copy): New. (joust): Call it.
-
Jason Merrill authored
When I implemented the [over.match.ref] rule that a reference conversion function needs to match l/rvalue of the target reference type it changed our handling of this testcase. It seems to me that our current behavior is what the standard says, but it doesn't seem desirable, and all the other compilers have our old behavior. So let's limit the change to non-templates until there's some clarification from the committee. gcc/cp/ChangeLog 2020-02-26 Jason Merrill <jason@redhat.com> PR c++/90546 * call.c (build_user_type_conversion_1): Allow a template conversion returning an rvalue reference to bind directly to an lvalue.
-
Jason Merrill authored
Here we were wrongly treating binding a const lvalue ref to an xvalue as direct binding, which is wrong under [dcl.init.ref] and [over.match.ref]. gcc/cp/ChangeLog 2020-02-26 Jason Merrill <jason@redhat.com> PR c++/86521 - wrong overload resolution with ref-qualifiers. * call.c (build_user_type_conversion_1): Don't use a conversion to a reference of the wrong rvalueness for direct binding.
-
Jason Merrill authored
Since the fix for 15272 we were remembering the wrong function to use at instantiation time, because the type of the SCOPE_REF didn't reflect the cv-quals of 'this'. Conveniently, we can fix this by simplifying the code. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/89831 - error with qualified-id in const member function. * semantics.c (finish_non_static_data_member): Use object cv-quals in scoped case, too.
-
Jason Merrill authored
Here 'skipped' was set to -1 to force an explicit initializer for 'uninit' before the initializer for 'initialized', and so we also tried to emit an explicit initializer for the flexible array, for which build_zero_init returns error_mark_node. We should ignore flexarrays even when skipped < 0. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/88380 - wrong-code with flexible array and NSDMI. * typeck2.c (process_init_constructor_record): Skip flexarrays.
-
Jason Merrill authored
The standard says that in a generic lambda we should speculatively capture 'this' if we see a call to an overload set that contains a non-static member function, but it seems wrong to reject the program if we can't capture, since it might not actually be needed. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/87685 - generic lambda 'this' capture error. * lambda.c (lambda_expr_this_capture): Change add_capture_p to int. (maybe_generic_this_capture): Pass -1.
-
Jason Merrill authored
The removed code ended up setting DECL_INITIAL to the INIT_EXPR returned by split_nonconstant_init, which makes no sense. This code was added back in 1996, so any rationale is long lost. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/87554 - ICE with extern template and reference member. * decl.c (cp_finish_decl): Don't set DECL_INITIAL of external vars.
-
Alexandre Oliva authored
When a member template is redeclared as a friend, we enter the context of the member before looking it up, and then we check that the decls are compatible. However, when the member template references template types of the enclosing context, say an enclosing template class, the compare fails because the friend decl is already tsubsted, whereas the looked up name isn't. The problem is that the enclosing context is taken from the friend declaration before tsubsting it, so we look up in the context of the generic template instead of that of the tsubsted one we're specializing. The solution is to tsubst the enclosing context when it's a non-namespace scope. gcc/cp/ChangeLog 2020-02-25 Alexandre Oliva <aoliva@redhat.com> PR c++/86747 * pt.c (tsubst_friend_class): Enter tsubsted class context. gcc/testsuite/ChangeLog 2020-02-25 Alexandre Oliva <aoliva@redhat.com> PR c++/86747 * g++.dg/pr86747.C: New.
-
Jason Merrill authored
When we refer to a captured variable from a constant-expression context inside a lambda, the closure (like any function parameter) is not constant because we aren't in a call, so we don't have an argument. So the capture is non-constant. But if the captured variable is constant, we might be able to use it directly in constexpr evaluation. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/86429 - constexpr variable in lambda. PR c++/82643 PR c++/87327 * constexpr.c (cxx_eval_constant_expression): In a lambda function, try evaluating the captured variable directly.
-
Jason Merrill authored
Various backports depend on it. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> * cp-tree.h (TYPE_REF_P): New.
-
Jason Merrill authored
This issue is similar to PR 87480; in both cases we were doing non-dependent substitution with processing_template_decl set, leading to member access expressions seeming still instantiation-dependent, and therefore decltype not being simplified to its actual type. And as in that PR, the fix is to clear processing_template_decl while substituting a default template argument. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/87748 - substitution failure error with decltype. * pt.c (most_specialized_partial_spec): Clear processing_template_decl.
-
Jason Merrill authored
The issue here is that declval<T>().d is considered instantiation-dependent within a template, as the access to 'd' might depend on the particular specialization. But when we're deducing template arguments for a call, we know that the call and the arguments are non-dependent, so we can do the substitution as though we aren't in a template. Which strictly speaking we aren't, since the default argument is considered a separate definition. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/87480 - decltype of member access in default template arg * pt.c (type_unification_real): Accept a dependent result in template context.
-
Jason Merrill authored
We mostly use is_normal_capture_proxy to decide whether or not to use DECL_CAPTURED_VARIABLE; we could just check whether it's set. VLA capture is still mostly broken, but this fixes this ICE. gcc/cp/ChangeLog 2020-02-25 Jason Merrill <jason@redhat.com> PR c++/88394 - ICE with VLA init-capture. * lambda.c (is_normal_capture_proxy): Check DECL_CAPTURED_VARIABLE.
-
GCC Administrator authored
-
- 25 Feb, 2020 1 commit
-
-
Alexandre Oliva authored
When instantiating a partial specialization of a template member function for a full specialization of a class template, we test whether the context of variables local to the partial specialization, i.e., the partial specialization itself, is dependent, and this ICEs in type_dependent_expression_p, when checking that the function type isn't type-dependent because it is not in a type-dependent scope. We shouldn't have got that far: the previous block in type_dependent_expression_p catches cases in which the function itself takes template arguments of its own, but it only did so for primary templates, not for partial specializations. This patch fixes that. gcc/cp/ChangeLog 2019-02-05 Alexandre Oliva <aoliva@redhat.com> PR c++/87770 * pt.c (instantiates_primary_template_p): New. (type_dependent_expression_p): Use it. gcc/testsuite/ChangeLog 2019-02-05 Alexandre Oliva <aoliva@redhat.com> PR c++/87770 * g++.dg/pr87770.C: New.
-