Skip to content
Snippets Groups Projects
  1. Mar 02, 2025
    • Sandra Loosemore's avatar
      Fortran: Move "Standard" subheading in documentation [PR47928] · 43f2bc4a
      Sandra Loosemore authored
      As noted in the issue, the version of the standard an intrinsic was
      introduced in is usually not the second-most-important thing a user
      needs to know.  This patch moves it from near the beginning of each
      section towards the end, just ahead of "See also".
      
      gcc/fortran/ChangeLog
      	PR fortran/47928
      	* intrinsic.texi: Move the "Standard" subheading farther down.
      43f2bc4a
    • Sandra Loosemore's avatar
      Fortran: Rename/move "Syntax" subheading in documentation [PR47928] · 9edd165e
      Sandra Loosemore authored
      As suggested in the issue, it makes more sense to describe the function
      call argument syntax before talking about the arguments in the description.
      
      gcc/fortran/ChangeLog
      	PR fortran/47928
      	* gfortran.texi: Move all the "Syntax" subheadings ahead of
      	"Description", and rename to "Synopsis".
      	* intrinsic.texi: Likewise.
      9edd165e
    • Sandra Loosemore's avatar
      Fortran: Whitespace cleanup in documentation [PR47928] · 1f458cfc
      Sandra Loosemore authored
      This is a preparatory patch for the main changes requested in the issue.
      
      gcc/fortran/ChangeLog
      	PR fortran/47928
      	* intrinsic.texi: Put a blank line between "@item @emph{}"
      	subheadings, but not more than one.
      1f458cfc
    • Sandra Loosemore's avatar
      Fortran: Tidy subheadings in Fortran documentation [PR47928] · d8f5e1b0
      Sandra Loosemore authored
      This is a preparatory patch for the main documentation changes requested
      in the issue.
      
      gcc/fortran/ChangeLog
      	PR fortran/47928
      	* gfortran.texi: Consistently use "@emph{Notes}:" instead of
      	other spellings.
      	* intrinsic.texi: Likewise.  Also fix an inconsistent capitalization
      	and remove a redundant "Standard" entry.
      d8f5e1b0
    • Jakub Jelinek's avatar
      avr: Fix up avr_print_operand diagnostics [PR118991] · 047b7f9a
      Jakub Jelinek authored
      As can be seen in gcc/po/gcc.pot:
       #: config/avr/avr.cc:2754
       #, c-format
       msgid "bad I/O address 0x"
       msgstr ""
      
      exgettext couldn't retrieve the whole format string in this case,
      because it uses a macro in the middle.  output_operand_lossage
      is c-format function though, so we can't use %wx to print HOST_WIDE_INT,
      and HOST_WIDE_INT_PRINT_HEX_PURE is on some hosts %lx, on others %llx
      and on others %I64x so isn't really translatable that way.
      
      As Joseph mentioned in the PR, there is no easy way around this
      but go through a temporary buffer, which the following patch does.
      
      2025-03-02  Jakub Jelinek  <jakub@redhat.com>
      
      	PR translation/118991
      	* config/avr/avr.cc (avr_print_operand): Print ival into
      	a temporary buffer and use %s in output_operand_lossage to make
      	the diagnostics translatable.
      047b7f9a
    • Filip Kastl's avatar
      gimple: sccopy: Prune removed statements from SCCs [PR117919] · 5349aa2a
      Filip Kastl authored
      
      While writing the sccopy pass I didn't realize that 'replace_uses_by ()' can
      remove portions of the CFG.  This happens when replacing arguments of some
      statement results in the removal of an EH edge.  Because of this sccopy can
      then work with GIMPLE statements that aren't part of the IR anymore.  In
      PR117919 this triggered an assertion within the pass which assumes that
      statements the pass works with are reachable.
      
      This patch tells the pass to notice when a statement isn't in the IR anymore
      and remove it from it's worklist.
      
      	PR tree-optimization/117919
      
      gcc/ChangeLog:
      
      	* gimple-ssa-sccopy.cc (scc_copy_prop::propagate): Prune
      	statements that 'replace_uses_by ()' removed.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/pr117919.C: New test.
      
      Signed-off-by: default avatarFilip Kastl <fkastl@suse.cz>
      5349aa2a
    • GCC Administrator's avatar
      Daily bump. · 88e620c8
      GCC Administrator authored
      88e620c8
  2. Mar 01, 2025
    • Gerald Pfeifer's avatar
      doc: Simplify description of *-*-freebsd* · 4fee152d
      Gerald Pfeifer authored
      gcc:
      	PR target/69374
      	* doc/install.texi (Specific, *-*-freebsd*): Simplify description.
      4fee152d
    • Jakub Jelinek's avatar
      ggc: Fix up ggc_internal_cleared_alloc_no_dtor [PR117047] · ff38712b
      Jakub Jelinek authored
      Apparently I got one of the !HAVE_ATTRIBUTE_ALIAS fallbacks wrong.
      
      It compiled with a warning:
      ../../gcc/ggc-common.cc: In function 'void* ggc_internal_cleared_alloc_no_dtor(size_t, void (*)(void*), size_t, size_t)':
      ../../gcc/ggc-common.cc:154:44: warning: unused parameter 'size' [-Wunused-parameter]
        154 | ggc_internal_cleared_alloc_no_dtor (size_t size, void (*f)(void *),
            |                                     ~~~~~~~^~~~
      and obviously didn't work right (always allocated 0-sized objects).
      
      Fixed thusly.
      
      2025-03-01  Jakub Jelinek  <jakub@redhat.com>
      
      	PR jit/117047
      	* ggc-common.cc (ggc_internal_cleared_alloc_no_dtor): Pass size
      	rather than s as the first argument to ggc_internal_cleared_alloc.
      ff38712b
    • Harald Anlauf's avatar
      Fortran: fix front-end memleak after failure during parsing of NULLIFY · f7db0263
      Harald Anlauf authored
      gcc/fortran/ChangeLog:
      
      	* match.cc (gfc_match_nullify): Free matched expression when
      	cleaning up.
      	* primary.cc (match_variable): Initialize result to NULL.
      f7db0263
    • Yuriy Kolerov's avatar
      [PR target/118906] [PATCH v2] RISC-V: Fix a typo in zce to zcf implication · a0d29dd2
      Yuriy Kolerov authored
      zce must imply zcf but this rule was corrupted after
      refactoring in 9e12010b. This may be observed
      ater generating an .s file from any source code file with
      -mriscv-attribute -march=rv32if_zce -mabi=ilp32 -S
      options. A full march will be presented in arch attribute:
      
          rv32i2p1_f2p2_zicsr2p0_zca1p0_zcb1p0_zce1p0_zcmp1p0_zcmt1p0
      
      As you see, zcf is not presented here though f_zce pair is
      passed in -march. According to The RISC-V Instruction
      Set Manual:
      
          Specifying Zce on RV32 with F includes Zca, Zcb, Zcmp,
          Zcmt and Zcf.
      
      	PR target/118906
      gcc/ChangeLog:
      
      	* common/config/riscv/riscv-common.cc: fix zce to zcf
      	implication.
      
      gcc/testsuite/ChangeLog:
      
      	* gcc.target/riscv/attribute-zce-1.c: New test.
      	* gcc.target/riscv/attribute-zce-2.c: New test.
      	* gcc.target/riscv/attribute-zce-3.c: New test.
      	* gcc.target/riscv/attribute-zce-4.c: New test.
      a0d29dd2
    • Jan Dubiec's avatar
      [PATCH] H8/300, libgcc: PR target/114222 For HImode call internal ffs()... · 898f22d1
      Jan Dubiec authored
      [PATCH] H8/300, libgcc: PR target/114222 For HImode call internal ffs() implementation instead of an external one
      
      When INT_TYPE_SIZE < BITS_PER_WORD gcc emits a call to an external ffs()
      implementation instead of a call to "__builtin_ffs()" – see function
      init_optabs() in <SRCROOT>/gcc/optabs-libfuncs.cc. External ffs()
      (which is usually the one from newlib) in turn calls __builtin_ffs()
      what causes infinite recursion and stack overflow. This patch overrides
      default gcc bahaviour for H8/300H (and newer) and provides a generic
      ffs() implementation for HImode.
      
      	PR target/114222
      gcc/ChangeLog:
      
      	* config/h8300/h8300.cc (h8300_init_libfuncs): For HImode override
      	calls to external ffs() (from newlib) with calls to __ffshi2() from
      	libgcc. The implementation of ffs() in newlib calls __builtin_ffs()
      	what causes infinite recursion and finally a stack overflow.
      
      libgcc/ChangeLog:
      
      	* config/h8300/t-h8300: Add __ffshi2().
      	* config/h8300/ffshi2.c: New file.
      898f22d1
    • Jakub Jelinek's avatar
      input: Fix UB during self-tests [PR119052] · dfdbad87
      Jakub Jelinek authored
      As the comment in check_line says:
        /* get_buffer is not null terminated, but the sscanf stops after a number.  */
      the buffer is not null terminated, there is line.length () to determine
      the size of the line.  But unlike what the comment says, sscanf actually
      still requires null terminated string argument, anything else is UB.
      E.g. glibc when initializing the temporary FILE stream for the string does
        if (size == 0)
          end = strchr (ptr, '\0');
      and this strchr/rawmemchr is what shows up in valgrind report on cc1/cc1plus
      doing self-tests.
      
      The function is used only in a test with 1000 lines, each containg its
      number, so numbers from 1 to 1000 inclusive (each time with '\n' separator,
      but that isn't included in line.length ()).
      
      So the function just uses a temporary buffer which can fit numbers from 1 to
      1000 as strings with terminating '\0' and runs sscanf on that (why not
      strtoul?).
      
      Furthermore, the caller allocated number of lines * 15 bytes for the
      string, but 1000\n is 5 bytes, so I think * 5 is more than enough.
      
      2025-03-01  Jakub Jelinek  <jakub@redhat.com>
      
      	PR other/119052
      	* input.cc (check_line): Don't call sscanf on non-null terminated
      	buffer, instead copy line.length () bytes from line.get_buffer ()
      	to a local buffer, null terminate it and call sscanf on that.
      	Formatting fix.
      	(test_replacement): Just allocate maxline * 5 rather than maxline * 15
      	bytes for the file.  Formatting fix.
      dfdbad87
    • GCC Administrator's avatar
      Daily bump. · 89c4a0b1
      GCC Administrator authored
      89c4a0b1
    • Jakub Jelinek's avatar
      ggc: Avoid using ATTRIBUTE_MALLOC for allocations that need finalization [PR117047] · 8c15a6ce
      Jakub Jelinek authored
      As analyzed by Andrew/David/Richi/Sam in the PR, the reason for the
      libgccjit ICE is that there are GC allocations with finalizers and we
      still mark ggc_internal_{,cleared_}alloc with ATTRIBUTE_MALLOC, which
      to the optimizers hints that nothing will actually read the state
      of the objects when they get out of lifetime.  The finalizer actually
      inspects those though.  What actually happens in the testcases is that on
        tree expr_size = TYPE_SIZE (expr->get_type ()->as_tree ());
      we see that expr->get_type () was allocated using something with malloc
      attribute but it doesn't escape and only the type size from it is queried,
      so there is no need to store other members of it.  Except that it does escape
      in the GC internals.  Normal GC allocations are fine, they don't look at the
      data in the allocated objects on "free", but the ones with finalizers actually
      call a function on that object and expect the data to be in there.
      So that we don't lose ATTRIBUTE_MALLOC for the common case when no
      finalization is needed, the following patch uses the approach used e.g.
      for glibc error function which can sometimes be noreturn but at other
      times just return normally.
      If possible, it uses __attribute__((alias ("..."))) to add an alias
      to the function, where one is without ATTRIBUTE_MALLOC and one
      (with _no_dtor suffix) is with ATTRIBUTE_MALLOC (note, as this is
      C++ and I didn't want to hardcode particular mangling I used an
      extern "C" function with 2 aliases to it), and otherwise adds a wrapper
      (for the ggc-page/ggc-common case with noinline attribute if possible,
      for ggc-none that doesn't matter because ggc-none doesn't support
      finalizers).
      The *_no_dtor aliases/wrappers are then used in inline functions which
      pass unconditional NULL, 0 as the f/s pair.
      
      2025-03-01  Jakub Jelinek  <jakub@redhat.com>
      
      	PR jit/117047
      	* acinclude.m4 (gcc_CHECK_ATTRIBUTE_ALIAS): New.
      	* configure.ac: Add gcc_CHECK_ATTRIBUTE_ALIAS.
      	* ggc.h (ggc_internal_alloc): Remove ATTRIBUTE_MALLOC from
      	overload with finalizer pointer.  Call ggc_internal_alloc_no_dtor
      	in inline overload without finalizer pointer.
      	(ggc_internal_alloc_no_dtor): Declare.
      	(ggc_internal_cleared_alloc): Remove ATTRIBUTE_MALLOC from
      	overload with finalizer pointer.  Call
      	ggc_internal_cleared_alloc_no_dtor in inline overload without
      	finalizer pointer.
      	(ggc_internal_cleared_alloc_no_dtor): Declare.
      	(ggc_alloc): Call ggc_internal_alloc_no_dtor if no finalization
      	is needed.
      	(ggc_alloc_no_dtor): Call ggc_internal_alloc_no_dtor.
      	(ggc_cleared_alloc): Call ggc_internal_cleared_alloc_no_dtor if no
      	finalization is needed.
      	(ggc_vec_alloc): Call ggc_internal_alloc_no_dtor if no finalization
      	is needed.
      	(ggc_cleared_vec_alloc): Call ggc_internal_cleared_alloc_no_dtor if no
      	finalization is needed.
      	* ggc-page.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
      	overload with finalizer into alias to ggc_internal_alloc_ and
      	rename it to ...
      	(ggc_internal_alloc_): ... this, make it extern "C".
      	(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
      	otherwise new noinline wrapper.
      	* ggc-common.cc (ggc_internal_cleared_alloc): If HAVE_ATTRIBUTE_ALIAS,
      	turn overload with finalizer into alias to ggc_internal_alloc_ and
      	rename it to ...
      	(ggc_internal_cleared_alloc_): ... this, make it extern "C".
      	(ggc_internal_cleared_alloc_no_dtor): New alias if
      	HAVE_ATTRIBUTE_ALIAS, otherwise new noinline wrapper.
      	* ggc-none.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
      	overload with finalizer into alias to ggc_internal_alloc_ and
      	rename it to ...
      	(ggc_internal_alloc_): ... this, make it extern "C".
      	(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
      	otherwise new wrapper.
      	(ggc_internal_cleared_alloc): If HAVE_ATTRIBUTE_ALIAS, turn overload
      	with finalizer into alias to ggc_internal_alloc_ and rename it to ...
      	(ggc_internal_cleared_alloc_): ... this, make it extern "C".
      	(ggc_internal_cleared_alloc_no_dtor): New alias if
      	HAVE_ATTRIBUTE_ALIAS, otherwise new wrapper.
      	* genmatch.cc (ggc_internal_cleared_alloc, ggc_free): Formatting fix.
      	(ggc_internal_cleared_alloc_no_dtor): Define.
      	* config.in: Regenerate.
      	* configure: Regenerate.
      8c15a6ce
    • Jakub Jelinek's avatar
      openmp: Fix up simd clone mask argument creation on x86 [PR115871] · 6589eb4e
      Jakub Jelinek authored
      The following testcase ICEs since r14-5057.
      The Intel vector ABI says that in the ZMM case the masks is passed
      in unsigned int or unsigned long long arguments and how many bits in
      them and how many of those arguments are is determined by the characteristic
      data type of the function.  In the testcase simdlen is 32 and characteristic
      data type is double, so return as well as first argument is passed in 4
      V8DFmode arguments and the mask is supposed to be passed in 4 unsigned int
      arguments (8 bits in each).
      Before the r14-5057 change there was
            sc->args[i].orig_type = parm_type;
      ...
              case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
              case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
              case SIMD_CLONE_ARG_TYPE_VECTOR:
                if (INTEGRAL_TYPE_P (parm_type) || POINTER_TYPE_P (parm_type))
                  veclen = sc->vecsize_int;
                else
                  veclen = sc->vecsize_float;
                if (known_eq (veclen, 0U))
                  veclen = sc->simdlen;
                else
                  veclen
                    = exact_div (veclen,
                                 GET_MODE_BITSIZE (SCALAR_TYPE_MODE (parm_type)));
      for the argument handling and
        if (sc->inbranch)
          {
            tree base_type = simd_clone_compute_base_data_type (sc->origin, sc);
      ...
            if (INTEGRAL_TYPE_P (base_type) || POINTER_TYPE_P (base_type))
              veclen = sc->vecsize_int;
            else
              veclen = sc->vecsize_float;
            if (known_eq (veclen, 0U))
              veclen = sc->simdlen;
            else
              veclen = exact_div (veclen,
                                  GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type)));
      for the mask handling.  r14-5057 moved this argument creation later and
      unified that:
              case SIMD_CLONE_ARG_TYPE_MASK:
              case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
              case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
              case SIMD_CLONE_ARG_TYPE_VECTOR:
                if (sc->args[i].arg_type == SIMD_CLONE_ARG_TYPE_MASK
                    && sc->mask_mode != VOIDmode)
                  elem_type = boolean_type_node;
                else
                  elem_type = TREE_TYPE (sc->args[i].vector_type);
                if (INTEGRAL_TYPE_P (elem_type) || POINTER_TYPE_P (elem_type))
                  veclen = sc->vecsize_int;
                else
                  veclen = sc->vecsize_float;
                if (known_eq (veclen, 0U))
                  veclen = sc->simdlen;
                else
                  veclen
                    = exact_div (veclen,
                                 GET_MODE_BITSIZE (SCALAR_TYPE_MODE (elem_type)));
      This is correct for the argument cases (so linear or vector) (though
      POINTER_TYPE_P will never appear as TREE_TYPE of a vector), but the
      boolean_type_node in there is completely bogus, when using AVX512 integer
      masks as I wrote above we need the characteristic data type, not bool,
      and bool is strange in that it has bitsize of 8 (or 32 on darwin), while
      the masks are 1 bit per lane anyway.
      
      Fixed thusly.
      
      2025-03-01  Jakub Jelinek  <jakub@redhat.com>
      
      	PR middle-end/115871
      	* omp-simd-clone.cc (simd_clone_adjust): For SIMD_CLONE_ARG_TYPE_MASK
      	and sc->mask_mode not VOIDmode, set elem_type to the characteristic
      	type rather than boolean_type_node.
      
      	* gcc.dg/gomp/simd-clones-8.c: New test.
      6589eb4e
    • Jan Dubiec's avatar
      [PATCH] H8/300: PR target/109189 Silence -Wformat warnings on Windows · 2fc17730
      Jan Dubiec authored
      This patch fixes annoying -Wformat warnings when gcc is built
      on Windows/MinGW64. Instead of %ld it uses HOST_WIDE_INT_PRINT_DEC
      macro, just like many other targets do.
      
      	PR target/109189
      gcc/ChangeLog:
      
      	* config/h8300/h8300.cc (h8300_print_operand): Replace %ld format
      	strings with HOST_WIDE_INT_PRINT_DEC macro in order to silence
      	-Wformat warnings when building on Windows/MinGW64.
      2fc17730
    • Xi Ruoyao's avatar
      testsuite: Fix up toplevel-asm-1.c for LoongArch · 20d95bfa
      Xi Ruoyao authored
      Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs
      even with -fno-pic.
      
      gcc/testsuite/ChangeLog:
      
      	* c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3
      	%c4 on LoongArch.
      20d95bfa
  3. Feb 28, 2025
    • Jonathan Wakely's avatar
      libstdc++: Fix ranges::iter_move handling of rvalues [PR106612] · a8ee522c
      Jonathan Wakely authored
      
      The specification for std::ranges::iter_move apparently requires us to
      handle types which do not satisfy std::indirectly_readable, for example
      with overloaded operator* which behaves differently for different value
      categories.
      
      libstdc++-v3/ChangeLog:
      
      	PR libstdc++/106612
      	* include/bits/iterator_concepts.h (_IterMove::__iter_ref_t):
      	New alias template.
      	(_IterMove::__result): Use __iter_ref_t instead of
      	std::iter_reference_t.
      	(_IterMove::__type): Remove incorrect __dereferenceable
      	constraint.
      	(_IterMove::operator()): Likewise. Add correct constraints. Use
      	__iter_ref_t instead of std::iter_reference_t. Forward parameter
      	as correct value category.
      	(iter_swap): Add comments.
      	* testsuite/24_iterators/customization_points/iter_move.cc: Test
      	that iter_move is found by ADL and that rvalue arguments are
      	handled correctly.
      
      Reviewed-by: default avatarPatrick Palka <ppalka@redhat.com>
      a8ee522c
    • Jonathan Wakely's avatar
      libstdc++: Fix ranges::move and ranges::move_backward to use iter_move [PR105609] · 3866ca79
      Jonathan Wakely authored
      The ranges::move and ranges::move_backward algorithms are supposed to
      use ranges::iter_move(iter) instead of std::move(*iter), which matters
      for an iterator type with an iter_move overload findable by ADL.
      
      Currently those algorithms use std::__assign_one which uses std::move,
      so define a new ranges::__detail::__assign_one helper function that uses
      ranges::iter_move.
      
      libstdc++-v3/ChangeLog:
      
      	PR libstdc++/105609
      	* include/bits/ranges_algobase.h (__detail::__assign_one): New
      	helper function.
      	(__copy_or_move, __copy_or_move_backward): Use new function
      	instead of std::__assign_one.
      	* testsuite/25_algorithms/move/constrained.cc: Check that
      	ADL iter_move is used in preference to std::move.
      	* testsuite/25_algorithms/move_backward/constrained.cc:
      	Likewise.
      3866ca79
    • Jonathan Wakely's avatar
      libstdc++: Add static_assertions to ranges::to adaptor factory [PR112803] · a9cfcd0d
      Jonathan Wakely authored
      The standard requires that we reject attempts to create a ranges::to
      adaptor for cv-qualified types and non-class types. Currently we only
      diagnose it once the adaptor is used in a pipeline.
      
      This adds static assertions to diagnose it immediately.
      
      libstdc++-v3/ChangeLog:
      
      	PR libstdc++/112803
      	* include/std/ranges (ranges::to): Add static assertions to
      	enforce Mandates conditions.
      	* testsuite/std/ranges/conv/112803.cc: New test.
      a9cfcd0d
    • Iain Buclaw's avatar
      d: Fix comparing uninitialized memory in dstruct.d [PR116961] · f7bc17eb
      Iain Buclaw authored
      Floating-point emulation in the D front-end is done via a type named
      `struct longdouble`, which in GDC is a small interface around the
      real_value type. Because the D code cannot include gcc/real.h directly,
      a big enough buffer is used for the data instead.
      
      On x86_64, this buffer is actually bigger than real_value itself, so
      when a new longdouble object is created with
      
          longdouble r;
          real_from_string3 (&r.rv (), buffer, mode);
          return r;
      
      there is uninitialized padding at the end of `r`.  This was never a
      problem when D was implemented in C++ (until GCC 12) as comparing two
      longdouble objects with `==' would be forwarded to the relevant
      operator== overload that extracted the underlying real_value.
      
      However when the front-end was translated to D, such conditions were
      instead rewritten into identity comparisons
      
          return exp.toReal() is CTFloat.zero
      
      The `is` operator gets lowered as a call to `memcmp() == 0', which is
      where the read of uninitialized memory occurs, as seen by valgrind.
      
      ==26778== Conditional jump or move depends on uninitialised value(s)
      ==26778==    at 0x911F41: dmd.dstruct._isZeroInit(dmd.expression.Expression) (dstruct.d:635)
      ==26778==    by 0x9123BE: StructDeclaration::finalizeSize() (dstruct.d:373)
      ==26778==    by 0x86747C: dmd.aggregate.AggregateDeclaration.determineSize(ref const(dmd.location.Loc)) (aggregate.d:226)
      [...]
      
      To avoid accidentally reading uninitialized data, explicitly initialize
      all `longdouble` variables with an empty constructor on C++ side of the
      implementation before initializing underlying real_value type it holds.
      
      	PR d/116961
      
      gcc/d/ChangeLog:
      
      	* d-codegen.cc (build_float_cst): Change new_value type from real_t to
      	real_value.
      	* d-ctfloat.cc (CTFloat::fabs): Default initialize the return value.
      	(CTFloat::ldexp): Likewise.
      	(CTFloat::parse): Likewise.
      	* d-longdouble.cc (longdouble::add): Likewise.
      	(longdouble::sub): Likewise.
      	(longdouble::mul): Likewise.
      	(longdouble::div): Likewise.
      	(longdouble::mod): Likewise.
      	(longdouble::neg): Likewise.
      	* d-port.cc (Port::isFloat32LiteralOutOfRange): Likewise.
      	(Port::isFloat64LiteralOutOfRange): Likewise.
      
      gcc/testsuite/ChangeLog:
      
      	* gdc.dg/pr116961.d: New test.
      f7bc17eb
    • Marek Polacek's avatar
      c++: fix rejects-valid and ICE with constexpr NSDMI [PR110822] · 96572464
      Marek Polacek authored
      
      Since r10-7718 the attached tests produce an ICE in verify_address:
      
        error: constant not recomputed when 'ADDR_EXPR' changed
      
      but before that we wrongly rejected the tests with "is not a constant
      expression".  This patch fixes both problems.
      
      Since r10-7718 replace_decl_r can replace
      
        {._M_dataplus=&<retval>._M_local_buf, ._M_local_buf=0}
      
      with
      
        {._M_dataplus=&HelloWorld._M_local_buf, ._M_local_buf=0}
      
      The initial &<retval>._M_local_buf was not constant, but since
      HelloWorld is a static VAR_DECL, the resulting &HelloWorld._M_local_buf
      should have been marked as TREE_CONSTANT.  And since we're taking
      its address, the whole thing should be TREE_ADDRESSABLE.
      
      	PR c++/114913
      	PR c++/110822
      
      gcc/cp/ChangeLog:
      
      	* constexpr.cc (replace_decl_r): If we've replaced something
      	inside of an ADDR_EXPR, call cxx_mark_addressable and
      	recompute_tree_invariant_for_addr_expr on the resulting ADDR_EXPR.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp0x/constexpr-nsdmi4.C: New test.
      	* g++.dg/cpp0x/constexpr-nsdmi5.C: New test.
      
      Reviewed-by: default avatarJason Merrill <jason@redhat.com>
      96572464
    • Marek Polacek's avatar
      c++: ICE in replace_decl [PR118986] · 22018a4a
      Marek Polacek authored
      
      Yet another problem that started with r15-6052, compile time evaluation of
      prvalues.
      
      cp_fold_r/TARGET_EXPR sees:
      
        TARGET_EXPR <D.2701, <<< Unknown tree: expr_stmt
          D.2701.__p = TARGET_EXPR <D.2684, <<< Unknown tree: aggr_init_expr
            3
            f1
            D.2684 >>>> >>>>
      
      so when we call maybe_constant_init, the object we're initializing is D.2701,
      and the init is the expr_stmt.  We unwrap the EXPR_STMT/INIT_EXPR/TARGET_EXPR
      in maybe_constant_init_1 and so end up evaluating the f1 call.  But f1 returns
      c2 whereas the type of D.2701 is ._anon_0 -- the closure.
      
      So then we crash in replace_decl on:
      
      	  gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p
      			       (TREE_TYPE (decl), TREE_TYPE (replacement)));
      
      due to the mismatched types.
      
      cxx_eval_outermost_constant_expr is already ready for the types to be
      different, in which case the result isn't constant.  But replace_decl
      is called before that check.
      
      I'm leaving the assert in replace_decl on purpose, maybe we'll find
      another use for it.
      
      	PR c++/118986
      
      gcc/cp/ChangeLog:
      
      	* constexpr.cc (cxx_eval_call_expression): Check that the types match
      	before calling replace_decl, if not, set *non_constant_p.
      	(maybe_constant_init_1): Don't strip INIT_EXPR if it would change the
      	type of the expression.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp2a/constexpr-prvalue1.C: New test.
      
      Reviewed-by: default avatarJason Merrill <jason@redhat.com>
      22018a4a
    • Martin Jambor's avatar
      ipa-sra: Avoid clashes with ipa-cp when pulling accesses across calls (PR 118243) · 0bffcd46
      Martin Jambor authored
      Among other things, IPA-SRA checks whether splitting out a bit of an
      aggregate or something passed by reference would lead into a clash
      with an already known IPA-CP constant a way which would cause problems
      later on.  Unfortunately the test is done only in
      adjust_parameter_descriptions and is missing when accesses are
      propagated from callees to callers, which leads to miscompilation
      reported as PR 118243 (where the callee is a function created by
      ipa-split).
      
      The matter is then further complicated by the fact that we consider
      complex numbers as scalars even though they can be modified piecemeal
      (IPA-CP can detect and propagate the pieces separately too) which then
      confuses the parameter manipulation machinery furter.
      
      This patch simply adds the missing check to avoid the IPA-SRA
      transform in these cases too, which should be suitable for backporting
      to all affected release branches.  It is a bit of a shame as in the PR
      testcase we do propagate both components of the complex number in
      question and the transformation phase could recover.  I have some
      prototype patches in this direction but that is something for (a)
      stage 1.
      
      gcc/ChangeLog:
      
      2025-02-10  Martin Jambor  <mjambor@suse.cz>
      
      	PR ipa/118243
      	* ipa-sra.cc (pull_accesses_from_callee): New parameters
      	caller_ipcp_ts and param_idx.  Check that scalar pulled accesses would
      	not clash with a known IPA-CP aggregate constant.
      	(param_splitting_across_edge): Pass IPA-CP transformation summary and
      	caller parameter index to pull_accesses_from_callee.
      
      gcc/testsuite/ChangeLog:
      
      2025-02-10  Martin Jambor  <mjambor@suse.cz>
      
      	PR ipa/118243
      	* g++.dg/ipa/pr118243.C: New test.
      0bffcd46
    • Patrick Palka's avatar
      c++: generic lambda, implicit 'this' capture, xobj memfn [PR119038] · 1a150f1f
      Patrick Palka authored
      
      When a generic lambda calls an overload set containing an iobj member
      function we speculatively capture 'this'.  We need to do the same
      for an xobj member function.
      
      	PR c++/119038
      
      gcc/cp/ChangeLog:
      
      	* lambda.cc (maybe_generic_this_capture): Consider xobj
      	member functions as well, not just iobj.  Update function
      	comment.
      
      gcc/testsuite/ChangeLog:
      
      	* g++.dg/cpp23/explicit-obj-lambda15.C: New test.
      
      Reviewed-by: default avatarJason Merrill <jason@redhat.com>
      1a150f1f
    • Patrick Palka's avatar
      libstdc++: Improve optional's <=> constraint recursion workaround [PR104606] · 815f1f27
      Patrick Palka authored
      
      It turns out the reason the behavior of this testcase changed after CWG
      2369 is because validity of the substituted return type is now checked
      later, after constraints.  So a more reliable workaround for this issue
      is to add a constraint to check the validity of the return type earlier,
      matching the pre-CWG 2369 semantics.
      
      	PR libstdc++/104606
      
      libstdc++-v3/ChangeLog:
      
      	* include/std/optional (operator<=>): Revert r14-9771 change.
      	Add constraint checking the validity of the return type
      	compare_three_way_result_t before the three_way_comparable_with
      	constraint.
      
      Reviewed-by: default avatarJonathan Wakely <jwakely@redhat.com>
      815f1f27
    • Patrick Palka's avatar
      libstdc++: Fix constraint recursion in basic_const_iterator relops [PR112490] · 4342c50c
      Patrick Palka authored
      
      Here for
      
        using RCI = reverse_iterator<basic_const_iterator<vector<int>::iterator>>
        static_assert(std::totally_ordered<RCI>);
      
      we effectively need to check the requirement
      
        requires (RCI x) { x RELOP x; }  for each RELOP in {<, >, <=, >=}
      
      which we expect to be straightforwardly satisfied by reverse_iterator's
      namespace-scope relops.  But due to ADL we find ourselves also
      considering the basic_const_iterator relop friends, which before CWG
      2369 would be quickly discarded since RCI clearly isn't convertible to
      basic_const_iterator.  After CWG 2369 though we must first check these
      relops' constraints (with _It = vector<int>::iterator and _It2 = RCI),
      which entails checking totally_ordered<RCI> recursively.
      
      This patch fixes this by turning the problematic non-dependent function
      parameters of type basic_const_iterator<_It> into dependent ones of
      type basic_const_iterator<_It3> where _It3 is constrained to match _It.
      Thus the basic_const_iterator relop friends now get quickly discarded
      during deduction and before the constraint check if the second operand
      isn't a specialization of basic_const_iterator (or derived from one)
      like before CWG 2369.
      
      	PR libstdc++/112490
      
      libstdc++-v3/ChangeLog:
      
      	* include/bits/stl_iterator.h (basic_const_iterator::operator<):
      	Replace non-dependent basic_const_iterator function parameter with
      	a dependent one of type basic_const_iterator<_It3> where _It3
      	matches _It.
      	(basic_const_iterator::operator>): Likewise.
      	(basic_const_iterator::operator<=): Likewise.
      	(basic_const_iterator::operator>=): Likewise.
      	* testsuite/24_iterators/const_iterator/112490.cc: New test.
      
      Reviewed-by: default avatarJonathan Wakely <jwakely@redhat.com>
      4342c50c
    • Jakub Jelinek's avatar
      c++: Fix cxx_eval_store_expression {REAL,IMAG}PART_EXPR handling [PR119045] · 7eb8ec18
      Jakub Jelinek authored
      I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
      always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
      etc. on it further doesn't make sense and the later code relies on it
      to be the last one in refs array.  But as the following testcase shows,
      we can fail those assertions in case there is a reference or pointer
      to the __real__ or __imag__ part, in that case we just evaluate the
      constant expression and so probe won't be the same as target.
      That case doesn't push anything into the refs array though.
      
      The following patch changes those asserts to verify that refs is still
      empty, which fixes it.
      
      2025-02-28  Jakub Jelinek  <jakub@redhat.com>
      
      	PR c++/119045
      	* constexpr.cc (cxx_eval_store_expression) <case REALPART_EXPR>:
      	Assert that refs->is_empty () rather than probe == target.
      	(cxx_eval_store_expression) <case IMAGPART_EXPR>: Likewise.
      
      	* g++.dg/cpp1y/constexpr-complex2.C: New test.
      7eb8ec18
    • Jakub Jelinek's avatar
      c++: Adjust #embed support for P1967R14 · b510c53b
      Jakub Jelinek authored
      Now that the #embed paper has been voted in, the following patch
      removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
      older C++ versions) and predefines __cpp_pp_embed FTM.
      
      Also, the patch changes cpp_error to cpp_pedwarning with for C++
      -Wc++26-extensions guarding, and for C add -Wc11-c23-compat warning
      about #embed.
      
      I believe we otherwise implement everything in the paper already,
      except I'm really confused by the
       [Example:
      
       #embed <data.dat> limit(__has_include("a.h"))
      
       #if __has_embed(<data.dat> limit(__has_include("a.h")))
       // ill-formed: __has_include [cpp.cond] cannot appear here
       #endif
      
       — end example]
      part.  My reading of both C23 and C++ with the P1967R14 paper in
      is that the first case (#embed with __has_include or __has_embed in its
      clauses) is what is clearly invalid and so the ill-formed note should be
      for #embed.  And the __has_include/__has_embed in __has_embed is actually
      questionable.
      Both C and C++ have something like
      "The identifiers __has_include, __has_embed, and __has_c_attribute
      shall not appear in any context not mentioned in this subclause."
      or
      "The identifiers __has_include and __has_cpp_attribute shall not appear
      in any context not mentioned in this subclause."
      (into which P1967R14 adds __has_embed) in the conditional inclusion
      subclause.  #embed is defined in a different one, so using those in there
      is invalid (unless "using the rules specified for conditional inclusion"
      wording e.g. in limit clause overrides that).
      The reason why I think it is fuzzy for __has_embed is that __has_embed
      is actually defined in the Conditional inclusion subclause (so that
      would mean one can use __has_include, __has_embed and __has_*attribute
      in there) but its clauses are described in a different one.
      
      GCC currently accepts
       #embed __FILE__ limit (__has_include (<stdarg.h>))
       #if __has_embed (__FILE__ limit (__has_include (<stdarg.h>)))
       #endif
       #embed __FILE__ limit (__has_embed (__FILE__))
       #if __has_embed (__FILE__ limit (__has_embed (__FILE__)))
       #endif
      Note, it isn't just about limit clause, but also about
      prefix/suffix/if_empty, except that in those cases the "using the rules
      specified for conditional inclusion" doesn't apply.
      
      In any case, I'd hope that can be dealt with incrementally (and should
      be handled the same for both C and C++).
      
      2025-02-28  Jakub Jelinek  <jakub@redhat.com>
      
      libcpp/
      	* include/cpplib.h (enum cpp_warning_reason): Add
      	CPP_W_CXX26_EXTENSIONS enumerator.
      	* init.cc (lang_defaults): Set embed for GNUCXX26 and CXX26.
      	* directives.cc (do_embed): Adjust pedwarn wording for embed in C++,
      	use cpp_pedwarning instead of cpp_error and add CPP_W_C11_C23_COMPAT
      	warning of cpp_pedwarning hasn't diagnosed anything.
      gcc/c-family/
      	* c.opt (Wc++26-extensions): Add CppReason(CPP_W_CXX26_EXTENSIONS).
      	* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_pp_embed=202502
      	for C++26.
      gcc/testsuite/
      	* g++.dg/cpp/embed-1.C: Adjust for pedwarn wording change and don't
      	expect any error for C++26.
      	* g++.dg/cpp/embed-2.C: Adjust for pedwarn wording change and don't
      	expect any warning for C++26.
      	* g++.dg/cpp26/feat-cxx26.C: Test __cpp_pp_embed value.
      	* gcc.dg/cpp/embed-17.c: New test.
      b510c53b
    • Richard Biener's avatar
      lto/91299 - weak definition inlined with LTO · bc34db5b
      Richard Biener authored
      The following fixes a thinko in the handling of interposed weak
      definitions which confused the interposition check in
      get_availability by setting DECL_EXTERNAL too early.
      
      	PR lto/91299
      gcc/lto/
      	* lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL
      	only after calling get_availability.
      
      gcc/testsuite/
      	* gcc.dg/lto/pr91299_0.c: New testcase.
      	* gcc.dg/lto/pr91299_1.c: Likewise.
      bc34db5b
    • Richard Biener's avatar
      ipa/111245 - bogus modref analysis for store in call that might throw · e6037af6
      Richard Biener authored
      We currently record a kill for
      
        *x_4(D) = always_throws ();
      
      because we consider the store always executing since the appropriate
      check for whether the stmt could throw is guarded by
      !cfun->can_throw_non_call_exceptions.
      
      	PR ipa/111245
      	* ipa-modref.cc (modref_access_analysis::analyze_store): Do
      	not guard the check of whether the stmt could throw by
      	cfun->can_throw_non_call_exceptions.
      
      	* g++.dg/torture/pr111245.C: New testcase.
      e6037af6
    • Jakub Jelinek's avatar
      ifcvt: Fix ICE with (fix:SI (fix:DF (reg:DF))) [PR117712] · 26e4783c
      Jakub Jelinek authored
      As documented in the manual, FIX/UNSIGNED_FIX from floating point
      mode to integral mode has unspecified rounding and FIX from floating point
      mode to the same floating point mode is expressing rounding toward zero.
      So, some targets (arc, arm, csky, m68k, mmix, nds32, pdp11, sparc and
      visium) use
      (fix:SI (fix:SF (match_operand:SF 1 "..._operand")))
      etc. to express the rounding toward zero during conversion to integer.
      For some reason other targets don't use that.
      
      Anyway, the 2 FIXes (or inner FIX with outer UNSIGNED_FIX) cause problems
      since the r15-2890 which removed some strict checks in ifcvt.cc on what
      SET_SRC can be actually conditionalized (I must say I'm still worried
      about the change, don't know why one can't get e.g. inline asm or
      something with UNSPEC or some complex backend specific RTLs that
      force_operand can't handle), force_operand just ICEs on it, it can only
      handle (through expand_fix) conversions from floating point to integral.
      
      The following patch fixes this by detecting this case and just pretend
      the inner FIX isn't there, i.e. call expand_fix with the inner FIX's
      operand instead, which works and on targets like arm it will just
      create the nested FIXes again.
      
      2025-02-28  Jakub Jelinek  <jakub@redhat.com>
      
      	PR rtl-optimization/117712
      	* expr.cc (force_operand): Handle {,UNSIGNED_}FIX with
      	FIX operand using expand_fix on the inner FIX operand.
      
      	* gcc.dg/pr117712.c: New test.
      26e4783c
    • Richard Biener's avatar
      tree-optimization/87984 - hard register assignments not preserved · 535115ca
      Richard Biener authored
      The following disables redundant store elimination to hard register
      variables which isn't valid.
      
      	PR tree-optimization/87984
      	* tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do
      	not perform redundant store elimination to hard register
      	variables.
      	* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
      	Likewise.
      
      	* gcc.target/i386/pr87984.c: New testcase.
      535115ca
    • Richard Biener's avatar
      middle-end/66279 - gimplification clobbers shared asm constraints · 95f5d6cc
      Richard Biener authored
      When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints
      fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes.
      At this point doing that seems too dangerous so the following instead
      avoids gimplification of ASM_EXPRs to clobber the shared constraints
      and unshares it there, like it also unshares TREE_VALUE when it
      re-writes a "+" output constraint to separate "=" output and matching
      input constraint.
      
      	PR middle-end/66279
      	* gimplify.cc (gimplify_asm_expr): Copy TREE_PURPOSE before
      	rewriting it for "+" processing.
      
      	* g++.dg/pr66279.C: New testcase.
      95f5d6cc
    • Jakub Jelinek's avatar
      testsuite: Remove -m32 from another i386/ test · 616d1bd1
      Jakub Jelinek authored
      I found another test which uses -m32 in gcc.target/i386/ .  Similarly
      to the previously posted test, the test ought to be tested during i686-linux
      testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
      There is nothing ia32 specific on the test, so I've just dropped the -m32.
      
      2025-02-28  Jakub Jelinek  <jakub@redhat.com>
      
      	* gcc.target/i386/strub-pr118006.c: Remove -m32 from dg-options.
      616d1bd1
    • Jakub Jelinek's avatar
      testsuite: Fix up gcc.target/i386/pr118940.c test [PR118940] · 146cb828
      Jakub Jelinek authored
      The testcase uses -m32 in dg-options, something we try hard not to do,
      if something should be tested only for -m32, it is { target ia32 } test,
      if it can be tested for -m64/-mx32 too, just some extra options are
      needed for ia32, it should have dg-additional-options with ia32 target.
      
      Also, the test wasn't reduced, so I've reduced it using cvise and manual
      tweaks and verified the test still FAILs before r15-7700 and succeeds
      with current trunk.
      
      2025-02-28  Jakub Jelinek  <jakub@redhat.com>
      
      	PR target/118940
      	* gcc.target/i386/pr118940.c: Drop -w, -g and -m32 from dg-options, move
      	-march=i386 -mregparm=3 to dg-additional-options for ia32 and -fno-pie
      	to dg-additional-options for pie.  Reduce the test.
      146cb828
    • Andre Vehreschild's avatar
      Fortran: Ensure finalizer is called for unreferenced variable [PR118730] · c1606e38
      Andre Vehreschild authored
      	PR fortran/118730
      
      gcc/fortran/ChangeLog:
      
      	* resolve.cc: Mark unused derived type variable with finalizers
      	referenced to execute finalizer when leaving scope.
      
      gcc/testsuite/ChangeLog:
      
      	* gfortran.dg/class_array_15.f03: Remove unused variable.
      	* gfortran.dg/coarray_poly_7.f90: Adapt scan-tree-dump expr.
      	* gfortran.dg/coarray_poly_8.f90: Same.
      	* gfortran.dg/finalize_60.f90: New test.
      c1606e38
    • Giuseppe D'Angelo's avatar
      MAINTAINERS: add myself to write after approval and DCO · a3f77f25
      Giuseppe D'Angelo authored
      ChangeLog:
      
      	* MAINTAINERS: Added myself as write after approval and DCO.
      a3f77f25
    • H.J. Lu's avatar
      x86: Move TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P to i386.cc · 075611b6
      H.J. Lu authored
      
      Move the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P target hook from
      i386.h to i386.cc.
      
      	* config/i386/i386.h (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
      	Moved to ...
      	* config/i386/i386.cc (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
      	Here.
      
      Signed-off-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      075611b6
Loading