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. 27 May, 2020 1 commit
  2. 26 May, 2020 2 commits
    • Alexandre Oliva's avatar
      [rs6000] fix mffsl emulation · cd8cc299
      Alexandre Oliva authored
      The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
      through the motions, but not storing the result in the given
      operands[0]; it rather modifies operands[0] without effect.  It also
      creates a DImode pseudo that it doesn't use, overwriting subregs
      instead.
      
      The patch below fixes all of these, the indentation and a typo.
      
      
      I'm concerned about several issues in the mffsl testcase.  First, I
      don't see that comparing the values as doubles rather than as long
      longs is desirable.  These are FPSCR bitfields, not FP numbers.  I
      understand mffs et al use double because they output to FP registers,
      and the bit patterns are subnormal FP numbers, so it works, but given
      the need for bit masking of at least one side, I'm changing the
      compare to long longs.
      
      Another issue with the test is that, if the compare fails, it calls
      mffsl again to print the value, as if it would yield the same result.
      But part of the FPSCR that mffsl (emulated with mffs or not) copies to
      the output FP register is the FPCC, so the fcmpu used to compare the
      result of the first mffsl will modify FPSCR and thus the result of the
      second mffsl call.  After changing the compare, this is no longer the
      case, but I still think it's better to make absolutely sure what we
      print is what we compared.
      
      Yet another issue is that the test assumed the mffs bits that are not
      to be extracted by mffsl to be already zero, instead of masking them
      out explicitly.  This is not about the mffs emulation in the mffsl
      implementation, but about the mffs use in the test proper.  The bits
      appear to be zero indeed, as the bits left out are for sticky
      exceptions, but there are reserved parts of FPSCR that might turn out
      to be set in the future, so we're better off masking them out
      explicitly, otherwise those bits could cause the compare to fail.
      
      If some future mffsl is changed so that it copies additional nonzero
      bits, the test will fail, and then we'll have a chance to adjust it
      and the emulation.
      
      
      gcc/ChangeLog:
      
      	PR target/94812
      	* config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
      	output operand in emulation.  Don't overwrite pseudos.
      
      gcc/testsuite/ChangeLog:
      
      	PR target/94812
      	* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
      	Reinterpret the doubles as long longs for compares.  Mask out
      	mffs bits that are not expected from mffsl.
      
      (cherry picked from commit 50714f45)
      cd8cc299
    • GCC Administrator's avatar
      Daily bump. · b31e1415
      GCC Administrator authored
      b31e1415
  3. 25 May, 2020 5 commits
    • Jason Merrill's avatar
      c++: constexpr and lambda capture [PR90212] · 0296697c
      Jason Merrill authored
      This is the same issue as PR86429, just in potential_constant_expression_1
      rather than cxx_eval_constant_expression.  As in that case, when we're
      trying to evaluate a constant expression within a lambda, we don't have a
      constant closure object to refer to, but we can try to refer directly to the
      captured variable.
      
      gcc/cp/ChangeLog
      2020-05-05  Jason Merrill  <jason@redhat.com>
      
      	PR c++/90212
      	* constexpr.c (potential_constant_expression_1): In a lambda
      	function, consider a captured variable directly.
      0296697c
    • Jason Merrill's avatar
      c++: Local class DMI using local static [PR90479] · e153e0ef
      Jason Merrill authored
      For default member initializers in templates it's important to push into the
      right context during get_nsdmi.  But for a local class that's not possible,
      and trying leaves the function context we need to be in, so don't try.
      
      gcc/cp/ChangeLog
      2020-05-01  Jason Merrill  <jason@redhat.com>
      
      	PR c++/90479
      	* init.c (get_nsdmi): Don't push_to_top_level for a local class.
      e153e0ef
    • Jason Merrill's avatar
      c++: -fmerge-all-constants vs. destructors [PR91529] · f76202e0
      Jason Merrill authored
      cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
      have non-constant construction or destruction, but -fmerge-all-constants was
      converting an automatic variable to static while leaving TREE_READONLY set.
      
      Fixed by clearing the flag in cp_finish_decl in the presence of
      -fmerge-all-constants.
      
      gcc/cp/ChangeLog
      2020-05-01  Jason Merrill  <jason@redhat.com>
      
      	PR c++/91529
      	* decl.c (cp_finish_decl): Also clear TREE_READONLY if
      	-fmerge-all-constants.
      f76202e0
    • Jason Merrill's avatar
      c++: generic lambda and -fsanitize=vla-bound [PR93822] · 91664c43
      Jason Merrill authored
      Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR
      which is a NOP_EXPR to the VLA type of the proxy.  The problem here was that
      when instantiating we were tsubsting that type twice, once for the type of
      the DECL and once for the type of the NOP_EXPR, and getting two
      different (though equivalent) types.  Then gimplify_type_sizes fixed up the
      type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
      to sadness.
      
      Fixed by directly reusing the type from the DECL.
      
      gcc/cp/ChangeLog
      2020-05-01  Jason Merrill  <jason@redhat.com>
      
      	PR c++/93822
      	* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
      	the same type as the variable.
      91664c43
    • GCC Administrator's avatar
      Daily bump. · 1b91e2f5
      GCC Administrator authored
      1b91e2f5
  4. 24 May, 2020 2 commits
  5. 23 May, 2020 1 commit
  6. 22 May, 2020 3 commits
    • Thomas Koenig's avatar
      Add early return for invalid STATUS for close. · f1d34396
      Thomas Koenig authored
      2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>
      
      	PR libfortran/95119
      	* io/close.c (close_status): Add CLOSE_INVALID.
      	(st_close): Return early on invalid STATUS parameter.
      
      2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>
      
      	PR libfortran/95119
      	* testsuite/libgomp.fortran/close_errors_1.f90: New test.
      
      (cherry picked from commit cdc34b50)
      (cherry picked from commit d975519a)
      (cherry picked from commit 8275e0a6)
      f1d34396
    • Bin Cheng's avatar
      Add missing unit dependence vector in data dependence analysis · 466ad887
      Bin Cheng authored
      Current data dependence analysis misses unit distant vector if DRs in
      DDR have the same invariant access functions.  This adds the vector as
      the constant access function case.
      
      Also fix typo in testcase.
      
      Backport from master.
      
      2020-05-13  Bin Cheng  <bin.cheng@linux.alibaba.com>
      
      gcc/
      	PR tree-optimization/94969
      	* tree-data-ref.c (constant_access_functions): Rename to...
      	(invariant_access_functions): ...this.  Add parameter.  Check for
      	invariant access function, rather than constant.
      	(build_classic_dist_vector): Call above function.
      	* tree-loop-distribution.c (pg_add_dependence_edges): Add comment.
      
      gcc/testsuite/
      	PR tree-optimization/94969
      	* gcc.dg/tree-ssa/pr94969.c: New test.
      
      2020-05-13  Jakub Jelinek  <jakub@redhat.com>
      
      gcc/testsuite/
      	PR tree-optimization/95110
      	* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.
      466ad887
    • GCC Administrator's avatar
      Daily bump. · 5885168d
      GCC Administrator authored
      5885168d
  7. 21 May, 2020 4 commits
    • Martin Liska's avatar
      Fix backport due to usage for x_target_flags. · ef1420e8
      Martin Liska authored
      gcc/ChangeLog:
      
      	* common/config/aarch64/aarch64-common.c (aarch64_handle_option):
      	Use MASK_OUTLINE_ATOMICS for x_target_flags.
      
      (cherry picked from commit f26cfe27)
      ef1420e8
    • Martin Liska's avatar
      Add outline-atomics to target attribute. · 595a1376
      Martin Liska authored
      	* common/config/aarch64/aarch64-common.c (aarch64_handle_option):
      	Handle OPT_moutline_atomics.
      	* config/aarch64/aarch64.c: Add outline-atomics to
      	aarch64_attributes.
      
      	* doc/extend.texi: Document the newly added target attribute.
      
      	* gcc.target/aarch64/target_attr_20.c: New test.
      	* gcc.target/aarch64/target_attr_21.c: New test.
      
      (cherry picked from commit 9e02b45f)
      595a1376
    • H.J. Lu's avatar
      x86: Update VPCLMULQDQ check · d7796c9d
      H.J. Lu authored
      Update VPCLMULQDQ check to support processors with AVX version of
      VPCLMULQDQ.
      
      	Backport from master
      	PR target/91695
      	* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
      	check.
      
      (cherry picked from commit 1e46a443)
      d7796c9d
    • GCC Administrator's avatar
      Daily bump. · ce911702
      GCC Administrator authored
      ce911702
  8. 20 May, 2020 2 commits
    • Mark Eggleston's avatar
      Fortran : ProcPtr function results: 'ppr@' in error message PR39695 · 7c9bfd40
      Mark Eggleston authored
      The value 'ppr@' is set in the name of result symbol, the actual
      name of the symbol is in the procedure name symbol pointed
      to by the result symbol's namespace (ns). When reporting errors for
      symbols that have the proc_pointer attribute check whether the
      result attribute is set and set the name accordingly.
      
      Backported from master.
      
      2020-05-20  Mark Eggleston  <markeggleston@gcc.gnu.org>
      
      gcc/fortran/
      
      	PR fortran/39695
      	* resolve.c (resolve_fl_procedure): Set name depending on
      	whether the result attribute is set.  For PROCEDURE/RESULT
      	conflict use the name in sym->ns->proc_name->name.
      	* symbol.c (gfc_add_type): Add check for function and result
      	attributes use sym->ns->proc_name->name if both are set.
      	Where the symbol cannot have a type use the name in
      	sym->ns->proc_name->name.
      
      2020-05-20  Mark Eggleston  <markeggleston@gcc.gnu.org>
      
      gcc/testsuite/
      
      	PR fortran/39695
      	* gfortran.dg/pr39695_1.f90: New test.
      	* gfortran.dg/pr39695_2.f90: New test.
      	* gfortran.dg/pr39695_3.f90: New test.
      	* gfortran.dg/pr39695_4.f90: New test.
      
      	(cherry picked from commit eb069ae8)
      7c9bfd40
    • GCC Administrator's avatar
      Daily bump. · 5207cd42
      GCC Administrator authored
      5207cd42
  9. 19 May, 2020 2 commits
    • H.J. Lu's avatar
      x86: Update GFNI check · 2c7b7479
      H.J. Lu authored
      Update GFNI check to support processors with SSE and AVX versions of GFNI.
      
      	Backport from master
      	PR target/95220
      	* config/i386/cpuinfo.c (get_available_features): Fix
      	FEATURE_GFNI check.
      2c7b7479
    • GCC Administrator's avatar
      Daily bump. · f49afad3
      GCC Administrator authored
      f49afad3
  10. 18 May, 2020 3 commits
    • Douglas Rupp's avatar
      Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c · 87891f42
      Douglas Rupp authored
      We're getting an error when running this test on PowerPC VxWorks 7,
      due to an unexpected warning:
      
          | Excess errors:
          | cc1: warning: '-mvsx' and '-mno-altivec' are incompatible
      
      The warning comes from a combination of factors:
        - The test itself uses -mvsx explicitly via the following directive:
             // { dg-options "-O1 -mvsx" }
        - Our toolchain was configured so as to make -mno-altivec
          the default;
        - These two options are mutually exclusive.
      
      This commit adds a powerpc_vsx_ok dg-require-effective-target directive
      to that test, and thus making it UNSUPPORTED instead.
      
      Tested on PowerPC VxWorks 7. Also tested on PowerPC ELF as well,
      a platform where we do not make -mno-altivec the default, to verify
      that the test continues to run as usual in that case.
      
      gcc/testsuite/
      
              * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.
      
      (cherry picked from commit c917584a)
      87891f42
    • Iain Buclaw's avatar
      d: Fix multiple definition error when using mixins and interfaces. · 3e84ee0f
      Iain Buclaw authored
      gcc/d/ChangeLog:
      
      	PR d/92216
      	* decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target
      	function is external to the current compilation.
      
      gcc/testsuite/ChangeLog:
      
      	PR d/92216
      	* gdc.dg/imports/pr92216.d: New.
      	* gdc.dg/pr92216.d: New test.
      3e84ee0f
    • GCC Administrator's avatar
      Daily bump. · e8dcd6c7
      GCC Administrator authored
      e8dcd6c7
  11. 17 May, 2020 2 commits
    • Iain Buclaw's avatar
      d: Fix ICE in verify_gimple_stmt, at tree-cfg.c:4959 · 80cefde6
      Iain Buclaw authored
      Both array concat and array new expressions wrapped any temporaries
      created into a BIND_EXPR.  This does not work if an expression used to
      construct the result requires scope destruction, which is represented by
      a TARGET_EXPR with a clean-up, and a CLEANUP_POINT_EXPR at the
      location where the temporaries logically go out of scope.  The reason
      for this not working is because the lowering of cleanup point
      expressions does not traverse inside BIND_EXPRs to expand any gimple
      cleanup expressions within.
      
      The use of creating BIND_EXPR has been removed at both locations, and
      replaced with a normal temporary variable that has initialization
      delayed until its address is taken.
      
      gcc/d/ChangeLog:
      
      	PR d/94970
      	* d-codegen.cc (force_target_expr): Move create_temporary_var
      	implementation inline here.
      	(create_temporary_var): Remove.
      	(maybe_temporary_var): Remove.
      	(bind_expr): Remove.
      	* d-convert.cc (d_array_convert): Use build_local_temp to generate
      	temporaries, and generate its assignment.
      	* d-tree.h (create_temporary_var): Remove.
      	(maybe_temporary_var): Remove.
      	(d_array_convert): Remove vars argument.
      	* expr.cc (ExprVisitor::visit (CatExp *)): Use build_local_temp to
      	generate temporaries, don't wrap them in a BIND_EXPR.
      	(ExprVisitor::visit (NewExp *)): Likewise.
      
      gcc/testsuite/ChangeLog:
      
      	PR d/94970
      	* gdc.dg/pr94970.d: New test.
      80cefde6
    • GCC Administrator's avatar
      Daily bump. · cdbe37de
      GCC Administrator authored
      cdbe37de
  12. 16 May, 2020 3 commits
    • Iain Buclaw's avatar
      d: Fix wrong vtable offset in virtual function call · 7d505b0e
      Iain Buclaw authored
      The Semantic (pass 1) analysis for classes is handled by
      ClassDeclaration::semantic.  For a given class, this method may be ran
      multiple times in order to resolve forward references.  The method
      incrementally tries to resolve the types referred to by the members of
      the class.
      
      The subsequent calls to this method are short-circuited if the class
      members have been fully analyzed.  For this the code tests that it is
      not the first/main call to the method (semanticRun == PASS.init else
      branch), scx is not set, and that the this->symtab is already set.  If
      all these conditions are met, the method returns.  But before returning,
      the method was setting this->semanticRun to PASSsemanticdone.  It should
      not set semanticRun since the class has not been fully analyzed yet.
      The base class analysis for this class could be pending and as a result
      vtable may not have been fully created.
      
      This fake setting of semanticRun results in the semantic analyzer to
      believe that the class has been fully analyzed.  As exposed by the
      issues in upstream, it may result in compile time errors when a derived
      type class is getting analyzed and because of this fake semanticdone on
      the base class, the semantic analysis construes that an overriden method
      is not defined in the base class.  PR95155 exposes anoter scenario where
      a buggy vtable may be created and a call to a class method may result in
      execution of some adhoc code.
      
      gcc/d/ChangeLog:
      
      	PR d/95155
      	* dmd/dclass.c (ClassDeclaration::semantic): Don't prematurely
      	set done on semantic analysis.
      
      gcc/testsuite/ChangeLog:
      
      	PR d/95155
      	* gdc.test/compilable/imports/pr9471a.d: New test.
      	* gdc.test/compilable/imports/pr9471b.d: New test.
      	* gdc.test/compilable/imports/pr9471c.d: New test.
      	* gdc.test/compilable/imports/pr9471d.d: New test.
      	* gdc.test/compilable/pr9471.d: New test.
      7d505b0e
    • Iain Buclaw's avatar
      libphobos: Fix struct layout of stat_t on sparc-*-solaris* · 866f7405
      Iain Buclaw authored
      The last change to the bindings removed the st_pad3 field from the wrong
      struct.  It should have been stat64_t that needed updating instead.
      
      libphobos/ChangeLog
      
      	PR d/90719
      	* libdruntime/core/sys/posix/sys/stat.d (Solaris): Move st_pad3 from
      	struct stat64_t to stat32_t.
      866f7405
    • GCC Administrator's avatar
      Daily bump. · 6d0e00a9
      GCC Administrator authored
      6d0e00a9
  13. 15 May, 2020 1 commit
  14. 14 May, 2020 5 commits
    • Szabolcs Nagy's avatar
      aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748] · 9a1b74d4
      Szabolcs Nagy authored
      It was previously discussed that indirect branches cannot go to
      NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
      See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html
      
      Before the patch a bti j was inserted after the label in
      
        __attribute__((target("branch-protection=bti")))
        int foo (void)
        {
        label:
          return 0;
        }
      
      This is not necessary and weakens the security protection.
      
      gcc/ChangeLog:
      
      	Backport from mainline.
      	2020-04-30  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94748
      	* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
      	the check for NOTE_INSN_DELETED_LABEL.
      
      gcc/testsuite/ChangeLog:
      
      	Backport from mainline.
      	2020-04-30  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94748
      	* gcc.target/aarch64/pr94748.c: New test.
      9a1b74d4
    • Szabolcs Nagy's avatar
      aarch64: ensure bti c is emitted at function start [PR94697] · f6e42cde
      Szabolcs Nagy authored
      The bti pass currently first emits bti c at function start
      if there is no paciasp (which also acts as indirect call
      landing pad), then bti j is emitted at jump labels, however
      if there is a label right before paciasp then the function
      start can end up like
      
        foo:
        label:
          bti j
          paciasp
          ...
      
      This patch is a minimal fix that just moves the bti c handling
      after the bti j handling so we end up with
      
        foo:
          bti c
        label:
          bti j
          paciasp
          ...
      
      This could be improved by emitting bti jc in this case, or by
      detecting that the label is not in fact an indirect jump target
      and then this situation would be much less common.
      
      Needs to be backported to gcc-9 branch.
      
      Backported without the testcase because of missing infrastructure
      for check-function-bodies.
      
      gcc/ChangeLog:
      
      	Backport from mainline.
      	2020-04-23  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94697
      	* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap
      	bti c and bti j handling.
      f6e42cde
    • Szabolcs Nagy's avatar
      aarch64: Fix .cfi_window_save with pac-ret [PR94515] · 95833c34
      Szabolcs Nagy authored
      On aarch64 -mbranch-protection=pac-ret reuses the dwarf
      opcode for window_save to mean "toggle the return address
      mangle state", but in the dwarf2cfi internal logic the
      state was not updated when an opcode was emitted, the
      currently present update logic is only valid for the
      original sparc use of window_save so a separate bool is
      used on aarch64 to track the state.
      
      This bug can cause the unwinder not to authenticate return
      addresses that were signed (or vice versa) which means a
      runtime crash on a pauth enabled system.
      
      Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.
      
      This should be backported to gcc-9 and gcc-8 branches.
      
      gcc/ChangeLog:
      
      	Backport from mainline.
      	2020-04-27  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94515
      	* dwarf2cfi.c (struct GTY): Add ra_mangled.
      	(cfi_row_equal_p): Check ra_mangled.
      	(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
      	this only handles the sparc logic now.
      	(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
      	the aarch64 specific logic.
      	(dwarf2out_frame_debug): Update to use the new subroutines.
      	(change_cfi_row): Check ra_mangled.
      
      gcc/testsuite/ChangeLog:
      
      	Backport from mainline.
      	2020-04-27  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94515
      	* g++.target/aarch64/pr94515-1.C: New test.
      	* g++.target/aarch64/pr94515-2.C: New test.
      95833c34
    • Szabolcs Nagy's avatar
      aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514] · 6173489d
      Szabolcs Nagy authored
      With -mbranch-protection=pac-ret the debug info toggles the
      signedness state of the return address so the unwinder knows when
      the return address needs pointer authentication.
      
      The unwind context flags were not updated according to the dwarf
      frame info.
      
      This causes unwinding across frames that were built without pac-ret
      to incorrectly authenticate the return address wich corrupts the
      return address on a system where PAuth is enabled.
      
      Note: This even affects systems where all code use pac-ret because
      unwinding across a signal frame the return address is not signed.
      
      gcc/testsuite/ChangeLog:
      
      	Backport from mainline.
      	2020-04-23  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94514
      	* g++.target/aarch64/pr94514.C: Require lp64.
      	* gcc.target/aarch64/pr94514.c: Likewise.
      
      	Backport from mainline.
      	2020-04-21  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94514
      	* g++.target/aarch64/pr94514.C: New test.
      	* gcc.target/aarch64/pr94514.c: New test.
      
      libgcc/ChangeLog:
      
      	Backport from mainline.
      	2020-04-21  Szabolcs Nagy  <szabolcs.nagy@arm.com>
      
      	PR target/94514
      	* config/aarch64/aarch64-unwind.h (aarch64_frob_update_context):
      	Update context->flags accroding to the frame state.
      6173489d
    • GCC Administrator's avatar
      Daily bump. · a357a7b9
      GCC Administrator authored
      a357a7b9
  15. 13 May, 2020 2 commits
    • Mark Eggleston's avatar
      Fortran : ICE in gfc_conv_array_constructor_expr PR93497 · cf7a6070
      Mark Eggleston authored
      Invalid expressions, such as those involving array constructors,
      used for the length of character types will cause an ICE.
      
      2020-05-11  Mark Eggleston  <markeggleston@gcc.gnu.org>
      
      Backported from master
      2020-05-13  Steven G. Kargl  <kargl@gcc.gnu.org>
      
      gcc/fortran/
      
      	PR fortran/93497
      	* decl.c (char_len_param_value): Check whether character
      	length expression is of type EXPR_OP and if so simplify it.
      	* resolve.c (resolve_charlen): Reject length if it has a
      	rank.
      
      2020-05-11  Mark Eggleston  <markeggleston@gcc.gnu.org>
      
      Backported from master
      2020-05-13  Mark Eggleston  <markeggleston@gcc.gnu.org>
      
      gcc/testsuite/
      
      	PR fortran/93497
      	* gfortran.dg/pr88025.f90: Change in wording of error.
      	* gfortran.dg/pr93497.f90: New test.
      	* gfortran.dg/pr93714_1.f90: Change in wording of errors.
      	* gfortran.dg/pr93714_2.f90: Change in wording of errors.
      cf7a6070
    • GCC Administrator's avatar
      Daily bump. · 6c0bd2f0
      GCC Administrator authored
      6c0bd2f0
  16. 12 May, 2020 2 commits
    • Jonathan Wakely's avatar
      libstdc++: Fix incorrect size calculation in PMR resource (PR 94906) · 45a6686e
      Jonathan Wakely authored
      Calculating the size of a chunk being returned to the upstream allocator
      was done with a 32-bit type, so it wrapped if the chunk was 4GB or
      larger.
      
      I don't know how to test this without allocating 4GB, so there's no test
      in the testsuite. It has been tested manually of course.
      
      Backport from mainline
      2020-05-04  Jonathan Wakely  <jwakely@redhat.com>
      
      	PR libstdc++/94906
      	* src/c++17/memory_resource.cc
      	(monotonic_buffer_resource::_Chunk::release): Use size_t for shift
      	operands.
      45a6686e
    • Clement Chigot's avatar
      rs6000: Link with libc128.a for long-double-128. · 89714e45
      Clement Chigot authored
      AIX applications using 128-bit long double must be linked with
      libc128.a, in order to have 128-bit compatible routines.
      
      AIX 7.2, 7.1, 6.1: Build/Tests: OK
      
      2020-04-03 Clément Chigot <clement.chigot@atos.net>
      
      * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128.
      * config/rs6000/aix71.h (LIB_SPEC): Likewise.
      * config/rs6000/aix72.h (LIB_SPEC): Likewise.
      89714e45