As stated in signaling_?.f90 tests, x86-32 ABI is not suitable to
correctly handle signaling NaNs. However, XFAIL is not the correct choice
to disable these tests, since various optimizations can generate code
that avoids moves from registers to memory (and back), resulting
in the code that executes correctly, producing spurious XFAIL.
These tests should be disabled on x86-32 using { ! ia32 } dg-directive
which rules out x32 ilp32 ABI, where tests execute without problems.
Please note that check_effective_target_ia32 test tries to compile code that
uses __i386__ target-dependent preprocessor definition, so it is guaranteed
to fail on all non-ia32 targets.
2022-01-27 Uroš Bizjak <ubizjak@gmail.com>
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/signaling_1.f90 (dg-do):
Run only on non-ia32 targets.
* gfortran.dg/ieee/signaling_2.f90 (dg-do): Ditto.
* gfortran.dg/ieee/signaling_3.f90 (dg-do): Ditto.
gcc/fortran/ChangeLog:
PR fortran/104128
* expr.cc (gfc_copy_expr): Convert internal representation of
string to wide char in value only for default character kind.
* target-memory.cc (interpret_array): Pass flag for conversion of
wide chars.
(gfc_target_interpret_expr): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/104128
* gfortran.dg/transfer_simplify_14.f90: New test.
contrib/ChangeLog:
* git-descr.sh: New file.
* git-undescr.sh: New file.
Support optional arguments --long, --short and default
to 14 characters of git hash.
* gcc-git-customization.sh: Use the created files.
Co-Authored-By: Martin Jambor <mjambor@suse.cz>
Here we're emitting a bogus error during ahead of time evaluation of a
non-dependent immediate member function call such as a.f(args) because
the defacto templated form for such a call is (a.f)(args) but we're
trying to evaluate it using the intermediate CALL_EXPR built by
build_over_call, which has the non-member form f(a, args). The defacto
member form is built in build_new_method_call, so it seems we should
handle the immediate call there instead, or perhaps make build_over_call
build the correct form in the first place.
Giiven that there are many spots other than build_new_method_call that
call build_over_call for member functions, e.g. build_op_call, this
patch takes the latter approach.
In passing, this patch makes us avoid wrapping PARM_DECL in
NON_DEPENDENT_EXPR for benefit of the third testcase below.
PR c++/99895
gcc/cp/ChangeLog:
* call.cc (build_over_call): For a non-dependent member call,
build up a CALL_EXPR using a COMPONENT_REF callee, as in
build_new_method_call.
* pt.cc (build_non_dependent_expr): Don't wrap PARM_DECL either.
* tree.cc (build_min_non_dep_op_overload): Adjust accordingly
after the build_over_call change.
gcc/ChangeLog:
* tree.cc (build_call_vec): Add const to second parameter.
* tree.h (build_call_vec): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/consteval-memfn1.C: New test.
* g++.dg/cpp2a/consteval-memfn2.C: New test.
* g++.dg/cpp2a/consteval28.C: New test.
In the nested_name_specifier branch within cp_parser_class_head, we need
to update 'type' with the result of maybe_process_partial_specialization
like we do in the template_id_p branch.
PR c++/92944
PR c++/103678
gcc/cp/ChangeLog:
* parser.cc (cp_parser_class_head): Update 'type' with the result
of maybe_process_partial_specialization in the
nested_name_specifier branch. Refactor nearby code to accomodate
that maybe_process_partial_specialization returns a _TYPE, not a
TYPE_DECL, and eliminate local variable 'class_type' in passing.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-partial-spec10.C: New test.
* g++.dg/cpp2a/concepts-partial-spec11.C: New test.
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto (&r)[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct]
prohibits that: "...the declared type of the variable shall be cv T,
where T is the placeholder." However, in /2 it explicitly states that
"A placeholder for a deduced class type can also be used in the
type-specifier-seq in the new-type-id or type-id of a new-expression."
In this PR, it manifested by making us accept invalid
template<class T> struct A { A(T); };
auto p = new A[]{1};
[expr.new]/2 says that such a construct is treated as an invented
declaration of the form
A x[]{1};
but, I think, that ought to be ill-formed as per above. So this patch
sort of restores the create_array_type_for_decl check. I should mention
that the difference between [] and [1] is due to cp_parser_new_type_id:
if (*nelts == NULL_TREE)
/* Leave [] in the declarator. */;
and groktypename returning different types based on that.
PR c++/101988
gcc/cp/ChangeLog:
* decl.cc (create_array_type_for_decl): Reject forming an array of
placeholder for a deduced class type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/class-deduction-new1.C: New test.
* g++.dg/cpp23/auto-array2.C: New test.
PR web/104254
gcc/ChangeLog:
* diagnostic.cc (diagnostic_initialize):
Initialize report_bug flag.
(diagnostic_action_after_output):
Explain that -freport-bug option can be used for pre-processed
file creation. Make the message shorter.
(error_recursion): Rename Internal to internal.
* diagnostic.h (struct diagnostic_context): New field.
* opts.cc (common_handle_option): Init the field here.
PR analyzer/104247
gcc/analyzer/ChangeLog:
* constraint-manager.cc (bounded_ranges_manager::log_stats):
Cast to long for format purpose.
* region-model-manager.cc (log_uniq_map): Likewise.
This patch is to fix one wrong assertion which is too aggressive.
Vectorizer can do vec_construct costing for the vector type which
only has one unit. For the failed case, the passed in vector type
is "vector(1) int", though it doesn't end up with any construction
eventually, we have to handle this kind of possibility.
gcc/ChangeLog:
PR target/103702
* config/rs6000/rs6000.cc
(rs6000_cost_data::update_target_cost_per_stmt): Fix one wrong
assertion with early return.
gcc/testsuite/ChangeLog:
PR target/103702
* gcc.target/powerpc/pr103702.c: New test.
This issue was triggered after the patch extending syntax for component access
in map clauses in commit 0ab29cf0bb.
In gimplify_scan_omp_clauses, the case for handling indirect accesses (which
creates firstprivate ptr and zero-length array section map for such decls) was
erroneously went into for non-pointer cases (here being the base struct decl),
so added the
appropriate checks there.
Added new testcase is a compile only test for the ICE. The original omptests
t-partial-struct test actually should not execute correctly, because for
map(t.s->a[:N]), map(t.s[:1]) is not implicitly mapped, thus the entire
offloaded access does not work as is (fixing that omptests test is out of
scope here).
2022-01-27 Chung-Lin Tang <cltang@codesourcery.com>
PR middle-end/103642
gcc/ChangeLog:
* gimplify.cc (gimplify_scan_omp_clauses): Do not do indir_p handling
for non-pointer or non-reference-to-pointer cases.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pr103642.c: New test.
After the quoting changes in r12-6521-g03a1a86b5ee40d4e240, branch-protection-attr.c
fails due to expecting a different quoting type for "leaf".
This patch changes the quoting from "" to '' as that is what is used now.
Committed as obvious after a test of the testcase.
gcc/testsuite/ChangeLog:
PR target/104201
* gcc.target/aarch64/branch-protection-attr.c: Fix quoting for
the expected error message on line 5 of leaf.
As mentioned in the PR, reassoc1 miscompiles following testcase.
We have:
if (a.1_1 >= 0)
goto <bb 5>; [59.00%]
else
goto <bb 4>; [41.00%]
<bb 4> [local count: 440234144]:
_3 = -2147483647 - a.1_1;
_9 = a.1_1 != -2147479551;
_4 = _3 == 1;
_8 = _4 | _9;
if (_8 != 0)
goto <bb 5>; [34.51%]
else
goto <bb 3>; [65.49%]
and the inter-bb range test optimization treats it as:
if ((a.1_1 >= 0)
| (-2147483647 - a.1_1 == 1)
| (a.1_1 != -2147479551))
goto bb5;
else
goto bb3;
and recognizes that a.1_1 >= 0 is redundant with a.1_1 != -2147479551
and so will optimize it into:
if (0
| (-2147483647 - a.1_1 == 1)
| (a.1_1 != -2147479551))
goto bb5;
else
goto bb3;
When merging 2 comparisons, we use update_range_test which picks one
of the comparisons as the one holding the result (currently always
the RANGE one rather than all the OTHERRANGE* ones) and adjusts the
others to be true or false.
The problem with doing that is that means the
_3 = -2147483647 - a.1_1;
stmt with undefined behavior on overflow used to be conditional before
but now is unconditional. reassoc performs a no_side_effect_bb check
which among other checks punts on gimple_has_side_effects and
gimple_assign_rhs_could_trap_p stmts as well as ones that have uses of
their lhs outside of the same bb, but it doesn't punt for this potential
signed overflow case.
Now, for this testcase, it can be fixed in update_range_test by being
smarter and choosing the other comparison to modify. This is achieved
by storing into oe->id index of the bb with GIMPLE_COND the
comparison feeds into not just for the cases where the comparison is
the GIMPLE_COND itself, but in all cases, and then finding oe->id that
isn't dominated by others. If we find such, use that oe for the merge
test and if successful, swap range->idx and swap_with->idx.
So for the above case we optimize it into:
if ((a.1_1 != -2147479551)
| (-2147483647 - a.1_1 == 1)
| 0)
goto bb5;
else
goto bb3;
instead.
Unfortunately, this doesn't work in all cases,
optimize_range_tests_to_bit_test and
optimize_range_tests_cmp_bitwise optimizations use non-NULL seq
to update_range_test and they carefully choose a particular comparison
because the sequence then uses SSA_NAMEs that may be defined only in
their blocks. For that case, the patch keeps using the chosen comparison
but if the merge is successful, rewrites stmts with signed overflow behavior
into defined overflow.
For this I ran into a problem, rewrite_to_defined_overflow returns a
sequence that includes the original stmt with modified arguments, this means
it needs to be gsi_remove first. Unfortunately, gsi_remove regardless of
the remove_permanently argument creates debug temps for the lhs, which I
think is quite undesirable here. So I've added an argument (default to
false) to rewrite_to_defined_overflow to do the modification in place
without the need to remove the stmt.
2022-01-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/104196
* gimple-fold.h (rewrite_to_defined_overflow): Add IN_PLACE argument.
* gimple-fold.cc (rewrite_to_defined_overflow): Likewise. If true,
return NULL and emit needed stmts before and after stmt.
* tree-ssa-reassoc.cc (update_range_test): For inter-bb range opt
pick as operand_entry that will hold the merged test the one feeding
earliest condition, ensure that by swapping range->idx with some
other range's idx if needed. If seq is non-NULL, don't actually swap
it but instead rewrite stmts with undefined overflow in between
the two locations.
(maybe_optimize_range_tests): Set ops[]->id to bb->index with the
corresponding condition even if they have non-NULL ops[]->op.
Formatting fix.
* gcc.c-torture/execute/pr104196.c: New test.
When writing testcases for the previously posted patch, I have noticed
that 3 of the headers aren't valid C89 (I didn't have any dg-options
so -ansi -pedantic-errors was implied and these errors were reported).
The following patch fixes those, ok for trunk?
Note, as can be seen even in this patch, seems older rs6000/*intrin.h
headers uglify not just argument names (__A instead of A etc.), but also
automatic variable names and other local identifiers, while e.g. emmintrin.h
or bmi2intrin.h clearly uglify only the argument names and not local
variables. I think that should be fixed but don't have time for that myself
(libstdc++ or e.g. the x86 headers uglify everything; this is so that one
can
#define result a + b
#include <x86intrin.h>
etc.).
2022-01-26 Jakub Jelinek <jakub@redhat.com>
PR target/104239
* config/rs6000/emmintrin.h (_mm_sad_epu8): Use __asm__ instead of
asm.
* config/rs6000/smmintrin.h (_mm_minpos_epu16): Declare iterator
before for loop instead of for init clause.
* config/rs6000/bmi2intrin.h (_pext_u64): Likewise.
* gcc.target/powerpc/pr104239-3.c: New test.
r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
to rs6000, these headers are on x86 standalone headers that various
programs include directly rather than including them through
<x86intrin.h>.
Unfortunately, for that change the bmiintrin.h and bmi2intrin.h
headers haven't been adjusted, so the effect is that if one includes them
(without including also x86intrin.h first) #error will trigger.
Furthermore, when including such headers conditionally as some real-world
packages do, this means a regression.
The following patch fixes it and matches what the x86 bmi{,2}intrin.h
headers do.
2022-01-26 Jakub Jelinek <jakub@redhat.com>
PR target/104239
* config/rs6000/bmiintrin.h: Test _X86GPRINTRIN_H_INCLUDED instead of
_X86INTRIN_H_INCLUDED and adjust #error wording.
* config/rs6000/bmi2intrin.h: Likewise.
* gcc.target/powerpc/pr104239-1.c: New test.
* gcc.target/powerpc/pr104239-2.c: New test.
My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.
PR c++/104206
PR c++/101072
gcc/cp/ChangeLog:
* semantics.cc (finish_compound_literal): Restore VECTOR_TYPE check.
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
> I bet gdb would even handle it without any changes, but of course, it would
> be larger than the other proposed changes.
Here it is implemented.
Testcases I've played with are e.g.:
__ibm128 a;
long double b;
_Complex long double c;
static __attribute__((noinline)) int
foo (long double d)
{
long double e = d + 1.0L;
return 0;
}
int
main ()
{
a = 1.0;
b = 2.0;
c = 5.0 + 6.0i;
return foo (7.0L);
}
and
real(kind=16) :: a
complex(kind=16) :: b
a = 1.0
b = 2.0
end
Printing the values of the variables works well,
p &b or p &c shows pointer to the correct type, just
ptype b or ptype c prints _Float128 instead of
long double or complex _Float128 instead of complex long double.
Even worse in fortran where obviously _Float128 or
complex _Float128 aren't valid types, but as GDB knows them by name,
it is just ptype that is weird.
2022-01-26 Jakub Jelinek <jakub@redhat.com>
PR debug/104194
* dwarf2out.cc (long_double_as_float128): New function.
(modified_type_die): For powerpc64le IEEE 754 quad long double
and complex long double emit those as DW_TAG_typedef to
_Float128 or complex _Float128 base type.
The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1, V4SImode_var_2 }), and expansion of
__builtin_shufflevector emits these early, so constexpr.cc can see those
too.
constexpr.cc already has special cases for NULL index which is typical
for VECTOR_TYPE CONSTRUCTORs, and for VECTOR_TYPE CONSTRUCTORs that
contain just scalar elts that works just fine - init_subob_ctx just
returns on non-aggregate elts and get_or_insert_ctor_field has
if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
{
CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
return &CONSTRUCTOR_ELTS (ctor)->last();
}
handling for it. But for the vector in vector case init_subob_ctx would
try to create a sub-CONSTRUCTOR and even didn't handle the NULL index
case well, so instead of creating the sub-CONSTRUCTOR after the elts already
in it overwrote the first one. So
(V8SImode) { { 0, 0, 0, 0 }, { 0, 0, 0, 0 } }
became
(V8SImode) { 0, 0, 0, 0 }
The following patch fixes it by not forcing a sub-CONSTRUCTOR for this
vector in vector case.
2022-01-26 Jakub Jelinek <jakub@redhat.com>
PR c++/104226
* constexpr.cc (init_subob_ctx): For vector ctors containing
vector elements, ensure appending to the same ctor instead of
creating another one.
* g++.dg/cpp0x/constexpr-104226.C: New test.
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into issues later on.
This patch uses suppress_warning on 'this' for certain cdtor_returns_this
cases in the C++ FE, and then warn_invalid_pointer makes use of this
information and doesn't warn.
In my first attempt I tried suppress_warning the MODIFY_EXPR or RETURN_EXPR
we build in build_delete_destructor_body, but the complication is that
the suppress_warning bits don't always survive gimplification; see e.g.
gimplify_modify_expr where we do
6130 if (COMPARISON_CLASS_P (*from_p))
6131 copy_warning (assign, *from_p);
but here we're not dealing with a comparison. Removing that check
regresses uninit-pr74762.C. Adding copy_warning (assign, *expr_p)
regresses c-c++-common/uninit-17.c.
PR target/104213
gcc/cp/ChangeLog:
* decl.cc (finish_constructor_body): Suppress -Wuse-after-free.
(finish_destructor_body): Likewise.
* optimize.cc (build_delete_destructor_body): Likewise.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (pass_waccess::warn_invalid_pointer): Don't
warn when the SSA_NAME_VAR of REF has supressed -Wuse-after-free.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wuse-after-free2.C: New test.
* g++.dg/warn/Wuse-after-free3.C: New test.
cp_parser_template_id wasn't prepared to handle getting a USING_DECL back
from cp_parser_template_name. Let's defer that case to instantiation time,
as well.
PR c++/104235
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Repeat lookup of USING_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/parse/template-keyword2.C: New test.
Commit 4343f5e256 ("rtl: builtins: (not just) rs6000: Add builtins
for fegetround, feclearexcept and feraiseexcept [PR94193]") broke gcc
bootstra when building with --enable-checking=rtl[1].
The function expand_builtin_feclear_feraise_except was failing to
proper validate op0 predicate before emit_insn leading to the mismatch
type failure.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589186.html
2022-01-26 Raoni Fassina Firmino <raoni@linux.ibm.com>
gcc/
PR target/94193
* builtins.cc (expand_builtin_feclear_feraise_except): Add op0
predicate check.
Signed-off-by: Raoni Fassina Firmino <raoni@linux.ibm.com>
We were failing to check for uninitialized arguments to stdio builtins,
such as when passing local "go" to the call to "printf" in "main" in
the testcase.
gcc/analyzer/ChangeLog:
PR analyzer/104224
* region-model.cc (region_model::check_call_args): New.
(region_model::on_call_pre): Call it when ignoring stdio builtins.
* region-model.h (region_model::check_call_args): New decl
gcc/testsuite/ChangeLog:
PR analyzer/104224
* gcc.dg/analyzer/pr104224.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Mikael Morin spotted that I got the sense wrong when discarding
redundant constraints in
r12-6782-gc4b8f3730a80025192fdb485ad2535c165340e41.
Fixed as follows, which also moves the rejection of contradictory
constraints in range::add_bound to earlier, so that this code can
be self-tested.
gcc/analyzer/ChangeLog:
PR analyzer/94362
* constraint-manager.cc (range::add_bound): Fix tests for
discarding redundant constraints. Perform test for rejecting
unsatisfiable constraints earlier so that they don't update
the object on failure.
(selftest::test_range): New.
(selftest::test_constant_comparisons): Add test coverage for
existing constraints becoming narrower until they are
unsatisfiable.
(selftest::run_constraint_manager_tests): Call test_range.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
On i686-linux this new testcase FAILs with:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
FAIL: gcc.target/i386/pr104188.c (test for excess errors)
Excess errors:
cc1: warning: SSE instruction set disabled, using 387 arithmetics
This is because it uses -mfpmath=sse, but -msse2 isn't on. Fixed
by adding -msse2 to dg-options and requiring sse2_runtime effective
target.
2022-01-26 Jakub Jelinek <jakub@redhat.com>
PR target/104188
* gcc.target/i386/pr104188.c: Add dg-require-effective-target
sse2_runtime. Add -msse2 to dg-options.
Usually we handle DR1558 substitution near the top of tsubst, but in this
case while substituting TYPENAME_TYPE we were passing an alias
specialization to tsubst_aggr_type, which ignored its aliasness.
PR c++/103057
gcc/cp/ChangeLog:
* pt.cc (tsubst_aggr_type): Call tsubst for alias template
specialization.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-void1.C: New test.
With -fno-exceptions we get a -Wmisleading-indentation warning for:
if (cond)
__try {}
__catch (...) {}
This is because the __catch(...) expands to if (false), but is indented
as though it is controlled by the preceding 'if'. Surround it in braces.
The new make_shared<T[]> code triggers a bogus warning due to PR 61596,
which can be disabled with a pragma.
libstdc++-v3/ChangeLog:
PR libstdc++/104019
* include/bits/istream.tcc (basic_istream::sentry): Add braces
around try-block.
* include/bits/shared_ptr_base.h (_Sp_counted_array_base::_M_init):
Add pragmas to disable bogus warnings from PR 61596.
For GNU/Linux G++ defines _GNU_SOURCE automatically, but not for Cygwin.
This means secure_getenv is not declared by Cygwin's <stdlib.h>, even
though autoconf detected it is present in the library. Define it in the
source files that want to use secure_getenv.
libstdc++-v3/ChangeLog:
PR libstdc++/104217
* src/c++17/fs_ops.cc (_GNU_SOURCE): Define.
* src/filesystem/dir.cc (_GNU_SOURCE): Define.
* src/filesystem/ops.cc (_GNU_SOURCE): Define.
This adds a new internal flag to the filesystem::directory_iterator
constructor that makes it fail if the path is a symlink that resolves to
a directory. This prevents filesystem::remove_all from following a
symlink to a directory, rather than deleting the symlink itself.
We can also use that new flag in recursive_directory_iterator to ensure
that we don't follow symlinks if the follow_directory_symlink option is
not set.
This also moves an error check in filesystem::remove_all after the while
loop, so that errors from the directory_iterator constructor are
reproted, instead of continuing to the filesystem::remove call below.
libstdc++-v3/ChangeLog:
PR libstdc++/104161
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for
fdopendir.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/c++17/fs_dir.cc (_Dir): Add nofollow flag to constructor
and pass it to base class constructor.
(directory_iterator): Pass nofollow flag to _Dir constructor.
(fs::recursive_directory_iterator::increment): Likewise.
* src/c++17/fs_ops.cc (do_remove_all): Use nofollow option for
directory_iterator constructor. Move error check outside loop.
* src/filesystem/dir-common.h (_Dir_base): Add nofollow flag to
constructor and when it's set use ::open with O_NOFOLLOW and
O_DIRECTORY.
* src/filesystem/dir.cc (_Dir): Add nofollow flag to constructor
and pass it to base class constructor.
(directory_iterator): Pass nofollow flag to _Dir constructor.
(fs::recursive_directory_iterator::increment): Likewise.
* src/filesystem/ops.cc (remove_all): Use nofollow option for
directory_iterator constructor. Move error check outside loop.
gcc/fortran/ChangeLog:
PR fortran/104227
* check.cc (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.
gcc/testsuite/ChangeLog:
PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.
Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions. This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.
To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.
PR c++/101532
PR c++/104225
gcc/cp/ChangeLog:
* decl2.cc (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-template21.C: New test.
* g++.dg/cpp0x/nsdmi-template21a.C: New test.
Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the
TARGET_EXPR. But that's the wrong value category for the result of the
defaulted class assignment operator, which returns an lvalue, so we need to
actually build the INDIRECT_REF.
PR c++/59950
gcc/cp/ChangeLog:
* call.cc (build_over_call): Use cp_build_indirect_ref.
gcc/testsuite/ChangeLog:
* g++.dg/init/assign2.C: New test.
This reverts commit db1a65d936.
On 2021-09-17T01:01:39-0700, Andrew Pinski via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> On Fri, Sep 17, 2021 at 12:46 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
>> On 2021-09-15T13:56:37-0700, apinski--- via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>> > The error message is obvious -funconfigured-libstdc++-v3 is used
>> > on the g++ command line. So we just add the dependancy.
>>
>> > --- a/Makefile.def
>> > +++ b/Makefile.def
>> > @@ -592,6 +592,7 @@ dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
>> > dependencies = { module=all-target-fastjar; on=all-target-zlib; };
>> > dependencies = { module=configure-target-libgo; on=configure-target-libffi; };
>> > dependencies = { module=configure-target-libgo; on=all-target-libstdc++-v3; };
>> > +dependencies = { module=configure-target-libffi; on=all-target-libstdc++-v3; };
>> > dependencies = { module=all-target-libgo; on=all-target-libbacktrace; };
>> > dependencies = { module=all-target-libgo; on=all-target-libffi; };
>> > dependencies = { module=all-target-libgo; on=all-target-libatomic; };
>>
>> I'm confused, because given that this 'Makefile.def' change only has the
>> following effect:
>>
>> > --- a/Makefile.in
>> > +++ b/Makefile.in
>> > @@ -61261,6 +61261,7 @@ all-bison: maybe-all-intl
>> > all-flex: maybe-all-intl
>> > all-m4: maybe-all-intl
>> > configure-target-libgo: maybe-all-target-libstdc++-v3
>> > +configure-target-libffi: maybe-all-target-libstdc++-v3
>> > configure-target-liboffloadmic: maybe-configure-target-libgomp
>> > all-target-liboffloadmic: maybe-all-target-libgomp
>> > configure-target-newlib: maybe-all-binutils
>>
>> ... isn't that actually a no-op, because we already had such a dependency
>> listed? Now twice:
>>
>> $ grep -n -F 'configure-target-libffi: maybe-all-target-libstdc++-v3' -- Makefile.in
>> 61264:configure-target-libffi: maybe-all-target-libstdc++-v3
>> 61372:configure-target-libffi: maybe-all-target-libstdc++-v3
>>
>> Compared to the existing one, the one you've added is additionally
>> restricted by '@unless gcc-bootstrap'.
>>
>> I noticed this as I remembered that on our og[...] development branches
>> we have a patch in the opposite direction: get rid of this dependency via
>> removing 'lang_env_dependencies = { module=libffi; cxx=true; };' from
>> 'Makefile.def'. See
>> <http://mid.mail-archive.com/alpine.DEB.2.21.9999.1812201344250.99920@build7-trusty-cs.sje.mentorg.com>
>> "Disable libstdc++ dependency for libffi". (Maciej CCed in case you have
>> any further thoughts on that.)
>
> Oh, I see what happened now, the old bug was actually fixed by r6-5415
> which added cxx=true.
> So yes my patch is actually not needed and can be reverted.
> I tried to look to see if there was a dependency was there but for
> some reason I did not see it.
A recent patch added tests for OPTION_GLIBC that is defined in
linux.h and linux64.h. This broke bootstrap for non-Linux rs6000
configurations. This patch defines OPTION_GLIBC as 0.
* config/rs6000/aix.h (OPTION_GLIBC): Define as 0.
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series.
> For targets with IEEE support but without the issignaling macro in libc
> (i.e., everywhere except glibc), this allows us to provide a fallback
> implementation.
This doesn't seem to handle the powerpc* IBM double double long double.
__LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.
2022-01-25 Jakub Jelinek <jakub@redhat.com>
* ieee/issignaling_fallback.h (__issignalingl): Define for
IBM extended long double are returning __issignaling on the
first double.
When we have a pointer relational compare we have stronger guarantees
about overflow, in particular rewriting BASE0 + STEP0 cmp BASE1 + STEP1
as BASE0 + STEP0 - STEP1 cmp BASE1 is always valid and the new IV0
does not overflow. The patch basically reverts the previous change
when pointers are involved, keeping only the more conservative handling
for equality compares which can involve comparing different object
addresses.
2022-01-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/104214
* tree-ssa-loop-niter.cc (number_of_iterations_cond): Use
stronger guarantees for relational pointer compares when
rewriting BASE0 + STEP0 cmp BASE1 + STEP1 as
BASE0 + STEP0 - STEP1 cmp BASE1.
* gcc.dg/vect/pr81196-2.c: New variant testcase only
requiring vect_int.
_dl_find_object returns success even if no unwind information has been
found, and dlfo_eh_frame is NULL.
libgcc/ChangeLog:
PR libgcc/104207
* unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL check.
