Hi,
This patch changes the default linkage of templates in the D language to
be DECL_WEAK instead of DECL_ONE_ONLY, if supported. This better
matches the expected override semantics of template symbols compiled to
object code. For example:
module rt.config;
template rt_flag()
{
pragma(man
On 4/3/21 10:54 AM, Jason Merrill wrote:
The if allows TEMPLATE_DECL, but then checking DECL_MODULE_IMPORT_P crashes
on TEMPLATE_DECL. Fixed by stripping TEMPLATE_DECL first.
Nathan, does this look right to you?
gcc/cp/ChangeLog:
* ptree.c (cxx_print_decl): Check DECL_MODULE_IMPORT_P
When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need
to walk into the body of a lambda to find all the local_specializations that
we need to remember, like we do in find_parameter_packs_r.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/9920
'extern template' should mean that the relevant symbols are never emitted.
But in this case we were assuming that DECL_EXTERNAL was already set on the
variable, so we just needed to clear DECL_NOT_REALLY_EXTERN. Since
DECL_EXTERNAL was not set, we emitted a definition of npos.
Tested x86_64-pc-li
On Mon, Mar 22, 2021 at 6:16 AM H.J. Lu wrote:
>
> Simply memcpy and memset inline strategies to avoid branches for
> Skylake family CPUs:
>
> 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector
>load and store for up to 16 * 16 (256) bytes when the data size is
>fixed an
This problem got introduced fixing a module numbering problem. When
preprocessing a header unit, we don't need to send an EXPORT query
unless we're also determining dependencies, or the mapper askedus to.
Sadly the testsuite isn't set up to test this kind of subtlety. I
manually did that with
The analyzer appeared to enter an infinite loop on malloc-1.c
when -fanalyzer-verbosity=0 was used. In fact, it was slowly
counting from 0 to 0x.
Root cause is looping up to effectively ((unsigned)0) - 1 in
diagnostic_manager::consolidate_conditions when there are no events
in the path.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7988-g7d8f4240c94e2e7643ac13cda1fdd0bb6ca3a3fb.
gcc/analyzer/ChangeLog:
PR analyzer/99906
* analyzer.cc (maybe_reconstruct_from_def_stmt): Fix NULL
dereference on calls with zero arguments
In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and adc_return_type during the constraint handling.
Meanwhile, I noticed we weren't checkin
On Mon, 5 Apr 2021, Patrick Palka wrote:
> In this PR, we're crashing because the constraint handling inside
> do_auto_deduction doesn't expect to see an adc_decomp_type context.
> This patch fixes this by treating adc_decomp_type like adc_variable_type
> and adc_return_type during the constraint
When the enumeration constants of an enumeration type are defined by explicit
values, the binding generated by -fdump-ada-spec does not use an enumeration
type on the Ada side, because the set of allowed values in C/C++ is larger
than the set of allowed values in Ada, but instead use an integer
On 4/5/21 12:31 PM, Patrick Palka wrote:
On Mon, 5 Apr 2021, Patrick Palka wrote:
In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and ad
Here enclosing_instantiation_of was failing to find a match because otctx is
struct S and current_function_decl is S::S(), so the latter has more
function contexts, and we end up trying to compare S() to NULL_TREE.
After spending a bit of time working on establishing the correspondence in
this cas
Here we weren't instantiating the enumerators because the arglist still had
the template parameter for the generic lambda, so looking one up failed. We
need to instantiate if the non-lambda enclosing scope is non-dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
Hi,
This patch adds TARGET_D_HAS_STDCALL_CONVENTION as a new D front-end
target hook. It replaces the use of the D front-end `is64bit' parameter
in determining whether to insert the "stdcall" function attribute.
It is also used to determine whether `extern(System)' should be the same
as `extern(
Hi,
This patch adds TARGET_D_REGISTER_CPU_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "floatAbi")' for all
targets that have D support files.
This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left out un
Hi,
This patch adds TARGET_D_REGISTER_OS_TARGET_INFO as a new D front-end
target hook, implementing `__traits(getTargetInfo, "objectFormat")' for
all targets that have D support files.
This trait was added earlier in the front-end as a stub, however the
target-specific implementation was left out
> > /* skylake_cost should produce code tuned for Skylake familly of CPUs. */
> > static stringop_algs skylake_memcpy[2] = {
> > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > - {libcall, {{16, loop, false}, {512, unrolled_loop, false},
> > - {-1, libca
In r260622 I allowed this under the general principle that [basic.lval]
"Whenever a prvalue appears as an operand of an operator that expects a
glvalue for that operand, the temporary materialization conversion (7.3.4)
is applied to convert the expression to an xvalue." But
[expr.reinterpret.cast]
We never called mark_use for a return value in a function with dependent
return type. In that situation we don't know if the use is as an rvalue or
lvalue, but we can use mark_exp_read instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/96311
* typec
On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka wrote:
>
> > > /* skylake_cost should produce code tuned for Skylake familly of CPUs.
> > > */
> > > static stringop_algs skylake_memcpy[2] = {
> > > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}},
> > > - {libcall, {{16, loo
In this testcase, the parms remembered in LAMBDA_EXPR_EXTRA_SCOPE are no
longer the parms of the FUNCTION_DECL they have as their DECL_CONTEXT, so we
were mangling both lambdas as parm #0. But since the parms are numbered
from right to left we don't need to need to find them in the FUNCTION_DECL,
22 matches
Mail list logo
