and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

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 .
  1. 04 Mar, 2020 2 commits
  2. 03 Mar, 2020 1 commit
  3. 02 Mar, 2020 3 commits
  4. 01 Mar, 2020 1 commit
  5. 29 Feb, 2020 4 commits
  6. 28 Feb, 2020 1 commit
  7. 27 Feb, 2020 2 commits
    • GCC Administrator's avatar
      Daily bump. · 39338122
      GCC Administrator authored
      39338122
    • Carl Love's avatar
      PR target/91276 - Doc typos in __builtin_crypto_vpmsum* · f551b088
      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.
      f551b088
  8. 26 Feb, 2020 25 commits
    • Jonathan Wakely's avatar
      libstdc++: Fix undefined behaviour in random dist serialization (PR93205) · f80c40f9
      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.
      f80c40f9
    • Jonathan Wakely's avatar
      libstdc++: Fix description of std::ios::trunc (PR 92886) · a13dd21c
      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.
      a13dd21c
    • Jonathan Wakely's avatar
      libstdc++: Replace glibc-specific check for clock_gettime (PR 93325) · 655434f5
      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.
      655434f5
    • Jonathan Wakely's avatar
      libstdc++: Fix regressions in unique_ptr::swap (PR 93562) · e47c9cd7
      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.
      e47c9cd7
    • Jonathan Wakely's avatar
      libstdc++: Fix freestanding build (PR 92376) · 499ea2e3
      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.
      499ea2e3
    • Jonathan Wakely's avatar
      PR libstdc++/78552 only construct std::locale for C locale once · 26b070a3
      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.
      26b070a3
    • Jonathan Wakely's avatar
      libstdc++: Simplify makefile rule for largefile-config.h (PR91947) · 761696ab
      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.
      761696ab
    • Jonathan Wakely's avatar
      Build filesystem library with large file support · 56b6c2ba
      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.
      56b6c2ba
    • Jakub Jelinek's avatar
      store-merging: Fix coalesce_immediate_stores [PR93820] · 8edd406b
      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.
      8edd406b
    • Jakub Jelinek's avatar
      c++: Fix rejects-valid bug in cxx_eval_outermost_constant_expr [PR93905] · f4335f97
      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.
      f4335f97
    • Marek Polacek's avatar
      PR c++/90998 - ICE with copy elision in init by ctor and -Wconversion. · f52ec6bc
      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.
      f52ec6bc
    • Jason Merrill's avatar
      PR c++/86521 - C++17 copy elision in initialization by constructor. · 32988aac
      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.
      32988aac
    • Jason Merrill's avatar
      c++: Allow template rvalue-ref conv to bind to lvalue ref. · c93117ee
      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.
      c93117ee
    • Jason Merrill's avatar
      PR c++/86521 - wrong overload resolution with ref-qualifiers. · f93784da
      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.
      f93784da
    • Jason Merrill's avatar
      PR c++/89831 - error with qualified-id in const member function. · 2b6565dd
      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.
      
      2b6565dd
    • Jason Merrill's avatar
      PR c++/88380 - wrong-code with flexible array and NSDMI. · b9bfe25d
      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.
      
      b9bfe25d
    • Jason Merrill's avatar
      PR c++/87685 - generic lambda 'this' capture error. · b6136084
      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.
      
      b6136084
    • Jason Merrill's avatar
      PR c++/87554 - ICE with extern template and reference member. · a57528b3
      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.
      
      a57528b3
    • Alexandre Oliva's avatar
      c++: tsubst friend tpl ctxt before looking it up for dupes [PR86747] · 3d99aab5
      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.
      3d99aab5
    • Jason Merrill's avatar
      PR c++/86429 - constexpr variable in lambda. · 6470e8ca
      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.
      6470e8ca
    • Jason Merrill's avatar
      c++: Define TYPE_REF_P. · f59aeab7
      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.
      f59aeab7
    • Jason Merrill's avatar
      PR c++/87748 - substitution failure error with decltype. · ac5e2891
      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.
      ac5e2891
    • Jason Merrill's avatar
      PR c++/87480 - decltype of member access in default template arg · 2dcdcda9
      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.
      2dcdcda9
    • Jason Merrill's avatar
      PR c++/88394 - ICE with VLA init-capture. · bf2fe5d4
      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.
      bf2fe5d4
    • GCC Administrator's avatar
      Daily bump. · 1c10b978
      GCC Administrator authored
      1c10b978
  9. 25 Feb, 2020 1 commit
    • Alexandre Oliva's avatar
      c++: test partial specializations for type dependence [PR87770] · d2221c11
      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.
      d2221c11