while preparing testcase for return slot tracking I noticed that both
ipa-pure-const and modref treat return slot writes as non-local which prevents
detecting functions as pure or not modifying global state. Fixed by making
points_to_local_or_readonly_memory_p to special case return slot. This is bit
of a side case, but presently at all uses of
points_to_local_or_readonly_memory_p we want to handle return slot this way.
I also noticed that we handle gimple copy unnecesarily pesimistically. This
does not make difference right now since we do no not track non-scalars, but
I fixed it anyway.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* ipa-fnsummary.c: Include tree-dfa.h.
(points_to_local_or_readonly_memory_p): Return true on return
slot writes.
* ipa-modref.c (analyze_ssa_name_flags): Fix handling of copy
statement.
gcc/testsuite/ChangeLog:
* g++.dg/ipa/modref-1.C: New test.
The _Unwind_Exception struct had its alignment adjusted to 16-bytes,
however malloc() on Solaris X86 is not guaranteed to allocate memory
aligned to 16-bytes as well.
PR d/102837
libphobos/ChangeLog:
* libdruntime/gcc/deh.d (ExceptionHeader.free): Use memset to reset
contents of internal EH storage.
The value used to initialize the integer field in the union didn't
account for BigEndian targets running this code.
PR d/102959
gcc/testsuite/ChangeLog:
* gdc.dg/torture/pr96435.d: Adjust for BigEndian.
The teams construct only permits omp_get_num_teams and omp_get_team_num
as API call in strictly nested regions - check for it.
Additionally, for Fortran, using DECL_NAME does not show the mangled
name, hence, DECL_ASSEMBLER_NAME had to be used to.
Finally, 'target device(ancestor:1)' wrongly rejected non-API calls
as well.
PR middle-end/102972
gcc/ChangeLog:
* omp-low.c (omp_runtime_api_call): Use DECL_ASSEMBLER_NAME to get
internal Fortran name; new permit_num_teams arg to permit
omp_get_num_teams and omp_get_team_num.
(scan_omp_1_stmt): Update call to it, add missing call for
reverse offload, and check for strictly nested API calls in teams.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/target-device-ancestor-3.c: Add non-API
routine test.
* gfortran.dg/gomp/order-6.f90: Add missing bind(C).
* c-c++-common/gomp/teams-3.c: New test.
* gfortran.dg/gomp/teams-3.f90: New test.
* gfortran.dg/gomp/teams-4.f90: New test.
libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/icv-3.c: Nest API calls inside
parallel construct.
* testsuite/libgomp.c-c++-common/icv-4.c: Likewise.
* testsuite/libgomp.c/target-3.c: Likewise.
* testsuite/libgomp.c/target-5.c: Likewise.
* testsuite/libgomp.c/target-6.c: Likewise.
* testsuite/libgomp.c/target-teams-1.c: Likewise.
* testsuite/libgomp.c/teams-1.c: Likewise.
* testsuite/libgomp.c/thread-limit-2.c: Likewise.
* testsuite/libgomp.c/thread-limit-3.c: Likewise.
* testsuite/libgomp.c/thread-limit-4.c: Likewise.
* testsuite/libgomp.c/thread-limit-5.c: Likewise.
* testsuite/libgomp.fortran/icv-3.f90: Likewise.
* testsuite/libgomp.fortran/icv-4.f90: Likewise.
* testsuite/libgomp.fortran/teams1.f90: Likewise.
We did not free global symbols. For a simplified abstract_type_3.f90
valgrind reports:
96 bytes in 1 blocks are still reachable in loss record 461 of 602
at 0x48377D5: calloc (vg_replace_malloc.c:711)
by 0x21257C3: xcalloc (xmalloc.c:162)
by 0x98611B: gfc_get_gsymbol(char const*) (symbol.c:4341)
by 0x932C58: parse_module() (parse.c:5912)
by 0x9336F8: gfc_parse_file() (parse.c:6236)
by 0x991449: gfc_be_parse_file() (f95-lang.c:204)
by 0x11D8EDE: compile_file() (toplev.c:455)
by 0x11DB9C3: do_compile() (toplev.c:2170)
by 0x11DBCAF: toplev::main(int, char**) (toplev.c:2305)
by 0x2045D37: main (main.c:39)
This patch reduces this to
LEAK SUMMARY:
definitely lost: 344 bytes in 1 blocks
indirectly lost: 3,024 bytes in 4 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 1,576,174 bytes in 2,277 blocks
+ still reachable: 1,576,078 bytes in 2,276 blocks
suppressed: 0 bytes in 0 blocks
gcc/fortran/ChangeLog:
2018-10-21 Bernhard Reutner-Fischer <aldot@gcc.gnu.org>
* parse.c (clean_up_modules): Free gsym.
Improve the wording on optimizations that prevent compare hardening,
so as to also cover cases in which explicit compares get combined into
operations with implied compares.
for gcc/ada/ChangeLog
* doc/gnat_rm/security_hardening_features.rst: Mention
optimization to operations with implied compares.
We weren't diagnosing the
The loop iteration variable may not appear in a threadprivate directive.
restriction which used to be in 5.0 just among the Worksharing-Loop
restrictions but in 5.1 it is among Canonical Loop Nest Form restrictions.
This patch diagnoses those.
2021-10-30 Jakub Jelinek <jakub@redhat.com>
* gimplify.c (gimplify_omp_for): Diagnose threadprivate iterators.
* c-c++-common/gomp/loop-10.c: New test.
The sharing of the COMPLEX_MUL node makes it so it's
more efficient to not generate both a MUL and FMA
in this node.
Because the shape for a normal FMA is not different
the FMA is no longer detected here which results in
better codegen so update the testcase.
gcc/testsuite/ChangeLog:
* g++.dg/vect/pr99149.cc: Update case.
Both #pragma and _Pragma ended up as CPP_PRAGMA. Presumably since
r131819 (2008, GCC 4.3) for PR34692, pragmas are not expanded in
macro arguments but are output as is before. From the old bug report,
that was to fix usage like
FOO (
#pragma GCC diagnostic
)
However, that change also affected _Pragma such that
BAR (
"1";
_Pragma("omp ..."); )
yielded
#pragma omp ...
followed by what BAR expanded too, possibly including '"1";'.
This commit adds a flag, PRAGMA_OP, to tokens to make the two
distinguishable - and include again _Pragma in the expanded arguments.
libcpp/ChangeLog:
PR c++/102409
* directives.c (destringize_and_run): Add PRAGMA_OP to the
CPP_PRAGMA token's flags to mark is as coming from _Pragma.
* include/cpplib.h (PRAGMA_OP): #define, to be used with token flags.
* macro.c (collect_args): Only handle CPP_PRAGMA special if PRAGMA_OP
is set.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pragma-1.c: New test.
* c-c++-common/gomp/pragma-2.c: New test.
Adding newlines so that the two strings line up makes string equality
failures considerably easier to read.
gcc/ChangeLog:
* selftest.c (assert_streq): Add newlines when emitting non-equal
non-NULL strings.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound
structs:
56 bytes in 1 blocks are definitely lost.
at 0x4C2CC05: calloc (vg_replace_malloc.c:711)
by 0x151EA90: xcalloc (xmalloc.c:162)
by 0x8E3E4F: gfc_get_typebound_proc(gfc_typebound_proc*) (symbol.c:4945)
by 0x84C095: match_procedure_in_type (decl.c:10486)
by 0x84C095: gfc_match_procedure() (decl.c:6696)
...
gcc/fortran/ChangeLog:
2017-12-06 Bernhard Reutner-Fischer <aldot@gcc.gnu.org>
* symbol.c (free_tb_tree): Free type-bound procedure struct.
(gfc_get_typebound_proc): Use explicit memcpy for clarity.
Since registering a kill means removing all references to it from the
path oracle list, make sure we don't look back to the root oracle
either.
Tested on x86-64 Linux.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com>
gcc/ChangeLog:
* value-relation.cc (path_oracle::killing_def): Add a
self-equivalence so we don't look to the root oracle.
This patch upgrades the pre-VRP threading passes to fully resolving
backward threaders, and removes the post-VRP threading passes altogether.
With it, we reduce the number of threaders in our pipeline from 9 to 7.
This will leave DOM as the only forward threader client. When the ranger
can handle floats, we should be able to upgrade the pre-DOM threaders to
fully resolving threaders and kill the embedded DOM threader.
The numbers are as follows:
prev: # threads in backward + vrp-threaders = 92624
now: # threads in backward threaders = 94275
Gain: +1.78%
prev: # total threads: 189495
now: # total threads: 193714
Gain: +2.22%
The numbers are not as great as my initial proposal, but I've
recently pushed all the work that got us to this point ;-).
And... the compilation improves by 1.32%!
There's a regression on uninit-pred-7_a.c that I've yet to look at. I
want to make sure it's not a missing thread. If it is, I'll create a PR
and own it.
Also, the tree-ssa/phi_on_compare-*.c tests have all regressed. This
seems to be some special case the forward threader handles that the
backward threader does not (edge_forwards_cmp_to_conditional_jump*).
I haven't dug deep to see if this is solveable within our
infrastructure, but a cursory look shows that even though the VRP
threader threads this, the *.optimized dump ends with more conditional
jumps than without the optimization. I'd like to punt on this for
now, because DOM actually catches this through its lone use of the
forward threader (I've adjusted the tests). However, we will need to
address this sooner or later, if indeed it's still improving the final
assembly.
gcc/ChangeLog:
* passes.def: Replace the pass_thread_jumps before VRP* with
pass_thread_jumps_full. Remove all pass_vrp_threader instances.
* tree-ssa-threadbackward.c (pass_data_thread_jumps_full):
Remove hyphen from "thread-full" name.
libgomp/ChangeLog:
* testsuite/libgomp.graphite/force-parallel-4.c: Adjust for threading changes.
* testsuite/libgomp.graphite/force-parallel-8.c: Same.
gcc/testsuite/ChangeLog:
* gcc.dg/loop-unswitch-2.c: Adjust for threading changes.
* gcc.dg/old-style-asm-1.c: Same.
* gcc.dg/tree-ssa/phi_on_compare-1.c: Same.
* gcc.dg/tree-ssa/phi_on_compare-2.c: Same.
* gcc.dg/tree-ssa/phi_on_compare-3.c: Same.
* gcc.dg/tree-ssa/phi_on_compare-4.c: Same.
* gcc.dg/tree-ssa/pr20701.c: Same.
* gcc.dg/tree-ssa/pr21001.c: Same.
* gcc.dg/tree-ssa/pr21294.c: Same.
* gcc.dg/tree-ssa/pr21417.c: Same.
* gcc.dg/tree-ssa/pr21559.c: Same.
* gcc.dg/tree-ssa/pr21563.c: Same.
* gcc.dg/tree-ssa/pr49039.c: Same.
* gcc.dg/tree-ssa/pr59597.c: Same.
* gcc.dg/tree-ssa/pr61839_1.c: Same.
* gcc.dg/tree-ssa/pr61839_3.c: Same.
* gcc.dg/tree-ssa/pr66752-3.c: Same.
* gcc.dg/tree-ssa/pr68198.c: Same.
* gcc.dg/tree-ssa/pr77445-2.c: Same.
* gcc.dg/tree-ssa/pr77445.c: Same.
* gcc.dg/tree-ssa/ranger-threader-1.c: Same.
* gcc.dg/tree-ssa/ranger-threader-2.c: Same.
* gcc.dg/tree-ssa/ranger-threader-4.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-1.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-11.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-12.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-14.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-16.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same.
* gcc.dg/tree-ssa/ssa-thread-14.c: Same.
* gcc.dg/tree-ssa/ssa-thread-backedge.c: Same.
* gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Same.
* gcc.dg/tree-ssa/vrp02.c: Same.
* gcc.dg/tree-ssa/vrp03.c: Same.
* gcc.dg/tree-ssa/vrp05.c: Same.
* gcc.dg/tree-ssa/vrp06.c: Same.
* gcc.dg/tree-ssa/vrp07.c: Same.
* gcc.dg/tree-ssa/vrp08.c: Same.
* gcc.dg/tree-ssa/vrp09.c: Same.
* gcc.dg/tree-ssa/vrp33.c: Same.
* gcc.dg/uninit-pred-9_b.c: Same.
* gcc.dg/uninit-pred-7_a.c: xfail.
Occasionally I've been seeing failures with the multi-line diagnostics. It's never been clear what's causing the spurious failures, though I have long suspected a greedy regexp match.
It happened again yesterday with a local change that in no way should affect diagnostics, so I finally went searching and found that sure enough the multi-line diagnostics had a ".*" in their regexp. According to the comments, the .* is primarily to catch any dg directives that may appear -- ie it should eat to EOL, but not multiple lines. But a .* can indeed match a newline and cause it to eat multiple lines.
The fix is simple. [^\r\n]* will eat to EOL, but not further.
Regression tested on x86_64 and on our internal target.
gcc/testsuite
* lib/multiline.exp (_build_multiline_regex): Use a better
regexp than .* to match up to EOL.
Propagation is automatically done by the temporal cache when defs are
out of date from the names on the RHS, but a gcond has no LHS, and any
updates on the RHS are never propagated. Always propagate them.
gcc/
PR tree-optimization/102983
* gimple-range-cache.h (propagate_updated_value): Make public.
* gimple-range.cc (gimple_ranger::range_of_stmt): Propagate exports
when processing gcond stmts.
gcc/testsuite/
* gcc.dg/pr102983.c: New.
Extend modref and tree-ssa-structalias to handle retslot flags.
Since retslot it essentially a hidden argument that is known to be write-only
we can do pretty much the same stuff as we do for regular parameters.
I plan to add static chain handling similar way.
We do not handle IPA propagation of retslot flags (where return slot is
initialized via return slot of other function). For this ipa-prop needs
to be extended to understand retslot as well.
Bootstrapped/regtested x86_64-linux, OK for the gimple bits?
Honza
gcc/ChangeLog:
* gimple.c (gimple_call_retslot_flags): New function.
* gimple.h (gimple_call_retslot_flags): Declare.
* ipa-modref.c: Include tree-cfg.h.
(struct escape_entry): Turn parm_index to signed.
(modref_summary_lto::modref_summary_lto): Add retslot_flags.
(modref_summary::modref_summary): Initialize retslot_flags.
(struct modref_summary_lto): Likewise.
(modref_summary::useful_p): Check retslot_flags.
(modref_summary_lto::useful_p): Likewise.
(modref_summary::dump): Dump retslot_flags.
(modref_summary_lto::dump): Likewise.
(struct escape_point): Add hidden_args enum.
(analyze_ssa_name_flags): Ignore return slot return;
use gimple_call_retslot_flags.
(record_escape_points): Break out from ...
(analyze_parms): ... here; handle retslot_flags.
(modref_summaries::duplicate): Duplicate retslot_flags.
(modref_summaries_lto::duplicate): Likewise.
(modref_write_escape_summary): Stream parm_index as signed.
(modref_read_escape_summary): Likewise.
(modref_write): Stream retslot_flags.
(read_section): Likewise.
(struct escape_map): Fix typo in comment.
(update_escape_summary_1): Fix whitespace.
(ipa_merge_modref_summary_after_inlining): Drop retslot_flags.
(modref_merge_call_site_flags): Merge retslot_flags.
* ipa-modref.h (struct modref_summary): Add retslot_flags.
* tree-ssa-structalias.c (handle_rhs_call): Handle retslot_flags.
The layout of the SLP tree has changed in GCC 12 which
broke the detection of complex FMA and FMS.
This patch updates the detection to the new tree shape
and by necessity merges the complex MUL and FMA detection
into one.
This does not yet address the wrong code-gen PR which I
will fix in a different patch as that needs backporting.
gcc/ChangeLog:
PR tree-optimization/102977
* tree-vect-slp-patterns.c (vect_match_call_p): Remove.
(vect_detect_pair_op): Add crosslane check.
(vect_match_call_complex_mla): Remove.
(class complex_mul_pattern): Update comment.
(complex_mul_pattern::matches): Update detection.
(class complex_fma_pattern): Remove.
(complex_fma_pattern::matches): Remove.
(complex_fma_pattern::recognize): Remove.
(complex_fma_pattern::build): Remove.
(class complex_fms_pattern): Update comment.
(complex_fms_pattern::matches): Remove.
(complex_operations_pattern::recognize): Remove complex_fma_pattern
As mentioned yesterday, gimple_fold_builtin_memset doesn't preserve
locus which means e.g. the -Wstringop-overflow warnings are emitted as:
In function 'test_max':
cc1: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
The function emits up to 2 new statements, but the latter (asgn) is added
through gsi_replace and therefore the locus is copied over from the call.
But store is emitted before the call and optionally the call removed
afterwards, so locus needs to be copied over manually.
2021-10-29 Jakub Jelinek <jakub@redhat.com>
* gimple-fold.c (gimple_fold_builtin_memset): Copy over location from
call to store.
* gcc.dg/Wstringop-overflow-62.c: Adjust expected diagnostics.
This forces -fexcess-precision=standard since the testcase is
otherwise prone to fail with x87 math.
2021-10-29 Richard Biener <rguenther@suse.de>
* gcc.dg/torture/fp-uint64-convert-double-1.c: Add
-fexcess-precision=standard.
Here is an implementation of DR2351 - void{} - where void{} after
pack expansion is considered valid and the same thing as void().
For templates, if CONSTRUCTOR_NELTS is 0, the CONSTRUCTOR is not dependent
and we can return void_node right away, if it is dependent and contains
only packs, then it is potentially zero element and so we need to build
CONSTRUCTOR_IS_DEPENDENT CONSTRUCTOR, while if it contains any non-pack
elts, we can diagnose it right away.
2021-10-29 Jakub Jelinek <jakub@redhat.com>
PR c++/102820
* semantics.c (maybe_zero_constructor_nelts): New function.
(finish_compound_literal): Implement DR2351 - void{}.
If type is cv void and compound_literal has no elements, return
void_node. If type is cv void and compound_literal might have no
elements after expansion, handle it like other dependent compound
literals.
* g++.dg/cpp0x/dr2351.C: New test.
If the second operand of __builtin_shuffle is const vector 0, and with
specific mask, it can be optimized to vspltisw+xxpermdi instead of lxv.
gcc/ChangeLog:
PR target/102868
* config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Add
patterns match and emit for VSX xxpermdi.
gcc/testsuite/ChangeLog:
PR target/102868
* gcc.target/powerpc/pr102868.c: New test.
Same thing as the relational change. Walk any equivalences that have
been registered on the path, and remove the name being killed. The
only reason we had added the equivalence with itself earlier is so we
wouldn't search any further in the equivalency list. So if we are
removing all references to it, then we no longer need to add a "kill"
record.
Will push pending tests on x86-64 Linux.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com>
gcc/ChangeLog:
* value-relation.cc (path_oracle::killing_def): Walk the
equivalency list and remove SSA from any equivalencies.
This fixes an issue in the glibc port I am working on where the build
fails due to the warning:
error: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Werror=frame-address]
This is due to how the current implementation of _mcount in glibc uses
__builtin_return_address with a count argument of 1.
Fix that by passing the value of LR_REGNUM to the _mcount function,
effectivtly providing the value _mcount is after.
This is an ABI change, but I think it's OK because the glibc port for
or1k is not yet upstreamed. Also, I think just adding an argument
should not break anything anyway.
gcc/ChangeLog:
* config/or1k/or1k.h (PROFILE_HOOK): Add return address argument
to _mcount.
This patch outlines the decision whether address comparison can be folded
or not from the match.pd simple comparison simplification and uses it
both there and in a new minmax simplification, such that we fold e.g.
MAX (&a[2], &a[1]) etc.
Some of the Wstringop-overflow-62.c changes might look weird, but that
seems to be mainly due to gimple_fold_builtin_memset not bothering to
copy over location, will fix that incrementally.
2021-10-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/102951
* fold-const.h (address_compare): Declare.
* fold-const.c (address_compare): New function.
* match.pd (cmp (convert1?@2 addr@0) (convert2? addr@1)): Use
address_compare helper.
(minmax cmp (convert1?@2 addr@0) (convert2?@3 addr@1)): New
simplification.
* gcc.dg/tree-ssa/pr102951.c: New test.
* gcc.dg/Wstringop-overflow-62.c: Adjust expected diagnostics.
The testcase fails if VRP2 is replaced with a non-assert based VRP because it
accidentally depends on specific IL changes when the asserts are removed. This
removes that dependency.
gcc/testsuite/
* gcc.dg/ifcvt-4.c: Adjust.
EVRP issues a message fior folding predicates in a different format than
VRP does, this patch unifies the messaging.
gcc/
* vr-values.c (simplify_using_ranges::fold_cond): Change fold message.
gcc/testsuite/
* gcc.dg/tree-ssa/evrp9.c: Adjust message scanned for.
* gcc.dg/tree-ssa/pr21458-2.c: Ditto.
Before invoking the array_checker, we need to reset scev so it will not try to
access any ssa_names that the substitute and fold engine has freed.
PR tree-optimization/102940
* tree-vrp.c (execute_ranger_vrp): Reset scev.
Here when checking for erroneous occurrences of 'auto' inside a template
argument (which is allowed by the concepts TS for class templates),
extract_autos_r picks up the CTAD placeholder for X{T{0}} which causes
check_auto_in_tmpl_args to reject this valid template argument. This
patch fixes this by making extract_autos_r ignore CTAD placeholders.
However, it seems we don't need to call check_auto_in_tmpl_args at all
outside of the concepts TS since using 'auto' as a type-id is otherwise
rejected more generally at parse time. So this patch makes the function
just exit early if !flag_concepts_ts.
Similarly, I think the concepts code paths in do_auto_deduction and
type_uses_auto are only necessary for the concepts TS, so this patch
also restricts these code paths accordingly.
PR c++/102933
gcc/cp/ChangeLog:
* parser.c (cp_parser_simple_type_specifier): Adjust diagnostic
for using auto in parameter declaration.
* pt.c (extract_autos_r): Ignore CTAD placeholders.
(extract_autos): Use range-based for.
(do_auto_deduction): Use extract_autos only for the concepts TS
and not also for standard concepts.
(type_uses_auto): Likewise with for_each_template_parm.
(check_auto_in_tmpl_args): Just return false outside of the
concepts TS. Simplify.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class50.C: New test.
* g++.dg/cpp2a/nontype-class50a.C: New test.
Add a definition of the musl linker used on the nios2 platform.
2021-10-26 Richard Purdie <richard.purdie@linuxfoundation.org>
gcc/ChangeLog:
* config/nios2/linux.h (MUSL_DYNAMIC_LINKER): Add musl linker
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During cross compiling, CPP is being set to the target compiler even for
build targets. As an example, when building a cross compiler targetting
mingw, the config.log for libiberty in
build.x86_64-pokysdk-mingw32.i586-poky-linux/build-x86_64-linux/libiberty/config.log
shows:
configure:3786: checking how to run the C preprocessor
configure:3856: result: x86_64-pokysdk-mingw32-gcc -E --sysroot=[sysroot]/x86_64-nativesdk-mingw32-pokysdk-mingw32
configure:3876: x86_64-pokysdk-mingw32-gcc -E --sysroot=[sysroot]/x86_64-nativesdk-mingw32-pokysdk-mingw32 conftest.c
configure:3876: $? = 0
This is libiberty being built for the build environment, not the target one
(i.e. in build-x86_64-linux). As such it should be using the build environment's
gcc and not the target one. In the mingw case the system headers are quite
different leading to build failures related to not being able to include a
process.h file for pem-unix.c.
Further analysis shows the same issue occuring for CPPFLAGS too.
Fix this by adding support for CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD which
for example, avoids mixing the mingw headers for host binaries on linux
systems.
2021-10-27 Richard Purdie <richard.purdie@linuxfoundation.org>
ChangeLog:
* Makefile.tpl: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add CPP_FOR_BUILD and CPPFLAGS_FOR_BUILD support
gcc/ChangeLog:
* configure: Regenerate.
* configure.ac: Use CPPFLAGS_FOR_BUILD for GMPINC
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the testcase below the two left fold expressions each expand into a
constant logical expression with 1024 terms, for which potential_const_expr
takes more than a minute to return true. This happens because p_c_e_1
performs trial evaluation of the first operand of a &&/|| in order to
determine whether to consider the potentiality of the second operand.
And because the expanded expression is left-associated, this trial
evaluation causes p_c_e_1 to be quadratic in the number of terms of the
expression.
This patch fixes this quadratic behavior by making p_c_e_1 preemptively
compute potentiality of the second operand of a &&/||, and perform trial
evaluation of the first operand only if the second operand isn't
potentially constant. We must be careful to avoid emitting bogus
diagnostics during the preemptive computation; to that end, we perform
this shortcut only when tf_error is cleared, and when tf_error is set we
now first check potentiality of the whole expression quietly and replay
the check noisily for diagnostics.
Apart from fixing the quadraticness for left-associated logical exprs,
this change also reduces compile time for the libstdc++ testcase
20_util/variant/87619.cc by about 15% even though our <variant> uses
right folds instead of left folds. Likewise for the testcase in the PR,
for which compile time is reduced by 30%. The reason for these speedups
is that p_c_e_1 no longer performs expensive trial evaluation of each term
of large constant logical expressions when determining their potentiality.
PR c++/102780
gcc/cp/ChangeLog:
* constexpr.c (potential_constant_expression_1) <case TRUTH_*_EXPR>:
When tf_error isn't set, preemptively check potentiality of the
second operand before performing trial evaluation of the first
operand.
(potential_constant_expression_1): When tf_error is set, first check
potentiality quietly and return true if successful, otherwise
proceed noisily to give errors.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/fold13.C: New test.
%X
Output the accumulated linker options specified by -Wl or a ‘%x’ spec string
The part about -Wl has been obsolete for 27 years, since this change:
Author: Torbjorn Granlund <tege@gnu.org>
Date: Thu Oct 27 18:04:25 1994 +0000
(process_command): Handle -Wl, and -Xlinker similar to -l,
i.e., preserve their order with respect to linker input files.
Technically speaking, the arguments of -l, -Wl and -Xlinker are input files.
gcc/
* doc/invoke.texi (%X): Remove obsolete reference to -Wl.
