| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There are various -Wanalyzer-null-dereference false +ves in bugzilla
that I've been attempting to fix. Unfortunately I haven't made much
progress, but it seems worth at least capturing the reduced
reproducers as test cases, to make it easier to spot changes in
behavior.
gcc/testsuite/ChangeLog:
PR analyzer/102671
PR analyzer/105755
PR analyzer/108251
PR analyzer/108400
* gcc.dg/analyzer/null-deref-pr102671-1.c: New test, reduced
from Emacs.
* gcc.dg/analyzer/null-deref-pr102671-2.c: Likewise.
* gcc.dg/analyzer/null-deref-pr105755.c: Likewise.
* gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
New test, reduced from haproxy's src/ssl_sample.c.
* gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:
Likewise.
* gcc.dg/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c: New
test, reduced from SoftEtherVPN's src/Cedar/WebUI.c.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
When doing an emergency dump the cfg output dumps are corrupted because the
ending "}" is missing.
Normally when the pass manager finishes it would call finish_graph_dump_file to
produce this. This is called here because each pass can dump multiple digraphs.
However during an emergency dump we only dump the current function and so after
that is done we never go back to the pass manager.
As such, we need to manually call finish_graph_dump_file in order to properly
finish off graph generation.
With this -ftree-dump-*-graph works properly during a crash dump.
gcc/ChangeLog:
* passes.cc (emergency_dump_function): Finish graph generation.
|
|
We were analyzing code quality after recent changes and have noticed that the
tbz support somehow managed to increase the number of branches overall rather
than decreased them.
While investigating this we figured out that the problem is that when an
existing & <contants> exists in gimple and the instruction is generated because
of the range information gotten from the ANDed constant that we end up with the
situation that you get a NOP AND in the RTL expansion.
This is not a problem as CSE will take care of it normally. The issue is when
this original AND was done in a location where PRE or FRE "lift" the AND to a
different basic block. This triggers a problem when the resulting value is not
single use. Instead of having an AND and tbz, we end up generating an
AND + TST + BR if the mode is HI or QI.
This CSE across BB was a problem before but this change made it worse. Our
branch patterns rely on combine being able to fold AND or zero_extends into the
instructions.
To work around this (since a proper fix is outside of the scope of stage-4) we
are limiting the new tbranch optab to only HI and QI mode values. This isn't a
problem because these two modes are modes for which we don't have CBZ support,
so they are the problematic cases to begin with. Additionally booleans are QI.
The second thing we're doing is limiting the only legal bitpos to pos 0. i.e.
only the bottom bit. This such that we prevent the double ANDs as much as
possible.
Now most other cases, i.e. where we had an explicit & in the source code are
still handled correctly by the anonymous (*tb<optab><ALLI:mode><GPI:mode>1)
pattern that was added along with tbranch support.
This means we don't expand the superflous AND here, and while it doesn't fix the
problem that in the cross BB case we loss tbz, it also doesn't make things worse.
With these tweaks we've now reduced the number of insn uniformly was originally
expected.
gcc/ChangeLog:
* config/aarch64/aarch64.md (tbranch_<code><mode>3): Restrict to SHORT
and bottom bit only.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/tbz_2.c: New test.
* gcc.target/aarch64/tbz_3.c: New test.
|
|
The LWG 3820 testcase revealed a bug in _M_advance, which this patch
also fixes.
libstdc++-v3/ChangeLog:
* include/std/ranges
(cartesian_product_view::_Iterator::_Iterator): Remove
constraint on default constructor as per LWG 3849.
(cartesian_product_view::_Iterator::_M_prev): Adjust position
of _Nm > 0 test as per LWG 3820.
(cartesian_product_view::_Iterator::_M_advance): Perform bounds
checking only on sized cartesian products.
* testsuite/std/ranges/cartesian_product/1.cc (test08): New test.
|
|
PR libstdc++/109024
libstdc++-v3/ChangeLog:
* include/std/ranges (chunk_by_view::_M_pred): Remove DMI as per
LWG 3796.
(repeat_view::_M_pred): Likewise.
* testsuite/std/ranges/adaptors/chunk_by/1.cc (test03): New test.
* testsuite/std/ranges/repeat/1.cc (test05): New test.
|
|
PR libstdc++/108362
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__can_single_view): New concept.
(_Single::operator()): Constrain it. Move [[nodiscard]] to the
end of the function declarator.
(__detail::__can_iota_view): New concept.
(_Iota::operator()): Constrain it. Move [[nodiscard]] to the
end of the function declarator.
(__detail::__can_istream_view): New concept.
(_Istream::operator()): Constrain it. Move [[nodiscard]] to the
end of the function declarator.
* testsuite/std/ranges/iota/iota_view.cc (test07): New test.
* testsuite/std/ranges/istream_view.cc (test08): New test.
* testsuite/std/ranges/single_view.cc (test07): New test.
|
|
The problem here is after r13-4748-g2a27ae32fabf85, in some
cases we were calling inform without a corresponding warning.
This changes the logic such that we only cause that to happen
if there was a warning happened before hand.
Changes since
* v1: Fix formating and dump message as suggested by Jakub.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/108980
* gimple-array-bounds.cc (array_bounds_checker::check_array_ref):
Reorgnize the call to warning for not strict flexible arrays
to be before the check of warned.
|
|
ranges::begin() isn't guaranteed to be equality-preserving for non-forward
ranges, so in cartesian_product_view::end we need to avoid needlessly
calling begin() on the first range (which could be non-forward) in the
case where __empty_tail is false as per its specification.
Since we're already using a variadic lambda to compute __empty_tail, we
might as well use that same lambda to build up the tuple of iterators
instead of building it separately via e.g. std::apply or __tuple_transform.
PR libstdc++/107572
libstdc++-v3/ChangeLog:
* include/std/ranges (cartesian_product_view::end): When
building the tuple of iterators, avoid calling ranges::begin on
the first range if __empty_tail is false.
* testsuite/std/ranges/cartesian_product/1.cc (test07): New test.
|
|
libstdc++-v3/ChangeLog:
PR libstdc++/108882
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Fix incorrect
patterns.
|
|
The standard was unclear what happens with the transformation of a deduction
guide if the initial template argument deduction fails for a reason other
than not deducing all the arguments; my implementation assumed that the
right thing was to give up on the deduction guide. But in consideration of
CWG2664 this week I realized that we get a better result by just continuing
with an empty set of deductions, so the alias deduction guide is the same as
the original deduction guide plus the deducible constraint.
DR 2664
PR c++/102529
gcc/cp/ChangeLog:
* pt.cc (alias_ctad_tweaks): Continue after deduction failure.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2664.C: New test.
* g++.dg/cpp2a/class-deduction-alias15.C: New test.
|
|
In my initial implementation of alias CTAD, I described a couple of
differences from the specification that I thought would not have a practical
effect; this testcase demonstrates that I was wrong. One difference is
resolved by the CPTK_IS_DEDUCIBLE commit; the other (adding too many of the
alias template parameters to the new deduction guide) is fixed by this
patch.
PR c++/105841
gcc/cp/ChangeLog:
* pt.cc (corresponding_template_parameter_list): Split out...
(corresponding_template_parameter): ...from here.
(find_template_parameters): Factor out...
(find_template_parameter_info::find_in): ...this function.
(find_template_parameter_info::find_in_recursive): New.
(find_template_parameter_info::found): New.
(alias_ctad_tweaks): Only add parms used in the deduced args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias14.C: New test.
Co-authored-by: Michael Spertus <mike@spertus.com>
|
|
I want to have more discussion about the interface before claiming the
__is_deducible name, so for GCC 13 make it internal-only.
gcc/ChangeLog:
* doc/extend.texi: Comment out __is_deducible docs.
gcc/cp/ChangeLog:
* cp-trait.def (IS_DEDUCIBLE): Add space to name.
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_deducible1.C: Guard with
__has_builtin (__is_deducible).
|
|
C++20 class template argument deduction for an alias template involves
adding a constraint that the template arguments for the alias template can
be deduced from the return type of the deduction guide for the underlying
class template. In the standard, this is modeled as defining a class
template with a partial specialization, but it's much more efficient to
implement with a trait that directly tries to perform the deduction.
The first argument to the trait is a template rather than a type, so various
places needed to be adjusted to accommodate that.
PR c++/105841
gcc/ChangeLog:
* doc/extend.texi (Type Traits):: Document __is_deducible.
gcc/cp/ChangeLog:
* cp-trait.def (IS_DEDUCIBLE): New.
* cxx-pretty-print.cc (pp_cxx_trait): Handle non-type.
* parser.cc (cp_parser_trait): Likewise.
* tree.cc (cp_tree_equal): Likewise.
* pt.cc (tsubst_copy_and_build): Likewise.
(type_targs_deducible_from): New.
(alias_ctad_tweaks): Use it.
* semantics.cc (trait_expr_value): Handle CPTK_IS_DEDUCIBLE.
(finish_trait_expr): Likewise.
* constraint.cc (diagnose_trait_expr): Likewise.
* cp-tree.h (type_targs_deducible_from): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_deducible1.C: New test.
|
|
Compile a resource object that contains the utf8 manifest.
Then link that object into the driver and compiler proper.
For compiler proper the link has to be forced because the
resource object file gets into a static library (libbackend.a)
and gets eventually dropped because it has no symbols of
its own and nothing is referencing it inside the library.
Therefore, an artificial symbol is planted to force the link.
gcc/ChangeLog:
PR driver/108865
* config.host: add object for x86_64-*-mingw*.
* config/i386/sym-mingw32.cc: dummy file to attach
symbol.
* config/i386/utf8-mingw32.rc: windres resource file.
* config/i386/winnt-utf8.manifest: XML manifest to
enable UTF-8.
* config/i386/x-mingw32: reference to x-mingw32-utf8.
* config/i386/x-mingw32-utf8: Makefile fragment to
embed UTF-8 manifest.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
|
|
LRA is too conservative in calculation of conflicts with clobbered regs by
using the biggest access mode. This results in failure of possible reg
coalescing and worse code. This patch solves the problem.
PR rtl-optimization/108999
gcc/ChangeLog:
* lra-constraints.cc (process_alt_operands): Use operand modes for
clobbered regs instead of the biggest access mode.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr108999.c: New.
|
|
The following plugs one place in extract_muldiv where it should avoid
folding when sanitizing overflow.
PR middle-end/108995
* fold-const.cc (extract_muldiv_1): Avoid folding
(CST * b) / CST2 when sanitizing overflow and we rely on
overflow being undefined.
* gcc.dg/ubsan/pr108995.c: New testcase.
|
|
The following testcase is reduced from miscompilation of scipy package.
If we have say lhs = [1., 1.] - [1., 1.] and want to compute the range
of lhs from it, we correctly determine it is [0., 0.] (if computations
are exact, we generally don't try to round them further in
frange_arithmetic). In the testcase it is about a reverse operation,
[1., 1.] = op1 + [1., 1.] and we want to compute range of op1 from that.
Right now we just perform the inverse operation (there are some corner
cases about NaN and infinities handling) and so arrive to range
[0., 0.] as well, and because it is a singleton, optimize return eps;
to return 0. That is incorrect though, for the reverse ops we need to
take into account also rounding, the right exact range is
[-0x1.0p-54, 0x1.0p-53] in this case when rounding to nearest, i.e.
all numbers which added to 1. with round to nearest still produce 1.
The problem isn't solely on singleton ranges, and isn't solely on
results around zero. We basically need to consider also values
where the result is up to 0.5ulp away from the lhs range boundaries
in each direction.
The following patch fixes it by extending the lhs range for the
reverse operations by 1ulp in each direction. The PR contains
a pseudo-random test generator I've used to generate 300000 tests
of + and - and then used the same test with * and / instead of + and -
together with a hack to print the discovered ranges by the patch in
a form that another test could then verify the range is conservatively
correct and how far it is from a minimal range.
I believe the results are good enough for now, though plan to look
incrementally into trying to do something better on the -XXX_MAX or
XXX_MAX boundaries (where I think frange_nextafter will use -inf or +inf)
and also try to increase the range just by 0.5ulp rather than 1ulp
if !flag_rounding_math. But dunno if either of those will be doable
and will pass the testing, so I think it is worth committing this fix
first.
2023-03-09 Jakub Jelinek <jakub@redhat.com>
Richard Biener <rguenther@suse.de>
PR tree-optimization/109008
* range-op-float.cc (float_widen_lhs_range): New function.
(foperator_plus::op1_range, foperator_minus::op1_range,
foperator_minus::op2_range, foperator_mult::op1_range,
foperator_div::op1_range, foperator_div::op2_range): Use it.
* gcc.c-torture/execute/ieee/pr109008.c: New test.
|
|
When OMP_WAIT_POLICY is not specified, current implementation will cause
icv flag GOMP_ICV_WAIT_POLICY unset, so global variable wait_policy
will remain its uninitialized value. Initialize it to -1 to make
GOMP_SPINCOUNT behavior consistent with its description.
libgomp/ChangeLog:
PR libgomp/109062
* env.c (wait_policy): Initialize to -1.
(initialize_icvs): Initialize icvs->wait_policy to -1.
* testsuite/libgomp.c-c++-common/pr109062.c: New test.
|
|
|
|
libgomp/ChangeLog:
* libgomp.texi (Offload-Target Specifics): Mention GCN_STACK_SIZE.
|
|
As PR108727 shows, when cleanup code called by the stack
unwinder calls function _Unwind_Resume, it goes via plt
stub like:
function 00000000.plt_call._Unwind_Resume:
=> 0x0000000010003580 <+0>: std r2,40(r1)
0x0000000010003584 <+4>: ld r12,-31760(r2)
0x0000000010003588 <+8>: mtctr r12
0x000000001000358c <+12>: ld r2,-31752(r2)
0x0000000010003590 <+16>: cmpldi r2,0
0x0000000010003594 <+20>: bnectr+
0x0000000010003598 <+24>: b 0x100031a4
<_Unwind_Resume@plt>
It wants to save TOC base (r2) to r1 + 40, but we only
bump the stack segment by 32 bytes as follows:
stdu %r29,-32(%r3)
It means the access is out of the stack segment allocated
by __generic_morestack, once the touch area isn't writable
like this failure shows, it would cause segment fault.
So fix the bump size with one reasonable value PARAMS.
PR libgcc/108727
libgcc/ChangeLog:
* config/rs6000/morestack.S (__morestack): Use PARAMS for new stack
bump size.
|
|
According to Haochen's finding in [1], currently ppc-fortran.exp
doesn't support Fortran specific warning or error messages well.
By looking into it, it's due to that gfortran uses some different
warning/error prefixes as follows:
set gcc_warning_prefix "\[Ww\]arning:"
set gcc_error_prefix "(Fatal )?\[Ee\]rror:"
comparing to:
set gcc_warning_prefix "warning:"
set gcc_error_prefix "(fatal )?error:"
So this is to override these two prefixes and make it support
dg-{warning,error} checks.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613302.html
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: Override
gcc_{warning,error}_prefix with Fortran specific one used in
gfortran_init.
|
|
Test cases scalar-test-data-class-1[45].c adopts type __int128
which requires to check int128 effective target, otherwise the
testing on them will fail at -m32. This patch is to add int128
effective target requirement.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/bfp/scalar-test-data-class-14.c: Adjust with
int128 effective target requirement.
* gcc.target/powerpc/bfp/scalar-test-data-class-15.c: Likewise.
|
|
Two test cases scalar-test-data-class-12.c and vec-test-data-class-9.c
fail on Power9 BE testing at -m32, they adopts a built-in function
scalar_insert_exp which requires powerpc64 support. This patch
is to make them to check has_arch_ppc64 effective target requirement.
PR testsuite/108729
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/bfp/scalar-test-data-class-12.c: Adjust with
has_arch_ppc64 effective target.
* gcc.target/powerpc/bfp/vec-test-data-class-9.c: Likewise.
|
|
The built-in function scalar_test_neg_qp is under stanza
ieee128-hw, that is TARGET_FLOAT128_HW. Since we don't
have float128 hardware support on 32-bit as follows:
if (TARGET_FLOAT128_HW && !TARGET_64BIT)
{
if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_HW) != 0)
error ("%qs requires %qs", "%<-mfloat128-hardware%>", "-m64");
rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
}
So adjust the case with lp64 effective target accordingly.
PR testsuite/108730
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/bfp/scalar-test-neg-8.c: Adjust with lp64
effective target requirement.
|
|
Compiled with cpu type Power9 or later, GCC generates
xxspltib rather than vspltis*, so adjust the test
case scanning content accordingly.
PR testsuite/108813
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr101384-2.c: Adjust with xxspltib.
|
|
On BE, the extracted index for the leftmost element is 0
rather than 1, adjust the test case accordingly.
PR testsuite/108810
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/fold-vec-extract-double.p9.c (testd_cst): Adjust
the extracted index for BE.
|
|
The mips msa-ds.c test is trying to ensure that MSA branches can have their
delay slots filled. The regexp it used looked for the function name, a nop,
then the function name again. If found that sequence, then the test failed.
The problem is with Vlad's recent IRA work there's simply less code in the
test (good) and as a result one of the *other* branches in the test had an
unfilled delay slot -- the delay slot for the MSA branch was still being
filled.
This patch tightens up the regexp. In particular it looks for the MSA branch
and a nop on the next line (avoiding the over-eager .* construct). That
indicates that the MSA branch did not have its delay slot filled. When that
sequence is found, then the test fails.
This fixes the recent regressions for mips64 and mips64el in the tester.
Installing on the trunk,
gcc/testsuite:
* gcc.target/mips/msa-ds.c: Fix over eager pattern matching.
|
|
The recently added tests missed checking for "fopenmp" (see
other tests where "-fopenmp" is passed), which makes them
fail on non-openmp systems.
* gcc.dg/analyzer/omp-parallel-for-get-min.c,
gcc.dg/analyzer/omp-parallel-for-1.c: Require effective target fopenmp.
|
|
|
|
gcc/ChangeLog
PR sanitizer/81649
* doc/invoke.texi (Instrumentation Options): Clarify
LeakSanitizer behavior.
|
|
gcc/ChangeLog
* doc/install.texi (Prerequisites): Add link to gmplib.org.
|
|
A missed piece of the patch for static operator(): in tsubst_function_decl,
we don't want to replace the first parameter with a new closure pointer if
operator() is static.
PR c++/108526
PR c++/106651
gcc/cp/ChangeLog:
* pt.cc (tsubst_function_decl): Don't replace the closure
parameter if DECL_STATIC_FUNCTION_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/static-operator-call5.C: Pass -g.
|
|
This updates baseline_symbols.txt for the Fedora 39 arches.
Most of the added symbols are added to all 5 files, exceptions are
DF16_ rtti stuff (only added on x86 and aarch64 which supports those),
DF16b rtti stuff (only x86 right now), _M_replace_cold (m vs. j
differences), DF128_ charconv (only x86), GLIBCXX_LDBL_3.4.31
symver (s390x), _M_get_sys_info/_M_get_local_info (l vs. x).
I was using
grep ^+ | sed 's/OBJECT:[0-9]*:/OBJECT:/' | sort | uniq -c | sort -n | less
on the patch to analyze.
powerpc64le-linux not included because I'll need to regenerate it.
2023-03-07 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
|
|
libstdc++-v3/ChangeLog:
PR libstdc++/108882
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Adjust patterns to
not match symbols in namespace std::__gnu_cxx11_ieee128.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add patterns for
std::__gnu_cxx11_ieee128::money_{get,put}.
|
|
libstdc++-v3/ChangeLog:
* libsupc++/eh_personality.cc: Fix spelling in comment.
|
|
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief. The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:
const Plane & meta = fm.planes().inner();
I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional<std::string>.
This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.
PR c++/107532
gcc/cp/ChangeLog:
* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter. See through
reference_like_class_p.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.
|
|
This fixes another syntax error in slp-3.c. I missed a '{ ... }' in
order to properly exclude s390_vx.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/slp-3.c: Add '{ ... }'.
|
|
In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can violate it by using typeid
etc. in the same TU and do it before ~__fundamental_type_info ()
definition.
The following patch fixes that by popping from unemitted_tinfo_decls
only in the normal case when it is there, and treating non-NULL
DECL_INITIAL on a tinfo node as indication that emit_tinfo_decl has
processed it already.
2023-03-07 Jakub Jelinek <jakub@redhat.com>
PR c++/109042
* rtti.cc (emit_support_tinfo_1): Don't assert that last
unemitted_tinfo_decls element is tinfo, instead pop from it only in
that case.
* decl2.cc (c_parse_final_cleanups): Don't call emit_tinfo_decl
for unemitted_tinfO_decls which have already non-NULL DECL_INITIAL.
* g++.dg/rtti/pr109042.C: New test.
|
|
When processing a noexcept, constructors aren't elided: build_over_call
has
/* It's unsafe to elide the constructor when handling
a noexcept-expression, it may evaluate to the wrong
value (c++/53025). */
&& (force_elide || cp_noexcept_operand == 0))
so the assert I added recently needs to be relaxed a little bit.
PR c++/109030
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Relax assert.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept77.C: New test.
|
|
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template<int>
constexpr auto p = q(0);
even though q has a constexpr operator(). It's deemed non-const by
decl_maybe_constant_var_p because even though 'q' is const it is not
of integral/enum type.
If fun is not a function pointer, we don't know if we're using it as an
lvalue or rvalue, so with this patch we pass 'any' for want_rval. With
that, p_c_e/VAR_DECL doesn't flat out reject the underlying VAR_DECL.
PR c++/107939
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>: Pass
'any' when recursing on a VAR_DECL and not a pointer to function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ74.C: Remove dg-error.
* g++.dg/cpp1y/var-templ77.C: New test.
|
|
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make the right decision for both the correctness and optimization.
Given below sample code:
void test_1(int8_t * restrict in, int8_t * restrict out)
{
vbool8_t v2 = *(vbool8_t*)in;
vbool16_t v5 = *(vbool16_t*)in;
*(vbool16_t*)(out + 200) = v5;
*(vbool8_t*)(out + 100) = v2;
}
Before the precision adjustment:
addi a4,a1,100
vsetvli a5,zero,e8,m1,ta,ma
addi a1,a1,200
vlm.v v24,0(a0)
vsm.v v24,0(a4)
// Need one vsetvli and vlm.v for correctness here.
vsm.v v24,0(a1)
After the precision adjustment:
csrr t0,vlenb
slli t1,t0,1
csrr a3,vlenb
sub sp,sp,t1
slli a4,a3,1
add a4,a4,sp
sub a3,a4,a3
vsetvli a5,zero,e8,m1,ta,ma
addi a2,a1,200
vlm.v v24,0(a0)
vsm.v v24,0(a3)
addi a1,a1,100
vsetvli a4,zero,e8,mf2,ta,ma
csrr t0,vlenb
vlm.v v25,0(a3)
vsm.v v25,0(a2)
slli t1,t0,1
vsetvli a5,zero,e8,m1,ta,ma
vsm.v v24,0(a1)
add sp,sp,t1
jr ra
However, there may be some optimization opportunates after
the mode precision adjustment. It can be token care of in
the RISC-V backend in the underlying separted PR(s).
gcc/ChangeLog:
PR target/108185
PR target/108654
* config/riscv/riscv-modes.def (ADJUST_PRECISION): Adjust VNx*BI
modes.
* config/riscv/riscv.cc (riscv_v_adjust_precision): New.
* config/riscv/riscv.h (riscv_v_adjust_precision): New.
* genmodes.cc (adj_precision): New.
(ADJUST_PRECISION): New.
(emit_mode_adjustments): Handle ADJUST_PRECISION.
gcc/testsuite/ChangeLog:
PR target/108185
PR target/108654
* gcc.target/riscv/rvv/base/pr108185-1.c: New test.
* gcc.target/riscv/rvv/base/pr108185-2.c: New test.
* gcc.target/riscv/rvv/base/pr108185-3.c: New test.
* gcc.target/riscv/rvv/base/pr108185-4.c: New test.
* gcc.target/riscv/rvv/base/pr108185-5.c: New test.
* gcc.target/riscv/rvv/base/pr108185-6.c: New test.
* gcc.target/riscv/rvv/base/pr108185-7.c: New test.
* gcc.target/riscv/rvv/base/pr108185-8.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
Co-authored-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
|
|
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/stack-check-cfa-1.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/stack-check-cfa-2.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/test_frame_17.c (dg-options): Add
-fno-stack-protector.
|
|
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr104005.c (dg-options): Add
-fno-stack-protector.
|
|
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-7.c (dg-options): Add
-fno-stack-protector.
|
|
Stack protector influence code generation and cause function body checks
fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
|
|
If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
|
|
In PIE, symbol "fixed_regs" is addressed via GOT. It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
|
|
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.dg/tls/pr78796.c (dg-additional-options): Add -fno-pie
-no-pie for aarch64-*-*.
* gcc.target/aarch64/pr63304_1.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr70120-2.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr78733.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr79041-2.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr94530.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr94577.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/reload-valid-spoff.c (dg-options): Add
-fno-pie.
|
|
If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
|
