Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows
On 06/16/2018 05:05 PM, Jonathan Wakely wrote: Oops, that message got bounced from the lists and was the wrong version of the patch anyway - this is the one I meant to attach. On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely wrote: Here's what I wanted to test, which removes the new AC_CHECK_FUNCS (replacing them with GLIBCXX_COMPILE_OR_LINK tests that shouldn't even get run on bare metal ). This patch worked for me, or at least I got successful builds now. I'm testing the new C-SKY port and built both csky-elf and csky-linux-gnu. (I expect to be submitting the port within the next few weeks.) -Sandra
Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows
Oops, that message got bounced from the lists and was the wrong
version of the patch anyway - this is the one I meant to attach.
On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely wrote:
>
> Here's what I wanted to test, which removes the new AC_CHECK_FUNCS (replacing
> them with GLIBCXX_COMPILE_OR_LINK tests that shouldn't even get run on bare
> metal ).
>
>
>
> On Sat, 16 Jun 2018 at 23:39, Jonathan Wakely wrote:
>>
>>
>>
>> On Sat, 16 Jun 2018 at 14:06, Jonathan Wakely wrote:
>>>
>>>
>>>
>>> On Sat, 16 Jun 2018 at 02:04, Sandra Loosemore
>>> wrote:
On 05/31/2018 01:19 PM, Jonathan Wakely wrote:
> This adds incomplete but functional support for std::filesystem and
> std::experimental::filesystem on MinGW. In theory there should be no
> changes to the existing behaviour for POSIX targets from this patch,
> as all the various bugs I found while working on this have already
> been fixed in separate patches.
>
> Tested powerpc64le-linux, and x86_64-w64-mingw32 (with a few expected
> FAILures on mingw-w64). Committed to trunk.
As noted in the issue (comment #16) 2 weeks ago already, this patch
breaks libstdc++ configure on bare-metal targets.
configure:80055: checking for link
configure:80055: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
Please fix? It's blocking other people from testing unrelated patches
on mainline.
>>>
>>>
>>> I'm not the only person able to make changes to autoconf files (and already
>>> said I didn't know how to fix this).
>>>
>>> I have a patch to replace the AC_CHECK_FUNCS line with
>>> GLIBCXX_COMPILE_OR_LINK tests inside GLIBCXX_CHECK_FILESYSTEM_DEPS which
>>> should work, I'll finish testing it when I get home this evening.
>>>
>>
>> I can't build aarch64-none-elf even before my commit, so I also can't test a
>> fix.
>>
>> checking for shl_load... configure: error: Link tests are not allowed after
>> GCC_NO_EXECUTABLES.
>>
>>
>>
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 4f37b6a6498..62b42d203e9 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4314,6 +4314,7 @@ dnl and define _GLIBCXX_USE_REALPATH and
_GLIBCXX_USE_UTIMENSAT.
dnl
AC_DEFUN([GLIBCXX_CHECK_FILESYSTEM_DEPS], [dnl
dnl
+ if test $enable_libstdcxx_filesystem_ts = yes; then
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXFLAGS="$CXXFLAGS"
@@ -4443,9 +,49 @@ dnl
AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in
.])
fi
AC_MSG_RESULT($glibcxx_cv_sendfile)
+dnl
+ AC_MSG_CHECKING([for link])
+ AC_CACHE_VAL(glibcxx_cv_link, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [link("", "");],
+ [glibcxx_cv_link=yes],
+ [glibcxx_cv_link=no])
+ ])
+ if test $glibcxx_cv_link = yes; then
+AC_DEFINE(HAVE_LINK, 1, [Define if link is available in .])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_link)
+dnl
+ AC_MSG_CHECKING([for readlink])
+ AC_CACHE_VAL(glibcxx_cv_readlink, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [char buf[32]; readlink("", buf, sizeof(buf));],
+ [glibcxx_cv_readlink=yes],
+ [glibcxx_cv_readlink=no])
+ ])
+ if test $glibcxx_cv_readlink = yes; then
+AC_DEFINE(HAVE_READLINK, 1, [Define if readlink is available in
.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_readlink)
+dnl
+ AC_MSG_CHECKING([for symlink])
+ AC_CACHE_VAL(glibcxx_cv_symlink, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [symlink("", "");],
+ [glibcxx_cv_symlink=yes],
+ [glibcxx_cv_symlink=no])
+ ])
+ if test $glibcxx_cv_symlink = yes; then
+AC_DEFINE(HAVE_SYMLINK, 1, [Define if symlink is available in .])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_symlink)
dnl
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
+ fi
])
dnl
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index dde1c4da944..7e1fd84606a 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -420,7 +420,6 @@ GLIBCXX_CHECK_GTHREADS
# For Filesystem TS.
AC_CHECK_HEADERS([fcntl.h dirent.h sys/statvfs.h utime.h])
-AC_CHECK_FUNCS(link readlink symlink)
GLIBCXX_ENABLE_FILESYSTEM_TS
GLIBCXX_CHECK_FILESYSTEM_DEPS
Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows
On Sat, 16 Jun 2018 at 14:06, Jonathan Wakely wrote: > > > On Sat, 16 Jun 2018 at 02:04, Sandra Loosemore > wrote: > >> On 05/31/2018 01:19 PM, Jonathan Wakely wrote: >> > This adds incomplete but functional support for std::filesystem and >> > std::experimental::filesystem on MinGW. In theory there should be no >> > changes to the existing behaviour for POSIX targets from this patch, >> > as all the various bugs I found while working on this have already >> > been fixed in separate patches. >> > >> > Tested powerpc64le-linux, and x86_64-w64-mingw32 (with a few expected >> > FAILures on mingw-w64). Committed to trunk. >> >> As noted in the issue (comment #16) 2 weeks ago already, this patch >> breaks libstdc++ configure on bare-metal targets. >> >> configure:80055: checking for link >> configure:80055: error: Link tests are not allowed after >> GCC_NO_EXECUTABLES. >> >> Please fix? It's blocking other people from testing unrelated patches >> on mainline. >> >> > > I'm not the only person able to make changes to autoconf files (and > already said I didn't know how to fix this). > > I have a patch to replace the AC_CHECK_FUNCS line with > GLIBCXX_COMPILE_OR_LINK tests inside GLIBCXX_CHECK_FILESYSTEM_DEPS which > should work, I'll finish testing it when I get home this evening. > > I can't build aarch64-none-elf even before my commit, so I also can't test a fix. checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig : >Hi Janus, > >> I happen to hold the opinion that optimizing out a call to a pure >> function may be reasonable if it does not influence the result of an >> expression, but optimizing out an effectively impure function (i.e. >one >> with side effects) is not a good idea at any time, since such an >> 'optimization' can drastically change the program flow and all >numerical >> results of a piece of code. > >Well, I am of a different opinion Of course opinions can differ. But could you explain what in my above statements sounds unreasonable to you? Otherwise it's hard to have an argument-based discussion. >and so is the Fortran standard. I don't think anything I wrote is in conflict with the standard. As I see it, the standard neither demands nor forbids short-circuiting. I'm just trying to fill that void in a reasonable way (having as much optimization as possible without altering results). >I think the compiler should strive to, in that order, > >- conform to the language standard >- generate fast programs >- warn about features which may trip the user I certainly agree to all of that, with the amendment that generating correct results should have precedence over generating fast programs. >In my patch, I have tried to do all three things at the same time, and >after this discussion, I still think that this is the right path >to follow. > >So, here is an update on the patch, which also covers ALLOCATED. > >Regression-tested. OK? I absolutely welcome the warnings for impure functions as second operand to .and./.or. operators, but (as noted earlier) I disagree with changing the ordering of operands. As our lengthy discussions show, things are already complicated enough, and this additional optimization just adds to the confusion IMHO. Cheers, Janus
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 11:14:08PM +0200, Thomas Koenig wrote: > Hi Janus, > > > I happen to hold the opinion that optimizing out a call to a pure > > function may be reasonable if it does not influence the result of an > > expression, but optimizing out an effectively impure function (i.e. one > > with side effects) is not a good idea at any time, since such an > > 'optimization' can drastically change the program flow and all numerical > > results of a piece of code. > > Well, I am of a different opinion, and so is the Fortran standard. > > I think the compiler should strive to, in that order, > > - conform to the language standard > - generate fast programs > - warn about features which may trip the user > > In my patch, I have tried to do all three things at the same time, and > after this discussion, I still think that this is the right path > to follow. > +1 -- Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 10:42:16PM +0200, Janus Weil wrote: > > Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl > : > >On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote: > >> > >> > >> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl > >: > >> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > >> >> > >> >> > >> >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > >> >: > >> >> >> But at least for pure functions, this optimization looks Ok. > >> >> >> > >> >> > > >> >> >Why is everyone fixated on PURE vs IMPURE functions? > >> >> > >> >> Simply because it makes a difference in this context! > >> > > >> >It does not! A function marked as PURE by a programmer > >> >must meet certain requirement of the Fortran standard. > >> >An unmarked function or a function marked as IMPURE can > >> >still meet those same requirements. Marking something as > >> >IMPURE has only a single requirement in the standard. > >> > > >> > An impure elemental procedure processes array arguments > >> > in array element order. > >> > > >> >That's it. Marking a function as IMPURE does not mean > >> >the function has side effects. It does not mean that > >> >a function must be evaluated for each reference. Are > >> >you advocating that gfortran must evaluate ping() > >> >twice for > >> > > >> > impure real function ping() > >> > end function ping > >> > > >> > x = ping() + 0 * ping() > >> > end > >> > >> Absolutely, sir. That's what I'm advocating. If someone > >> deliberately declares a function as impure, he should be > >> prepared to deal with the consequences. In general, though, > >> one can wonder whether the compiler could not warn that > >> the impure declaration is not necessary (or, in other words,i > >> that the function would be better declared as pure). > > > >This is a different answer than what you gave in > >the PR when I asked if you were special casing > >.and. and .or. > > Possibly we're having a communication issue here. It seems so. > >> In any case, the example you're showing is probably not > >> the most problematic one. I assume a much more frequent > >> and critical case would be the one where people forget > >> to mark a function that is effectively pure with the > >> PURE attribute. > > > >See Fortran 2018, Note 10.28 (if I remember correctly). > >That example explicitly involves .and., and it explicitly > >states that a function need not be evaluate. It does > >not sya "pure function". It says "function". > > You can stop throwing standard quotes. I do know what the > standard says about this by now. > > Point is: It does not sound very reasonable to me and I agree > with Janne that the standard's treatment of impure functions > is somewhere between careless and insane. > > If the standard says it's ok to optimize out any kind of > function, That is exactly what the Fortran standard says! I've quoted the relevant parts of Fortran standard, but you seem relucant to accept it and have ask me to stop supporting my position. For the logical expression, x = .false. .and. check() a Fortran compiler can replace this expression with x = .false. without evaluating check() (regardless of PURE vs IMPURE). That is exactly what Fortran 2018 Note 10.28 says. I won't quote it again. -- Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
Hi Janus,
I happen to hold the opinion that optimizing out a call to a pure
function may be reasonable if it does not influence the result of an
expression, but optimizing out an effectively impure function (i.e. one
with side effects) is not a good idea at any time, since such an
'optimization' can drastically change the program flow and all numerical
results of a piece of code.
Well, I am of a different opinion, and so is the Fortran standard.
I think the compiler should strive to, in that order,
- conform to the language standard
- generate fast programs
- warn about features which may trip the user
In my patch, I have tried to do all three things at the same time, and
after this discussion, I still think that this is the right path
to follow.
So, here is an update on the patch, which also covers ALLOCATED.
Regression-tested. OK?
Thomas
! { dg-do compile }
! { dg-additional-options "-Wsurprising -fdump-tree-original" }
! PR 85599 - check warning that impure function calls might be removed,
! and that logical expressions involving .and. and .or. will be
! reordered.
MODULE M1
TYPE T1
LOGICAL :: T=.TRUE.
END TYPE T1
CONTAINS
SUBROUTINE S1(m)
TYPE(T1), POINTER :: m
TYPE(T1), ALLOCATABLE :: x
IF (ASSOCIATED(m) .AND. m%T) THEN ! { dg-warning "does not guard expression" }
WRITE(6,*) "X"
ENDIF
IF (ALLOCATED(x) .AND. x%T) THEN ! { dg-warning "does not guard expression" }
WRITE(6,*) ""
ENDIF
END SUBROUTINE
END MODULE
module x
logical :: flag = .true.
integer :: count = 0
contains
pure function f()
logical :: f
f = .true.
end function f
function g()
logical :: g
g = .false.
end function g
real function h()
h = 1.2
count = count + 1
end function h
end module x
program main
use x
print *, g() .and. f() ! No warning, because g() follows all the rules of a pure function
print *, f() .and. flag
print *, h() > 1.0 .and. flag ! { dg-warning "might not be evaluated" }
print *, h() < 1.0 .or. flag ! { dg-warning "might not be evaluated" }
end program main
! { dg-final { scan-tree-dump-times "flag &&" 2 "original" } }
! { dg-final { scan-tree-dump-times "flag \\|\\|" 1 "original" } }
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (Revision 261388)
+++ dump-parse-tree.c (Arbeitskopie)
@@ -716,6 +716,8 @@ show_attr (symbol_attribute *attr, const char * mo
fputs (" ELEMENTAL", dumpfile);
if (attr->pure)
fputs (" PURE", dumpfile);
+ if (attr->implicit_pure)
+fputs (" IMPLICIT_PURE", dumpfile);
if (attr->recursive)
fputs (" RECURSIVE", dumpfile);
Index: resolve.c
===
--- resolve.c (Revision 261388)
+++ resolve.c (Arbeitskopie)
@@ -3807,7 +3807,43 @@ lookup_uop_fuzzy (const char *op, gfc_symtree *uop
return gfc_closest_fuzzy_match (op, candidates);
}
+/* Callback finding an impure function as an operand to an .and. or
+ .or. expression. Remember the last function warned about to
+ avoid double warnings when recursing. */
+static int
+impure_function_callback (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data)
+{
+ gfc_expr *f = *e;
+ const char *name;
+ static gfc_expr *last = NULL;
+ bool *found = (bool *) data;
+
+ if (f->expr_type == EXPR_FUNCTION)
+{
+ *found = 1;
+ if (f != last && !pure_function (f, ))
+ {
+ /* This could still be a function without side effects, i.e.
+ implicit pure. Do not warn for that case. */
+ if (f->symtree == NULL || f->symtree->n.sym == NULL
+ || !gfc_implicit_pure (f->symtree->n.sym))
+ {
+ if (name)
+ gfc_warning (OPT_Wsurprising, "Function %qs at %L "
+ "might not be evaluated", name, >where);
+ else
+ gfc_warning (OPT_Wsurprising, "Function at %L "
+ "might not be evaluated", >where);
+ }
+ }
+ last = f;
+}
+
+ return 0;
+}
+
/* Resolve an operator expression node. This can involve replacing the
operation with a user defined function call. */
@@ -3910,6 +3946,8 @@ resolve_operator (gfc_expr *e)
case INTRINSIC_NEQV:
if (op1->ts.type == BT_LOGICAL && op2->ts.type == BT_LOGICAL)
{
+ bool dont_move = false;
+
e->ts.type = BT_LOGICAL;
e->ts.kind = gfc_kind_max (op1, op2);
if (op1->ts.kind < e->ts.kind)
@@ -3916,6 +3954,67 @@ resolve_operator (gfc_expr *e)
gfc_convert_type (op1, >ts, 2);
else if (op2->ts.kind < e->ts.kind)
gfc_convert_type (op2, >ts, 2);
+
+ if (e->value.op.op == INTRINSIC_AND || e->value.op.op == INTRINSIC_OR)
+ {
+ bool op1_f, op2_f;
+
+ op1_f = false;
+ op2_f = false;
+ gfc_expr_walker (, impure_function_callback, _f);
+ gfc_expr_walker (, impure_function_callback, _f);
+
+ /* Some people code which depends on the short-circuiting that
+ Fortran does not provide, such as
+
+ if (associated(m) .and.
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl : >On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote: >> >> >> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl >: >> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: >> >> >> >> >> >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl >> >: >> >> >> But at least for pure functions, this optimization looks Ok. >> >> >> >> >> > >> >> >Why is everyone fixated on PURE vs IMPURE functions? >> >> >> >> Simply because it makes a difference in this context! >> > >> >It does not! A function marked as PURE by a programmer >> >must meet certain requirement of the Fortran standard. >> >An unmarked function or a function marked as IMPURE can >> >still meet those same requirements. Marking something as >> >IMPURE has only a single requirement in the standard. >> > >> > An impure elemental procedure processes array arguments >> > in array element order. >> > >> >That's it. Marking a function as IMPURE does not mean >> >the function has side effects. It does not mean that >> >a function must be evaluated for each reference. Are >> >you advocating that gfortran must evaluate ping() >> >twice for >> > >> > impure real function ping() >> > end function ping >> > >> > x = ping() + 0 * ping() >> > end >> >> Absolutely, sir. That's what I'm advocating. If someone >> deliberately declares a function as impure, he should be >> prepared to deal with the consequences. In general, though, >> one can wonder whether the compiler could not warn that >> the impure declaration is not necessary (or, in other words,i >> that the function would be better declared as pure). > >This is a different answer than what you gave in >the PR when I asked if you were special casing >.and. and .or. Possibly we're having a communication issue here. I don't quite understand what you mean by "special casing". >It is trivial to force the evaluation >of operands. I already posted the diff in the PR I know it's rather trivial to do this. Instead of using temporaries, as you propose, one could also use a proper middle-end operator, like BIT_AND_EXPR instead of TRUTH_AND_EXPR. The non-trivial part is obviously to find a consensus about what should be done. >> In any case, the example you're showing is probably not >> the most problematic one. I assume a much more frequent >> and critical case would be the one where people forget >> to mark a function that is effectively pure with the >> PURE attribute. > >See Fortran 2018, Note 10.28 (if I remember correctly). >That example explicitly involves .and., and it explicitly >states that a function need not be evaluate. It does >not sya "pure function". It says "function". You can stop throwing standard quotes. I do know what the standard says about this by now. Point is: It does not sound very reasonable to me and I agree with Janne that the standard's treatment of impure functions is somewhere between careless and insane. If the standard says it's ok to optimize out any kind of function, I would tend to take this less as an encouragement to compiler writers to absolutely do this under any circumstance, but rather as saying: "Those compiler people are smart enough. They can figure out where it makes sense all by themselves." I happen to hold the opinion that optimizing out a call to a pure function may be reasonable if it does not influence the result of an expression, but optimizing out an effectively impure function (i.e. one with side effects) is not a good idea at any time, since such an 'optimization' can drastically change the program flow and all numerical results of a piece of code. (Note the the standard does not require this kind of optimization either, and other popular compilers, like ifort, do not do it.) If we can find some kind of agreement that what I'm proposing is a reasonable thing to do, I will certainly be happy to provide a patch (however I will not be able to get to it before next weekend). Right now I feel like I'm running into various walls. Janne is basically the only one so far who expressed at least partial agreement with some of my notions, so I certainly don't feel very encouraged to even start working on a patch ... Cheers, Janus
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 01:00:14PM -0700, Steve Kargl wrote: > Untested. > > Index: trans-expr.c > === > --- trans-expr.c (revision 261674) > +++ trans-expr.c (working copy) > @@ -3429,6 +3429,10 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr) >gfc_conv_expr (, expr->value.op.op2); >gfc_add_block_to_block (>pre, ); > > + /* Force evaluation of op1 and op2 to prevent shorting-circuiting. */ > + lse.expr = gfc_evaluate_now (lse.expr); > + rse.expr = gfc_evaluate_noe (rse.expr); s/noe/now/ Or just use TRUTH_AND_EXPR/TRUTH_OR_EXPR instead of TRUTH_ANDIF_EXPR/TRUTH_ORIF_EXPR, the difference between those is exactly in short-circuiting. ANDIF/ORIF are for C/C++ &&/||, AND/OR are for C/C++ &/|. Jakub
[patch, fortran] PR25829 Asynchronous I/O (patch version 2.0)
Hey everyone,
Here is the next version of the async I/O patch. It adds the
documentation, renames the testcases, uses "gthr.h", follows the style
guidelines and has been regression tested cleanly.
As for adding additional flags, I think it would be better to follow
ifort to minimize complexity.
The benchmark (not for the test suite) should also run on systems with
small stack sizes.
I hope I forgot nothing.
Nicolas
2018-06-16 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* gfortran.texi: Add description of asynchronous I/O.
* trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables
as volatile.
* trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to
st_wait_async and change argument spec from ".X" to ".w".
(gfc_trans_wait): Pass ID argument via reference.
2018-06-16 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* gfortran.dg/f2003_inquire_1.f03: Add write statement.
* gfortran.dg/f2003_io_1.f03: Add wait statement.
2018-06-16 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* Makefile.am: Add async.c to gfor_io_src.
Add async.h to gfor_io_headers.
* Makefile.in: Regenerated.
* gfortran.map: Add _gfortran_st_wait_async.
* io/async.c: New file.
* io/async.h: New file.
* io/close.c: Include async.h.
(st_close): Call async_wait for an asynchronous unit.
* io/file_pos.c (st_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.
* io/inquire.c: Add handling for asynchronous PENDING
and ID arguments.
* io/io.h (st_parameter_dt): Add async bit.
(st_parameter_wait): Correct.
(gfc_unit): Add au pointer.
(st_wait_async): Add prototype.
(transfer_array_inner): Likewise.
(st_write_done_worker): Likewise.
* io/open.c: Include async.h.
(new_unit): Initialize asynchronous unit.
* io/transfer.c (async_opt): New struct.
(wrap_scalar_transfer): New function.
(transfer_integer): Call wrap_scalar_transfer to do the work.
(transfer_real): Likewise.
(transfer_real_write): Likewise.
(transfer_character): Likewise.
(transfer_character_wide): Likewise.
(transfer_complex): Likewise.
(transfer_array_inner): New function.
(transfer_array): Call transfer_array_inner.
(transfer_derived): Call wrap_scalar_transfer.
(data_transfer_init): Check for asynchronous I/O.
Perform a wait operation on any pending asynchronous I/O
if the data transfer is synchronous. Copy PDT and enqueue
thread for data transfer.
(st_read_done_worker): New function.
(st_read_done): Enqueue transfer or call st_read_done_worker.
(st_write_done_worker): New function.
(st_write_done): Enqueue transfer or call st_read_done_worker.
(st_wait): Document as no-op for compatibility reasons.
(st_wait_async): New function.
* io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK;
add NOTE where necessary.
(get_gfc_unit): Likewise.
(init_units): Likewise.
(close_unit_1): Likewise. Call async_close if asynchronous.
(close_unit): Use macros LOCK and UNLOCK.
(finish_last_advance_record): Likewise.
(newunit_alloc): Likewise.
* io/unix.c (find_file): Likewise.
(flush_all_units_1): Likewise.
(flush_all_units): Likewise.
* libgfortran.h (generate_error_common): Add prototype.
* runtime/error.c: Include io.h and async.h.
(generate_error_common): New function.
2018-06-16 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* testsuite/libgfomp.fortran/async_io_1.f90: New test.
* testsuite/libgfomp.fortran/async_io_2.f90: New test.
* testsuite/libgfomp.fortran/async_io_3.f90: New test.
program main
implicit none
integer, parameter :: n = 10**7
character(3), parameter :: yes = "yes"
real, dimension(:), allocatable :: a,b,c
allocate (a(n), b(n), c(n))
call random_number(a)
call random_number(b)
call random_number(c)
open (10, file="a.dat",asynchronous=yes)
open (20, file="b.dat",asynchronous=yes)
open (30, file="c.dat",asynchronous=yes)
write (10,*,asynchronous=yes) a
write (20,*,asynchronous=yes) b
write (30,*,asynchronous=yes) c
wait (10)
wait (20)
wait (30)
end program main
! { dg-do run }
! Check basic functionality of async I/O
program main
implicit none
integer:: i=1, j=2, k, l
real :: a, b, c, d
character(3), parameter:: yes="yes"
character(4) :: str
complex :: cc, dd
integer, dimension(4):: is = [0, 1, 2, 3]
integer, dimension(4):: res
character(10) :: inq
open (10, file='a.dat', asynchronous=yes)
cc = (1.5, 0.5)
inquire
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 12:43:08PM -0700, Steve Kargl wrote:
>
> This is a different answer than what you gave in
> the PR when I asked if you were special casing
> .and. and .or. It is trivial to force the evaluation
> of operands. I already posted the diff in the PR
> where I special cased .and. and .or.
>
> op1 .op. op2
>
> needs to be converted to
>
> tmp1 = op1
> tmp2 = op2
> x = tmp1 .op. tmp
>
> for all binary operators.
>
Untested.
Index: trans-expr.c
===
--- trans-expr.c(revision 261674)
+++ trans-expr.c(working copy)
@@ -3429,6 +3429,10 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr)
gfc_conv_expr (, expr->value.op.op2);
gfc_add_block_to_block (>pre, );
+ /* Force evaluation of op1 and op2 to prevent shorting-circuiting. */
+ lse.expr = gfc_evaluate_now (lse.expr);
+ rse.expr = gfc_evaluate_noe (rse.expr);
+
if (checkstring)
{
gfc_conv_string_parameter ();
--
Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote: > > > Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl > : > >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > >> > >> > >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > >: > >> >> But at least for pure functions, this optimization looks Ok. > >> >> > >> > > >> >Why is everyone fixated on PURE vs IMPURE functions? > >> > >> Simply because it makes a difference in this context! > > > >It does not! A function marked as PURE by a programmer > >must meet certain requirement of the Fortran standard. > >An unmarked function or a function marked as IMPURE can > >still meet those same requirements. Marking something as > >IMPURE has only a single requirement in the standard. > > > > An impure elemental procedure processes array arguments > > in array element order. > > > >That's it. Marking a function as IMPURE does not mean > >the function has side effects. It does not mean that > >a function must be evaluated for each reference. Are > >you advocating that gfortran must evaluate ping() > >twice for > > > > impure real function ping() > > end function ping > > > > x = ping() + 0 * ping() > > end > > Absolutely, sir. That's what I'm advocating. If someone > deliberately declares a function as impure, he should be > prepared to deal with the consequences. In general, though, > one can wonder whether the compiler could not warn that > the impure declaration is not necessary (or, in other words,i > that the function would be better declared as pure). This is a different answer than what you gave in the PR when I asked if you were special casing .and. and .or. It is trivial to force the evaluation of operands. I already posted the diff in the PR where I special cased .and. and .or. op1 .op. op2 needs to be converted to tmp1 = op1 tmp2 = op2 x = tmp1 .op. tmp for all binary operators. > In any case, the example you're showing is probably not > the most problematic one. I assume a much more frequent > and critical case would be the one where people forget > to mark a function that is effectively pure with the > PURE attribute. See Fortran 2018, Note 10.28 (if I remember correctly). That example explicitly involves .and., and it explicitly states that a function need not be evaluate. It does not sya "pure function". It says "function". -- Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl : >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: >> >> >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl >: >> >> But at least for pure functions, this optimization looks Ok. >> >> >> > >> >Why is everyone fixated on PURE vs IMPURE functions? >> >> Simply because it makes a difference in this context! > >It does not! A function marked as PURE by a programmer >must meet certain requirement of the Fortran standard. >An unmarked function or a function marked as IMPURE can >still meet those same requirements. Marking something as >IMPURE has only a single requirement in the standard. > > An impure elemental procedure processes array arguments > in array element order. > >That's it. Marking a function as IMPURE does not mean >the function has side effects. It does not mean that >a function must be evaluated for each reference. Are >you advocating that gfortran must evaluate ping() >twice for > > impure real function ping() > end function ping > > x = ping() + 0 * ping() > end Absolutely, sir. That's what I'm advocating. If someone deliberately declares a function as impure, he should be prepared to deal with the consequences. In general, though, one can wonder whether the compiler could not warn that the impure declaration is not necessary (or, in other words, that the function would be better declared as pure). In any case, the example you're showing is probably not the most problematic one. I assume a much more frequent and critical case would be the one where people forget to mark a function that is effectively pure with the PURE attribute. However, IIUC, gfortran has the ability to detect that a function meets all pureness requirements and mark it as implicit_pure, so that it can be treated like a pure procedure, even without any explicit PURE declaration by the programmer. If that's the case, the scheme I proposed should not even have any major performance penalty, since the pureness of a function without explicit pure/impure declaration can be automatically detected, and appropriate optimizations can be chosen. Therefore the most reasonable strategy I can see is still to apply short-circuiting only to pure functions (explicit or implicit) and avoid it for impure ones. Cheers, Janus
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 06:56:49PM +0100, graham stott wrote: > if i read this correctly it appears that IMPURE/PURE are not the normal > pure attribute used by gcc but some entirely diff attribute specific to > FORTAN so people are taking about different things > PURE and IMPURE are prefix-spec in Fortran. A Subprogram that is marked as PURE must meet additional requirements. Those requirements essentially eliminate the possibility of a function having side effects. A subprogram marked as IMPURE can also meet those additional requirements. BTW, the name of the language is Fortran (not FORTRAN). It's been Fortran for more than 27 years. -- Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
if i read this correctly it appears that IMPURE/PURE are not the normal pure attribute used by gcc but some entirely diff attribute specific to FORTANso people are taking about different things Original message From: Steve Kargl Date: 16/06/2018 17:38 (GMT+00:00) To: Janus Weil Cc: Janne Blomqvist , Thomas Koenig , fort...@gcc.gnu.org, gcc-patches Subject: Re: [patch, fortran] Handling of .and. and .or. expressions On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > > > Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > : > >> But at least for pure functions, this optimization looks Ok. > >> > > > >Why is everyone fixated on PURE vs IMPURE functions? > > Simply because it makes a difference in this context! It does not! A function marked as PURE by a programmer must meet certain requirement of the Fortran standard. An unmarked function or a function marked as IMPURE can still meet those same requirements. Marking something as IMPURE has only a single requirement in the standard. An impure elemental procedure processes array arguments in array element order. That's it. Marking a function as IMPURE does not mean the function has side effects. It does not mean that a function must be evaluated for each reference. Are you advocating that gfortran must evaluate ping() twice for impure real function ping() end function ping x = ping() + 0 * ping() end -- Steve
Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote: > > > Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl > : > >> But at least for pure functions, this optimization looks Ok. > >> > > > >Why is everyone fixated on PURE vs IMPURE functions? > > Simply because it makes a difference in this context! It does not! A function marked as PURE by a programmer must meet certain requirement of the Fortran standard. An unmarked function or a function marked as IMPURE can still meet those same requirements. Marking something as IMPURE has only a single requirement in the standard. An impure elemental procedure processes array arguments in array element order. That's it. Marking a function as IMPURE does not mean the function has side effects. It does not mean that a function must be evaluated for each reference. Are you advocating that gfortran must evaluate ping() twice for impure real function ping() end function ping x = ping() + 0 * ping() end -- Steve
Re: [PATCH] Use __builtin_memmove for trivially copy assignable types
On Sat, 16 Jun 2018, Glen Fernandes wrote: Use __builtin_memmove for trivially copy assignable types 2018-06-14 Glen Joseph Fernandes * include/bits/stl_algobase.h (__is_simple_copy_move): Defined helper. (__copy_move_a): Used helper. (__copy_move_backward_a): Likewise. * testsuite/25_algorithms/copy/58982.cc: Updated tests. * testsuite/25_algorithms/copy_n/58982.cc: Likewise. Tested x86_64-pc-linux-gnu. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 looks related but for a different function. Hopefully the issues discussed there don't apply here... -- Marc Glisse
Re: [PATCH] Use __builtin_memmove for trivially copy assignable types
On Sat, 16 Jun 2018 at 07:01, Glen Fernandes wrote: > Use __builtin_memmove for trivially copy assignable types > I'll review the patch later, just a quick comment for now. Every use of memcpy, memmove etc. makes it harder to make everything in constexpr (as we're now required to do). But that's an existing problem, and probably needs to be solved by teaching the built-ins to expand inside constant expression evaluation.
Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows
On Sat, 16 Jun 2018 at 02:04, Sandra Loosemore wrote: > On 05/31/2018 01:19 PM, Jonathan Wakely wrote: > > This adds incomplete but functional support for std::filesystem and > > std::experimental::filesystem on MinGW. In theory there should be no > > changes to the existing behaviour for POSIX targets from this patch, > > as all the various bugs I found while working on this have already > > been fixed in separate patches. > > > > Tested powerpc64le-linux, and x86_64-w64-mingw32 (with a few expected > > FAILures on mingw-w64). Committed to trunk. > > As noted in the issue (comment #16) 2 weeks ago already, this patch > breaks libstdc++ configure on bare-metal targets. > > configure:80055: checking for link > configure:80055: error: Link tests are not allowed after > GCC_NO_EXECUTABLES. > > Please fix? It's blocking other people from testing unrelated patches > on mainline. > > I'm not the only person able to make changes to autoconf files (and already said I didn't know how to fix this). I have a patch to replace the AC_CHECK_FUNCS line with GLIBCXX_COMPILE_OR_LINK tests inside GLIBCXX_CHECK_FILESYSTEM_DEPS which should work, I'll finish testing it when I get home this evening. > -Sandra >
Re: [PATCH] Add checking that during RTL bbs don't mix EH and non-complex predecessor edges
> Now committed after successful bootstrap/regtest on x86_64-linux and > i686-linux. Is the cfgrtl.c change ok for trunk too? > http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00967.html Don't we actually need to verify that all incoming edges are EH or none is? -- Eric Botcazou
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 16.06.2018 um 12:53 schrieb Janus Weil: Yes. Back when I followed c.l.f, several experts did advise people to never use functions unless they were pure (or more or less effectively so, if they didn't fulfill the standard requirements for purity). Considering that at least some of those same experts were also part of the Fortran standards committee, I just find it very strange that, to the best of my knowledge, no effort to fix this has been done. That is a bit distorted, at least from what I remember. The advice was rather "If you use functions with side effects, you may have problems". Something quite different. Very strange indeed. If someone tells me "don't use functions in Fortran", then what I hear is "don't use Fortran, it's broken". Well, nobody did, to the best of my knowledge (and I followed the same discussions).
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl : >> But at least for pure functions, this optimization looks Ok. >> > >Why is everyone fixated on PURE vs IMPURE functions? Simply because it makes a difference in this context! That the Fortran standard does not acknowledge this fact is more than surprising to me, given that Fortran actually has a way to mark functions as pure/impure. Not all languages have that. What's the use of a PURE keyword, if not to indicate to the compiler that certain optimizations can safely be done? Cheers, Janus
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 15. Juni 2018 19:49:42 MESZ schrieb Janne Blomqvist : >On Fri, Jun 15, 2018 at 12:22 PM, Janus Weil wrote: > >> Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist < >> blomqvist.ja...@gmail.com>: >> In Fortran, it still feels like functions as such are second-class >> citizens. People seriously advise against using them. Doesn't really >help >> the attractivity of the language. > > >Yes. Back when I followed c.l.f, several experts did advise people to >never >use functions unless they were pure (or more or less effectively so, if >they didn't fulfill the standard requirements for purity). Considering >that >at least some of those same experts were also part of the Fortran >standards >committee, I just find it very strange that, to the best of my >knowledge, >no effort to fix this has been done. Very strange indeed. If someone tells me "don't use functions in Fortran", then what I hear is "don't use Fortran, it's broken". Why would you introduce a language feature that is not meant to be used? >IMHO it is completely insane to optimize out impure functions, just for >a >> little bit of speedup, but sacrificing compiler-independent results. >> >> I really don't understand why I'm so alone here with this opinion. >> > >I would agree with you if there were some substantial majority opinion >among Fortran programmers that all the parts of a logical expression >are >always evaluated Look, in principle I don't really care how many parts of an expression are evaluated. If the compiler can prove that a certain part of the expression can not change the end result and has no side effects, great, please optimize it away. If the compiler can not prove that, the expression should not be altered. An 'optimization' that changes results is just not useful. It's broken. Cheers, Janus
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 15. Juni 2018 19:10:01 MESZ schrieb Thomas Koenig : >Am 14.06.2018 um 10:38 schrieb Janus Weil: >>> Also, there are AFAIU other similar weirdness with impure functions. >>> The >>> standard allows a compiler to optimize >>> >>> y = f(x) + f(x) >>> >>> into >>> >>> y = 2 * f(x) >>> >>> even if f is impure, which is totally bonkers. Or even not call f at >>> all, >>> if the compiler determines that y is not needed. >> Yes, that is the same kind of craziness. I hope gfortran does not >actually do this? > >I would vote for this, but currently it is not done unless >-faggressive-function-elimination is specified. How about putting the short-circuiting of logical expressions with impure functions under the same flag? >By the way, there is a bit of strangeness about this. People use -Ofast >knowing it will break all sorts of standards for numercial computation Things are a bit different with -Ofast and -ffast-math. They are not enabled by default, their effects are mentioned in the documentation, and they usually don't change the results totally. Short-circuiting is being done by default, is not properly documented and can potentially have a huge impact on results (an impure function that is optimized away can totally alter the program flow and all numerical results). >but they balk at using an optimization that is explicitly permitted >by the standard. The standard allowing it is really not any consolation, if my results are changed by this 'optimization' and I don't have any guarantee that different compilers do the same thing with my code. That's simply a bad idea, no matter how many official approval stamps it gets. Cheers, Janus
Re: [PATCH] Add checking that during RTL bbs don't mix EH and non-complex predecessor edges
On Fri, Jun 15, 2018 at 11:33:10PM +0200, Eric Botcazou wrote: > > So like this (if it passes another bootstrap/regtest together with the > > cfgrtl.c change)? It fixes the testcase too. > > > > 2018-06-15 Jakub Jelinek > > > > PR rtl-optimization/86108 > > * bb-reorder.c (create_forwarder_block): Renamed to ... > > (create_eh_forwarder_block): ... this. Split OLD_BB after labels and > > jump from new landing pad to the second part. > > (sjlj_fix_up_crossing_landing_pad, dw2_fix_up_crossing_landing_pad): > > Adjust callers. > > OK, thanks. I'll build the Ada compiler on x86/Windows once this is in. Now committed after successful bootstrap/regtest on x86_64-linux and i686-linux. Is the cfgrtl.c change ok for trunk too? http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00967.html Jakub
Re: [PATCH] Remove -Wunsafe-loop-optimizations option (PR middle-end/86095)
On June 15, 2018 9:08:05 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, all traces of this warning option except these
>were removed earlier, so the warning option does nothing.
>
>The following patch removes its documentation and makes it clear it
>does
>nothing. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
>trunk/8.2?
OK.
Richard.
>2018-06-15 Jakub Jelinek
>
> PR middle-end/86095
> * common.opt (Wunsafe-loop-optimizations): Add Ignore, remove Var,
> documented as preserved for backward compatibility only.
> * doc/invoke.texi: Remove -Wunsafe-loop-optimizations documentation.
>
>--- gcc/common.opt.jj 2018-06-14 13:14:52.124948298 +0200
>+++ gcc/common.opt 2018-06-15 14:29:53.824162546 +0200
>@@ -646,8 +646,8 @@ Common Var(warn_null_dereference) Warnin
>Warn if dereferencing a NULL pointer may lead to erroneous or undefined
>behavior.
>
> Wunsafe-loop-optimizations
>-Common Var(warn_unsafe_loop_optimizations) Warning
>-Warn if the loop cannot be optimized due to nontrivial assumptions.
>+Common Ignore Warning
>+Does nothing. Preserved for backward compatibility.
>
> Wmissing-noreturn
> Common Warning Alias(Wsuggest-attribute=noreturn)
>--- gcc/doc/invoke.texi.jj 2018-06-14 13:14:49.122945691 +0200
>+++ gcc/doc/invoke.texi2018-06-15 14:30:22.102188482 +0200
>@@ -323,7 +323,7 @@ Objective-C and Objective-C++ Dialects}.
> -Wswitch-unreachable -Wsync-nand @gol
>-Wsystem-headers -Wtautological-compare -Wtrampolines -Wtrigraphs
>@gol
> -Wtype-limits -Wundef @gol
>--Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations @gol
>+-Wuninitialized -Wunknown-pragmas @gol
> -Wunsuffixed-float-constants -Wunused -Wunused-function @gol
> -Wunused-label -Wunused-local-typedefs -Wunused-macros @gol
> -Wunused-parameter -Wno-unused-result @gol
>@@ -6000,14 +6000,6 @@ If the stack usage is (partly) dynamic a
> @end smallexample
> @end itemize
>
>-@item -Wunsafe-loop-optimizations
>-@opindex Wunsafe-loop-optimizations
>-@opindex Wno-unsafe-loop-optimizations
>-Warn if the loop cannot be optimized because the compiler cannot
>-assume anything on the bounds of the loop indices. With
>-@option{-funsafe-loop-optimizations} warn if the compiler makes
>-such assumptions.
>-
> @item -Wno-pedantic-ms-format @r{(MinGW targets only)}
> @opindex Wno-pedantic-ms-format
> @opindex Wpedantic-ms-format
>
> Jakub
C++ PATCH for c++/86147, wrong capture for template argument
In this testcase, N is only used in the lambda for its constant value,
so it should not be captured. The problem was that we didn't call
mark_rvalue_use on N when instantiating the lambda, because it was
wrapped in a NOP_EXPR converting it to the type of the template
argument. Rather than try to add mark_rvalue_use everywhere that
calls build_nop, let's make mark_rvalue_use look through all NOP_EXPR,
not just location wrappers.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit 6f0db97dbb4a43a69bc4ea4c32960cbd77b104a0
Author: Jason Merrill
Date: Fri Jun 15 17:05:39 2018 -0400
PR c++/86147 - wrong capture for template argument.
* expr.c (mark_use): Look through NOP_EXPR.
diff --git a/gcc/cp/expr.c b/gcc/cp/expr.c
index 9780b75d1cd..133a01b8a51 100644
--- a/gcc/cp/expr.c
+++ b/gcc/cp/expr.c
@@ -186,12 +186,15 @@ mark_use (tree expr, bool rvalue_p, bool read_p,
expr = convert_from_reference (r);
}
break;
-default:
+
+CASE_CONVERT:
+case VIEW_CONVERT_EXPR:
if (location_wrapper_p (expr))
- {
- loc = EXPR_LOCATION (expr);
- recurse_op[0] = true;
- }
+ loc = EXPR_LOCATION (expr);
+ recurse_op[0] = true;
+ break;
+
+default:
break;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
new file mode 100644
index 000..0724ae15d88
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
@@ -0,0 +1,17 @@
+// PR c++/86147
+// { dg-do compile { target c++11 } }
+
+template struct X { };
+
+struct A { static constexpr int value = 0; };
+
+template
+void foo() {
+constexpr int N = C::value;
+auto f = [&]{ X a; };
+}
+
+int main() {
+foo();
+return 0;
+}
[PATCH] Use __builtin_memmove for trivially copy assignable types
Use __builtin_memmove for trivially copy assignable types
2018-06-14 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__is_simple_copy_move): Defined helper.
(__copy_move_a): Used helper.
(__copy_move_backward_a): Likewise.
* testsuite/25_algorithms/copy/58982.cc: Updated tests.
* testsuite/25_algorithms/copy_n/58982.cc: Likewise.
Tested x86_64-pc-linux-gnu.
Glen
commit 7ace2ad91fe7d2253b086aef8bfdb99f85d81f31
Author: Glen Fernandes
Date: Fri Jun 15 07:33:07 2018 -0400
Use __builtin_memmove for trivially copy assignable types
2018-06-14 Glen Joseph Fernandes
* include/bits/stl_algobase.h
(__is_simple_copy_move): Defined helper.
(__copy_move_a): Used helper.
(__copy_move_backward_a): Likewise.
* testsuite/25_algorithms/copy/58982.cc: Updated tests.
* testsuite/25_algorithms/copy_n/58982.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/stl_algobase.h
b/libstdc++-v3/include/bits/stl_algobase.h
index 022a3f159..d9e1a7958 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -72,10 +72,20 @@
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+ template
+struct __is_simple_copy_move
+{
+#if __cplusplus < 201103L
+ enum { __value = __is_trivial(_Tp) };
+#else
+ enum { __value = is_trivially_copy_assignable<_Tp>::value };
+#endif
+};
+
#if __cplusplus < 201103L
// See http://gcc.gnu.org/ml/libstdc++/2004-08/msg00167.html: in a
// nutshell, we are partially implementing the resolution of DR 187,
// when it's safe, i.e., the value_types are equal.
template
@@ -375,11 +385,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__copy_move_a(_II __first, _II __last, _OI __result)
{
typedef typename iterator_traits<_II>::value_type _ValueTypeI;
typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
typedef typename iterator_traits<_II>::iterator_category _Category;
- const bool __simple = (__is_trivial(_ValueTypeI)
+ const bool __simple = (__is_simple_copy_move<_ValueTypeI>::__value
&& __is_pointer<_II>::__value
&& __is_pointer<_OI>::__value
&& __are_same<_ValueTypeI, _ValueTypeO>::__value);
return std::__copy_move<_IsMove, __simple,
@@ -576,11 +586,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__copy_move_backward_a(_BI1 __first, _BI1 __last, _BI2 __result)
{
typedef typename iterator_traits<_BI1>::value_type _ValueType1;
typedef typename iterator_traits<_BI2>::value_type _ValueType2;
typedef typename iterator_traits<_BI1>::iterator_category _Category;
- const bool __simple = (__is_trivial(_ValueType1)
+ const bool __simple = (__is_simple_copy_move<_ValueType1>::__value
&& __is_pointer<_BI1>::__value
&& __is_pointer<_BI2>::__value
&& __are_same<_ValueType1, _ValueType2>::__value);
return std::__copy_move_backward<_IsMove, __simple,
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy/58982.cc
b/libstdc++-v3/testsuite/25_algorithms/copy/58982.cc
index 03d918344..324f0e3b5 100644
--- a/libstdc++-v3/testsuite/25_algorithms/copy/58982.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/copy/58982.cc
@@ -36,6 +36,6 @@ void
test01(T* result)
{
T t[1];
std::copy(t, t+1, result); // { dg-error "here" }
}
-// { dg-prune-output "not assignable" }
+// { dg-prune-output "use of deleted function" }
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy_n/58982.cc
b/libstdc++-v3/testsuite/25_algorithms/copy_n/58982.cc
index dc488cd1f..3eb793218 100644
--- a/libstdc++-v3/testsuite/25_algorithms/copy_n/58982.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/copy_n/58982.cc
@@ -36,6 +36,6 @@ void
test01(T* result)
{
T t[1];
std::copy_n(t, 1, result); // { dg-error "here" }
}
-// { dg-prune-output "not assignable" }
+// { dg-prune-output "use of deleted function" }
