Re: malloc cannot alias preexisting pointers
On Sun, 12 May 2019, Marc Glisse wrote: this patch lets gcc know that if a pointer existed before the call to malloc, the result of malloc cannot alias it. This is a bit ad hoc and fragile. A small improvement would be, when the 2 statements are in the same bb but in the wrong order, to check if there is any statement in between that might prevent from reordering them. But that's more complicated, and the patch as it is already does help. I was also thinking of adding a few more cases: * if ptr1=PHI and ptr2 can alias neither x nor y... but we probably need to be careful to avoid a combinatorial explosion. * if ptr1 is a NULL pointer, we cannot dereference it (at least with the right flags), so dereferencing it cannot alias anything. This seems mostly useful as a recursive call with PHI. Let me know if this looks like a bad idea. -- Marc Glisse
[Darwin, PPC, committed] Improve mdebug=stack for Darwin.
It seems to be quite frequently the case that we need to look at the pro/epilogue behaviour. This adds the state of the “save_world” computation to the debug output that’s printed in response to -mdebug=stack on powerpc-darwin. tested on powerpc-darwin9, applied to trunk. thanks Iain gcc/ 2019-05-12 Iain Sandoe * config/rs6000/rs6000.c (debug_stack_info): When -mdebug=stack is given, print the state of the EH "save world" computation for Darwin. ppc-mdebug-stack-save-world.diff Description: Binary data
malloc cannot alias preexisting pointers
Hello,
this patch lets gcc know that if a pointer existed before the call to
malloc, the result of malloc cannot alias it. This is a bit ad hoc and
fragile. A small improvement would be, when the 2 statements are in the
same bb but in the wrong order, to check if there is any statement in
between that might prevent from reordering them. But that's more
complicated, and the patch as it is already does help.
I expect people may not like the call to a function from
tree-ssa-loop-niter too much, but it is convenient. And if someone
improves it, they will likely have to rewrite something not quite
equivalent to stmt_dominates_stmt_p.
The testcase uses libstdc++ quite a bit. I thought about putting it in the
libstdc++ testsuite, but it does not know scan-tree-dump, and in the
assembly it may be too late, memcpy may get expanded to something
target-specific. So it is in g++.dg. I could write a more artificial
testcase, but the behavior of std::vector is really what I want to test...
Bootstrap+regtest on x86_64-pc-linux-gnu.
2019-05-13 Marc Glisse
gcc/
* tree-ssa-loop-niter.c (stmt_dominates_stmt_p): Handle NULL
basic block.
* tree-ssa-alias.c: Include tree-ssa-loop-niter.h.
(ptr_derefs_may_alias_p): Detect malloc and an older pointer.
gcc/testsuite/
* g++.dg/tree-ssa/ldist-2.C: New file.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/tree-ssa/ldist-2.C
===
--- gcc/testsuite/g++.dg/tree-ssa/ldist-2.C (nonexistent)
+++ gcc/testsuite/g++.dg/tree-ssa/ldist-2.C (working copy)
@@ -0,0 +1,14 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-O3 -fdump-tree-optimized" }
+
+#include
+#include
+#include
+// Remove those 2 inlines once gcc knows that new/delete are special
+inline void* operator new(std::size_t n){return malloc(n);}
+inline void operator delete(void*p){free(p);}
+typedef std::unique_ptr T;
+typedef std::vector V;
+void f(V){v.reserve(1024);}
+
+/* { dg-final { scan-tree-dump "memcpy" "optimized" } } */
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c (revision 271097)
+++ gcc/tree-ssa-alias.c (working copy)
@@ -31,20 +31,21 @@ along with GCC; see the file COPYING3.
#include "cgraph.h"
#include "tree-pretty-print.h"
#include "alias.h"
#include "fold-const.h"
#include "langhooks.h"
#include "dumpfile.h"
#include "tree-eh.h"
#include "tree-dfa.h"
#include "ipa-reference.h"
#include "varasm.h"
+#include "tree-ssa-loop-niter.h"
/* Broad overview of how alias analysis on gimple works:
Statements clobbering or using memory are linked through the
virtual operand factored use-def chain. The virtual operand
is unique per function, its symbol is accessible via gimple_vop (cfun).
Virtual operands are used for efficiently walking memory statements
in the gimple IL and are useful for things like value-numbering as
a generation count for memory references.
@@ -284,20 +285,40 @@ ptr_derefs_may_alias_p (tree ptr1, tree
|| !POINTER_TYPE_P (TREE_TYPE (ptr1))
|| !POINTER_TYPE_P (TREE_TYPE (ptr2)))
return true;
/* We may end up with two empty points-to solutions for two same pointers.
In this case we still want to say both pointers alias, so shortcut
that here. */
if (ptr1 == ptr2)
return true;
+ /* Memory returned by malloc cannot alias with a pre-existing pointer.
+ This is extremely crude, the order between the statements may be quite
+ arbitrary. */
+ if (in_gimple_form && dom_info_available_p (cfun, CDI_DOMINATORS))
+{
+ gimple *def1 = SSA_NAME_DEF_STMT (ptr1);
+ gimple *def2 = SSA_NAME_DEF_STMT (ptr2);
+ tree decl;
+ if (stmt_dominates_stmt_p (def1, def2)
+ && is_gimple_call (def2)
+ && (decl = gimple_call_fndecl (def2))
+ && DECL_IS_MALLOC (decl))
+ return false;
+ else if (stmt_dominates_stmt_p (def2, def1)
+ && is_gimple_call (def1)
+ && (decl = gimple_call_fndecl (def1))
+ && DECL_IS_MALLOC (decl))
+ return false;
+}
+
/* If we do not have useful points-to information for either pointer
we cannot disambiguate anything else. */
pi1 = SSA_NAME_PTR_INFO (ptr1);
pi2 = SSA_NAME_PTR_INFO (ptr2);
if (!pi1 || !pi2)
return true;
/* ??? This does not use TBAA to prune decls from the intersection
that not both pointers may access. */
return pt_solutions_intersect (>pt, >pt);
Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c (revision 271097)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -4433,20 +4433,23 @@ stmt_dominates_stmt_p (gimple *s1, gimpl
if (gimple_code (s1) == GIMPLE_PHI)
return true;
for (bsi = gsi_start_bb (bb1); gsi_stmt (bsi) != s2; gsi_next ())
if (gsi_stmt (bsi) == s1)
return true;
return
Re: [PATCH] fortran: C++ support for generating C prototypes
On Sun, May 12, 2019 at 12:47:04AM +0300, Janne Blomqvist wrote:
> When generating C prototypes for Fortran procedures with the
> -fc-prototypes and -fc-prototypes-external options, print a snippet
> defining macros for complex types, and add C++ support by suppressing
> mangling.
>
> fortran/ChangeLog:
>
> 2019-05-12 Janne Blomqvist
>
> * dump-parse-tree.c (get_c_type_name): Use macros for complex type
> names.
> * parse.c (gfc_parse_file): Define complex macros, add CPP support
> when printing C prototypes.
>
> Ok for trunk?
Is it correct to use macros in user namespace? Shouldn't they be say __
prefixed, or even have __GFC_ or __GFORTRAN_ in them?
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -3143,11 +3143,11 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec
> *as, const char **pre,
> else if (strcmp (*type_name, "size_t") == 0)
> *type_name = "ssize_t";
> else if (strcmp (*type_name, "float_complex") == 0)
> - *type_name = "float complex";
> + *type_name = "FLOAT_COMPLEX";
> else if (strcmp (*type_name, "double_complex") == 0)
> - *type_name = "double complex";
> + *type_name = "DOUBLE_COMPLEX";
> else if (strcmp (*type_name, "long_double_complex") == 0)
> - *type_name = "long double complex";
> + *type_name = "LONG_DOUBLE_COMPLEX";
>
> ret = T_OK;
> }
> @@ -3166,11 +3166,11 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec
> *as, const char **pre,
> else if (strcmp (*type_name, "size_t") == 0)
> *type_name = "ssize_t";
> else if (strcmp (*type_name, "float_complex") == 0)
> - *type_name = "float complex";
> + *type_name = "FLOAT_COMPLEX";
> else if (strcmp (*type_name, "double_complex") == 0)
> - *type_name = "double complex";
> + *type_name = "DOUBLE_COMPLEX";
> else if (strcmp (*type_name, "long_double_complex") == 0)
> - *type_name = "long double complex";
> + *type_name = "LONG_DOUBLE_COMPLEX";
>
> ret = T_WARN;
> break;
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 9d693595e20..8077da870b0 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -6331,6 +6331,24 @@ done:
>}
>
>/* Dump C prototypes. */
> + if (flag_c_prototypes || flag_c_prototypes_external)
> +{
> + fprintf (stdout,
> +_("#include \n"
> + "#ifdef __cplusplus\n"
> + "#include \n"
> + "#define FLOAT_COMPLEX std::complex\n"
> + "#define DOUBLE_COMPLEX std::complex\n"
> + "#define LONG_DOUBLE_COMPLEX std::complex\n"
> + "extern \"C\" {\n"
> + "#else\n"
> + "#define FLOAT_COMPLEX float _Complex\n"
> + "#define DOUBLE_COMPLEX double _Complex\n"
> + "#define LONG_DOUBLE_COMPLEX long double _Complex\n"
> + "#endif\n\n"));
> +}
> +
> + /* First dump BIND(C) prototypes. */
>if (flag_c_prototypes)
> {
>for (gfc_current_ns = gfc_global_ns_list; gfc_current_ns;
> @@ -6342,6 +6360,10 @@ done:
>if (flag_c_prototypes_external)
> gfc_dump_external_c_prototypes (stdout);
>
> + if (flag_c_prototypes || flag_c_prototypes_external)
> +fprintf (stdout,
> + _("\n#ifdef __cplusplus\n}\n#endif\n"));
> +
>/* Do the translation. */
>translate_all_program_units (gfc_global_ns_list);
>
> --
> 2.17.1
Jakub
[PATCH] fortran: C++ support for generating C prototypes
When generating C prototypes for Fortran procedures with the
-fc-prototypes and -fc-prototypes-external options, print a snippet
defining macros for complex types, and add C++ support by suppressing
mangling.
fortran/ChangeLog:
2019-05-12 Janne Blomqvist
* dump-parse-tree.c (get_c_type_name): Use macros for complex type
names.
* parse.c (gfc_parse_file): Define complex macros, add CPP support
when printing C prototypes.
Ok for trunk?
---
gcc/fortran/dump-parse-tree.c | 12 ++--
gcc/fortran/parse.c | 22 ++
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 54af5dfd50d..21305243522 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -3143,11 +3143,11 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
else if (strcmp (*type_name, "size_t") == 0)
*type_name = "ssize_t";
else if (strcmp (*type_name, "float_complex") == 0)
- *type_name = "float complex";
+ *type_name = "FLOAT_COMPLEX";
else if (strcmp (*type_name, "double_complex") == 0)
- *type_name = "double complex";
+ *type_name = "DOUBLE_COMPLEX";
else if (strcmp (*type_name, "long_double_complex") == 0)
- *type_name = "long double complex";
+ *type_name = "LONG_DOUBLE_COMPLEX";
ret = T_OK;
}
@@ -3166,11 +3166,11 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
else if (strcmp (*type_name, "size_t") == 0)
*type_name = "ssize_t";
else if (strcmp (*type_name, "float_complex") == 0)
- *type_name = "float complex";
+ *type_name = "FLOAT_COMPLEX";
else if (strcmp (*type_name, "double_complex") == 0)
- *type_name = "double complex";
+ *type_name = "DOUBLE_COMPLEX";
else if (strcmp (*type_name, "long_double_complex") == 0)
- *type_name = "long double complex";
+ *type_name = "LONG_DOUBLE_COMPLEX";
ret = T_WARN;
break;
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 9d693595e20..8077da870b0 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -6331,6 +6331,24 @@ done:
}
/* Dump C prototypes. */
+ if (flag_c_prototypes || flag_c_prototypes_external)
+{
+ fprintf (stdout,
+ _("#include \n"
+"#ifdef __cplusplus\n"
+"#include \n"
+"#define FLOAT_COMPLEX std::complex\n"
+"#define DOUBLE_COMPLEX std::complex\n"
+"#define LONG_DOUBLE_COMPLEX std::complex\n"
+"extern \"C\" {\n"
+"#else\n"
+"#define FLOAT_COMPLEX float _Complex\n"
+"#define DOUBLE_COMPLEX double _Complex\n"
+"#define LONG_DOUBLE_COMPLEX long double _Complex\n"
+"#endif\n\n"));
+}
+
+ /* First dump BIND(C) prototypes. */
if (flag_c_prototypes)
{
for (gfc_current_ns = gfc_global_ns_list; gfc_current_ns;
@@ -6342,6 +6360,10 @@ done:
if (flag_c_prototypes_external)
gfc_dump_external_c_prototypes (stdout);
+ if (flag_c_prototypes || flag_c_prototypes_external)
+fprintf (stdout,
+_("\n#ifdef __cplusplus\n}\n#endif\n"));
+
/* Do the translation. */
translate_all_program_units (gfc_global_ns_list);
--
2.17.1
Re: [patch] Multilib support for amd64 FreeBSD
On 25.04.19 22:07, Andreas Tobler wrote: On 18.03.19 22:28, Andreas Tobler wrote: On 18.03.19 22:22, Jeff Law wrote: On 3/17/19 2:40 PM, Andreas Tobler wrote: Hi all, this patch adds support for multilib on x86_64-unknown-freebsd* The multilibs are 32-bit. This patch is functionality tested on gcc8 and gcc9. Test suite testing is a bit tricky since the FreeBSD dynamic linker handles both, the 32-bit and the 64-bit binaries. So, if I have a 64-bit libgcc in the LD_LIBRARY_PATH the test fails. I tweaked the build tree and removed the 64-bit libgcc to test the 32-bit binaries built. So far it looks good. Need to find a way to extend the testsuite to handle this situation. Any comments about it are welcome. Also, when would be the best time to commit this patch? Afair trunk is in stage4, right? The patch itself only affects x86_64-unknown-freebsd. TIA, Andreas 2019-03-17 Andreas Tobler * config/i386/freebsd64.h: Add bits for 32-bit multilib support. * config/i386/t-freebsd64: New file. * config.gcc: Add the t-freebsd64 for multilib support. stage4 is supposed to be regression fixes only, so it's difficult to make a case for this patch to get into gcc-9. I'd say defer to gcc-10. Ok, fine with me. Once gcc-10 opens, I will commit this patch also to all open and active branches. Commit to branch gcc8 done. Andreas
Re: [patch] Multilib support for amd64 FreeBSD
On 25.04.19 22:07, Andreas Tobler wrote: On 18.03.19 22:28, Andreas Tobler wrote: On 18.03.19 22:22, Jeff Law wrote: On 3/17/19 2:40 PM, Andreas Tobler wrote: Hi all, this patch adds support for multilib on x86_64-unknown-freebsd* The multilibs are 32-bit. This patch is functionality tested on gcc8 and gcc9. Test suite testing is a bit tricky since the FreeBSD dynamic linker handles both, the 32-bit and the 64-bit binaries. So, if I have a 64-bit libgcc in the LD_LIBRARY_PATH the test fails. I tweaked the build tree and removed the 64-bit libgcc to test the 32-bit binaries built. So far it looks good. Need to find a way to extend the testsuite to handle this situation. Any comments about it are welcome. Also, when would be the best time to commit this patch? Afair trunk is in stage4, right? The patch itself only affects x86_64-unknown-freebsd. TIA, Andreas 2019-03-17 Andreas Tobler * config/i386/freebsd64.h: Add bits for 32-bit multilib support. * config/i386/t-freebsd64: New file. * config.gcc: Add the t-freebsd64 for multilib support. stage4 is supposed to be regression fixes only, so it's difficult to make a case for this patch to get into gcc-9. I'd say defer to gcc-10. Ok, fine with me. Once gcc-10 opens, I will commit this patch also to all open and active branches. Pushed to trunk, branches will follow. Commit to branch gcc9 done. Andreas
[Darwin, fixincludes, committed] Fix PR90379
This does not alter the fixincludes, but only the test conditions - the test was failing because test_text should not be provided for wrap fixes. Tested on x86-64-linux and x86-64-darwin (also confirmed to fix the issue by the OP). Applied to trunk, backport to 9 in due course. Thanks Iain fixincludes/ 2019-05-11 Iain Sandoe PR target/90379 PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. pr90379.diff Description: Binary data
[PATCH] Remove Profile Mode, deprecated since GCC 7.1
The Profile Mode extension is not used by anybody, nor maintained by anybody. The containers do not support the full API specified in recent standards, and so enabling Profile Mode is not source compatible with much modern C++ code. The heuristics that would check the profile information and make useful suggestions never materialized, so it isn't useful. It should be removed. Remove Profile Mode, deprecated since 7.1.0 * doc/Makefile.am: Remove XML file for profile mode docs. * doc/Makefile.in: Regenerate. * doc/xml/authors.xml: Remove authors of profile mode docs. * doc/xml/manual/appendix_contributing.xml: Remove mention of profile mode. * doc/xml/manual/debug.xml: Likewise. * doc/xml/manual/evolution.xml: Document removal of profile mode. * doc/xml/manual/profile_mode.xml: Remove profile mode docs. * doc/xml/manual/spine.xml: Remove profile mode author credit. * doc/xml/manual/test.xml: Remove docs for dg-require-profile-mode directive. * doc/xml/manual/using.xml: Remove docs for profile mode headers and macro. * doc/html/*: Regenerate. * include/Makefile.am: Remove profile mode headers. * include/Makefile.in: Regenerate. * include/bits/c++config (std::__profile): Remove namespace. [_GLIBCXX_PROFILE]: Remove checks for macro. * include/profile/array: Remove. * include/profile/base.h: Remove. * include/profile/bitset: Remove. * include/profile/deque: Remove. * include/profile/forward_list: Remove. * include/profile/impl/profiler.h: Remove. * include/profile/impl/profiler_algos.h: Remove. * include/profile/impl/profiler_container_size.h: Remove. * include/profile/impl/profiler_hash_func.h: Remove. * include/profile/impl/profiler_hashtable_size.h: Remove. * include/profile/impl/profiler_list_to_slist.h: Remove. * include/profile/impl/profiler_list_to_vector.h: Remove. * include/profile/impl/profiler_map_to_unordered_map.h: Remove. * include/profile/impl/profiler_node.h: Remove. * include/profile/impl/profiler_state.h: Remove. * include/profile/impl/profiler_trace.h: Remove. * include/profile/impl/profiler_vector_size.h: Remove. * include/profile/impl/profiler_vector_to_list.h: Remove. * include/profile/iterator_tracker.h: Remove. * include/profile/list: Remove. * include/profile/map: Remove. * include/profile/map.h: Remove. * include/profile/multimap.h: Remove. * include/profile/multiset.h: Remove. * include/profile/ordered_base.h: Remove. * include/profile/set: Remove. * include/profile/set.h: Remove. * include/profile/unordered_base.h: Remove. * include/profile/unordered_map: Remove. * include/profile/unordered_set: Remove. * include/profile/vector: Remove. * scripts/run_doxygen: Do not process profile mode headers. * testsuite/23_containers/array/element_access/60497.cc: Don't use profile mode type. * testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc: Remove dg-skip-if for profile mode. * testsuite/23_containers/forward_list/capacity/1.cc: Remove preprocessor check for profile mode. * testsuite/23_containers/list/capacity/29134.cc: Likewise. * testsuite/23_containers/map/modifiers/extract.cc: Remove dg-skip-if for profile mode. * testsuite/23_containers/map/modifiers/insert_or_assign/1.cc: Likewise. * testsuite/23_containers/map/modifiers/try_emplace/1.cc: Likewise. * testsuite/23_containers/multimap/modifiers/extract.cc: Likewise. * testsuite/23_containers/multiset/modifiers/extract.cc: Likewise. * testsuite/23_containers/set/modifiers/extract.cc: Likewise. * testsuite/23_containers/unordered_map/modifiers/extract.cc: Likewise. * testsuite/23_containers/unordered_multimap/modifiers/extract.cc: Likewise. * testsuite/23_containers/unordered_multiset/modifiers/extract.cc: Likewise. * testsuite/23_containers/unordered_set/modifiers/extract.cc: Likewise. * testsuite/23_containers/vector/bool/capacity/29134.cc: Remove preprocessor check for profile mode. * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: Likewise. * testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc: Remove dg-skip-if for profile mode. * testsuite/25_algorithms/binary_search/partitioned.cc: Likewise. * testsuite/25_algorithms/equal_range/partitioned.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare/71545.cc: Likewise. * testsuite/25_algorithms/lower_bound/partitioned.cc: Likewise. *
[PATCH] Remove array_allocator extension, deprecated since 4.9.0
This type is not a conforming allocator, because it cannot be reliably rebound to allocate for a different type. The result of the rebind transformation still uses the same underlying std::tr1::array array, which may not be correctly aligned or even have elements the right size for the value_type of the rebound allocator. It has been deprecated for several years and should now be removed. * doc/xml/manual/allocator.xml: Remove documentation for array_allocator. * doc/xml/manual/evolution.xml: Document array_allocator removal. * doc/xml/manual/using.xml: Remove header from documentation. * include/Makefile.am: Remove header. * include/Makefile.in: Regenerate. * include/ext/array_allocator.h: Remove. * include/precompiled/extc++.h: Do not include removed header. * testsuite/ext/array_allocator/1.cc: Remove. * testsuite/ext/array_allocator/2.cc: Remove. * testsuite/ext/array_allocator/26875.cc: Remove. * testsuite/ext/array_allocator/3.cc: Remove. * testsuite/ext/array_allocator/check_deallocate_null.cc: Remove. * testsuite/ext/array_allocator/check_delete.cc: Remove. * testsuite/ext/array_allocator/check_new.cc: Remove. * testsuite/ext/array_allocator/variadic_construct.cc: Remove. * testsuite/ext/headers.cc: Do not include removed header. Tested powerpc64le-linux. If you want to speak in favour of keeping this please do so soon, and please volunteer to fix it to actually meet the allocator requirements. commit 5f01861c1f2891c4d766cab508a38af472a24527 Author: Jonathan Wakely Date: Thu Apr 11 12:31:31 2019 +0100 Remove array_allocator extension, deprecated since 4.9.0 This type is not a conforming allocator, because it cannot be reliably rebound to allocate for a different type. The result of the rebind transformation still uses the same underlying std::tr1::array array, which may not be correctly aligned or even have elements the right size for the value_type of the rebound allocator. It has been deprecated for several years and should now be removed. * doc/xml/manual/allocator.xml: Remove documentation for array_allocator. * doc/xml/manual/evolution.xml: Document array_allocator removal. * doc/xml/manual/using.xml: Remove header from documentation. * include/Makefile.am: Remove header. * include/Makefile.in: Regenerate. * include/ext/array_allocator.h: Remove. * include/precompiled/extc++.h: Do not include removed header. * testsuite/ext/array_allocator/1.cc: Remove. * testsuite/ext/array_allocator/2.cc: Remove. * testsuite/ext/array_allocator/26875.cc: Remove. * testsuite/ext/array_allocator/3.cc: Remove. * testsuite/ext/array_allocator/check_deallocate_null.cc: Remove. * testsuite/ext/array_allocator/check_delete.cc: Remove. * testsuite/ext/array_allocator/check_new.cc: Remove. * testsuite/ext/array_allocator/variadic_construct.cc: Remove. * testsuite/ext/headers.cc: Do not include removed header. diff --git a/libstdc++-v3/doc/xml/manual/allocator.xml b/libstdc++-v3/doc/xml/manual/allocator.xml index 8d49b919ff6..2b9a5ca6611 100644 --- a/libstdc++-v3/doc/xml/manual/allocator.xml +++ b/libstdc++-v3/doc/xml/manual/allocator.xml @@ -354,23 +354,6 @@ taken care of elsewhere). - - - array_allocator - - -Allows allocations of known and fixed sizes using existing -global or external storage allocated via construction of -std::tr1::array objects. By using this -allocator, fixed size containers (including -std::string) can be used without -instances calling ::operator new and -::operator delete. This capability -allows the use of STL abstractions without runtime -complications or overhead, even in situations such as program -startup. For usage examples, please consult the testsuite. - - debug_allocator diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml index c7efb8f0f8a..80288694056 100644 --- a/libstdc++-v3/doc/xml/manual/evolution.xml +++ b/libstdc++-v3/doc/xml/manual/evolution.xml @@ -947,4 +947,8 @@ now defaults to zero. +10 + __gnu_cxx::array_allocator removed. + + diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml index 8e099d9c3d8..a97099989a1 100644 --- a/libstdc++-v3/doc/xml/manual/using.xml +++ b/libstdc++-v3/doc/xml/manual/using.xml @@ -719,7 +719,6 @@ compiler supports scalar decimal floating-point types defined via ext/algorithm ext/atomicity.h -ext/array_allocator.h ext/bitmap_allocator.h ext/cast.h diff --git
Re: [PATCH] Fix aarch64 exception handling (PR c++/59813)
On Sat, May 11, 2019 at 09:38:22AM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > Previously, the mere existence of the addressable variables this_context
> > and cur_context prevented tail call on the early out
> > return _Unwind_RaiseException (exc);
> > but since r271013 the tailcall analysis figures that while those two
> > variables are there, they aren't touched before the possible tail call
> > site, so they can't be really live during the call.
Ah! That explains why this never happened before.
> > This does a lot of register saving and restoring, which is not needed but is
> > not wrong-code (guess separate shrink wrapping would help here if
> > implemented for the target).
SWS does not handle eh_return:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/shrink-wrap.c;h=57124db92c662bf52efc7ea94c274d9b4e234d04;hb=HEAD#l1780
But, a function calling eh_return will not get *any* shrink-wrapping:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/shrink-wrap.c;h=57124db92c662bf52efc7ea94c274d9b4e234d04;hb=HEAD#l658
(it has done this since r179553, when shrink-wrapping was added).
Some targets run splitters for their eh_return and evilness like that.
It never was documented what the compiler expects the target to do with
eh_return, and what the limitations are, etc.
> > The only wrong-code is actually the
> > add sp, sp, x4 instruction though. The previous instruction restored sp to
> > the value it had at the start of the function and then we should just tail
> > call.
But is that correct? eh_return is supposed to adjust the stack?
And, what should other targets do?
> FWIW, I agree we should just fix the targets and not even use the
> workaround you posted later. It won't be the first time that many
> targets have got something wrong due to lack of coverage.
eh_return isn't defined or documented very well. That should be fixed...
Or maybe eh_return should just be removed.
Segher
> > --- gcc/config/aarch64/aarch64.c.jj 2019-05-02 12:18:40.004979690 +0200
> > +++ gcc/config/aarch64/aarch64.c2019-05-09 20:08:00.774718003 +0200
> > @@ -5913,7 +5913,7 @@ aarch64_expand_epilogue (bool for_sibcal
> > }
> >
> >/* Stack adjustment for exception handler. */
> > - if (crtl->calls_eh_return)
> > + if (crtl->calls_eh_return && !for_sibcall)
> > {
> >/* We need to unwind the stack by the offset computed by
> > EH_RETURN_STACKADJ_RTX. We have already reset the CFA
[PATCH, Darwin, testsuite, committed] Fix PR81058.
The tests fail as noted in the PR, because Darwin’s ABI mandates indirection for common accesses, which means that the codegen doesn’t match what the tests expect. In this case, we can fix this simply by placing the relevant vars in the regular data section (by appending -fno-common to the test flags). Applied to trunk, will backport in due course. thanks. Iain gcc/testsuite/ 2019-05-11 Iain Sandoe PR testsuite/81058 * gcc.target/i386/avx512bw-vpmovswb-1.c: Use regular data section for variables on Darwin, rather than common. * gcc.target/i386/avx512bw-vpmovuswb-1.c: Likewise. * gcc.target/i386/avx512bw-vpmovwb-1.c: Likewise. pr81058-trunk.diff Description: Binary data
Re: [patch, fortran] Inline argument packing
> Le 11 mai 2019 à 15:49, Thomas Koenig a écrit : > > Hi Dominique, > >> How ever adding the new tests is a real PITA!-( >> Could you improve the naming scheme for them > > What should be the preferrred naming scheme for a > test that is split? I'm open to suggestions (but also, > the naming convention should not matter once the test > cases are committed). Well, when the naming I use for testing does not correspond to the one committed I have to clean the mess!-( You have attachments for typebound_assignment_5a.f90 and typebound_assignment_6a.f90 It would be nice to have similar attachments for the other splits. Also I can guess the names for the new tests, but it would help to have them in the same order as in the mail. (I think you should really use the +N option for the diff). Dominique > > Regards > > Thomas
Re: [patch, fortran] Inline argument packing
Hi Dominique, How ever adding the new tests is a real PITA!-( Could you improve the naming scheme for them What should be the preferrred naming scheme for a test that is split? I'm open to suggestions (but also, the naming convention should not matter once the test cases are committed). Regards Thomas
Re: [patch, fortran] Inline argument packing
Hi Thomas, I confirm that the new patch fixes the ICE. How ever adding the new tests is a real PITA!-( Could you improve the naming scheme for them TIA Dominique
Re: Make vector iterator operators hidden friends
On 5/10/19 3:59 PM, Jonathan Wakely wrote:
On 10/05/19 14:40 +0100, Jonathan Wakely wrote:
On Thu, 9 May 2019 at 06:49, François Dumont wrote:
Hi
Patch similar to the one I just apply for deque iterator including
NRVO copy ellision fix.
* include/bits/stl_bvector.h
(operator==(const _Bit_iterator_base&, const
_Bit_iterator_base&)):
Make hidden friend.
(operator<(const _Bit_iterator_base&, const _Bit_iterator_base&)):
Likewise.
(operator!=(const _Bit_iterator_base&, const
_Bit_iterator_base&)):
Likewise.
(operator>(const _Bit_iterator_base&, const _Bit_iterator_base&)):
Likewise.
(operator<=(const _Bit_iterator_base&, const
_Bit_iterator_base&)):
Likewise.
(operator>=(const _Bit_iterator_base&, const
_Bit_iterator_base&)):
Likewise.
(operator-(const _Bit_iterator_base&, const _Bit_iterator_base&)):
Likewise.
(_Bit_iterator::operator+(difference_type)): Likewise and allow
NRVO
copy elision.
(_Bit_iterator::operator-(difference_type)): Likewise.
(operator+(ptrdiff_t, const _Bit_iterator&)): Make hidden friend.
(_Bit_const_iterator::operator+(difference_type)): Likewise and
allow
NRVO copy elision.
(_Bit_const_iterator::operator-(difference_type)): Likewise.
(operator+(ptrdiff_t, const _Bit_const_iterator&)): Make hidden
friend.
These const_iterator overloads seem to be missing the NRVO fix.
But the patch looks good otherwise, so OK for trunk with the NRVO
changes. Thanks.
Indeed, I had put it in the ChangeLog but forgotten to adapt code.
Attached patch committed.
François
diff --git a/libstdc++-v3/include/bits/stl_bvector.h b/libstdc++-v3/include/bits/stl_bvector.h
index c60f4f0ef1c..280d40f60c5 100644
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -182,40 +182,40 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_M_offset = static_cast(__n);
}
-bool
-operator==(const _Bit_iterator_base& __i) const
-{ return _M_p == __i._M_p && _M_offset == __i._M_offset; }
+friend bool
+operator==(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{ return __x._M_p == __y._M_p && __x._M_offset == __y._M_offset; }
-bool
-operator<(const _Bit_iterator_base& __i) const
+friend bool
+operator<(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
{
- return _M_p < __i._M_p
- || (_M_p == __i._M_p && _M_offset < __i._M_offset);
+ return __x._M_p < __y._M_p
+ || (__x._M_p == __y._M_p && __x._M_offset < __y._M_offset);
}
-bool
-operator!=(const _Bit_iterator_base& __i) const
-{ return !(*this == __i); }
+friend bool
+operator!=(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{ return !(__x == __y); }
-bool
-operator>(const _Bit_iterator_base& __i) const
-{ return __i < *this; }
+friend bool
+operator>(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{ return __y < __x; }
-bool
-operator<=(const _Bit_iterator_base& __i) const
-{ return !(__i < *this); }
+friend bool
+operator<=(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{ return !(__y < __x); }
-bool
-operator>=(const _Bit_iterator_base& __i) const
-{ return !(*this < __i); }
- };
+friend bool
+operator>=(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{ return !(__x < __y); }
- inline ptrdiff_t
- operator-(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
- {
-return (int(_S_word_bit) * (__x._M_p - __y._M_p)
- + __x._M_offset - __y._M_offset);
- }
+friend ptrdiff_t
+operator-(const _Bit_iterator_base& __x, const _Bit_iterator_base& __y)
+{
+ return (int(_S_word_bit) * (__x._M_p - __y._M_p)
+ + __x._M_offset - __y._M_offset);
+}
+ };
struct _Bit_iterator : public _Bit_iterator_base
{
@@ -280,29 +280,31 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
return *this;
}
-iterator
-operator+(difference_type __i) const
+reference
+operator[](difference_type __i) const
+{ return *(*this + __i); }
+
+friend iterator
+operator+(const iterator& __x, difference_type __n)
{
- iterator __tmp = *this;
- return __tmp += __i;
+ iterator __tmp = __x;
+ __tmp += __n;
+ return __tmp;
}
-iterator
-operator-(difference_type __i) const
+friend iterator
+operator+(difference_type __n, const iterator& __x)
+{ return __x + __n; }
+
+friend iterator
+operator-(const iterator& __x, difference_type __n)
{
- iterator __tmp = *this;
- return __tmp -= __i;
+ iterator __tmp = __x;
+ __tmp -= __n;
+ return __tmp;
}
-
-reference
-operator[](difference_type __i) const
-{ return *(*this + __i); }
};
- inline _Bit_iterator
- operator+(ptrdiff_t __n, const
[patch, fortran] Inline argument packing
Hello world,
this new version of the inlie argument packing patch (PR 88821)
avoids the ICE on the test case for PR 61968. Otherwise it is
unchanged.
Regression-tested. OK for trunk?
Regards
Thomas
2019-05-11 Thomas Koenig
PR fortran/88821
* expr.c (gfc_is_simply_contiguous): Return true for
an EXPR_ARRAY.
* trans-array.c (is_pointer): New function.
(gfc_conv_array_parameter): Call gfc_conv_subref_array_arg
when not optimizing and not optimizing for size if the formal
arg is passed by reference.
* trans-expr.c (gfc_conv_subref_array_arg): Add arguments
fsym, proc_name and sym. Add run-time warning for temporary
array creation. Wrap argument if passing on an optional
argument to an optional argument.
* trans.h (gfc_conv_subref_array_arg): Add optional arguments
fsym, proc_name and sym to prototype.
2019-05-11 Thomas Koenig
PR fortran/88821
* gfortran.dg/alloc_comp_auto_array_3.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/assumed_type_2.f90: Split compile and run time
tests into this and
* gfortran.dg/assumed_type_2a.f90: New file.
* gfortran.dg/c_loc_test_22.f90: Likewise.
* gfortran.dg/contiguous_3.f90: Likewise.
* gfortran.dg/internal_pack_11.f90: Likewise.
* gfortran.dg/internal_pack_12.f90: Likewise.
* gfortran.dg/internal_pack_16.f90: Likewise.
* gfortran.dg/internal_pack_17.f90: Likewise.
* gfortran.dg/internal_pack_18.f90: Likewise.
* gfortran.dg/internal_pack_4.f90: Likewise.
* gfortran.dg/internal_pack_5.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/internal_pack_6.f90: Split compile and run time
tests into this and
* gfortran.dg/internal_pack_6a.f90: New file.
* gfortran.dg/internal_pack_8.f90: Likewise.
* gfortran.dg/missing_optional_dummy_6: Split compile and run time
tests into this and
* gfortran.dg/missing_optional_dummy_6a.f90: New file.
* gfortran.dg/no_arg_check_2.f90: Split compile and run time tests
into this and
* gfortran.dg/no_arg_check_2a.f90: New file.
* gfortran.dg/typebound_assignment_5.f90: Split compile and run time
tests into this and
* gfortran.dg/typebound_assignment_5a.f90: New file.
* gfortran.dg/typebound_assignment_6.f90: Split compile and run time
tests into this and
* gfortran.dg/typebound_assignment_6a.f90: New file.
* gfortran.dg/internal_pack_19.f90: New file.
* gfortran.dg/internal_pack_20.f90: New file.
* gfortran.dg/internal_pack_21.f90: New file.
Index: fortran/expr.c
===
--- fortran/expr.c (Revision 270622)
+++ fortran/expr.c (Arbeitskopie)
@@ -5713,6 +5713,9 @@ gfc_is_simply_contiguous (gfc_expr *expr, bool str
gfc_ref *ref, *part_ref = NULL;
gfc_symbol *sym;
+ if (expr->expr_type == EXPR_ARRAY)
+return true;
+
if (expr->expr_type == EXPR_FUNCTION)
{
if (expr->value.function.esym)
Index: fortran/trans-array.c
===
--- fortran/trans-array.c (Revision 270622)
+++ fortran/trans-array.c (Arbeitskopie)
@@ -7869,6 +7869,23 @@ array_parameter_size (tree desc, gfc_expr *expr, t
*size, fold_convert (gfc_array_index_type, elem));
}
+/* Helper function - return true if the argument is a pointer. */
+
+static bool
+is_pointer (gfc_expr *e)
+{
+ gfc_symbol *sym;
+
+ if (e->expr_type != EXPR_VARIABLE || e->symtree == NULL)
+return false;
+
+ sym = e->symtree->n.sym;
+ if (sym == NULL)
+return false;
+
+ return sym->attr.pointer || sym->attr.proc_pointer;
+}
+
/* Convert an array for passing as an actual parameter. */
void
@@ -8120,6 +8137,20 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
"Creating array temporary at %L", >where);
}
+ /* When optmizing, we can use gfc_conv_subref_array_arg for
+ making the packing and unpacking operation visible to the
+ optimizers. */
+
+ if (g77 && optimize && !optimize_size && expr->expr_type == EXPR_VARIABLE
+ && !is_pointer (expr) && (fsym == NULL
+|| fsym->ts.type != BT_ASSUMED))
+ {
+ gfc_conv_subref_array_arg (se, expr, g77,
+ fsym ? fsym->attr.intent : INTENT_INOUT,
+ false, fsym, proc_name, sym);
+ return;
+ }
+
ptr = build_call_expr_loc (input_location,
gfor_fndecl_in_pack, 1, desc);
Index: fortran/trans-expr.c
===
--- fortran/trans-expr.c (Revision 270622)
+++ fortran/trans-expr.c (Arbeitskopie)
@@ -4576,8 +4576,10 @@ gfc_apply_interface_mapping (gfc_interface_mapping
an actual argument derived type array is
Re: [PATCH] Fix aarch64 exception handling (PR c++/59813)
Jakub Jelinek writes:
> Hi!
>
> My recent patch for tail call improvement apparently affects also the
> _Unwind_Resume_or_Rethrow function in libgcc:
>
> _Unwind_Reason_Code __attribute__((optimize ("no-omit-frame-pointer")))
> _Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
> {
> struct _Unwind_Context this_context, cur_context;
> _Unwind_Reason_Code code;
> unsigned long frames;
> if (exc->private_1 == 0)
> return _Unwind_RaiseException (exc);
> do { __builtin_unwind_init (); uw_init_context_1 (_context,
> __builtin_dwarf_cfa (), __builtin_return_address (0)); } while (0);
> cur_context = this_context;
> code = _Unwind_ForcedUnwind_Phase2 (exc, _context, );
> ((void)(!(code == _URC_INSTALL_CONTEXT) ? abort (), 0 : 0));
> do { long offset = uw_install_context_1 ((_context), (_context));
> void *handler = uw_frob_return_addr ((_context), (_context));
> _Unwind_DebugHook ((_context)->cfa, handler); ; __builtin_eh_return
> (offset, handler); } while (0);
> }
>
> Previously, the mere existence of the addressable variables this_context
> and cur_context prevented tail call on the early out
> return _Unwind_RaiseException (exc);
> but since r271013 the tailcall analysis figures that while those two
> variables are there, they aren't touched before the possible tail call
> site, so they can't be really live during the call.
> The problem is that this is one of the few calls that call
> __builtin_eh_return which normally user code doesn't use, we use it just
> for the unwinder routines and so some targets (in this case aarch64, in
> another report powerpc-darwin) show that the combination of
> cfun->calls_eh_return + tail calls has not been really tested.
> One possibility is to do if (cfun->calls_eh_return) return false; in
> the target hook *_ok_for_sibcall, the other possibility is to fix that
> case properly.
>
> The following patch fixes the aarch64 case.
> The code emitted for the code path from the start of the function
> till the tail call was:
> 2778 <_Unwind_Resume_or_Rethrow>:
> 2778: d12143ffsub sp, sp, #0x850
> 277c: a9007bfdstp x29, x30, [sp]
> 2780: 910003fdmov x29, sp
> 2784: a90107e0stp x0, x1, [sp, #16]
> 2788: f9400801ldr x1, [x0, #16]
> 278c: a9020fe2stp x2, x3, [sp, #32]
> 2790: a90353f3stp x19, x20, [sp, #48]
> 2794: aa0003f3mov x19, x0
> 2798: a9045bf5stp x21, x22, [sp, #64]
> 279c: a90563f7stp x23, x24, [sp, #80]
> 27a0: a9066bf9stp x25, x26, [sp, #96]
> 27a4: a90773fbstp x27, x28, [sp, #112]
> 27a8: 6d0827e8stp d8, d9, [sp, #128]
> 27ac: 6d092feastp d10, d11, [sp, #144]
> 27b0: 6d0a37ecstp d12, d13, [sp, #160]
> 27b4: 6d0b3feestp d14, d15, [sp, #176]
> 27b8: b5000201cbnzx1, 27f8
> <_Unwind_Resume_or_Rethrow+0x80>
> 27bc: a9407bfdldp x29, x30, [sp]
> 27c0: a94107e0ldp x0, x1, [sp, #16]
> 27c4: a9420fe2ldp x2, x3, [sp, #32]
> 27c8: a94353f3ldp x19, x20, [sp, #48]
> 27cc: a9445bf5ldp x21, x22, [sp, #64]
> 27d0: a94563f7ldp x23, x24, [sp, #80]
> 27d4: a9466bf9ldp x25, x26, [sp, #96]
> 27d8: a94773fbldp x27, x28, [sp, #112]
> 27dc: 6d4827e8ldp d8, d9, [sp, #128]
> 27e0: 6d492fealdp d10, d11, [sp, #144]
> 27e4: 6d4a37ecldp d12, d13, [sp, #160]
> 27e8: 6d4b3feeldp d14, d15, [sp, #176]
> 27ec: 912143ffadd sp, sp, #0x850
> 27f0: 8b2463ffadd sp, sp, x4
> 27f4: 1400b 23c8 <_Unwind_RaiseException>
> 27f4: R_AARCH64_JUMP26 _Unwind_RaiseException
> This does a lot of register saving and restoring, which is not needed but is
> not wrong-code (guess separate shrink wrapping would help here if
> implemented for the target). The only wrong-code is actually the
> add sp, sp, x4 instruction though. The previous instruction restored sp to
> the value it had at the start of the function and then we should just tail
> call. This instruction is something that is needed in the spot where
> __builtin_eh_return is emitted.
>
> Fixed thusly, bootstrapped/regtested on aarch64-linux, ok for trunk?
>
> 2019-05-10 Jakub Jelinek
>
> PR c++/59813
> * config/aarch64/aarch64.c (aarch64_expand_epilogue): Don't add
> EH_RETURN_STACKADJ_RTX to sp in sibcall epilogues.
OK, thanks.
FWIW, I agree we should just fix the targets and not even use the
workaround you posted later. It won't be the first time that many
targets have got
[PATCH, i386]: Use pinsrd to move DImode value to xmm reg
We can use pinsrd when moving DImode value from integer register pair
to xmm reg for 32bit SSE4.1 targets.
2019-05-11 Uroš Bizjak
* config/i386/i386.md (floatdi2_i387_with_xmm):
Use pinsrd for TARGET_SSE4_1.
* config/i386/sse.md (movdi_to_sse): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 46277f158bb3..1886715fe77e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5117,12 +5117,12 @@
})
(define_insn_and_split "floatdi2_i387_with_xmm"
- [(set (match_operand:X87MODEF 0 "register_operand" "=f")
+ [(set (match_operand:X87MODEF 0 "register_operand" "=f,f")
(float:X87MODEF
- (match_operand:DI 1 "register_operand" "r")))
- (clobber (match_scratch:V4SI 3 "=x"))
- (clobber (match_scratch:V4SI 4 "=x"))
- (clobber (match_operand:DI 2 "memory_operand" "=m"))]
+ (match_operand:DI 1 "register_operand" "r,r")))
+ (clobber (match_operand:DI 2 "memory_operand" "=m,m"))
+ (clobber (match_scratch:V4SI 3 "=x,x"))
+ (clobber (match_scratch:V4SI 4 "=X,x"))]
"!TARGET_64BIT && TARGET_INTER_UNIT_MOVES_TO_VEC
&& TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
&& TARGET_SSE2 && optimize_function_for_speed_p (cfun)"
@@ -5135,14 +5135,21 @@
Assemble the 64-bit DImode value in an xmm register. */
emit_insn (gen_sse2_loadld (operands[3], CONST0_RTX (V4SImode),
gen_lowpart (SImode, operands[1])));
- emit_insn (gen_sse2_loadld (operands[4], CONST0_RTX (V4SImode),
- gen_highpart (SImode, operands[1])));
- emit_insn (gen_vec_interleave_lowv4si (operands[3], operands[3],
-operands[4]));
-
+ if (TARGET_SSE4_1)
+emit_insn (gen_sse4_1_pinsrd (operands[3], operands[3],
+ gen_highpart (SImode, operands[1]),
+ GEN_INT (2)));
+ else
+{
+ emit_insn (gen_sse2_loadld (operands[4], CONST0_RTX (V4SImode),
+ gen_highpart (SImode, operands[1])));
+ emit_insn (gen_vec_interleave_lowv4si (operands[3], operands[3],
+operands[4]));
+}
operands[3] = gen_lowpart (DImode, operands[3]);
}
- [(set_attr "type" "multi")
+ [(set_attr "isa" "sse4,*")
+ (set_attr "type" "multi")
(set_attr "mode" "")
(set_attr "unit" "i387")
(set_attr "fp_int_src" "true")])
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6b8298d957ed..a223a58ed540 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1300,10 +1300,10 @@
;; from there.
(define_insn_and_split "movdi_to_sse"
- [(set (match_operand:V4SI 0 "register_operand" "=?x,x")
- (unspec:V4SI [(match_operand:DI 1 "nonimmediate_operand" "r,m")]
+ [(set (match_operand:V4SI 0 "register_operand" "=x,x,?x")
+ (unspec:V4SI [(match_operand:DI 1 "nonimmediate_operand" "r,m,r")]
UNSPEC_MOVDI_TO_SSE))
- (clobber (match_scratch:V4SI 2 "=,X"))]
+ (clobber (match_scratch:V4SI 2 "=X,X,"))]
"!TARGET_64BIT && TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_TO_VEC"
"#"
"&& reload_completed"
@@ -1315,18 +1315,26 @@
Assemble the 64-bit DImode value in an xmm register. */
emit_insn (gen_sse2_loadld (operands[0], CONST0_RTX (V4SImode),
gen_lowpart (SImode, operands[1])));
- emit_insn (gen_sse2_loadld (operands[2], CONST0_RTX (V4SImode),
- gen_highpart (SImode, operands[1])));
- emit_insn (gen_vec_interleave_lowv4si (operands[0], operands[0],
-operands[2]));
- }
+ if (TARGET_SSE4_1)
+emit_insn (gen_sse4_1_pinsrd (operands[0], operands[0],
+ gen_highpart (SImode, operands[1]),
+ GEN_INT (2)));
+ else
+ {
+ emit_insn (gen_sse2_loadld (operands[2], CONST0_RTX (V4SImode),
+ gen_highpart (SImode, operands[1])));
+ emit_insn (gen_vec_interleave_lowv4si (operands[0], operands[0],
+operands[2]));
+ }
+ }
else if (memory_operand (operands[1], DImode))
emit_insn (gen_vec_concatv2di (gen_lowpart (V2DImode, operands[0]),
operands[1], const0_rtx));
else
gcc_unreachable ();
DONE;
-})
+}
+ [(set_attr "isa" "sse4,*,*")])
(define_split
[(set (match_operand:V4SF 0 "register_operand")
Re: [Patch, fortran] ISO_Fortran_binding PRs 90093, 90352 & 90355
Committed to 9-branch as revision 271089. Paul On Fri, 10 May 2019 at 09:00, Paul Richard Thomas wrote: > > Committed to trunk as revision 271057. > > Will do likewise with 9-branch asap. > > Cheers > > Paul > > On Wed, 8 May 2019 at 19:40, Paul Richard Thomas > wrote: > > > > Unless there are any objections to this patch, I plan to commit to > > trunk and 9-branch tomorrow night, with the change to the testcase > > pointed out by Dominique. > > > > I sincerely hope that will be the end of CFI PRs for a little while, > > at least. I have a load of pending patches and want to get on with > > fixing PDTs. > > > > Cheers > > > > Paul > > > > On Mon, 6 May 2019 at 19:59, Paul Richard Thomas > > wrote: > > > > > > It helps to attach the patch! > > > > > > On Mon, 6 May 2019 at 19:57, Paul Richard Thomas > > > wrote: > > > > > > > > Unfortunately, this patch was still in the making at the release of > > > > 9.1. It is more or less self explanatory with the ChangeLogs. > > > > > > > > It should be noted that gfc_conv_expr_present could not be used in the > > > > fix for PR90093 because the passed descriptor is a CFI type. Instead, > > > > the test is for a null pointer passed. > > > > > > > > The changes to trans-array.c(gfc_trans_create_temp_array) have an eye > > > > on the future, as well as PR90355. I am progressing towards the point > > > > where all descriptors have 'span' set correctly so that > > > > trans.c(get_array_span) can be eliminated and much of the code in the > > > > callers can be simplified. > > > > > > > > Bootstrapped and regtested on FC29/x86_64 - OK for trunk and 9-branch? > > > > > > > > Paul > > > > > > > > 2019-05-06 Paul Thomas > > > > > > > > PR fortran/90093 > > > > * trans-decl.c (convert_CFI_desc): Test that the dummy is > > > > present before doing any of the conversions. > > > > > > > > PR fortran/90352 > > > > * decl.c (gfc_verify_c_interop_param): Restore the error for > > > > charlen > 1 actual arguments passed to bind(C) procs. > > > > Clean up trailing white space. > > > > > > > > PR fortran/90355 > > > > * trans-array.c (gfc_trans_create_temp_array): Set the 'span' > > > > field to the element length for all types. > > > > (gfc_conv_expr_descriptor): The force_no_tmp flag is used to > > > > prevent temporary creation, especially for substrings. > > > > * trans-decl.c (gfc_trans_deferred_vars): Rather than assert > > > > that the backend decl for the string length is non-null, use it > > > > as a condition before calling gfc_trans_vla_type_sizes. > > > > * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp' > > > > is set before calling gfc_conv_expr_descriptor. > > > > * trans.c (get_array_span): Move the code for extracting 'span' > > > > from gfc_build_array_ref to this function. This is specific to > > > > descriptors that are component and indirect references. > > > > * trans.h : Add the force_no_tmp flag bitfield to gfc_se. > > > > > > > > 2019-05-06 Paul Thomas > > > > > > > > PR fortran/90093 > > > > * gfortran.dg/ISO_Fortran_binding_12.f90: New test. > > > > * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. > > > > > > > > PR fortran/90352 > > > > * gfortran.dg/iso_c_binding_char_1.f90: New test. > > > > > > > > PR fortran/90355 > > > > * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test > > > > the direct passing of substrings as descriptors to bind(C). > > > > * gfortran.dg/assign_10.f90: Increase the tree_dump count of > > > > 'atmp' to account for the setting of the 'span' field. > > > > * gfortran.dg/transpose_optimization_2.f90: Ditto. > > > > > > > > -- > > "If you can't explain it simply, you don't understand it well enough" > > - Albert Einstein > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [committed, wwwdocs] OpenACC status for GCC 9
On Thu, 2 May 2019, Thomas Schwinge wrote: > +https://www.openacc.org;>OpenACC support in C, C++, and > +Fortran continues to be maintained and improved. > +Most of the OpenACC 2.5 specification is implemented. > +See the > +https://gcc.gnu.org/wiki/OpenACC#status-9;>implementation > +status section on > +the https://gcc.gnu.org/wiki/OpenACC;>OpenACC wiki page for > +further information. Thanks for making this addition, Thomas! On this I'd omit the second link if that's okay with you? (I'm happy to make the change, wanted to check in with you first.) Gerald
[wwwdocs] extensions.html -- update link to Lua plugin
Committed. Gerald Index: extensions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v retrieving revision 1.62 diff -u -r1.62 extensions.html --- extensions.html 30 Sep 2018 14:38:46 - 1.62 +++ extensions.html 11 May 2019 06:30:33 - @@ -36,7 +36,7 @@ to ease development of GCC plugin-like extensions. -https://colberg.org/gcc-lua/;>Lua plugin for GCC +https://peter.colberg.org/gcc-lua;>Lua plugin for GCC gcc‑lua extends GCC with the ability to run Lua scripts. The plugin provides an interface to register callback functions for plugin events,
