Skip to content
Snippets Groups Projects
  1. Feb 19, 2024
    • Iain Buclaw's avatar
      d: Add UTF BOM tests to gdc.dg testsuite · eb17bdc2
      Iain Buclaw authored
      Some of these are part of the upstream DMD `gdc.test' testsuite, but
      they had been omitted because they get mangled by the lib/gdc-utils.exp
      helpers when parsing and staging the tests. Translate them over to the
      gdc.dg testsuite instead.
      
      gcc/testsuite/ChangeLog:
      
      	* gdc.dg/bom_UTF16BE.d: New test.
      	* gdc.dg/bom_UTF16LE.d: New test.
      	* gdc.dg/bom_UTF32BE.d: New test.
      	* gdc.dg/bom_UTF32LE.d: New test.
      	* gdc.dg/bom_UTF8.d: New test.
      	* gdc.dg/bom_characters.d: New test.
      	* gdc.dg/bom_error_UTF8.d: New test.
      	* gdc.dg/bom_infer_UTF16BE.d: New test.
      	* gdc.dg/bom_infer_UTF16LE.d: New test.
      	* gdc.dg/bom_infer_UTF32BE.d: New test.
      	* gdc.dg/bom_infer_UTF32LE.d: New test.
      	* gdc.dg/bom_infer_UTF8.d: New test.
      eb17bdc2
    • Jakub Jelinek's avatar
      match.pd: Fix ICE on BIT_INSERT_EXPR of BIT_FIELD_REF folding [PR113967] · 2bfdeca1
      Jakub Jelinek authored
      The following testcase ICEs, because BIT_FIELD_REF's position is not
      multiple of the vector element's bit size and the code uses exact_div
      to divide those 2 values.
      
      For BIT_INSERT_EXPR, the tree-cfg.cc verification verifies the position
      is a multiple of the inserted bit size when inserting into vectors,
      but for BIT_FIELD_REF the position can be arbitrary if within the range.
      
      The following patch fixes that.
      
      2024-02-19  Jakub Jelinek  <jakub@redhat.com>
      
      	PR tree-optimization/113967
      	* match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): Require
      	in condition that @rpos is multiple of vector element size.
      
      	* gcc.dg/pr113967.c: New test.
      2bfdeca1
    • Juzhe-Zhong's avatar
      RISC-V: Suppress the vsetvl fusion for conflict successors · 60820248
      Juzhe-Zhong authored
      Update in v2: Add dump information.
      
      This patch fixes the following ineffective vsetvl insertion:
      
      void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond, size_t cond2)
      {
        for (size_t i = 0; i < n; i++)
          {
            if (i == cond) {
              vint8mf8_t v = *(vint8mf8_t*)(in + i + 100);
              *(vint8mf8_t*)(out + i + 100) = v;
            } else if (i == cond2) {
              vfloat32mf2_t v = *(vfloat32mf2_t*)(in + i + 200);
              *(vfloat32mf2_t*)(out + i + 200) = v;
            } else if (i == (cond2 - 1)) {
              vuint16mf2_t v = *(vuint16mf2_t*)(in + i + 300);
              *(vuint16mf2_t*)(out + i + 300) = v;
            } else {
              vint8mf4_t v = *(vint8mf4_t*)(in + i + 400);
              *(vint8mf4_t*)(out + i + 400) = v;
            }
          }
      }
      
      Before this patch:
      
      f:
      .LFB0:
              .cfi_startproc
              beq     a2,zero,.L12
              addi    a7,a0,400
              addi    a6,a1,400
              addi    a0,a0,1600
              addi    a1,a1,1600
              li      a5,0
              addi    t6,a4,-1
              vsetvli t3,zero,e8,mf8,ta,ma     ---> ineffective uplift
      .L7:
              beq     a3,a5,.L15
              beq     a4,a5,.L16
              beq     t6,a5,.L17
              vsetvli t1,zero,e8,mf4,ta,ma
              vle8.v  v1,0(a0)
              vse8.v  v1,0(a1)
              vsetvli t3,zero,e8,mf8,ta,ma
      .L4:
              addi    a5,a5,1
              addi    a7,a7,4
              addi    a6,a6,4
              addi    a0,a0,4
              addi    a1,a1,4
              bne     a2,a5,.L7
      .L12:
              ret
      .L15:
              vle8.v  v1,0(a7)
              vse8.v  v1,0(a6)
              j       .L4
      .L17:
              vsetvli t1,zero,e8,mf4,ta,ma
              addi    t5,a0,-400
              addi    t4,a1,-400
              vle16.v v1,0(t5)
              vse16.v v1,0(t4)
              vsetvli t3,zero,e8,mf8,ta,ma
              j       .L4
      .L16:
              addi    t5,a0,-800
              addi    t4,a1,-800
              vle32.v v1,0(t5)
              vse32.v v1,0(t4)
              j       .L4
      
      It's obvious that we are hoisting the e8mf8 vsetvl to the top. It's ineffective since e8mf8 comes from
      low probability block which is if (i == cond).
      
      For this case, we disable such fusion.
      
      After this patch:
      
      f:
      	beq	a2,zero,.L12
      	addi	a7,a0,400
      	addi	a6,a1,400
      	addi	a0,a0,1600
      	addi	a1,a1,1600
      	li	a5,0
      	addi	t6,a4,-1
      .L7:
      	beq	a3,a5,.L15
      	beq	a4,a5,.L16
      	beq	t6,a5,.L17
      	vsetvli	t1,zero,e8,mf4,ta,ma
      	vle8.v	v1,0(a0)
      	vse8.v	v1,0(a1)
      .L4:
      	addi	a5,a5,1
      	addi	a7,a7,4
      	addi	a6,a6,4
      	addi	a0,a0,4
      	addi	a1,a1,4
      	bne	a2,a5,.L7
      .L12:
      	ret
      .L15:
      	vsetvli	t3,zero,e8,mf8,ta,ma
      	vle8.v	v1,0(a7)
      	vse8.v	v1,0(a6)
      	j	.L4
      .L17:
      	addi	t5,a0,-400
      	addi	t4,a1,-400
      	vsetvli	t1,zero,e8,mf4,ta,ma
      	vle16.v	v1,0(t5)
      	vse16.v	v1,0(t4)
      	j	.L4
      .L16:
      	addi	t5,a0,-800
      	addi	t4,a1,-800
      	vsetvli	t3,zero,e32,mf2,ta,ma
      	vle32.v	v1,0(t5)
      	vse32.v	v1,0(t4)
      	j	.L4
      
      Tested on both RV32/RV64 no regression. Ok for trunk ?
      
      	PR target/113696
      
      gcc/ChangeLog:
      
      	* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
      	Suppress vsetvl fusion.
      
      gcc/testsuite/ChangeLog:
      
      	* gcc.target/riscv/rvv/vsetvl/pr113696.c: New test.
      60820248
    • GCC Administrator's avatar
      Daily bump. · e42287ea
      GCC Administrator authored
      e42287ea
  2. Feb 18, 2024
    • H.J. Lu's avatar
      x86-64: Generate push2/pop2 only if the incoming stack is 16-byte aligned · 853eb577
      H.J. Lu authored
      Since push2/pop2 requires 16-byte stack alignment, don't generate them
      if the incoming stack isn't 16-byte aligned.
      
      gcc/
      
      	PR target/113912
      	* config/i386/i386.cc (ix86_can_use_push2pop2): New.
      	(ix86_pro_and_epilogue_can_use_push2pop2): Use it.
      	(ix86_emit_save_regs): Don't generate push2 if
      	ix86_can_use_push2pop2 return false.
      	(ix86_expand_epilogue): Don't generate pop2 if
      	ix86_can_use_push2pop2 return false.
      
      gcc/testsuite/
      
      	PR target/113912
      	* gcc.target/i386/apx-push2pop2-2.c: New test.
      853eb577
    • Georg-Johann Lay's avatar
      AVR: Improve documentation for -mmcu=. · e63ae908
      Georg-Johann Lay authored
      gcc/
      	* doc/invoke.texi (AVR Options) <-mmcu>: Remove "Atmel".
      	Note on complete device support.
      e63ae908
    • Georg-Johann Lay's avatar
      AVR: Add examples for ISR macro to interrupt attribute doc. · 0b2284bb
      Georg-Johann Lay authored
      gcc/
      	* doc/extend.texi (AVR Function Attributes): Fuse description
      	of "signal" and "interrupt" attribute.  Link pseudo instruction.
      0b2284bb
    • Dimitar Dimitrov's avatar
      testsuite: Mark non-optimized variants as expensive · 3796216b
      Dimitar Dimitrov authored
      
      When not optimized for speed, the test for PR112344 takes several
      seconds to execute on native x86_64, and 15 minutes on PRU target
      simulator.  Thus mark those variants as expensive.  The -O2 variant
      which originally triggered the PR is not expensive, hence it is
      still run by default.
      
      	PR middle-end/112344
      
      gcc/testsuite/ChangeLog:
      
      	* gcc.dg/torture/pr112344.c: Run non-optimized variants only
      	if expensive tests are allowed.
      
      Signed-off-by: default avatarDimitar Dimitrov <dimitar@dinux.eu>
      3796216b
    • Lulu Cheng's avatar
      LoongArch: Remove redundant symbol type conversions in larchintrin.h. · 80362ffb
      Lulu Cheng authored
      gcc/ChangeLog:
      
      	* config/loongarch/larchintrin.h (__movgr2fcsr): Remove redundant
      	symbol type conversions.
      	(__cacop_d): Likewise.
      	(__cpucfg): Likewise.
      	(__asrtle_d): Likewise.
      	(__asrtgt_d): Likewise.
      	(__lddir_d): Likewise.
      	(__ldpte_d): Likewise.
      	(__crc_w_b_w): Likewise.
      	(__crc_w_h_w): Likewise.
      	(__crc_w_w_w): Likewise.
      	(__crc_w_d_w): Likewise.
      	(__crcc_w_b_w): Likewise.
      	(__crcc_w_h_w): Likewise.
      	(__crcc_w_w_w): Likewise.
      	(__crcc_w_d_w): Likewise.
      	(__csrrd_w): Likewise.
      	(__csrwr_w): Likewise.
      	(__csrxchg_w): Likewise.
      	(__csrrd_d): Likewise.
      	(__csrwr_d): Likewise.
      	(__csrxchg_d): Likewise.
      	(__iocsrrd_b): Likewise.
      	(__iocsrrd_h): Likewise.
      	(__iocsrrd_w): Likewise.
      	(__iocsrrd_d): Likewise.
      	(__iocsrwr_b): Likewise.
      	(__iocsrwr_h): Likewise.
      	(__iocsrwr_w): Likewise.
      	(__iocsrwr_d): Likewise.
      	(__frecipe_s): Likewise.
      	(__frecipe_d): Likewise.
      	(__frsqrte_s): Likewise.
      	(__frsqrte_d): Likewise.
      80362ffb
    • Lulu Cheng's avatar
      LoongArch: Fix wrong return value type of __iocsrrd_h. · 12bcac83
      Lulu Cheng authored
      gcc/ChangeLog:
      
      	* config/loongarch/larchintrin.h (__iocsrrd_h): Modify the
      	function return value type to unsigned short.
      12bcac83
    • GCC Administrator's avatar
      Daily bump. · c1d15713
      GCC Administrator authored
      c1d15713
  3. Feb 17, 2024
    • Iain Buclaw's avatar
      d: Merge dmd, druntime 9471b25db9, phobos 547886846. · 5aff58e5
      Iain Buclaw authored
      D front-end changes:
      
      	- Import dmd v2.107.1-rc.1.
      
      D runtime changes:
      
      	- Import druntime v2.107.1-rc.1.
      
      Phobos changes:
      
      	- Import phobos v2.107.1-rc.1.
      
      gcc/d/ChangeLog:
      
      	* dmd/MERGE: Merge upstream dmd 9471b25db9.
      	* dmd/VERSION: Bump version to v2.107.1-rc.1.
      	* Make-lang.in (D_FRONTEND_OBJS): Add d/cxxfrontend.o.
      	* d-attribs.cc (build_attributes): Update for new front-end interface.
      	* d-builtins.cc (build_frontend_type): Likewise.
      	(strip_type_modifiers): Likewise.
      	(covariant_with_builtin_type_p): Likewise.
      	* d-codegen.cc (declaration_type): Likewise.
      	(parameter_type): Likewise.
      	(build_array_struct_comparison): Likewise.
      	(void_okay_p): Likewise.
      	* d-convert.cc (convert_expr): Likewise.
      	(check_valist_conversion): Likewise.
      	* d-lang.cc (d_generate_ddoc_file): Likewise.
      	(d_parse_file): Likewise.
      	* d-target.cc (TargetCPP::toMangle): Likewise.
      	(TargetCPP::typeInfoMangle): Likewise.
      	(TargetCPP::thunkMangle): Likewise.
      	(TargetCPP::parameterType): Likewise.
      	* decl.cc (d_mangle_decl): Likewise.
      	(DeclVisitor::visit): Likewise.
      	(DeclVisitor::visit (CAsmDeclaration *)): New method.
      	(get_symbol_decl): Update for new front-end interface.
      	(layout_class_initializer): Likewise.
      	* expr.cc (ExprVisitor::visit): Likewise.
      	* intrinsics.cc (maybe_set_intrinsic): Likewise.
      	(expand_intrinsic_rotate): Likewise.
      	* modules.cc (layout_moduleinfo_fields): Likewise.
      	(layout_moduleinfo): Likewise.
      	* runtime.cc (get_libcall_type): Likewise.
      	* typeinfo.cc (make_frontend_typeinfo): Likewise.
      	(TypeInfoVisitor::visit): Likewise.
      	(create_typeinfo): Likewise.
      	* types.cc (same_type_p): Likewise.
      	(build_ctype): Likewise.
      
      libphobos/ChangeLog:
      
      	* libdruntime/MERGE: Merge upstream druntime 9471b25db9.
      	* src/MERGE: Merge upstream phobos 547886846.
      5aff58e5
    • Jerry DeLisle's avatar
      libgfortran: [PR105473] Fix checks for decimal='comma'. · a71d8743
      Jerry DeLisle authored
      	PR libfortran/105473
      
      libgfortran/ChangeLog:
      
      	* io/list_read.c (eat_separator): Reject comma as a
      	seprator when it is being used as a decimal point.
      	(parse_real): Reject a '.' when is should be a comma.
      	(read_real): Likewise.
      	* io/read.c (read_f): Add more checks for ',' and '.'
      	conditions.
      
      gcc/testsuite/ChangeLog:
      
      	* gfortran.dg/pr105473.f90: New test.
      a71d8743
    • Jakub Jelinek's avatar
      fortran: gfc_trans_subcomponent_assign fixes [PR113503] · 296284a9
      Jakub Jelinek authored
      The r14-870 changes broke xtb package tests (reduced testcase is the first
      one below) and caused ICEs on a test derived from that (the second one).
      For the
        x = T(u = trim (us(1)))
      statement, before that change gfortran used to emit weird code with
      2 trim calls:
            _gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
            if (len.2 > 0)
              {
                __builtin_free ((void *) pstr.1);
              }
            D.4275 = len.2;
            t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) D.4275, 1>);
            t.0._u_length = D.4275;
            _gfortran_string_trim (&len.4, (void * *) &pstr.3, 20, &us[0]);
            (void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.3, (unsigned long) NON_LVALUE_EXPR <len.4>);
            if (len.4 > 0)
              {
                __builtin_free ((void *) pstr.3);
              }
      That worked at runtime, though it is wasteful.
      That commit changed it to:
            slen.3 = len.2;
            t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.3, 1>);
            t.0._u_length = slen.3;
            _gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
            (void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.1, (unsigned long) NON_LVALUE_EXPR <len.2>);
            if (len.2 > 0)
              {
                __builtin_free ((void *) pstr.1);
              }
      which results in -Wuninitialized warning later on and if one is unlucky and
      the uninitialized len.2 variable is smaller than the trimmed length, it
      results in heap overflow and often crashes later on.
      The bug above is clear, len.2 is only initialized in the
      _gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
      call, but used before that.  Now, the
            slen.3 = len.2;
            t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.3, 1>);
            t.0._u_length = slen.3;
      statements come from the alloc_scalar_allocatable_subcomponent call,
      while
            _gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
      from the gfc_conv_expr (&se, expr); call which is done before the
      alloc_scalar_allocatable_subcomponent call, but is only appended later on
      with gfc_add_block_to_block (&block, &se.pre);
      Now, obviously the alloc_scalar_allocatable_subcomponent emitted statements
      can depend on the se.pre sequence statements which can compute variables
      used by alloc_scalar_allocatable_subcomponent like the length.
      On the other side, I think the se.pre sequence really shouldn't depend
      on the changes done by alloc_scalar_allocatable_subcomponent, that is
      initializing the FIELD_DECLs of the destination allocatable subcomponent
      only, the gfc_conv_expr statements are already created, so all they could
      in theory depend above is on t.0.u or t.0._u_length, but I believe if the
      rhs dependened on the lhs content (which is allocated by those statements
      but really uninitialized), it would need to be discovered by the dependency
      analysis and forced into a temporary.
      So, in order to fix the first testcase, the second hunk of the patch just
      emits the se.pre block before the alloc_scalar_allocatable_subcomponent
      changes rather than after it.
      
      The second problem is an ICE on the second testcase.  expr in the caller
      (expr2 inside of alloc_scalar_allocatable_subcomponent) has
      expr2->ts.u.cl->backend_decl already set, INTEGER_CST 20, but
      alloc_scalar_allocatable_subcomponent overwrites it to a new VAR_DECL
      which it assigns a value to before the malloc.  That can work if the only
      places the expr2->ts is ever used are in the same local block or its
      subblocks (and only if it is dominated by the code emitted by
      alloc_scalar_allocatable_subcomponent, so e.g. not if that call is inside
      of a conditional code and use later unconditional), but doesn't work
      if expr2->ts is used before that block or after it.  So, the exact ICE is
      because of:
        slen.1 = 20;
          static character(kind=1) us[1][1:20] = {"foo                 "};
        x.u = 0B;
        x._u_length = 0;
        {
          struct t t.0;
          struct t D.4308;
      
          {
            integer(kind=8) slen.1;
      
            slen.1 = 20;
            t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
            t.0._u_length = slen.1;
            (void) __builtin_memcpy ((void *) t.0.u, (void *) &us[0], 20);
          }
      where the first slen.1 = 20; is emitted because it sees us has a VAR_DECL
      ts.u.cl->backend_decl and so it wants to initialize it to the actual length.
      This is invalid GENERIC, because the slen.1 variable is only declared inside
      of a {} later on and so uses outside of it are wrong.  Similarly wrong would
      be if it is used later on.  E.g. in the same testcase if it has
        type(T) :: x, y
        x = T(u = us(1))
        y%u = us(1)
      then there is
          {
            integer(kind=8) slen.1;
      
            slen.1 = 20;
            t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
            t.0._u_length = slen.1;
            (void) __builtin_memcpy ((void *) t.0.u, (void *) &us[0], 20);
          }
      ...
          if (y.u != 0B) goto L.1;
          y.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
      i.e. another use of slen.1, this time after slen.1 got out of scope.
      
      I really don't understand why the code modifies
      expr2->ts.u.cl->backend_decl, expr2 isn't used there anywhere except for
      expr2->ts.u.cl->backend_decl expressions, so hacks like save the previous
      value, overwrite it temporarily over some call that will use expr2 and
      restore afterwards aren't needed - there are no such calls, so the
      following patch fixes it just by not messing up with
      expr2->ts.u.cl->backend_decl, only set it to size variable and overwrite
      that with a temporary if needed.
      
      2024-02-17  Jakub Jelinek  <jakub@redhat.com>
      
      	PR fortran/113503
      	* trans-expr.cc (alloc_scalar_allocatable_subcomponent): Don't
      	overwrite expr2->ts.u.cl->backend_decl, instead set size to
      	expr2->ts.u.cl->backend_decl first and use size instead of
      	expr2->ts.u.cl->backend_decl.
      	(gfc_trans_subcomponent_assign): Emit se.pre into block
      	before calling alloc_scalar_allocatable_subcomponent instead of
      	after it.
      
      	* gfortran.dg/pr113503_1.f90: New test.
      	* gfortran.dg/pr113503_2.f90: New test.
      296284a9
    • Jerry DeLisle's avatar
      libgfortran: Fix namelist read. · fccfe662
      Jerry DeLisle authored
      	PR libfortran/107068
      
      libgfortran/ChangeLog:
      
      	* io/list_read.c (read_logical): When looking for a possible
      	variable name, check for left paren, indicating a possible
      	array reference.
      
      gcc/testsuite/ChangeLog:
      
      	* gfortran.dg/pr107068.f90: New test.
      fccfe662
    • Marek Polacek's avatar
      c++: wrong looser excep spec for dep noexcept [PR113158] · 876fa432
      Marek Polacek authored
      Here we find ourselves in maybe_check_overriding_exception_spec in
      a template context where we can't instantiate a dependent noexcept.
      That's OK, but we have to defer the checking otherwise we give wrong
      errors.
      
      	PR c++/113158
      
      gcc/cp/ChangeLog:
      
      	* search.cc (maybe_check_overriding_exception_spec): Defer checking
      	when a noexcept couldn't be instantiated & evaluated to false/true.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp0x/noexcept83.C: New test.
      876fa432
    • François Dumont's avatar
      libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior · 9739d7eb
      François Dumont authored
      std::__niter_base is used in _GLIBCXX_DEBUG mode to remove _Safe_iterator<>
      wrapper on random access iterators. But doing so it should also preserve original
      behavior to remove __normal_iterator wrapper.
      
      libstdc++-v3/ChangeLog:
      
      	* include/bits/stl_algobase.h (std::__niter_base): Redefine the overload
      	definitions for __gnu_debug::_Safe_iterator.
      	* include/debug/safe_iterator.tcc (std::__niter_base): Adapt declarations.
      9739d7eb
    • Harald Anlauf's avatar
      Fortran: deferred length of character variables shall not get lost [PR113911] · 76aac40f
      Harald Anlauf authored
      	PR fortran/113911
      
      gcc/fortran/ChangeLog:
      
      	* trans-array.cc (gfc_trans_deferred_array): Do not clobber
      	deferred length for a character variable passed as dummy argument.
      
      gcc/testsuite/ChangeLog:
      
      	* gfortran.dg/allocatable_length_2.f90: New test.
      	* gfortran.dg/bind_c_optional-2.f90: Enable deferred-length test.
      76aac40f
    • Jakub Jelinek's avatar
      testsuite: Fix up lra effective target · e16f90be
      Jakub Jelinek authored
      Given the recent discussions on IRC started with Andrew P. mentioning that
      an asm goto outputs test should have { target lra } and the lra effective
      target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
      we clearly have 14 other targets which don't support LRA and a couple of
      further ones which have an -mlra/-mno-lra switch (whatever default they
      have), seems to me the effective target is quite broken.
      
      The following patch rewrites it, such that it has a fast path for heavily
      used targets which are for years known to use only LRA (just an
      optimization) plus determines whether it is a LRA target or reload target
      by scanning the -fdump-rtl-reload-details dump on an empty function,
      LRA has quite a few always emitted messages in that case while reload has
      none of those.
      
      Tested on x86_64-linux and cross to s390x-linux, for the latter with both
      make check-gcc RUNTESTFLAGS='--target_board=unix/-mno-lra dg.exp=pr107385.c'
      where the test is now UNSUPPORTED and
      make check-gcc RUNTESTFLAGS='--target_board=unix/-mlra dg.exp=pr107385.c'
      where it fails because I don't have libc around.
      
      There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
      target.  I think claiming for it that it is a lra target is strange (even
      though it effectively returns true for targetm.lra_p ()), unsure if it
      supports asm goto with outputs or not, if it does and we want to test it,
      perhaps we should introduce asm_goto_outputs effective target and use
      lra || nvptx-*-* for that?
      
      2024-02-17  Jakub Jelinek  <jakub@redhat.com>
      
      	* lib/target-supports.exp (check_effective_target_lra): Rewrite
      	to list some heavily used always LRA targets and otherwise check the
      	-fdump-rtl-reload-details dump for messages specific to LRA.
      e16f90be
    • GCC Administrator's avatar
      Daily bump. · d70f155b
      GCC Administrator authored
      d70f155b
  4. Feb 16, 2024
    • Matteo Italia's avatar
      libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850] · 05ad8fb5
      Matteo Italia authored
      Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
      relative time in seconds instead of milliseconds. As a consequence,
      __gthr_win32_cond_timedwait called SleepConditionVariableCS with a
      1000x shorter timeout; this caused ~1000x more spurious wakeups in
      CV timed waits such as std::condition_variable::wait_for or wait_until,
      resulting generally in much higher CPU usage.
      
      This can be demonstrated by this sample program:
      
      ```
      
      int main() {
          std::condition_variable cv;
          std::mutex mx;
          bool pass = false;
      
          auto thread_fn = [&](bool timed) {
              int wakeups = 0;
              using sc = std::chrono::system_clock;
              auto before = sc::now();
              std::unique_lock<std::mutex> ml(mx);
              if (timed) {
                  cv.wait_for(ml, std::chrono::seconds(2), [&]{
                      ++wakeups;
                      return pass;
                  });
              } else {
                  cv.wait(ml, [&]{
                      ++wakeups;
                      return pass;
                  });
              }
              printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
                      int((sc::now() - before) / std::chrono::milliseconds(1)));
              pass = false;
          };
      
          {
              // timed wait, let expire
              std::thread t(thread_fn, true);
              t.join();
          }
      
          {
              // timed wait, wake up explicitly after 1 second
              std::thread t(thread_fn, true);
              std::this_thread::sleep_for(std::chrono::seconds(1));
              {
                  std::unique_lock<std::mutex> ml(mx);
                  pass = true;
              }
              cv.notify_all();
              t.join();
          }
      
          {
              // non-timed wait, wake up explicitly after 1 second
              std::thread t(thread_fn, false);
              std::this_thread::sleep_for(std::chrono::seconds(1));
              {
                  std::unique_lock<std::mutex> ml(mx);
                  pass = true;
              }
              cv.notify_all();
              t.join();
          }
          return 0;
      }
      ```
      
      On builds based on non-affected threading models (e.g. POSIX on Linux,
      or winpthreads or MCF on Win32) the output is something like
      ```
      pass: 0; wakeups: 2; elapsed: 2000 ms
      pass: 1; wakeups: 2; elapsed: 991 ms
      pass: 1; wakeups: 2; elapsed: 996 ms
      ```
      
      while with the Win32 threading model we get
      ```
      pass: 0; wakeups: 1418; elapsed: 2000 ms
      pass: 1; wakeups: 479; elapsed: 988 ms
      pass: 1; wakeups: 2; elapsed: 992 ms
      ```
      (notice the huge number of wakeups in the timed wait cases only).
      
      This commit fixes the conversion, adjusting the final division by
      NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
      file and not used in any other place, so probably just a typo).
      
      libgcc/ChangeLog:
      
      	PR libgcc/113850
      	* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
      	fix absolute timespec to relative milliseconds count
      	conversion (it incorrectly returned seconds instead of
      	milliseconds); this avoids spurious wakeups in
      	__gthr_win32_cond_timedwait
      05ad8fb5
    • Andrew Pinski's avatar
      Add -Wstrict-aliasing to vector-struct-1.C testcase · cd503b06
      Andrew Pinski authored
      As noticed by Marek Polacek in https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645836.html
      
      ,
      this testcase was not failing before without -Wstrict-aliasing so let's add that option.
      
      Committed as obvious after testing to make sure the test is now testing with `-Wstrict-aliasing` and `-flto`.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/torture/vector-struct-1.C: Add -Wstrict-aliasing.
      
      Signed-off-by: default avatarAndrew Pinski <quic_apinski@quicinc.com>
      cd503b06
    • Joseph Myers's avatar
      Regenerate .pot files · 69efea3e
      Joseph Myers authored
      gcc/po/
      	* gcc.pot: Regenerate.
      
      libcpp/po/
      	* cpplib.pot: Regenerate.
      69efea3e
    • Marek Polacek's avatar
      c++: wrong looser exception spec with deleted fn · 40b8d7b7
      Marek Polacek authored
      I noticed we don't implement the "unless the overriding function is
      defined as deleted" wording added to [except.spec] via CWG 1351.
      
      	DR 1351
      
      gcc/cp/ChangeLog:
      
      	* search.cc (maybe_check_overriding_exception_spec): Don't error about
      	a looser exception specification if the overrider is deleted.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp0x/noexcept82.C: New test.
      40b8d7b7
    • Jonathan Wakely's avatar
      libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961] · c74131e7
      Jonathan Wakely authored
      	PR libstdc++/87744
      	PR libstdc++/113961
      
      libstdc++-v3/ChangeLog:
      
      	* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
      	line number.
      c74131e7
    • Andrew Pinski's avatar
      c++: Add testcase for this PR [PR97990] · 5f1438db
      Andrew Pinski authored
      
      This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
      one to make sure it does not regress again.
      
      Committed as obvious after a quick test on the testcase.
      
      	PR c++/97990
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/torture/vector-struct-1.C: New test.
      
      Signed-off-by: default avatarAndrew Pinski <quic_apinski@quicinc.com>
      5f1438db
    • Edwin Lu's avatar
      testsuite: Add support for scanning assembly with comparitor · bf6f00cb
      Edwin Lu authored
      
      There is currently no support for matching at least x lines of assembly
      (only scan-assembler-times). This patch would allow setting upper or lower
      bounds.
      
      Use case: using different scheduler descriptions and/or cost models will change
      assembler output. Testing common functionality across tunes would require a
      separate testcase per tune since each assembly output would be different. If we
      know a base number of lines should appear across all tunes (i.e. testing return
      values: we expect at minimum n stores into register x), we can lower-bound the
      test to search for scan-assembler-bound {RE for storing into register x} >= n.
      This avoids artificially inflating the scan-assembler-times expected count due
      to the assembler choosing to perform extra stores into register x (using it as
      a temporary register).
      
      The testcase would be more robust to cpu/tune changes at the cost of not being
      as granular towards specific cpu tuning.
      
      gcc/ChangeLog:
      
      	* doc/sourcebuild.texi: add scan-assembler-bound
      
      gcc/testsuite/ChangeLog:
      
      	* lib/scanasm.exp: add scan-assembler-bound
      
      Signed-off-by: default avatarEdwin Lu <ewlu@rivosinc.com>
      bf6f00cb
    • Patrick Palka's avatar
      c++: add fixed testcase [PR111682] · c95dc611
      Patrick Palka authored
      Fixed by the PR113612 fix r14-8960-g19ac327de421fe.
      
      	PR c++/111682
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp1y/var-templ86.C: New test.
      c95dc611
    • Marek Polacek's avatar
      c++: implicit move with throw [PR113853] · 254ff3d0
      Marek Polacek authored
      Here we have
      
        template<class T>
        auto is_throwable(T t) -> decltype(throw t, true) { ... }
      
      where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
      the wrong overload to have been chosen.  Jason figured out it's because
      we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
      says that an id-expression is move-eligible if
      
      "the id-expression (possibly parenthesized) is the operand of
      a throw-expression, and names an implicitly movable entity that belongs
      to a scope that does not contain the compound-statement of the innermost
      lambda-expression, try-block, or function-try-block (if any) whose
      compound-statement or ctor-initializer contains the throw-expression."
      
      I worked out that it's trying to say that given
      
        struct X {
          X();
          X(const X&);
          X(X&&) = delete;
        };
      
      the following should fail: the scope of the throw is an sk_try, and it's
      also x's scope S, and S "does not contain the compound-statement of the
      *try-block" so x is move-eligible, so we move, so we fail.
      
        void f ()
        try {
          X x;
          throw x;  // use of deleted function
        } catch (...) {
        }
      
      Whereas here:
      
        void g (X x)
        try {
          throw x;
        } catch (...) {
        }
      
      the throw is again in an sk_try, but x's scope is an sk_function_parms
      which *does* contain the {} of the *try-block, so x is not move-eligible,
      so we don't move, so we use X(const X&), and the code is fine.
      
      The current code also doesn't seem to handle
      
        void h (X x) {
          void z (decltype(throw x, true));
        }
      
      where there's no enclosing lambda or sk_try so we should move.
      
      I'm not doing anything about lambdas because we shouldn't reach the
      code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
      shouldn't let us go further.
      
      	PR c++/113789
      	PR c++/113853
      
      gcc/cp/ChangeLog:
      
      	* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
      	reflect [expr.prim.id.unqual]#4.2.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
      	* g++.dg/cpp0x/sfinae70.C: New test.
      	* g++.dg/cpp0x/sfinae71.C: New test.
      	* g++.dg/cpp0x/sfinae72.C: New test.
      	* g++.dg/cpp2a/implicit-move4.C: New test.
      254ff3d0
    • Jakub Jelinek's avatar
      c++: Diagnose this specifier on template parameters [PR113929] · 5286b076
      Jakub Jelinek authored
      For template parameters, the optional this specifier is in the grammar
      template-parameter-list -> template-parameter -> parameter-declaration,
      just [dcl.fct/6] says that it is only valid in parameter-list of certain
      functions.  So, unlike the case of decl-specifier-seq used in non-terminals
      other than parameter-declaration, I think it is better not to fix this
      by
         cp_parser_decl_specifier_seq (parser,
      -                                flags | CP_PARSER_FLAGS_PARAMETER,
      +                                flags | (template_parameter_p ? 0
      +                                         : CP_PARSER_FLAGS_PARAMETER),
                                       &decl_specifiers,
                                       &declares_class_or_enum);
      which would be pretending it isn't in the grammar, but by diagnosing it
      separately, which is what the following patch does.
      
      2024-02-16  Jakub Jelinek  <jakub@redhat.com>
      
      	PR c++/113929
      	* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
      	on template parameter declaration.
      
      	* g++.dg/parse/pr113929.C: New test.
      5286b076
    • Jason Merrill's avatar
      gdbhooks: regex syntax error · 945cb849
      Jason Merrill authored
      Recent python complains about this pattern with
        SyntaxWarning: invalid escape sequence '\s'
      because \s in a regular string just means 's'; for it to mean whitespace,
      you need \\ or for the pattern to be a raw string.
      
      Curiously, break-on-pass completion works for me either with or without this
      change, but at least this avoids the warning.
      
      gcc/ChangeLog:
      
      	* gdbhooks.py: Fix regex syntax.
      945cb849
    • Patrick Palka's avatar
      c++/modules: stream TREE_UNAVAILABLE and LAMBDA_EXPR_REGEN_INFO · 83aaa107
      Patrick Palka authored
      
      gcc/cp/ChangeLog:
      
      	* module.cc (trees_out::core_bools): Stream TREE_UNAVAILABLE.
      	(trees_in::core_bools): Likewise.
      	(trees_out::core_vals): Stream LAMBDA_EXPR_REGEN_INFO.
      	(trees_in::core_vals): Likewise.
      
      Reviewed-by: default avatarJason Merrill <jason@redhat.com>
      83aaa107
    • Rainer Orth's avatar
      libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785] · 7c6071a6
      Rainer Orth authored
      c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
      
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -O0  execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -O1  execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2  execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -O2 -flto  execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -flto-partition=none
      execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer
      -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -O3 -g  execution test
      FAIL: c-c++-common/asan/swapcontext-test-1.c   -Os  execution test
      
      As detailed in PR sanitizer/113785, this happens because an ABI change
      in Solaris 10/SPARC caused the external symbol for makecontext to be
      changed to __makecontext_v2, which isn't intercepted.
      
      The following patch, submitted upstream at
      https://github.com/llvm/llvm-project/pull/81588, fixes that.
      
      Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
      
      2024-02-16  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
      
      	libsanitizer:
      	PR sanitizer/113785
      	* asan/asan_interceptors.cpp: Cherry-pick llvm-project revision
      	8c2033719a843a1880427a5e8caa5563248bce78.
      7c6071a6
    • Richard Biener's avatar
      tree-optimization/113895 - consistency check fails in copy_reference_ops_from_ref · 5fd1cbfd
      Richard Biener authored
      The following addresses consistency check fails in copy_reference_ops_from_ref
      when we are handling out-of-bound array accesses (it's almost impossible
      to identically mimic the get_ref_base_and_extent behavior).  It also
      addresses the case where an out-of-bound constant offset computes to a
      -1 off which is the special value for "unknown".  This patch basically
      turns off verification in those cases.
      
      	PR tree-optimization/113895
      	* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Disable
      	consistency checking when there are out-of-bound array
      	accesses.  Allow -1 off when from an array reference with
      	constant index.
      
      	* gcc.dg/torture/pr113895-2.c: New testcase.
      	* gcc.dg/torture/pr113895-3.c: Likewise.
      	* gcc.dg/torture/pr113895-4.c: Likewise.
      5fd1cbfd
    • Jonathan Wakely's avatar
      libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931] · 7f3d9006
      Jonathan Wakely authored
      	PR libstdc++/87744
      	PR libstdc++/113931
      
      libstdc++-v3/ChangeLog:
      
      	* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
      	line number.
      7f3d9006
    • Jonathan Wakely's avatar
      libstdc++: Improve docs for debug mode backtraces · 1aef0a9b
      Jonathan Wakely authored
      The configure option is no longer necessary.
      
      libstdc++-v3/ChangeLog:
      
      	* doc/xml/manual/debug_mode.xml: Update docs for backtraces.
      	* doc/html/manual/debug_mode_using.html: Regenerate.
      1aef0a9b
    • Jonathan Wakely's avatar
      libstdc++: Fix spelling of <envar> elements in manual · 1c05d4e9
      Jonathan Wakely authored
      libstdc++-v3/ChangeLog:
      
      	* doc/xml/manual/test.xml: Fix spelling of <envar> elements.
      	* doc/html/manual/test.html: Regenerate.
      1c05d4e9
    • Kito Cheng's avatar
      RISC-V: Fix *sge<u>_<X:mode><GPR:mode> pattern · 325d5dd5
      Kito Cheng authored
      *sge<u>_<X:mode><GPR:mode> pattern has referenced operand[2] which is
      invalid...it should just use `slti<u>` rather than `slti%i2<u>`.
      
      gcc/ChangeLog:
      
      	PR target/106543
      	* config/riscv/riscv.md (*sge<u>_<X:mode><GPR:mode>): Fix asm
      	pattern.
      325d5dd5
    • Rainer Orth's avatar
      testsuite: Require lto-plugin support in gcc.dg/lto/modref-3 etc. [PR98237] · de658585
      Rainer Orth authored
      gcc.dg/lto/modref-3 etc. FAIL on Solaris with the native linker:
      
      FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
      FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
      FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto
      FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto
      
      The issue is that the tests require the linker plugin, which isn't
      available with Solaris ld.  Thus, it also FAILs when gcc is configured
      with --disable-lto-plugin.
      
      This patch thus declares the requirement.  As it turns out, there's an
      undocumented dg-require-linker-plugin already, but I introduce and use
      the corresponding effective-target keyword and document both.
      
      Given that the effective-target form is more flexible, I'm tempted to
      remove dg-require-* with an empty arg as already mentioned in
      sourcebuild.texi.  That is not this patch, however.
      
      Tested on i386-pc-solaris2.11 with ld and gld.
      
      2024-02-14  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
      
      	gcc/testsuite:
      	PR ipa/98237
      	* lib/target-supports.exp (is-effective-target): Handle
      	linker_plugin.
      	* gcc.dg/lto/modref-3_0.c: Require linker_plugin support.
      	* gcc.dg/lto/modref-4_0.c: Likewise.
      
      	gcc:
      	* doc/sourcebuild.texi (Effective-Target Keywords, Other
      	attribugs): Document linker_plugin.
      	(Require Support): Document dg-require-linker-plugin.
      de658585
    • Kito Cheng's avatar
      RISC-V: Add new option -march=help to print all supported extensions · 7af0f1e1
      Kito Cheng authored
      
      The output of -march=help is like below:
      
      ```
      All available -march extensions for RISC-V:
              Name                Version
              i                       2.0, 2.1
              e                       2.0
              m                       2.0
              a                       2.0, 2.1
              f                       2.0, 2.2
              d                       2.0, 2.2
      ...
      ```
      
      Also support -print-supported-extensions and --print-supported-extensions for
      clang compatibility.
      
      gcc/ChangeLog:
      
      	PR target/109349
      
      	* common/config/riscv/riscv-common.cc (riscv_arch_help): New.
      	* config/riscv/riscv-protos.h (RISCV_MAJOR_VERSION_BASE): New.
      	(RISCV_MINOR_VERSION_BASE): Ditto.
      	(RISCV_REVISION_VERSION_BASE): Ditto.
      	* config/riscv/riscv-c.cc (riscv_ext_version_value): Use enum
      	rather than magic number.
      	* config/riscv/riscv.h (riscv_arch_help): New.
      	(EXTRA_SPEC_FUNCTIONS): Add riscv_arch_help.
      	(DRIVER_SELF_SPECS): Handle -march=help, -print-supported-extensions and
      	--print-supported-extensions.
      	* config/riscv/riscv.opt (march=help): New.
      	(print-supported-extensions): New.
      	(-print-supported-extensions): New.
      	* doc/invoke.texi (RISC-V Options): Document -march=help.
      
      Reviewed-by: default avatarChristoph Müllner <christoph.muellner@vrull.eu>
      7af0f1e1
Loading