PR analyzer/104308 initially reported about a
-Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION
when complaining about certain memmove operations where the source
is uninitialized.
In r12-7856-g875342766d4298 I fixed the missing location for
a stmt generated by gimple_fold_builtin_memory_op, but the reporter
then found another way to generate such a stmt with UNKNOWN_LOCATION.
I've now gone through gimple_fold_builtin_memory_op looking at all
statement creation, and found three places in which a new statement
doesn't have a location set on it (either directly via
gimple_set_location, or indirectly via gsi_replace), one of which is
the new reproducer.
This patch adds a gimple_set_location to these three cases, and adds
test coverage for one of them (the third hunk within the patch), fixing
the new reproducer for PR analyzer/104308.
gcc/ChangeLog:
PR analyzer/104308
* gimple-fold.cc (gimple_fold_builtin_memory_op): Explicitly set
the location of new_stmt in all places that don't already set it,
whether explicitly, or via a call to gsi_replace.
gcc/testsuite/ChangeLog:
PR analyzer/104308
* gcc.dg/analyzer/pr104308.c: Add test coverage.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
for which that function is invoked need an extra artificial BIND_EXPR
around their body so that we move all variables of the bodies.
The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
or OMP_TARGET and for OpenACC constructs that behave similarly to
OMP_TARGET, but the Fortran FE only does that for OpenMP constructs.
The following patch does that for OpenACC constructs too.
PR fortran/104717
gcc/fortran/
* trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body
in an extra BIND_EXPR.
gcc/testsuite/
* gfortran.dg/goacc/pr104717.f90: New test.
* gfortran.dg/goacc/privatization-1-compute-loop.f90: Adjust.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Adjust.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
Filter out:
libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-attribute-extensions]
contrib/ChangeLog:
* filter-clang-warnings.py: Filter out
-Wc++20-attribute-extensions in lex.cc.
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define
conditionally.
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Define for C++23.
(default_delete, default_delete<T[]>, __uniq_ptr_impl)
(unique_ptr, unique_ptr<T[], D>): Add constexpr to all member
functions.
* include/std/version (__cpp_lib_constexpr_memory): Define new
value for C++23.
* testsuite/20_util/unique_ptr/assign/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/comparison/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/cons/constexpr_c++20.cc: New test.
* testsuite/20_util/unique_ptr/creation/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/modifiers/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/specialized_algorithms/constexpr.cc:
New test.
This change was LWG 3117.
The test is copied from 20_util/function/cons/deduction.cc
libstdc++-v3/ChangeLog:
PR libstdc++/105375
* include/std/future (packaged_task): Add deduction guides.
* testsuite/30_threads/packaged_task/cons/deduction.cc: New test.
Here we issue an error from c_build_shufflevector while parsing a template
because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs
(except the first two arguments). It checks if any of the arguments are
type-dependent, if so, we leave the processing for later, but it should
also check value-dependency for the 3rd+ arguments, so as to avoid the
problem above.
This is not a regression -- __builtin_shufflevector was introduced in
GCC 12, but it looks safe enough.
PR c++/105353
gcc/cp/ChangeLog:
* typeck.cc (build_x_shufflevector): Use
instantiation_dependent_expression_p except for the first two
arguments.
gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin-shufflevector-3.C: New test.
In commit a2a919aa50 (2003), built-ins for modf and modff were added.
In extend.texi, section "Other Builtins", "modf" was added to the paragraph
"There are also built-in versions of the ISO C99 functions [...]" and
"modf" was also added to the paragraph "The ISO C90 functions [...]".
"modff" was not added to either paragraph.
Based on the context clues about where "modfl" and other similar function
pairs like "powf/powl" appear, I believe the reference to "modf" in the
first paragraph (C99) should instead be "modff".
2022-04-25 Paul A. Clarke <pc@us.ibm.com>
gcc
* doc/extend.texi (Other Builtins): Correct reference to 'modff'.
When range_of_stmt was adjusted to avoid large recursion depth, we need to
intersect the calculated range whth the any known range to avoid losing
info. Range_of_stmt does this, but the new prefill code missed it.
PR tree-optimization/105276
gcc/
* gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Include
existing global range with calculated value.
gcc/testsuite/
* g++.dg/pr105276.C: New.
Re-using the std::span printer, this now shows the contents of the
initializer list instead of the pointer and length members.
Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdSpanPrinter._iterator):
Rename as iterator.
(StdInitializerListPrinter): Define new printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Check printer for
initializer_list.
This fixes a dump tree match check that is UNRESOLVED with the -O0
optimization option, as the optimization pass corresponding to the
dump file is not run at -O0, and the dump is not generated.
PR fortran/103662
gcc/testsuite/ChangeLog:
* gfortran.dg/unlimited_polymorphic_3.f03: Force execution of
the DSE optimization pass.
The following avoids undefined signed overflow when computing
the absolute of the exponent in powi_cost.
2022-04-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/105368
* tree-ssa-math-opts.cc (powi_cost): Use absu_hwi.
The following attempts to avoid IVOPTs rewriting uses using
IV candidates that involve undefined behavior by using uninitialized
SSA names. First we restrict the set of candidates we produce
for such IVs to the original ones and mark them as not important.
Second we try to only allow expressing uses with such IV if they
originally use them. That is to avoid rewriting all such uses
in terms of other IVs. Since cand->iv and use->iv seem to never
exactly match up we resort to comparing the IV bases.
The approach ends up similar to the one posted by Roger at
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578441.html
but it marks IV candidates rather than use groups and the cases
we allow in determine_group_iv_cost_generic are slightly different.
2022-01-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc (struct iv_cand): Add involves_undefs flag.
(find_ssa_undef): New function.
(add_candidate_1): Avoid adding derived candidates with
undefined SSA names and mark the original ones.
(determine_group_iv_cost_generic): Reject rewriting
uses with a different IV when that involves undefined SSA names.
* gcc.dg/torture/pr100810.c: New testcase.
* gcc.dg/torture/pr105337.c: Likewise.
Back story: When GCC is configured and built on non-glibc platforms,
it seems very little to no effort is made to enumerate the available
C99 libm functions. It is all or nothing for C99 libm. The patch
introduces a new function, used on only FreeBSD, to inform gcc that
it has C99 libm functions (minus a few which clearly GCC does not check
nor test).
2022-04-15 Steven G. Kargl <kargl@gcc.gnu.org>
PR target/89125
* config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
bsd_libc_has_function.
* targhooks.cc (bsd_libc_has_function): New function.
Expand the supported math functions to inclue C99 libm.
* targhooks.h (bsd_libc_has_function): New Prototype.
The following mitigates a problem in combine distribute_notes which
places an original REG_EH_REGION based on only may_trap_p which is
good to test whether a non-call insn can possibly throw but not if
actually it does or we care. That's something we decided at RTL
expansion time where we possibly still know the insn evaluates
to a constant.
In fact, the REG_EH_REGION note with lp > 0 can only come from the
original i3 and an assert is added to that effect. That means we only
need to retain the note on i3 or, if that cannot trap, drop it but we
should never move it to i2.
The following places constraints on the insns to combine with
non-call exceptions since we cannot handle the case where we
have more than one EH side-effect in the IL. The patch also
makes sure we can accumulate that on i3 and do not split
a possible exception raising part of it to i2. As a special
case we do not place any restriction on all externally
throwing insns when there is no REG_EH_REGION present.
2022-04-22 Richard Biener <rguenther@suse.de>
PR rtl-optimization/105231
* combine.cc (distribute_notes): Assert that a REG_EH_REGION
with landing pad > 0 is from i3. Put any REG_EH_REGION note
on i3 or drop it if the insn can not trap.
(try_combine): Ensure that we can merge REG_EH_REGION notes
with non-call exceptions. Ensure we are not splitting a
trapping part of an insn with non-call exceptions when there
is any REG_EH_REGION note to preserve.
* gcc.dg/torture/pr105231.c: New testcase.
This fixes a type-based alias analysis issue with unlimited polymorphic
class descriptors (types behind class(*)) causing data initialisation to
be removed by optimization.
The fortran front-end may create multiple declarations for types, for
example if a type is redeclared in each program unit it is used in.
To avoid optimization seeing them as non-aliasing, a list of derived
types is created at resolution time, and used at translation to set
the same TYPE_CANONICAL type for each duplicate type declaration.
This mechanism didn’t work for unlimited polymorphic descriptors types,
as there is a short-circuit return skipping all the resolution handling
for them, including the type registration.
This change adds type registration at the short-circuit return, and
updates type comparison to handle specifically unlimited polymorphic
fake symbols, class descriptor types and virtual table types.
The test, which exhibited mismatching dynamic types had to be fixed as
well.
PR fortran/103662
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_derived_types): Support comparing
unlimited polymorphic fake symbols. Recursively compare class
descriptor types and virtual table types.
* resolve.cc (resolve_fl_derived): Add type to the types list
on unlimited polymorphic short-circuit return.
gcc/testsuite/ChangeLog:
* gfortran.dg/unlimited_polymorphic_3.f03 (foo): Separate
bind(c) and sequence checks to...
(foo_bc, foo_sq): ... two different procedures.
(main, foo*): Change type declarations so that type name,
component name, and either bind(c) or sequence attribute match
between the main type declarations and the procedure type
declarations.
(toplevel): Add optimization dump checks.
Co-Authored-By: Jakub Jelinek <jakub@redhat.com>
The following testcase regressed on x86_64 on the trunk, due to some GIMPLE
pass changes (r12-7687) we end up an *.optimized dump difference of:
@@ -8,14 +8,14 @@ int foo (int i)
<bb 2> [local count: 1073741824]:
if (i_2(D) != 0)
- goto <bb 4>; [35.00%]
+ goto <bb 3>; [35.00%]
else
- goto <bb 3>; [65.00%]
+ goto <bb 4>; [65.00%]
- <bb 3> [local count: 697932184]:
+ <bb 3> [local count: 375809640]:
<bb 4> [local count: 1073741824]:
- # iftmp.0_1 = PHI <5(2), i_2(D)(3)>
+ # iftmp.0_1 = PHI <5(3), i_2(D)(2)>
return iftmp.0_1;
}
and similarly for the other functions. That is functionally equivalent and
there is no canonical form for those. The reason for i_2(D) in the PHI
argument as opposed to 0 is the uncprop pass, that is in many cases
beneficial for expansion as we don't need to load the value into some pseudo
in one of the if blocks.
Now, for the 11.x ordering we have the pseudo = i insn in the extended basic
block (it comes first) and so forwprop1 undoes what uncprop does by
propagating constant 0 there. But for the 12.x ordering, the extended basic
block contains pseudo = 5 and pseudo = i is in the other bb and so fwprop1
doesn't change it.
During the ce1 pass, we attempt to emit a conditional move and we have very
nice code for the cases where both last operands of ?: are constant, and yet
another for !TARGET_CMOVE if at least one of them is.
The following patch will undo the uncprop behavior during
ix86_expand_int_movcc, but just for those spots that can benefit from both
or at least one operands being constant, leaving the pure cmov case as is
(because then it is useful not to have to load a constant into a pseudo
as it already is in one). We can do that in the
op0 == op1 ? op0 : op3
or
op0 != op1 ? op2 : op0
cases if op1 is a CONST_INT by pretending it is
op0 == op1 ? op1 : op3
or
op0 != op1 ? op2 : op1
2022-04-23 Jakub Jelinek <jakub@redhat.com>
PR target/105338
* config/i386/i386-expand.cc (ix86_expand_int_movcc): Handle
op0 == cst1 ? op0 : op3 like op0 == cst1 ? cst1 : op3 for the non-cmov
cases.
* gcc.target/i386/pr105338.c: New test.
<recording this here for future reference>
PR102994 "atomics: std::atomic<ptr>::wait is not marked const" raises the
issue that the current libstdc++ implementation marks the notify members
const, the implementation strategy used by libstdc++, as well as libc++
and the Microsoft STL, do not require the atomic to be mutable (it is hard
to conceive of a desirable implementation approach that would require it).
The original paper proposing the wait/notify functionality for atomics
(p1185) also had these members marked const for the first three revisions,
but that was changed without explanation in r3 and subsequent revisions of
the paper.
After raising the issue to the authors of p1185 and the author of the
libc++ implementation, the consensus seems to be "meh, it's harmless" so
there seems little appetite for an LWG issue to revisit the subject.
This patch changes the libstdc++ implementation to be in agreement with
the standard by removing const from those notify_one/notify_all members.
libstdc++-v3/ChangeLog:
PR libstdc++/102994
* include/bits/atomic_base.h (atomic_flag::notify_one,
notify_all): Remove const qualification.
(__atomic_base::notify_one, notify_all): Likewise.
* include/std/atomic (atomic<bool>::notify_one, notify_all):
Likewise.
(atomic::notify_one, notify_all): Likewise.
(atomic<T*>::notify_one, notify_all): Likewise.
(atomic_notify_one, atomic_notify_all): Likewise.
* testsuite/29_atomics/atomic/wait_notify/102994.cc: Adjust test
to account for change in notify_one/notify_all signature.
The code generated for array references used to be ARRAY_REF trees as
could be expected. However, the middle-end may conclude from those
trees that the indexes used are non-negative (more precisely not below
the lower bound), which is a wrong assumption in the case of "reversed-
order" arrays.
The problematic arrays are those with a descriptor and having a negative
stride for at least one dimension. The descriptor data points to the
first element in array order (which is not the first in memory order in
that case), and the negative stride(s) makes walking the array backwards
(towards lower memory addresses), and we can access elements with
negative index wrt data pointer.
With this change, pointer arithmetic is generated by default for array
references, unless we are in a case where negative indexes can’t happen
(array descriptor’s dim element, substrings, explicit shape,
allocatable, or assumed shape contiguous). A new flag is added to
choose between array indexing and pointer arithmetic, and it’s set
if the context can tell array indexing is safe (descriptor dim
element, substring, temporary array), or a new method is called
to decide on whether the flag should be set for one given array
expression.
PR fortran/102043
gcc/fortran/ChangeLog:
* trans.h (gfc_build_array_ref): Add non_negative_offset
argument.
* trans.cc (gfc_build_array_ref): Ditto. Use pointer arithmetic
if non_negative_offset is false.
* trans-expr.cc (gfc_conv_substring): Set flag in the call to
gfc_build_array_ref.
* trans-array.cc (gfc_get_cfi_dim_item,
gfc_conv_descriptor_dimension): Same.
(build_array_ref): Decide on whether to set the flag and update
the call.
(gfc_conv_scalarized_array_ref): Same. New argument tmp_array.
(gfc_conv_tmp_array_ref): Update call to
gfc_conv_scalarized_ref.
(non_negative_strides_array_p): New function.
gcc/testsuite/ChangeLog:
* gfortran.dg/array_reference_3.f90: New.
* gfortran.dg/negative_stride_1.f90: New.
* gfortran.dg/vector_subscript_8.f90: New.
* gfortran.dg/vector_subscript_9.f90: New.
* gfortran.dg/c_loc_test_22.f90: Update dump patterns.
* gfortran.dg/finalize_10.f90: Same.
Co-Authored-By: Richard Biener <rguenther@suse.de>
This avoids regressing on char_cast_1.f90 and char_cast_2.f90 later in
the patch series when the code generation for array references is
changed to use pointer arithmetic.
The regressing testcases match part of an array reference in the
generated tree dump and it’s not clear how the pattern should be
rewritten to match the equivalent with pointer arithmetic.
This change uses a method specific to array temporaries to generate
array-references, so that these array references are flagged as safe
for array indexing and will not be updated to use pointer arithmetic.
PR fortran/102043
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_expr_descriptor): Use
gfc_conv_tmp_array_ref.
This avoids a regression on hollerith4.f90 and hollerith6.f90 later in
the patch series when code generation for array references is changed
to use pointer arithmetic.
The problem comes from the extraction of the array index from an
ARRAY_REF tree, which doesn’t work if the tree is not an ARRAY_REF
any more.
This updates the code generated for remaining size evaluation to work
with a source tree that uses either array indexing or pointer
arithmetic.
PR fortran/102043
gcc/fortran/ChangeLog:
* trans-io.cc: Add handling for the case where the array
is referenced using pointer arithmetic.
This avoids a regression on deferred_character_23.f90 later in the
patch series when array references are rewritten to use pointer
arithmetic.
The problem is a SAVE_EXPR tree as TYPE_SIZE_UNIT of one array element
type, which is used by the pointer arithmetic expressions. As these
expressions appear in both branches of an if-then-else block, the tree
is lowered to a variable in one of the branches but it’s used in both
branches, which is invalid middle-end code.
This change pre-evaluates the array references or pointer arithmetics
to variables before the if-then-else block, so that the SAVE_EXPR are
expanded to variables in the parent scope of the if-then-else block,
and expressions referencing the variables remain valid in both
branches.
PR fortran/102043
gcc/fortran/ChangeLog:
* trans-expr.cc: Pre-evaluate src and dest to variables
before using them.
gcc/testsuite/ChangeLog:
* gfortran.dg/dependency_49.f90: Update variable occurence
count.
For PR103623 I fixed unpack, but pack is broken as well, as reported in
PR105334. Fixing that is a bit more code, but it is pretty simple code
nonetheless.
2022-04-22 Segher Boessenkool <segher@kernel.crashing.org>
PR target/105334
* config/rs6000/rs6000.md (pack<mode> for FMOVE128): New expander.
(pack<mode> for FMOVE128): Rename and split the insn_and_split to...
(pack<mode>_hard for FMOVE128): ... this...
(pack<mode>_soft for FMOVE128): ... and this.
The following testcase FAILs, because replace_rtx replaces a REG with
CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation
because a SUBREG relies on SUBREG_REG having non-VOIDmode but
CONST_WIDE_INT has VOIDmode.
replace_rtx already has code to deal with it, but it was doing
it only for CONST_INTs. The following patch does it also for
VOIDmode CONST_DOUBLE or CONST_WIDE_INT.
2022-04-22 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/105333
* rtlanal.cc (replace_rtx): Use simplify_subreg or
simplify_unary_operation if CONST_SCALAR_INT_P rather than just
CONST_INT_P.
* gcc.dg/pr105333.c: New test.
This testcase does not generate anywhere near optimal code for 32-bit
code. For p10 it actually now fails this testcase, after the previous
patch. Let's xfail it.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.
RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes. We can fix that by putting a small penalty on the
instruction alternatives for those.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi<mode>2 for EXTHI): Ditto.
(zero_extendsi<mode>2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov<mode>_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.
This is true if we have -mpowerpc64.
2022-04-21 Segher Boessenkool <segher@kernel.crashing.org>
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_has_arch_ppc64): New.
In starts_with_ci and in __floating_from_chars_hex's inf/nan handling,
we were assuming that the letters are contiguous and that 'A' + 32 == 'a'
which is true for ASCII but not for other character encodings.
This patch fixes starts_with_ci by using a constexpr lookup table that
maps uppercase letters to lowercase, and fixes __floating_from_chars_hex
by using __from_chars_alnum_to_val.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum_to_val_table):
Simplify initialization of __lower/__upper_letters.
(__from_chars_alnum_to_val): Default the template parameter to
false.
* src/c++17/floating_from_chars.cc (starts_with_ci): Don't
assume the uppercase and lowercase letters are contiguous.
(__floating_from_chars_hex): Likewise.
Here we issue a bogus error for the first assert in the test. Therein
we have
<retval> = (void) (VIEW_CONVERT_EXPR<bool>(yes) || handle_error ());, VIEW_CONVERT_EXPR<int>(value);
which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
<case COMPOUND_EXPR>. The problem here is that we call
7044 /* Check that the LHS is constant and then discard it. */
7045 cxx_eval_constant_expression (ctx, op0,
7046 true, non_constant_p, overflow_p,
7047 jump_target);
where lval is always true, so the PARM_DECL 'yes' is not evaluated into
its value.
Fixed by always passing false for 'lval' in cxx_eval_logical_expression;
there's no case where we actually expect an lvalue from a TRUTH_*.
PR c++/105321
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_logical_expression): Always pass false for lval
to cxx_eval_constant_expression.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-105321.C: New test.
This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC
STRUCTURE when compiled with -finit-derived -finit-local-zero.
The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer
modified the vector pointer, but the pointer was passed by-value,
so the old pointer from the caller (gfc_conv_structure) pointed to freed
memory.
PR fortran/105310
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_union_initializer): Pass vec* by reference.
gcc/testsuite/ChangeLog:
* gfortran.dg/dec_union_12.f90: New test.
This makes the initializer for __table in __from_chars_alnum_to_val
dependent in an artificial way, which works around the reported modules
testsuite ICE by preventing the compiler from evaluating the initializer
parse time.
Compared to the alternative workaround of using a non-local class type
for __table, this workaround has the advantage of slightly speeding up
compilation of <charconv>, since now the table won't get built (via
constexpr evaluation) until the integer std::from_chars overload is
instantiated.
PR c++/105297
PR c++/105322
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_alnum_to_val): Make
initializer for __table dependent in an artificial way.
I'm not sure what I was thinking when I added this assertion, maybe it
was supposed to be alignment == 1 (which is what the pmr::string actually
uses). The simplest fix is to just remove the assertion.
The assertion is no longer enabled by default on trunk, but it's still
there for the --enablke-libstdcxx-debug build, and is still wrong. The
fix is needed on the gcc-11 branch.
libstdc++-v3/ChangeLog:
PR libstdc++/105324
* src/c++17/floating_from_chars.cc (buffer_resource::do_allocate):
Remove assertion.
* testsuite/20_util/from_chars/pr105324.cc: New test.
When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
mark_jump_label on DEBUG_INSNs:
if (NONDEBUG_INSN_P (insn))
mark_jump_label (PATTERN (insn), insn, 0);
and so doesn't increment LABEL_NUSES from references in DEBUG_INSNs.
But, when we call emit_copy_of_insn_after e.g. when duplicating some
DEBUG_INSNs, we call it even on those, which then results in LABEL_NUSES
differences and -fcompare-debug failures.
The following patch makes sure we don't call it on DEBUG_INSNs.
2022-04-21 Jakub Jelinek <jakub@redhat.com>
PR debug/105203
* emit-rtl.cc (emit_copy_of_insn_after): Don't call mark_jump_label
on DEBUG_INSNs.
* gfortran.dg/g77/pr105203.f: New test.
If two arrays do not have the exact same element type including
qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]),
which can still be distinguished by the lvalue-rvalue tiebreaker.
By tightening this branch (in accordance with the letter of the Standard) we
fall through to the next branch, which tests whether they have different
element type ignoring qualification and returns 0 in that case; thus we only
actually fall through in the T[...] vs. T cv[...] case, eventually
considering the lvalue-rvalue tiebreaker at the end of compare_ics.
Signed-off-by: Ed Catmur <ed@catmur.uk>
PR c++/104996
gcc/cp/ChangeLog:
* call.cc (compare_ics): When comparing list-initialization
sequences, do not return early.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist129.C: New test.
The macro being tested here is wrong, but just happens to have the same
value as the one supposed to be tests.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string_view/operations/copy/char/constexpr.cc:
Check correct feature test macro.
This fixes missing libiconv symbols when libstdc++ is built on a system
that has libiconv installed. If the libiconv headers are found then
libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But
without this fix libstdc++ is not linked to the libiconv library that
provides the definitions of those symbols.
As discussed in PR 93602 this changed means that libstdc++.so.6 might
have an rpath pointing to the location of the libiconv.so library. If
that is not desired, then GCC must be configured to link to a static
libiconv.a instead, using either --with-libiconv-type=static or an
in-tree build of libiconv.
libstdc++-v3/ChangeLog:
PR libstdc++/93602
* doc/xml/manual/prerequisites.xml: Document libiconv
workarounds.
* doc/html/manual/setup.html: Regenerate.
* src/Makefile.am (CXXLINK): Add $(LTLIBICONV).
* src/Makefile.in: Regenerate.
