I noticed a -Wc++17-extensions warning due to use of if-constexpr in
std::experimental::filesystem::path, which was not protected by
diagnostic pragmas to disable the warning.
While adding the pragmas I noticed that other places in the same file
use tag dispatching and multiple overloads instead of if-constexpr.
Since we're already using it in that file, we might as well just use it
everywhere.
libstdc++-v3/ChangeLog:
* include/experimental/bits/fs_path.h (path::_Cvt): Refactor to
use if-constexpr.
(path::string(const Allocator&)): Likewise.
Marek Polacek [Thu, 5 Sep 2024 20:45:32 +0000 (16:45 -0400)]
c++: ICE with structured bindings and m-d array [PR102594]
We ICE in decay_conversion with this test:
struct S {
S() {}
};
S arr[1][1];
auto [m](arr3);
But not when the last line is:
auto [n] = arr3;
Therefore the difference is between copy- and direct-init. In
particular, in build_vec_init we have:
if (direct_init)
from = build_tree_list (NULL_TREE, from);
and then we call build_vec_init again with init==from. Then
decay_conversion gets the TREE_LIST and it crashes.
build_aggr_init has:
/* Wrap the initializer in a CONSTRUCTOR so that build_vec_init
recognizes it as direct-initialization. */
init = build_constructor_single (init_list_type_node,
NULL_TREE, init);
CONSTRUCTOR_IS_DIRECT_INIT (init) = true;
so I propose to do the same in build_vec_init.
PR c++/102594
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Build up a CONSTRUCTOR to signal
direct-initialization rather than a TREE_LIST.
Jonathan Wakely [Thu, 26 Sep 2024 22:38:41 +0000 (23:38 +0100)]
libstdc++: Fix test FAIL due to -Wpointer-arith
This fixes a FAIL due to a -Wpointer-arith warning when testing with
c++11 or c++14 dialects. As an extension our std::atomic<void*> supports
pointer arithmetic in C++11 and C++14, but due to the system header
changes there is now a warning about it. The warning seems reasonable,
so rather than suppress it we should make the test expect it.
While looking into this I decided to simplify some of the code related
to atomic<T*> arithmetic.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_base<T*>::_M_type_size):
Replace overloaded functions with static _S_type_size.
* include/std/atomic (atomic<T*>): Use is_object_v instead of
is_object.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Add dg-warning for -Wpointer-arith warning.
Matthieu Longo [Thu, 26 Sep 2024 17:14:23 +0000 (18:14 +0100)]
aarch64: fix build failure on aarch64-none-elf
A previous patch ([1]) introduced a build regression on aarch64-none-elf
target. The changes were primarilly tested on aarch64-unknown-linux-gnu,
so the issue was missed during development.
The includes are slighly different between the two targets, and due to some
include rules ([2]), "aarch64-unwind-def.h" was not found.
[2]: https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
> include "file"
> ... It searches for a file named file first in the directory
> containing the current file, ...
Jakub Jelinek [Fri, 27 Sep 2024 14:07:40 +0000 (16:07 +0200)]
diagnostic: Save/restore diagnostic context history and push/pop state for PCH [PR116847]
The following patch on top of the just posted cleanup patch
saves/restores the m_classification_history and m_push_list
vectors for PCH. Without that as the testcase shows during parsing
of the templates we don't report ignored diagnostics, but after loading
PCH header when instantiating those templates those warnings can be
emitted. This doesn't show up on x86_64-linux build because configure
injects there -fcf-protection -mshstk flags during library build (and so
also during PCH header creation), but make check doesn't use those flags
and so the PCH header is ignored.
2024-09-26 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/116847
gcc/
* diagnostic.h (diagnostic_option_classifier): Add pch_save and
pch_restore method declarations.
(diagnostic_context): Add pch_save and pch_restore inline method
definitions.
* diagnostic.cc (diagnostic_option_classifier::pch_save): New method.
(diagnostic_option_classifier::pch_restore): Likewise.
gcc/c-family/
* c-pch.cc: Include diagnostic.h.
(c_common_write_pch): Call global_dc->pch_save.
(c_common_read_pch): Call global_dc->pch_restore.
gcc/testsuite/
* g++.dg/pch/pr116847.C: New test.
* g++.dg/pch/pr116847.Hs: New test.
Jakub Jelinek [Fri, 27 Sep 2024 14:06:29 +0000 (16:06 +0200)]
diagnostic: Use vec instead of custom array reallocations for m_classification_history/m_push_list [PR116847]
diagnostic.h already relies on vec.h, it uses auto_vec in one spot.
The following patch converts m_classification_history and m_push_list
hand-managed arrays to vec templates.
The main advantage is exponential rather than linear reallocation,
e.g. with current libstdc++ headers if one includes all the standard
headers there could be ~ 300 reallocations of the m_classification_history
array (sure, not all of them will result in actually copying the data, but
still).
In addition to that it fixes some formatting issues in the code.
2024-09-26 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/116847
* diagnostic.h (diagnostic_option_classifier): Change type
of m_classification_history from diagnostic_classification_change_t *
to vec<diagnostic_classification_change_t>. Change type of
m_push_list from int * to vec<int>. Remove m_n_classification_history
and m_n_push members.
* diagnostic.cc (diagnostic_option_classifier::init): Set m_push_list
to vNULL rather than nullptr. Don't initialize m_n_push. Initialize
m_classification_history to vNULL.
(diagnostic_option_classifier::fini): Call release () method on
m_push_list instead of free on it. Call release () on
m_classification_history. Don't clear m_n_push.
(diagnostic_option_classifier::push): Adjust for m_push_list and
m_classification_history being vectors rather than custom allocated
arrays with counter.
(diagnostic_option_classifier::pop): Likewise.
(classify_diagnostic): Adjust for m_classification_history being
vector rather than custom allocated array with counter.
(update_effective_level_from_pragmas): Likewise.
Use iterative PTA definitions for members of the same AMD processor family.
Also, fix a couple of related M_CPU_TYPE/M_CPU_SUBTYPE inconsistencies.
No functional changes intended.
gcc/ChangeLog:
* config/i386/i386.h: Add PTA_BDVER1, PTA_BDVER2, PTA_BDVER3,
PTA_BDVER4, PTA_BTVER1 and PTA_BTVER2.
* common/config/i386/i386-common.cc (processor_alias_table)
<"bdver1">: Use PTA_BDVER1.
<"bdver2">: Use PTA_BDVER2.
<"bdver3">: Use PTA_BDVER3.
<"bdver4">: Use PTA_BDVER4.
<"btver1">: Use PTA_BTVER1. Use M_CPU_TYPE (AMD_BTVER1).
<"btver2">: Use PTA_BTVER2.
<"shanghai>: Use M_CPU_SUBTYPE (AMDFAM10H_SHANGHAI).
<"istanbul>: Use M_CPU_SUBTYPE (AMDFAM10H_ISTANBUL).
Mark Mentovai [Tue, 24 Sep 2024 20:11:14 +0000 (16:11 -0400)]
libgcc, Darwin: Don't build legacy libgcc_s.1 on macOS 14 [PR116809]
d9cafa0c4f0a stopped building libgcc_s.1 on macOS >= 15, in part because
that is required to bootstrap the compiler using the macOS 15 SDK. The
macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1
can no longer be built on macOS 14 using Xcode 16 by the same logic that
the previous change disabled it for macOS 15.
PR target/116809
libgcc/ChangeLog:
* config.host: Don't build legacy libgcc_s.1 on macOS 14.
c++/coro: ignore cleanup_point_exprs while expanding awaits [PR116793]
If we reach a CLEANUP_POINT_EXPR while trying to walk statements, we
actually care about the statement or statement list contained within it.
Indeed, such a construction started happening with r15-3513-g964577c31df206, after temporary promotion. In the test case
presented in PR116793, the compiler generated:
... i.e. a statement list within a cleanup point. In such a case, we
don't actually care about the cleanup point, but we do care about the
statement inside, so, we can just walk down into the CLEANUP_POINT_EXPR.
PR c++/116793
gcc/cp/ChangeLog:
* coroutines.cc (await_statement_expander): Just process
subtrees if encountering a CLEANUP_POINT_EXPR.
c++: simplify handling implicit INDIRECT_REF and co_await in convert_to_void
convert_to_void has, so far, when converting a co_await expression to
void altered the await_resume expression of a co_await so that it is
also converted to void. This meant that the type of the await_resume
expression, which is also supposed to be the type of the whole co_await
expression, was not the same as the type of the CO_AWAIT_EXPR tree.
While this has not caused problems so far, it is unexpected, I think.
Also, convert_to_void had a special case when an INDIRECT_REF wrapped a
CALL_EXPR. In this case, we also diagnosed maybe_warn_nodiscard. This
was a duplication of logic related to converting call expressions to
void.
Instead, we can generalize a bit, and rather discard the expression that
was implicitly dereferenced instead.
warning: indirection will not access object of incomplete type
'volatile S' in statement
... to:
warning: implicit dereference will not access object of type
‘volatile S’ in statement
... but should have no impact in other cases.
gcc/cp/ChangeLog:
* coroutines.cc (co_await_get_resume_call): Return a tree
directly, rather than a tree pointer.
* cp-tree.h (co_await_get_resume_call): Adjust signature
accordingly.
* cvt.cc (convert_to_void): Do not alter CO_AWAIT_EXPRs when
discarding them. Simplify handling implicit INDIRECT_REFs.
Arsen Arsenović [Wed, 28 Aug 2024 19:59:18 +0000 (21:59 +0200)]
c++/coro: prevent ICV_STATEMENT diagnostics in temp promotion [PR116502]
If such a diagnostic is necessary, it has already been emitted,
otherwise, it is not correct and emitting it here is inactionable by the
user, and bogus.
PR c++/116502
gcc/cp/ChangeLog:
* coroutines.cc (maybe_promote_temps): Convert temporary
initializers to void without complaining.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/maybe-unused-1.C: New test.
* g++.dg/coroutines/pr116502.C: New test.
Remove an item under "Other new TR 13 features" that since the last commit
(r15-3917-g6b7eaec20b046e) to this file is is covered by the added
"New @code{storage} map-type modifier; context-dependent @code{alloc} and
@code{release} are aliases"
"Update of the map-type decay for mapping and @code{declare_mapper}"
Richard Biener [Mon, 23 Sep 2024 13:24:01 +0000 (15:24 +0200)]
tree-optimization/116818 - try VMAT_GATHER_SCATTER also for SLP
When not doing SLP and we end up with VMAT_ELEMENTWISE we consider
using strided loads, aka VMAT_GATHER_SCATTER. The following moves
this logic down to also apply to SLP where we now can end up
using VMAT_ELEMENTWISE as well.
PR tree-optimization/116818
* tree-vect-stmts.cc (get_group_load_store_type): Consider
VMAT_GATHER_SCATTER instead of VMAT_ELEMENTWISE also for SLP.
(vectorizable_load): For single-lane VMAT_GATHER_SCATTER also
ignore permutations.
Richard Biener [Tue, 24 Sep 2024 08:42:01 +0000 (10:42 +0200)]
Fix bogus SLP nvector compute in check_load_store_for_partial_vectors
We have a new overload for vect_get_num_copies that handles both
SLP and non-SLP. Use it and avoid the division by group_size
for SLP when not using load-store lanes.
* tree-vect-stmts.cc (check_load_store_for_partial_vectors):
Use the new vect_get_num_copies overload. Only divide by
group_size for SLP for load-store lanes.
Andrew Pinski [Thu, 26 Sep 2024 05:55:58 +0000 (05:55 +0000)]
unswitch: Replace manual ondemand maybe_undef with ssa_name_maybe_undef_p/mark_ssa_maybe_undefs [PR116848]
The ondemand maybe_undef that follows phis was added in r7-6427-g8b670f93ab1136
but then later ssa_name_maybe_undef_p/mark_ssa_maybe_undefs was added in r13-972-gbe2861fe8c527a. This moves the ondemand one to use
mark_ssa_maybe_undefs/ssa_name_maybe_undef_p instead. Which itself will be
faster since the mark_ssa_maybe_undefs is a walk based on the uses of
undefined names (and only once) rather than a walk based on the def of
ones which are more likely defined (and on demand).
Even though the ondemand maybe_undef had some extra special cases, those won't make
a big difference in most code.
c++/modules: Allow imported references in constant expressions
Currently the streaming code uses TREE_CONSTANT to determine whether an
entity will have a definition that is interesting to stream out. This
is not sufficient, however; we also need to write the definition of
references, since although not TREE_CONSTANT they can still be usable in
constant expressions.
As such this patch uses the existing decl_maybe_constant_var function
which correctly handles this case.
gcc/cp/ChangeLog:
* module.cc (has_definition): Use decl_maybe_constant_var
instead of TREE_CONSTANT.
gcc/testsuite/ChangeLog:
* g++.dg/modules/cexpr-5_a.C: New test.
* g++.dg/modules/cexpr-5_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Fix linkage checks for exported using-decls
This fixes some inconsistencies with what kinds of linkage various
entities are assumed to have. This also fixes handling of exported
using-decls binding to GM entities and type aliases to better align with
the standard's requirements.
gcc/cp/ChangeLog:
* name-lookup.cc (check_can_export_using_decl): Handle internal
linkage GM entities (but ignore in header units); use linkage
of entity ultimately referred to by aliases.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-10.C: Add tests for no-linkage, fix
expected linkage of aliases.
* g++.dg/modules/using-12.C: Likewise.
* g++.dg/modules/using-27.C: New test.
* g++.dg/modules/using-28_a.C: New test.
* g++.dg/modules/using-28_b.C: New test.
* g++.dg/modules/using-29.H: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Mon, 19 Aug 2024 06:38:41 +0000 (16:38 +1000)]
c++: Update decl_linkage for C++11
Currently modules code uses a variety of ad-hoc methods to attempt to
determine whether an entity has internal linkage, which leads to
inconsistencies and some correctness issues as different edge cases are
neglected. While investigating this I discovered 'decl_linkage', but it
doesn't seem to have been updated to account for the C++11 clarification
that all entities declared in an anonymous namespace are internal.
I'm not convinced that even in C++98 it was intended that e.g. types in
anonymous namespaces should be external, but some tests in the testsuite
rely on this, so for compatibility I restricted those modifications to
C++11 and later.
This should have relatively minimal impact as not much seems to actually
rely on decl_linkage, but does change the mangling of symbols in
anonymous namespaces slightly. Previously, we had
namespace {
int x; // mangled as '_ZN12_GLOBAL__N_11xE'
static int y; // mangled as '_ZN12_GLOBAL__N_1L1yE'
}
but with this patch the x is now mangled like y (with the extra 'L').
For contrast, Clang currently mangles neither x nor y with the 'L'.
Since this only affects internal-linkage entities I don't believe this
should break ABI in any observable fashion.
gcc/cp/ChangeLog:
* name-lookup.cc (do_namespace_alias): Propagate TREE_PUBLIC for
namespace aliases.
* tree.cc (decl_linkage): Update rules for C++11.
gcc/testsuite/ChangeLog:
* g++.dg/modules/mod-sym-4.C: Update test to account for
non-static internal-linkage variables new mangling.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Now that fort.N files are removed by the testsuite
framework, remove this single "manual" file deletion.
(Also, it should have been "remote_file target delete",
since it's the target that creates the file, not the build
framework, which might matter to some setups.)
libgcc, libstdc++: Make declarations no longer TU-local [PR115126]
In C++20, modules streaming check for exposures of TU-local entities.
In general exposing internal linkage functions in a header is liable to
cause ODR violations in C++, and this is now detected in a module
context.
This patch goes through and removes 'static' from many declarations
exposed through libstdc++ to prevent code like the following from
failing:
export module M;
extern "C++" {
#include <bits/stdc++.h>
}
Since gthreads is used from C as well, we need to choose whether to use
'inline' or 'static inline' depending on whether we're compiling for C
or C++ (since the semantics of 'inline' are different between the
languages). Additionally we need to remove static global variables, so
we migrate these to function-local statics to avoid the ODR issues.
There doesn't seem to be a good workaround for weakrefs, so I've left
them as-is and will work around it in the modules streaming code to
consider them as not TU-local.
The same issue occurs in the objective-C specific parts of gthreads, but
I'm not familiar with the surrounding context and we don't currently
test modules with Objective C++ anyway so I've left it as-is.
PR libstdc++/115126
libgcc/ChangeLog:
* gthr-posix.h (__GTHREAD_ALWAYS_INLINE): New macro.
(__GTHREAD_INLINE): New macro.
(__gthread_active): Convert from variable to (hidden) function.
(__gthread_active_p): Mark as __GTHREAD_INLINE instead of
static; make visibility("hidden") when it has a static local
variable.
(__gthread_trigger): Mark as __GTHREAD_INLINE instead of static.
(__gthread_create): Likewise.
(__gthread_join): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_self): Likewise.
(__gthread_yield): Likewise.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_mutex_init_function): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_mutex_lock): Likewise.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_timedlock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_recursive_mutex_init_function): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_timedlock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
(__gthread_cond_init_function): Likewise.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__gthread_cond_wait_recursive): Likewise.
(__gthread_cond_destroy): Likewise.
(__gthread_rwlock_rdlock): Likewise.
(__gthread_rwlock_tryrdlock): Likewise.
(__gthread_rwlock_wrlock): Likewise.
(__gthread_rwlock_trywrlock): Likewise.
(__gthread_rwlock_unlock): Likewise.
* gthr-single.h: (__GTHREAD_ALWAYS_INLINE): New macro.
(__GTHREAD_INLINE): New macro.
(__gthread_active_p): Mark as __GTHREAD_INLINE instead of static.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_mutex_lock): Likewise.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
Jonathan Wakely [Tue, 30 Jan 2024 14:47:34 +0000 (14:47 +0000)]
libstdc++: Preserve signbit of nan when converting float to double [PR113578]
LWG 117 specifies that inserting a float into an ostream should cast it
to double, because there's no std::num_put::put member that takes a
float. However, on RISC-V converting a NaN float to double loses the
sign, which means that negative NaN floats are printed as positive.
This has been reported as LWG 4101 and there is good support for fixing
the standard to preserve the sign bit when printing negative NaN values.
This change uses copysign((double)f, (double)std::bit_cast<int>(f)) to
get a double that preserves the sign. The bit_cast gives us an integer
with the same signbit, and casting that to the target type preserves
the signbit. We don't care about the value, as copysign only uses the
signbit.
The inserters for extended floating-point types need the same treatment,
so add a new _S_cast_flt helper to do the signbit-preserving conversion
generically.
So far only RISC-V has been confirmed to need this treatment, but we
might need to extend it to other targets later.
libstdc++-v3/ChangeLog:
PR libstdc++/113578
* include/std/ostream (_S_cast_flt): New static member function
to restore signbit after casting to double or long double.
(operator<<(float), operator<<(_Float16), operator<<(_Float32))
(operator<<(_Float64), operator(_Float128))
(operator<<(__bfloat16_t)): Use _S_cast_flt.
testsuite/27_io/basic_ostream/inserters_arithmetic/lwg4101.cc:
New test.
Co-authored-by: Andrew Waterman <andrew@sifive.com>
Jonathan Wakely [Thu, 26 Sep 2024 11:14:54 +0000 (12:14 +0100)]
libstdc++: Add [[nodiscard]] to iostream members
These are all pure functions and MSVC also marks all of these as
nodiscard except for std::basic_ios::tie() const, but that's been
confirmed as an accidental omission.
Mikael Morin [Thu, 26 Sep 2024 12:23:06 +0000 (14:23 +0200)]
doc: Remove index reference to removed documentation in fortran manual
Fortran option -M used to be an alias for -J. After some deprecation time,
it was reused for another purpose at revision r0-100725-gd8ddea4044ee8212d5fe305e8e2a547700cd7b8f.
That revision removed the documentation parts of -J mentioning -M, but left
a reference to -M in the index.
This change removes the remaining reference.
gcc/fortran/ChangeLog:
* invoke.texi (-M): Remove index reference to removed documentation.
Richard Biener [Wed, 25 Sep 2024 08:38:12 +0000 (10:38 +0200)]
tree-optimization/114855 - speed up dom_oracle::register_transitives
dom_oracle::register_transitives contains an unbound dominator walk
which for the testcase in PR114855 dominates the profile. The following
fixes the unbound work done by assigning a constant work budget to the
loop, bounding the number of dominators visited but also the number of
relations processed. This gets both dom_oracle::register_transitives and
get_immediate_dominator off the profile.
I'll note that we're still doing an unbound dominator walk via
equiv_set in find_equiv_dom at the start of the function and when
we register a relation that also looks up the same way. At least
for the testcase at hand this isn't an issue.
I've also amended the guard to register_transitives with the
per-basic-block limit for the number of relations registered not
being exhausted.
PR tree-optimization/114855
* params.opt (--param transitive-relations-work-bound): New.
* doc/invoke.texi (--param transitive-relations-work-bound):
Document.
* value-relation.cc (dom_oracle::register_transitives):
Assing an overall work budget, bounding the dominator walk and
the number of relations processed.
(dom_oracle::record): Only register_transitives when the
number of already registered relations does not yet exceed
the per-BB limit.
libstdc++: Suppress an attribute suggestion warning [PR116853].
This warning is triggering during the build and breaking bootstrap on
at least two targets. The warning appears valid, but the final fix for
it is not yet clear.
In the meantime, to restore bootstrap, the following patch ignores the
warning in the relevant code section.
PR libstdc++/116853
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Ignore suggest-attribute=format
warning when using posix vsnprintf in to_string() implementations.
Jonathan Wakely [Tue, 24 Sep 2024 11:44:09 +0000 (12:44 +0100)]
libstdc++: Fix std::basic_stracktrace to not assume allocators throw std::bad_alloc
The standard allows allocators to throw any kind of exception, not only
something that can be caught as std::bad_alloc. std::basic_stracktrace
was assuming std::bad_alloc.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Do not assume allocators only throw std::bad_alloc.
Jakub Jelinek [Thu, 26 Sep 2024 09:55:13 +0000 (11:55 +0200)]
pretty-print: Fix up allocate_object
On Thu, Aug 29, 2024 at 06:58:12PM -0400, David Malcolm wrote:
> The following patch rewrites the internals of pp_format.
> The tokens and token lists are allocated on the chunk_obstack, and so
> there's no additional heap activity required, with the memory reclaimed
> when the chunk_obstack is freed after phase 3 of formatting.
> +static void *
> +allocate_object (size_t sz, obstack &s)
> +{
> + /* We must not be half-way through an object. */
> + gcc_assert (obstack_base (&s) == obstack_next_free (&s));
> +
> + obstack_grow (&s, obstack_base (&s), sz);
> + void *buf = obstack_finish (&s);
> + return buf;
> }
I think this is wrong. I hoped it would be the reason of the
unexpected libstdc++ warnings on certain architectures after
seeing
==4027220== Source and destination overlap in memcpy(0x4627154, 0x4627154, 12)
==4027220== at 0x404B93E: memcpy (vg_replace_strmem.c:1123)
==4027220== by 0xAAD5618: allocate_object(unsigned int, obstack&) (pretty-print.cc:1183)
==4027220== by 0xAAD8C0E: operator new (pretty-print.cc:1210)
==4027220== by 0xAAD8C0E: make (pretty-print-format-impl.h:305)
==4027220== by 0xAAD8C0E: format_phase_1 (pretty-print.cc:1659)
==4027220== by 0xAAD8C0E: pretty_printer::format(text_info&) (pretty-print.cc:1618)
==4027220== by 0xAAA840E: pp_format (pretty-print.h:583)
==4027220== by 0xAAA840E: diagnostic_context::report_diagnostic(diagnostic_info*) (diagnostic.cc:1260)
==4027220== by 0xAAA8703: diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, char**, diagnostic_t) (diagnostic.cc:1404)
==4027220== by 0xAAB8682: warning(diagnostic_option_id, char const*, ...) (diagnostic-global-context.cc:166)
==4027220== by 0x97725F5: warn_deprecated_use(tree_node*, tree_node*) (tree.cc:12485)
==4027220== by 0x8B6694B: mark_used(tree_node*, int) (decl2.cc:6121)
==4027220== by 0x8C9E25E: tsubst_expr(tree_node*, tree_node*, int, tree_node*) [clone .part.0] (pt.cc:21626)
==4027220== by 0x8C9E5E6: tsubst_expr(tree_node*, tree_node*, int, tree_node*) [clone .part.0] (pt.cc:20935)
==4027220== by 0x8C9E1D7: tsubst_expr(tree_node*, tree_node*, int, tree_node*) [clone .part.0] (pt.cc:20424)
==4027220== by 0x8C9DF2E: tsubst_expr(tree_node*, tree_node*, int, tree_node*) [clone .part.0] (pt.cc:20496)
==4027220==
etc. valgrind warnings, unfortunately it is not, but still
I think this is a bug.
If the obstack has enough space in it, i.e. if obstack_room (&s) >= sz,
then obstack_grow from obstack_base will copy uninitialized bytes
through memcpy (obstack_base (&s), obstack_base (&s), sz);
(which pedantically isn't valid due to the overlap, and so
the reason why valgrind complains, but in reality I think most
implementations can handle it fine, after all, we also use it for
structure assignments which could have full or no overlap but never
partial).
If obstack_room (&s) < sz, then obstack_grow will first
_obstack_newchunk (&s, sz); which will allocate new memory and
copy the existing data of the object (but the above assertion
guartantees it will copy 0 bytes) and then the memcpy copies
sz bytes from the old base to the new (if unlucky, that could crash
as there could be end of page and unmapped next page in between).
I think we should use obstack_blank instead of obstack_grow, which
does everything obstack_grow does, except for the memcpy of the
uninitialized data.
2024-09-25 Jakub Jelinek <jakub@redhat.com>
* pretty-print.cc (allocate_object): Use obstack_blank rather than
obstack_grow.
Levy Hsu [Wed, 11 Sep 2024 04:49:02 +0000 (14:19 +0930)]
x86: Extend AVX512 Vectorization for Popcount in Various Modes
This patch enables vectorization of the popcount operation for V2QI, V4QI,
V8QI, V2HI, V4HI, and V2SI modes.
gcc/ChangeLog:
* config/i386/mmx.md:
(VQI_16_32_64): New mode iterator for 8-byte, 4-byte, and 2-byte QImode.
(popcount<mode>2): New pattern for popcount of V2QI/V4QI/V8QI mode.
(popcount<mode>2): New pattern for popcount of V2HI/V4HI mode.
(popcountv2si2): New pattern for popcount of V2SI mode.
gcc/testsuite/ChangeLog:
* gcc.target/i386/part-vect-popcount-1.c: New test.
r15-3878 exposed a mistake in the testcase, probably from an older
version of the dumping logic.
Apart from the slightly different syntax for the dump line, also check
for importing the type_decl rather than the const_decl (we need the type
anyway and importing the type also brings along the enumerators so it
would be unnecessary to seed an import for them as well).
Pan Li [Sat, 21 Sep 2024 04:51:58 +0000 (12:51 +0800)]
RISC-V: Add testcases for form 3 of signed vector SAT_ADD
Form 3:
#define DEF_VEC_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_3 (T *out, T *op_1, T *op_2, unsigned limit) \
{ \
unsigned i; \
for (i = 0; i < limit; i++) \
{ \
T x = op_1[i]; \
T y = op_2[i]; \
T sum; \
bool overflow = __builtin_add_overflow (x, y, &sum); \
out[i] = overflow ? x < 0 ? MIN : MAX : sum; \
} \
}
The below test are passed for this patch.
* The rv64gcv fully regression test.
It is test only patch and obvious up to a point, will commit it
directly if no comments in next 48H.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vec_sat_arith.h: Add test helper macros.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-10.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-11.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-12.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-9.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-run-10.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-run-11.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-run-12.c: New test.
* gcc.target/riscv/rvv/autovec/binop/vec_sat_s_add-run-9.c: New test.
Pan Li [Sat, 21 Sep 2024 01:28:39 +0000 (09:28 +0800)]
Match: Support form 3 for vector signed integer .SAT_ADD
This patch would like to support the form 3 of the vector signed
integer .SAT_ADD. Aka below example:
Form 3:
#define DEF_VEC_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_3 (T *out, T *op_1, T *op_2, unsigned limit) \
{ \
unsigned i; \
for (i = 0; i < limit; i++) \
{ \
T x = op_1[i]; \
T y = op_2[i]; \
T sum; \
bool overflow = __builtin_add_overflow (x, y, &sum); \
out[i] = overflow ? x < 0 ? MIN : MAX : sum; \
} \
}
gfortran testsuite: Remove unit-files in files having open-statements, PR116701
PR testsuite/116701 shows that left-behind files from
unnamed gfortran open statements (named unit.N, where N =
unit number) can interfere with the result of a subsequent
run. While that's unlikely to happen for a "real" fortran
target or a test with a deleting close-statement, test-cases
should not rely on previous test-cases passing and not
execute along different execution paths depending on earlier
runs, even if the difference is benevolent.
Most but not all fortran test-cases go through
gfortran-dg-runtest (gfortran.dg) or fortran-torture-execute
(gfortran.fortran-torture). However, the exceptions, with
more complex framework and call-chains, either don't run or
don't have open-statements, so a more complex solution
doesn't seem worthwhile. If test-cases with open-statements
are added later to those parts of the test-suite, calls to
fortran-delete-unit-files at the right spot may be added or
worst case, "manual" cleanup-calls added, like:
! { dg-final { remote_file target delete "fort.10" } }
Put the new proc in fortran-modules.exp since that's where other
common fortran-testsuite dejagnu-library functions are located.
PR testsuite/116701
* lib/fortran-modules.exp (fortran-delete-unit-files): New proc.
* lib/gfortran-dg.exp (gfortran-dg-runtest): Call
fortran-delete-unit-files after executing test.
* lib/fortran-torture.exp (fortran-torture-execute): Ditto.
Mikael Morin [Wed, 25 Sep 2024 19:23:00 +0000 (21:23 +0200)]
doc: Remove @code wrapping of fortran option names [PR116801]
The documentation of gfortran options uses @code wrappings for arguments
to @opindex. This is superfluous, as 'op' index is a texinfo 'code' index,
that is it already implicitly formats its arguments as if in a @code block.
The superfluous wrapping has the effect of creating a nested
<code class="..."> tag inside the regular automatic <code> tag, in the
option index HTML page, preventing the recognition of the corresponding
option by the option URL generation script.
This change removes those superfluous @code wrappings. Additionally,
variables appearing as separate argument in index are removed, permitting
a few more URL recognition. Finally, the URL files are regenerated with the
new URLs recognized on the updated HTML files.
By the way, a spurious 'option' is removed from the label of the std= option
in the index, without any effect on URL recognition.
PR other/116801
gcc/fortran/ChangeLog:
* invoke.texi: Remove @code wrapping in arguments to @opindex.
(std=): Remove spurious 'option' in index.
(idirafter, imultilib, iprefix, isysroot, iquote, isystem,
fintrinsic-modules-path): Remove variable from index.
* lang.opt.urls: Regenerate.
Jakub Jelinek [Wed, 25 Sep 2024 18:17:11 +0000 (20:17 +0200)]
i386: Add GENERIC and GIMPLE folders of __builtin_ia32_{min,max}* [PR116738]
The following patch adds GENERIC and GIMPLE folders for various
x86 min/max builtins.
As discussed, these builtins have effectively x < y ? x : y
(or x > y ? x : y) behavior.
The GENERIC folding is done if all the (relevant) arguments are
constants (such as VECTOR_CST for vectors) and is done because
the GIMPLE folding can't easily handle masking, rounding and the
ss/sd cases (in a way that it would be pattern recognized back to the
corresponding instructions). The GIMPLE folding is also done just
for TARGET_SSE4 or later when optimizing, otherwise it is apparently
not matched back.
if address override is used to avoid the invalid memory operand like
cmpl %fs:previous_emax@dtpoff(%eax), %r12d
gcc/
PR target/116839
* config/i386/i386.cc (ix86_rewrite_tls_address_1): Make it
static. Return if TLS address is thread register plus an integer
register.
gcc/testsuite/
PR target/116839
* gcc.target/i386/pr116839.c: New file.
In particular, this now allows some harmless diagnostic flags (especially
useful for things like -Werror=odr), more optimization flags, and some
Clang-specific options.
GCC's -flto documentation mentions:
> To use the link-time optimizer, -flto and optimization options should be
> specified at compile time and during the final link. It is recommended
> that you compile all the files participating in the same link with the
> same options and also specify those options at link time.
This allows compliance with that.
* ltmain.sh (func_mode_link): Allow various flags through filter.
Andrew Pinski [Tue, 24 Sep 2024 02:17:42 +0000 (19:17 -0700)]
Add an alternative testcase for PR 70740
While looking into improving phiprop, I noticed that
the current pr70740.c testcase was being optimized almost
all the way before phiprop because the addresses were considered
the same; the arrays were all zero in size.
This adds an alternative testcase which changes the array sizes to be 1
and phiprop can and will act on this testcase now and the fix which was
being tested is actually tested now.
Tested on x86_64-linux-gnu.
PR tree-optimization/70740
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr70740-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Thu, 19 Sep 2024 20:50:14 +0000 (13:50 -0700)]
match: Fix `a != 0 ? a * b : 0` patterns for things that trap [PR116772]
For generic, `a != 0 ? a * b : 0` would match where `b` would be an expression
which trap (in the case of the testcase, it was an integer division but it could be any).
This adds a new helper function, expr_no_side_effects_p which tests if there is no side effects
and the expression is not trapping which might be used in other locations.
Changes since v1:
* v2: Add move check to helper function instead of inlining it.
PR middle-end/116772
gcc/ChangeLog:
* generic-match-head.cc (expr_no_side_effects_p): New function
* gimple-match-head.cc (expr_no_side_effects_p): New function
* match.pd (`a != 0 ? a / b : 0`): Check expr_no_side_effects_p.
(`a != 0 ? a * b : 0`, `a != 0 ? a & b : 0`): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr116772-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jakub Jelinek [Wed, 25 Sep 2024 14:07:50 +0000 (16:07 +0200)]
c++: Add testcase for DR 2836
Seems we already handle it the way the DR clarifies, if double/long double
and std::float64_t have the same mode, foo has long double type (while
x + y would be _Float64 in C23), so this patch just adds a testcase which
verifies that.
match: Fix A || B not optimized to true when !B implies A [PR114326]
In expressions like (a != b || ((a ^ b) & c) == d) and
(a != b || (a ^ b) == c), (a ^ b) is folded to false.
In the equivalent expressions (((a ^ b) & c) == d || a != b) and
((a ^ b) == c || a != b) this is not happening.
This patch adds the following simplifications in match.pd:
((a ^ b) & c) cmp d || a != b --> 0 cmp d || a != b
(a ^ b) cmp c || a != b --> 0 cmp c || a != b
PR tree-optimization/114326
gcc/ChangeLog:
* match.pd: Add two patterns to fold a ^ b to 0, when a == b.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/fold-xor-and-or.c: New test.
* gcc.dg/tree-ssa/fold-xor-or.c: New test.
Tested-by: Christoph Müllner <christoph.muellner@vrull.eu> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Signed-off-by: Konstantinos Eleftheriou <konstantinos.eleftheriou@vrull.eu>
Richard Biener [Wed, 25 Sep 2024 11:15:42 +0000 (13:15 +0200)]
Speed up wide_int_storage::operator=(wide_int_storage const&)
wide_int_storage shows up high in the profile for the testcase in
PR114855 where the apparent issue is that the conditional jump
on 'precision' after the (inlined) memcpy stalls the pipeline due
to the data dependence and required store-to-load forwarding. We
can add scheduling freedom by instead testing precision as from the
source which speeds up the function by 30%. I've applied the
same logic to the copy CTOR.
* wide-int.h (wide_int_storage::wide_int_storage): Branch
on source precision to avoid data dependence on memcpy
destination.
(wide_int_storage::operator=): Likewise.
match: Change (A * B) + (-C) to (B - C/A) * A, if C multiple of A [PR109393]
The following function:
int foo(int *a, int j)
{
int k = j - 1;
return a[j - 1] == a[k];
}
does not fold to `return 1;` using -O2 or higher. The cause of this is that
the expression `4 * j + (-4)` for the index computation is not folded to
`4 * (j - 1)`. Existing simplifications that handle similar cases are applied
when A == C, which is not the case in this instance.
A previous attempt to address this issue is
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649896.html
This patch adds the following simplification in match.pd:
(A * B) + (-C) -> (B - C/A) * A, if C a multiple of A
which also handles cases where the index is j - 2, j - 3, etc.
Bootstrapped for all languages and regression tested on x86-64 and aarch64.
PR tree-optimization/109393
gcc/ChangeLog:
* match.pd: (A * B) + (-C) -> (B - C/A) * A, if C a multiple of A.
gcc/testsuite/ChangeLog:
* gcc.dg/pr109393.c: New test.
Tested-by: Christoph Müllner <christoph.muellner@vrull.eu> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Signed-off-by: Konstantinos Eleftheriou <konstantinos.eleftheriou@vrull.eu>
Richard Biener [Wed, 25 Sep 2024 10:46:28 +0000 (12:46 +0200)]
remove dominator recursion from reassoc
The reassoc pass currently walks dominators in a recursive way where
I ran into a stack overflow with. The following replaces it with
worklists following patterns used elsewhere.
* tree-ssa-reassoc.cc (break_up_subtract_bb): Remove recursion.
(reassociate_bb): Likewise.
(do_reassoc): Implement worklist based dominator walks for
both break_up_subtract_bb and reassociate_bb.
Aldy Hernandez [Mon, 26 Aug 2024 05:33:38 +0000 (07:33 +0200)]
Remove recursion in simplify_control_stmt_condition_1 [PR114855].
Remove some ad-hoc simplification code in the forward threader, as the
call into the ranger in m_simplifier->simplify() will handle anything we
can do manually in simplify_control_stmt_condition_1.
In PR114855, DOM time is reduced from 120s to 92s (-23%) and overall
compilation time from 235s to 205s (-12%). The total thread count at -O1 is
unchanged for the testcase.
In our bootstrap .ii benchmark suite, I see we thread 3 threads less
over all files at -O1. At -O2, the backward threader picks up one more,
for no difference over all.
Jason Merrill [Thu, 12 Sep 2024 16:15:51 +0000 (12:15 -0400)]
libstdc++: #ifdef out #pragma GCC system_header
In r15-3714-gd3a7302ec5985a I added -Wsystem-headers to the libstdc++ build
flags to help catch problems in the library. This patch takes a different
approach, of disabling the #pragma system_header unless _GLIBCXX_SYSHDR is
defined. As a result, the testsuites will treat them as non-system-headers
to get better warning coverage during regression testing of both gcc and
libstdc++, not just when building the library.
My rationale for the #ifdef instead of just removing the #pragma is the
three G++ tests that want to test libstdc++ system header behavior, so we
need a way to select it.
This doesn't affect installed libraries, as they get their
system-header status from the lookup path. But testsuite_flags
--build-includes gives -I directives rather than -isystem.
This patch doesn't change the headers in config/ because I'm not compiling
with most of them, so won't see any warnings that need fixing. Adjusting
them could happen later, or we can not bother.
Richard Biener [Wed, 25 Sep 2024 10:52:32 +0000 (12:52 +0200)]
Use tree view for find_always_executed_bbs result
The following makes us use bitmap tree view for the always-executed-BBs
bitmap as computed by IPA utils find_always_executed_bbs and used by
IPA modref (where it shows up in the profile for PR114855.
* ipa-utils.cc (find_always_executed_bbs): Switch result
bitmap to tree view.
OpenMP: Update OMP_REQUIRES_TARGET_USED for declare_target + interop
Older versions of the OpenMP specification were not clear about what counted
as device usage. Newer (like TR13) are rather clear. Hence, this commit adds
GCC's target-used flag also when a 'declare target' or an 'interop' are
encountered. (The latter only to Fortran as C/C++ parsing support is still
missing.) TR13 also lists 'dispatch' as target-used construct (as it has the
device clause) and 'device_safesync' as clause with global requirement
property, but both are not yet supported in GCC.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_declare_target): Set target-used bit
in omp_requires_mask.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_declare_target): Set target-used bit
in omp_requires_mask.
gcc/fortran/ChangeLog:
* parse.cc (decode_omp_directive): Set target-used bit of
omp_requires_mask when encountering the declare_target or interop
directive.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/interop-1.f90: Add dg-error for missing
omp requires requirement and declare_variant usage.
* gfortran.dg/gomp/requires-8.f90: Likewise.
Richard Biener [Tue, 24 Sep 2024 12:10:13 +0000 (14:10 +0200)]
rtl-optimization/114855 - slow add_store_equivs in IRA
For the testcase in PR114855 at -O1 add_store_equivs shows up as the
main sink for bitmap_set_bit because it uses a bitmap to mark all
seen insns by UID to make sure the forward walk in memref_used_between_p
will find the insn in question. Given we do have a CFG here the
functions operation is questionable, given memref_used_between_p
together with the walk of all insns is obviously quadratic in the
worst case that whole thing should be re-done ... but, for the
testcase, using a sbitmap of size get_max_uid () + 1 gets
bitmap_set_bit off the profile and improves IRA time from 15.58s (8%)
to 3.46s (2%).
Now, given above quadraticness I wonder whether we should instead
gate add_store_equivs on optimize > 1 or flag_expensive_optimizations.
PR rtl-optimization/114855
* ira.cc (add_store_equivs): Use sbitmap for tracking
visited insns.
Richard Biener [Tue, 24 Sep 2024 09:47:26 +0000 (11:47 +0200)]
tree-optimization/114855 - slow VRP due to equiv oracle queries
For the testcase in PR114855 VRP takes 320.41s (23%) (after mitigating
backwards threader slowness). This is mostly due to the bitmap check
in equiv_oracle::find_equiv_dom. The following turns this bitmap
to tree view, trading the linear search for a O(log N) one which
improves VRP time to 54.54s (5%).
PR tree-optimization/114855
* value-relation.cc (equiv_oracle::equiv_oracle): Switch
m_equiv_set to tree view.
The testcase decare-variant-duplicates.c added in commit 96246bff0bcd9e5cdec9e6cf811ee3db4997f6d4 failed on 32-bit x86
because on that target "i386" is defined as a preprocessor macro
and cannot be used as an identifier. Fixed by rewriting that test
not to do that.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/declare-variant-duplicates.c: Avoid using
"i386" as an identifier.
Thomas Koenig [Tue, 24 Sep 2024 20:57:42 +0000 (22:57 +0200)]
Add random numbers and fix some bugs.
This patch adds random number support for UNSIGNED, plus fixes
two bugs, with array I/O where the type used to be set to BT_INTEGER,
and for division with the divisor being a constant.
gcc/fortran/ChangeLog:
* check.cc (gfc_check_random_number): Adjust for unsigned.
* iresolve.cc (gfc_resolve_random_number): Handle unsigned.
* trans-expr.cc (gfc_conv_expr_op): Handle BT_UNSIGNED for divide.
* trans-types.cc (gfc_get_dtype_rank_type): Handle BT_UNSIGNED.
* gfortran.texi: Add RANDOM_NUMBER for UNSIGNED.
libgfortran/ChangeLog:
* gfortran.map: Add _gfortran_random_m1, _gfortran_random_m2,
_gfortran_random_m4, _gfortran_random_m8 and _gfortran_random_m16.
* intrinsics/random.c (random_m1): New function.
(random_m2): New function.
(random_m4): New function.
(random_m8): New function.
(random_m16): New function.
(arandom_m1): New function.
(arandom_m2): New function.
(arandom_m4): New function.
(arandom_m8): New funciton.
(arandom_m16): New function.
Thomas Koenig [Tue, 24 Sep 2024 20:53:59 +0000 (22:53 +0200)]
Implement IANY, IALL and IPARITY for unsigned.
gcc/fortran/ChangeLog:
* check.cc (gfc_check_transf_bit_intrins): Handle unsigned.
* gfortran.texi: Docment IANY, IALL and IPARITY for unsigned.
* iresolve.cc (gfc_resolve_iall): Set flag to use integer
if type is BT_UNSIGNED.
(gfc_resolve_iany): Likewise.
(gfc_resolve_iparity): Likewise.
* simplify.cc (do_bit_and): Adjust asserts for BT_UNSIGNED.
(do_bit_ior): Likewise.
(do_bit_xor): Likewise
Thomas Koenig [Tue, 24 Sep 2024 19:59:10 +0000 (21:59 +0200)]
Implement SUM and PRODUCT for unsigned.
gcc/fortran/ChangeLog:
* gfortran.texi: Document SUM and PRODUCT.
* iresolve.cc (resolve_transformational): New argument,
use_integer, to translate calls to unsigned to calls to
integer.
(gfc_resolve_product): Use it
(gfc_resolve_sum): Use it.
* simplify.cc (init_result_expr): Handle BT_UNSIGNED.
Thomas Koenig [Tue, 24 Sep 2024 19:51:42 +0000 (21:51 +0200)]
Implement MATMUL and DOT_PRODUCT for unsigned.
gcc/fortran/ChangeLog:
* arith.cc (gfc_arith_uminus): Fix warning.
(gfc_arith_minus): Correctly truncate unsigneds.
* check.cc (gfc_check_dot_product): Handle unsigned arguments.
(gfc_check_matmul): Likewise.
* expr.cc (gfc_get_unsigned_expr): New function.
* gfortran.h (gfc_get_unsigned_expr): Add prototype.
* iresolve.cc (gfc_resolve_matmul): If using UNSIGNED, use the
signed integer version.
* gfortran.texi: Document MATMUL and DOT_PRODUCT for unsigned.
* simplify.cc (compute_dot_product): Handle unsigneds.
libgfortran/ChangeLog:
* m4/iparm.m4: Add UNSIGED if type is m.
* m4/matmul.m4: If type is GFC_INTEGER, use GFC_UINTEGER instead.
Whitespace fixes.
* m4/matmul_internal.m4: Whitespace fixes.
Jakub Jelinek [Tue, 24 Sep 2024 18:19:50 +0000 (20:19 +0200)]
c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for Loop [PR107637]
The following patch implements the C++23 P2718R0 paper
- Wording for P2644R1 Fix for Range-based for Loop.
The patch introduces a new option, -f{,no-}range-for-ext-temps so that
user can control the behavior even in older C++ versions.
The option is on by default in C++23 and later (-fno-range-for-ext-temps
is an error in that case) and in the -std=gnu++11 ... -std=gnu++20 modes
(one can use -fno-range-for-ext-temps to request previous behavior in that
case), and is not enabled by default in -std=c++11 ... -std=c++20 modes
but one can explicitly enable it with -frange-for-ext-temps.
As all the temporaries from __for_range initialization should have life
extended until the end of __for_range scope, this patch disables (for
-frange-for-ext-temps and if !processing_template_decl) CLEANUP_POINT_EXPR wrapping
of the __for_range declaration, also disables -Wdangling-reference warning
as well as the rest of extend_ref_init_temps (we know the __for_range temporary
is not TREE_STATIC and as all the temporaries from the initializer will be life
extended, we shouldn't try to handle temporaries referenced by references any
differently) and adds an extra push_stmt_list/pop_stmt_list before
cp_finish_decl of __for_range and after end of the for body and wraps all
that into CLEANUP_POINT_EXPR.
I had to repeat that also for OpenMP range loops because those are handled
differently.
2024-09-24 Jakub Jelinek <jakub@redhat.com>
PR c++/107637
gcc/
* omp-general.cc (find_combined_omp_for, find_nested_loop_xform):
Handle CLEANUP_POINT_EXPR like TRY_FINALLY_EXPR.
* doc/invoke.texi (frange-for-ext-temps): Document. Add
-fconcepts to the C++ option list.
gcc/c-family/
* c.opt (frange-for-ext-temps): New option.
* c-opts.cc (c_common_post_options): Set flag_range_for_ext_temps
for C++23 or later or for C++11 or later in !flag_iso mode if
the option wasn't set by user.
* c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_range_based_for
value for flag_range_for_ext_temps from 201603L to 202212L in C++17
or later.
* c-omp.cc (c_find_nested_loop_xform_r): Handle CLEANUP_POINT_EXPR
like TRY_FINALLY_EXPR.
gcc/cp/
* cp-tree.h: Implement C++23 P2718R0 - Wording for P2644R1 Fix for
Range-based for Loop.
(cp_convert_omp_range_for): Add bool tmpl_p argument.
(find_range_for_decls): Declare.
* parser.cc (cp_convert_range_for): For flag_range_for_ext_temps call
push_stmt_list () before cp_finish_decl for range_temp and save it
temporarily to FOR_INIT_STMT.
(cp_convert_omp_range_for): Add tmpl_p argument. If set, remember
DECL_NAME of range_temp and for cp_finish_decl call restore it before
clearing it again, if unset, don't adjust DECL_NAME of range_temp at
all.
(cp_parser_omp_loop_nest): For flag_range_for_ext_temps range for add
CLEANUP_POINT_EXPR around sl. Call find_range_for_decls and adjust
DECL_NAMEs for range fors if not processing_template_decl. Adjust
cp_convert_omp_range_for caller. Remove superfluous backslash at the
end of line.
* decl.cc (initialize_local_var): For flag_range_for_ext_temps
temporarily clear stmts_are_full_exprs_p rather than set for
for_range__identifier decls.
* call.cc (extend_ref_init_temps): For flag_range_for_ext_temps return
init early for for_range__identifier decls.
* semantics.cc (find_range_for_decls): New function.
(finish_for_stmt): Use it. For flag_range_for_ext_temps if
cp_convert_range_for set FOR_INIT_STMT, pop_stmt_list it and wrap
into CLEANUP_POINT_EXPR.
* pt.cc (tsubst_omp_for_iterator): Adjust tsubst_omp_for_iterator
caller.
(tsubst_stmt) <case OMP_FOR>: For flag_range_for_ext_temps if there
are any range fors in the loop nest, add push_stmt_list starting
before the initializations, pop_stmt_list it after the body and wrap
into CLEANUP_POINT_EXPR. Change DECL_NAME of range for temps from
NULL to for_range_identifier.
gcc/testsuite/
* g++.dg/cpp23/range-for1.C: New test.
* g++.dg/cpp23/range-for2.C: New test.
* g++.dg/cpp23/range-for3.C: New test.
* g++.dg/cpp23/range-for4.C: New test.
* g++.dg/cpp23/range-for5.C: New test.
* g++.dg/cpp23/range-for6.C: New test.
* g++.dg/cpp23/range-for7.C: New test.
* g++.dg/cpp23/range-for8.C: New test.
* g++.dg/cpp23/feat-cxx2b.C (__cpp_range_based_for): Check for
202212L rather than 201603L.
* g++.dg/cpp26/feat-cxx26.C (__cpp_range_based_for): Likewise.
* g++.dg/warn/Wdangling-reference4.C: Don't expect warning for C++23
or newer. Use dg-additional-options rather than dg-options.
libgomp/
* testsuite/libgomp.c++/range-for-1.C: New test.
* testsuite/libgomp.c++/range-for-2.C: New test.
* testsuite/libgomp.c++/range-for-3.C: New test.
* testsuite/libgomp.c++/range-for-4.C: New test.
* testsuite/libgomp.c++/range-for-5.C: New test.
libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809].
We have been building a legacy libgcc_s.1 DSO to support code that
was built with older compilers.
From macOS 15, the unwinder no longer exports some of the symbols used
in that library which (a) cuases bootstrap fail and (b) means that the
legacy library is no longer useful.
No open branch of GCC emits references to this library - and any already
-built code that depends on the symbols would need rework anyway.
PR target/116809
libgcc/ChangeLog:
* config.host: Build legacy libgcc_s.1 on hosts before macOS 15.
* config/i386/t-darwin: Remove reference to legacy libgcc_s.1
* config/rs6000/t-darwin: Likewise.
* config/t-darwin-libgccs1: New file.
c++/contracts: ICE in build_contract_condition_function [PR116490]
We currently do not expect comdat group of the guarded function to
be set at the time of generating pre and post check function.
However, in the case of an explicit instantiation, the guarded
function has been added to a comdat group before generating contract
check functions, which causes the observed ICE. Current assert
removed and an additional check for comdat group of the guarded
function added. With this change, the pre and post check functions
get added to the same comdat group of the guarded function if the
guarded function is already placed in a comdat group.
PR c++/116490
gcc/cp/ChangeLog:
* contracts.cc (build_contract_condition_function): added
a check for comdat group of the guarded function. If set,
the condition check function is added to the same comdat
group.
libgomp: with USM, init 'link' variables with host address
If requires unified_shared_memory or self_maps is set, make
'declare target link' variables to point initially to the host pointer.
libgomp/ChangeLog:
* target.c (gomp_load_image_to_device): For requires
unified_shared_memory, update 'link' vars to point to the host var.
* testsuite/libgomp.c-c++-common/target-link-3.c: New test.
* testsuite/libgomp.c-c++-common/target-link-4.c: New test.
projects / thirdparty / gcc.git / log
