[patch, libfortran, committed] Suppress -Wstringop-overflow warning

[Thomas Koenig via Gcc-patches]

Hi,

I just committed as obvious the patch below.

Disable -Wstringop-overflow warning after checking code path of caller.

The warning that is disabled, only on this single line, has been
inspected and found to be not applicable; it is known that the size
of the buffer is safe.

libgfortran/ChangeLog:

2020-06-13  Thomas Koenig  

PR libfortran/95313
* io/write.c (ztoa_big): Disable -Wstringop-overflow for one
line.
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 9f02683a25c..346615ed597 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1178,7 +1178,15 @@ ztoa_big (const char *s, char *buffer, int len, GFC_UINTEGER_LARGEST *n)
 	}
 }
 
+  /* write_z, which calls ztoa_big, is called from transfer.c,
+ formatted_transfer_scalar_write.  There it is passed the kind as
+ argument, which means a maximum of 16.  The buffer is large
+ enough, but the compiler does not know that, so shut up the
+ warning here.  */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
   *q = '\0';
+#pragma GCC diagnostic pop
 
   if (*n == 0)
 return "0";

[patch, libfortran, committed]

[Thomas Koenig via Gcc-patches]

Hi,

I just committed as obvious a patch which fixed a hang on close
with -pthread after a previous error on close with an invalid
STATUS.  The solution was obvious: Return early if an error
occurred.

I also managed to make some double ChangeLog entries (fixed with the
next commit after), but hey - git doing strange and unforseen stuff
is par for the course.  My life has gotten a lot easier since I stopped
worrying about that kind of stuff.

I will also backport to the other affected branches.

Regards

Thomas

Add early return for invalid STATUS for close.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* io/close.c (close_status): Add CLOSE_INVALID.
(st_close): Return early on invalid STATUS parameter.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* testsuite/libgomp.fortran/close_errors_1.f90: New test.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index 8aaa00393e7..17e064ba4e8 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -31,7 +31,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #endif
 
 typedef enum
-{ CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
+{ CLOSE_INVALID = - 1, CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
 close_status;
 
 static const st_option status_opt[] = {
@@ -61,6 +61,12 @@ st_close (st_parameter_close *clp)
 find_option (>common, clp->status, clp->status_len,
 		 status_opt, "Bad STATUS parameter in CLOSE statement");
 
+  if (status == CLOSE_INVALID)
+{
+  library_end ();
+  return;
+}
+
   u = find_unit (clp->common.unit);
 
   if (ASYNC_IO && u && u->au)
diff --git a/libgomp/testsuite/libgomp.fortran/close_errors_1.f90 b/libgomp/testsuite/libgomp.fortran/close_errors_1.f90
new file mode 100644
index 000..6edb7da4116
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/close_errors_1.f90
@@ -0,0 +1,19 @@
+! { dg-do run }
+! PR 95115 - this used to hang with -pthread.  Original test case by
+! Bill Long.
+
+program test
+  character(len=16) my_status
+  character(len=1000) :: iomsg
+  open (unit=10, file='test.dat')
+  print *,42
+  write (10, *) 'weird'
+  rewind (10)
+  read (10, *) my_status
+  close (10)
+  open (unit=10, file='test.dat')
+  close (unit=10, status=my_status, iostat=ios, iomsg=iomsg)
+  if (ios == 0) stop 1
+  if (iomsg /= "Bad STATUS parameter in CLOSE statement") stop 2
+  close (10, status='delete')
+end program test

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Martin Jambor]

Hi,

On Thu, Apr 19 2018, Thomas Schwinge wrote:
>
> Per PR85463 '[nvptx] "exit" in offloaded region doesn't terminate
> process' that I just filed, we currently have to use "abort" instead of
> "exit" for nvptx offloading, so I have applied the following in trunk
> r259491, where I completed this by adding and testing stop_string,
> error_stop_string, and error_stop_numeric functions, too.
>
> commit 6bc09e4fa2e5e59dee18f1c03f2d6529b9b0045b
> Author: tschwinge 
> Date:   Thu Apr 19 08:53:38 2018 +
>
> PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process'
> 
> libgomp/
> PR libfortran/85166
> * testsuite/libgomp.oacc-fortran/abort-1.f90: Switch back to "call
> abort".
> * testsuite/libgomp.oacc-fortran/abort-2.f90: Likewise.
> 
> libgfortran/
> PR libfortran/85166
> PR libgomp/85463
> * runtime/minimal.c (stop_numeric): Reimplement.
> (stop_string, error_stop_string, error_stop_numeric): New
> functions.
> libgomp/
> PR libgomp/85463
> * testsuite/libgomp.oacc-fortran/error_stop-1.f: New file.
> * testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
> * testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
> * testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.
> 

The "output pattern test" part of all of these new testcases fail on my
HSA tester even though no HSAIL is generated for them, only host
fallback is used.  Looking at the first one:

> diff --git libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f 
> libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f
> new file mode 100644
> index 000..4965e67
> --- /dev/null
> +++ libgomp/testsuite/libgomp.oacc-fortran/error_stop-1.f
> @@ -0,0 +1,20 @@
> +! { dg-do run }
> +
> +  PROGRAM MAIN
> +  IMPLICIT NONE
> +
> +  PRINT *, "CheCKpOInT"
> +!$ACC PARALLEL
> +  ERROR STOP
> +!$ACC END PARALLEL
> +  PRINT *, "WrONg WAy"
> +
> +  END PROGRAM MAIN
> +
> +! { dg-output "CheCKpOInT(\n|\r\n|\r)+" }
> +! { dg-output "ERROR STOP (\n|\r\n|\r)+" }
> +! PR85463.  The "minimal" libgfortran implementation used with nvptx
> +! offloading is a little bit different.
> +! { dg-output "Error termination.*" { target { ! 
> openacc_nvidia_accel_selected } } }
> +! { dg-output "libgomp: cuStreamSynchronize error.*" { target 
> openacc_nvidia_accel_selected } }
> +! { dg-shouldfail "" }

I can tell that checking for "CheCKpOInT" passes but checking for "ERROR
STOP" and "Error termination" do not.  Running the test manually, they
both appear, but in standard error, not standard output (where
CheCKpOInT is printed).  I am not 100% sure whether that is the reason
why they fail but do we have a way of testing std error of the executed
compiled binary?

Thanks,

Martin

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Thomas Schwinge]

Hi!

On Thu, 19 Apr 2018 13:32:16 +0200, Thomas König  wrote:
> > Mapping exit to abort is weird,
> 
> For Fortran, this is mapping STOP with a numeric code to abort.
> 
> The Fortran standard does not apply in this case. What does the OpenACC
> standard say about STOP in an offloaded region?

Nothing explicitly, as far as I know.  ;-/ Which means, that this either
a) has to be forbidden, or b) some common sense implementation is called
for.  Well, implicitly it's meant such that "standard Fortran language
usage" is supported inside such offloading regions.  And, as code like:

!$ACC PARALLEL
[compute A]
if (.not. [sanity check computation A]) then
  stop 1
end if
[compute B, using A]
!$ACC END PARALLEL
[compute C, using A and B]

... certainly is a reasonable thing to support, option b) clearly is
preferrable over option a).  Before my patch, if "[sanity check
computation A]" failed, the offloading region would terminate normally,
without executing "[compute B, using A]", but would then erroneously
"[compute C, using A and B]" with bogus data, so mapping that offloading
region's "stop 1" to "abort" again is an improvement, to make the "sanity
check" error observable.


Grüße
 Thomas

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Thomas König]

> Mapping exit to abort is weird,

For Fortran, this is mapping STOP with a numeric code to abort.

The Fortran standard does not apply in this case. What does the OpenACC 
standard say about STOP in an offloaded region?

Regards, Thomas

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Thomas Schwinge]

Hi!

On Thu, 19 Apr 2018 11:25:30 +0200, Jakub Jelinek  wrote:
> On Thu, Apr 19, 2018 at 11:19:31AM +0200, Thomas Schwinge wrote:
> > On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek  wrote:
> > > On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > > > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König  
> > > > wrote:
> > > > > the recent patch to make the gfortran and libgomp testsuites more
> > > > > standard conforming, by replacing CALL ABORT() with STOP N, led
> > > > > to numerous testsuite failures on nvptx because stop_numeric
> > > > > was not implemented in minimal.c.
> > > > > 
> > > > > I have committed the patch below in r259072 as obvious after Tom
> > > > > de Vries had confirmed that it solves the problem.
> > > > 
> > > > ... for some meaning of "solves the problem"; see below.  ;-) Which you
> > > > couldn't know, of course.  (So, definitely thanks anyway, for promptly
> > > > addressing the issue raised!)
> > > 
> > > My preference would be just to revert the call abort to stop n changes
> > > in target regions.
> > 
> > That seems backwards to me -- having "exit" (as well as Fortran language
> > "stop" and "error stop") inside offloaded regions do the right thing is
> > something we wanted to do anyway, eventually.
> 
> I'm looking for a GCC8 fix, and for that it seems like the simplest
> and safest solution.

As far as I know, the "call abort to stop n" changes regressed nvptx
targets only, and that's now fixed (and improved to handle more Fortran
language "stop" and "error stop" variants), so I don't see a reason to
iterate once again?  (Or, why didn't you then already dispute Thomas
König's nvptx/libgfortran minimal.c patch adding stop_numeric?)


> > > Mapping exit to abort is weird
> > 
> > Sure, that's why PR85463 is still open, and has some (initial)
> > comments/ideas regarding that.
> > 
> > > and making exit terminate whole process even
> > > when called from offloaded regions might be too expensive.
> > 
> > In what way "too expensive"?
> 
> If you need to add code to handle that case to every target region entry
> just in case something does stop, the slow down might be too high and
> unacceptable.  Depends on how it is implemented.

Right, but that's again "why PR85463 is still open, and has some
(initial) comments/ideas regarding that", and no overhead has so far been
introduced.


Grüße
 Thomas

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Jakub Jelinek]

On Thu, Apr 19, 2018 at 11:19:31AM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek  wrote:
> > On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König  wrote:
> > > > the recent patch to make the gfortran and libgomp testsuites more
> > > > standard conforming, by replacing CALL ABORT() with STOP N, led
> > > > to numerous testsuite failures on nvptx because stop_numeric
> > > > was not implemented in minimal.c.
> > > > 
> > > > I have committed the patch below in r259072 as obvious after Tom
> > > > de Vries had confirmed that it solves the problem.
> > > 
> > > ... for some meaning of "solves the problem"; see below.  ;-) Which you
> > > couldn't know, of course.  (So, definitely thanks anyway, for promptly
> > > addressing the issue raised!)
> > 
> > My preference would be just to revert the call abort to stop n changes
> > in target regions.
> 
> That seems backwards to me -- having "exit" (as well as Fortran language
> "stop" and "error stop") inside offloaded regions do the right thing is
> something we wanted to do anyway, eventually.

I'm looking for a GCC8 fix, and for that it seems like the simplest
and safest solution.

> > Mapping exit to abort is weird
> 
> Sure, that's why PR85463 is still open, and has some (initial)
> comments/ideas regarding that.
> 
> > and making exit terminate whole process even
> > when called from offloaded regions might be too expensive.
> 
> In what way "too expensive"?

If you need to add code to handle that case to every target region entry
just in case something does stop, the slow down might be too high and
unacceptable.  Depends on how it is implemented.

Jakub

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Thomas Schwinge]

Hi!

On Thu, 19 Apr 2018 11:14:38 +0200, Jakub Jelinek  wrote:
> On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> > On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König  wrote:
> > > the recent patch to make the gfortran and libgomp testsuites more
> > > standard conforming, by replacing CALL ABORT() with STOP N, led
> > > to numerous testsuite failures on nvptx because stop_numeric
> > > was not implemented in minimal.c.
> > > 
> > > I have committed the patch below in r259072 as obvious after Tom
> > > de Vries had confirmed that it solves the problem.
> > 
> > ... for some meaning of "solves the problem"; see below.  ;-) Which you
> > couldn't know, of course.  (So, definitely thanks anyway, for promptly
> > addressing the issue raised!)
> 
> My preference would be just to revert the call abort to stop n changes
> in target regions.

That seems backwards to me -- having "exit" (as well as Fortran language
"stop" and "error stop") inside offloaded regions do the right thing is
something we wanted to do anyway, eventually.

> Mapping exit to abort is weird

Sure, that's why PR85463 is still open, and has some (initial)
comments/ideas regarding that.

> and making exit terminate whole process even
> when called from offloaded regions might be too expensive.

In what way "too expensive"?


Grüße
 Thomas

Re: PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Jakub Jelinek]

On Thu, Apr 19, 2018 at 11:06:18AM +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König  wrote:
> > the recent patch to make the gfortran and libgomp testsuites more
> > standard conforming, by replacing CALL ABORT() with STOP N, led
> > to numerous testsuite failures on nvptx because stop_numeric
> > was not implemented in minimal.c.
> > 
> > I have committed the patch below in r259072 as obvious after Tom
> > de Vries had confirmed that it solves the problem.
> 
> ... for some meaning of "solves the problem"; see below.  ;-) Which you
> couldn't know, of course.  (So, definitely thanks anyway, for promptly
> addressing the issue raised!)

My preference would be just to revert the call abort to stop n changes
in target regions.
Mapping exit to abort is weird, and making exit terminate whole process even
when called from offloaded regions might be too expensive.

Jakub

PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process' (was: [patch, libfortran, committed] Implement stop_numeric for minimal targets)

[Thomas Schwinge]

Hi!

On Wed, 4 Apr 2018 11:30:34 +0200, Thomas König  wrote:
> the recent patch to make the gfortran and libgomp testsuites more
> standard conforming, by replacing CALL ABORT() with STOP N, led
> to numerous testsuite failures on nvptx because stop_numeric
> was not implemented in minimal.c.
> 
> I have committed the patch below in r259072 as obvious after Tom
> de Vries had confirmed that it solves the problem.

... for some meaning of "solves the problem"; see below.  ;-) Which you
couldn't know, of course.  (So, definitely thanks anyway, for promptly
addressing the issue raised!)

> --- runtime/minimal.c (Revision 259055)
> +++ runtime/minimal.c (Arbeitskopie)

> +void
> +stop_numeric (int code, bool quiet)
> +{
> +  if (!quiet)
> +printf ("STOP %d\n", code);
> +
> +  exit (code);
> +}

Per PR85463 '[nvptx] "exit" in offloaded region doesn't terminate
process' that I just filed, we currently have to use "abort" instead of
"exit" for nvptx offloading, so I have applied the following in trunk
r259491, where I completed this by adding and testing stop_string,
error_stop_string, and error_stop_numeric functions, too.

commit 6bc09e4fa2e5e59dee18f1c03f2d6529b9b0045b
Author: tschwinge 
Date:   Thu Apr 19 08:53:38 2018 +

PR85463 '[nvptx] "exit" in offloaded region doesn't terminate process'

libgomp/
PR libfortran/85166
* testsuite/libgomp.oacc-fortran/abort-1.f90: Switch back to "call
abort".
* testsuite/libgomp.oacc-fortran/abort-2.f90: Likewise.

libgfortran/
PR libfortran/85166
PR libgomp/85463
* runtime/minimal.c (stop_numeric): Reimplement.
(stop_string, error_stop_string, error_stop_numeric): New
functions.
libgomp/
PR libgomp/85463
* testsuite/libgomp.oacc-fortran/error_stop-1.f: New file.
* testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
* testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
* testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259491 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgfortran/ChangeLog  |  8 +++
 libgfortran/runtime/minimal.c  | 80 +-
 libgomp/ChangeLog  | 15 
 libgomp/testsuite/libgomp.oacc-fortran/abort-1.f90 |  5 +-
 libgomp/testsuite/libgomp.oacc-fortran/abort-2.f90 |  5 +-
 .../testsuite/libgomp.oacc-fortran/error_stop-1.f  | 20 ++
 .../testsuite/libgomp.oacc-fortran/error_stop-2.f  | 20 ++
 .../testsuite/libgomp.oacc-fortran/error_stop-3.f  | 20 ++
 libgomp/testsuite/libgomp.oacc-fortran/stop-1.f| 22 ++
 libgomp/testsuite/libgomp.oacc-fortran/stop-2.f| 20 ++
 libgomp/testsuite/libgomp.oacc-fortran/stop-3.f| 23 +++
 11 files changed, 234 insertions(+), 4 deletions(-)

diff --git libgfortran/ChangeLog libgfortran/ChangeLog
index d4a1fbb..ea4358c 100644
--- libgfortran/ChangeLog
+++ libgfortran/ChangeLog
@@ -1,3 +1,11 @@
+2018-04-19  Thomas Schwinge  
+
+   PR libfortran/85166
+   PR libgomp/85463
+   * runtime/minimal.c (stop_numeric): Reimplement.
+   (stop_string, error_stop_string, error_stop_numeric): New
+   functions.
+
 2018-04-19  Jakub Jelinek  
 
* configure: Regenerated.
diff --git libgfortran/runtime/minimal.c libgfortran/runtime/minimal.c
index e17666b..0b1efeb 100644
--- libgfortran/runtime/minimal.c
+++ libgfortran/runtime/minimal.c
@@ -188,6 +188,22 @@ sys_abort (void)
   abort();
 }
 
+
+/* runtime/stop.c */
+
+#undef report_exception
+#define report_exception() do {} while (0)
+#undef st_printf
+#define st_printf printf
+#undef estr_write
+#define estr_write printf
+/* Map "exit" to "abort"; see PR85463 '[nvptx] "exit" in offloaded region
+   doesn't terminate process'.  */
+#undef exit
+#define exit(...) do { abort (); } while (0)
+#undef exit_error
+#define exit_error(...) do { abort (); } while (0)
+
 /* A numeric STOP statement.  */
 
 extern _Noreturn void stop_numeric (int, bool);
@@ -197,7 +213,67 @@ void
 stop_numeric (int code, bool quiet)
 {
   if (!quiet)
-printf ("STOP %d\n", code);
-
+{
+  report_exception ();
+  st_printf ("STOP %d\n", code);
+}
   exit (code);
 }
+
+
+/* A character string or blank STOP statement.  */
+
+void
+stop_string (const char *string, size_t len, bool quiet)
+{
+  if (!quiet)
+{
+  report_exception ();
+  if (string)
+   {
+ estr_write ("STOP ");
+ (void) write (STDERR_FILENO, string, len);
+ estr_write ("\n");
+   }
+}
+  exit (0);
+}
+
+
+/* Per Fortran 

[patch, libfortran, committed] Implement stop_numeric for minimal targets

[Thomas König]

Hello world,

the recent patch to make the gfortran and libgomp testsuites more
standard conforming, by replacing CALL ABORT() with STOP N, led
to numerous testsuite failures on nvptx because stop_numeric
was not implemented in minimal.c.

I have committed the patch below in r259072 as obvious after Tom
de Vries had confirmed that it solves the problem.

Regards

Thomas

2018-04-04  Thomas Koenig  

PR libfortran/85166
* runtime/minimal.c (stop_numeric): Add new function in order to
implement numeric stop on minimal targets.
Index: runtime/minimal.c
===
--- runtime/minimal.c	(Revision 259055)
+++ runtime/minimal.c	(Arbeitskopie)
@@ -187,3 +187,17 @@
 
   abort();
 }
+
+/* A numeric STOP statement.  */
+
+extern _Noreturn void stop_numeric (int, bool);
+export_proto(stop_numeric);
+
+void
+stop_numeric (int code, bool quiet)
+{
+  if (!quiet)
+printf ("STOP %d\n", code);
+
+  exit (code);
+}

[patch, libfortran, committed] Restore bootstrap on non-x86* systems

[Thomas Koenig]

Hello world,

I have committed the attached patch as obvious as r248519 after testing
that it does indeed work on powerpc64-unknown-linux-gnu and that
it passes regression-test on that machine.

Sorry for the breakage. I'll use the gcc compile farm machines
in the future to test any such changes.

Regards

Thomas

2017-05-26  Thomas Koenig  

PR boostrap/80889
* acinclude.m4: Also set HAVE_AVX128 on the false
branch of LIBGFOR_CHECK_AVX128.
* configure:  Regenerated.
Index: acinclude.m4
===
--- acinclude.m4	(Revision 248472)
+++ acinclude.m4	(Arbeitskopie)
@@ -499,6 +499,6 @@ AC_DEFUN([LIBGFOR_CHECK_AVX128], [
 	AC_DEFINE(HAVE_AVX128, 1,
 	[Define if -mprefer-avx128 is supported.])
 	AM_CONDITIONAL([HAVE_AVX128],true),
-	[])
+	[AM_CONDITIONAL([HAVE_AVX128],false)])
   CFLAGS="$ac_save_CFLAGS"
 ])
Index: configure
===
--- configure	(Revision 248472)
+++ configure	(Arbeitskopie)
@@ -26453,7 +26453,16 @@ else
   HAVE_AVX128_FALSE=
 fi
 
+else
+   if false; then
+  HAVE_AVX128_TRUE=
+  HAVE_AVX128_FALSE='#'
+else
+  HAVE_AVX128_TRUE='#'
+  HAVE_AVX128_FALSE=
 fi
+
+fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
   CFLAGS="$ac_save_CFLAGS"
 
@@ -26714,6 +26723,10 @@ if test -z "${HAVE_AVX128_TRUE}" && test -z "${HAV
   as_fn_error "conditional \"HAVE_AVX128\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${HAVE_AVX128_TRUE}" && test -z "${HAVE_AVX128_FALSE}"; then
+  as_fn_error "conditional \"HAVE_AVX128\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
 
 : ${CONFIG_STATUS=./config.status}
 ac_write_fail=0

[PATCH, libfortran]: Committed: Read rounding mode from SSE mxcsr register on x86_64.

[Uros Bizjak]

Hello!

On x86_64, we can look into SSE mxcsr register to determine rounding mode.


2013-07-23  Uros Bizjak  ubiz...@gmail.com

* config/fpu-387.h (get_fpu_rounding_mode): Read rounding mode
from SSE mxcsr register on x86_64.

Tested on x86_64-pc-linux-gnu {,-m32}  and committed to mainline svn.

BTW. gfortran.dg/round_4.f90 test will fail on glibc  2.17 due to
glibc bug 3479 [1], Incorrect rounding in strtod().

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=3479

Uros.
Index: config/fpu-387.h
===
--- config/fpu-387.h(revision 201156)
+++ config/fpu-387.h(working copy)
@@ -102,11 +102,11 @@ has_sse (void)
 /* i387 rounding modes.  */
 
 #define _FPU_RC_NEAREST 0x0
-#define _FPU_RC_DOWN0x400
-#define _FPU_RC_UP  0x800
-#define _FPU_RC_ZERO0xc00
+#define _FPU_RC_DOWN0x1
+#define _FPU_RC_UP  0x2
+#define _FPU_RC_ZERO0x3
 
-#define _FPU_RC_MASK0xc00
+#define _FPU_RC_MASK0x3
 
 
 void
@@ -202,8 +202,9 @@ set_fpu_rounding_mode (int round)
 
   __asm__ __volatile__ (fnstcw\t%0 : =m (cw));
 
-  cw = ~_FPU_RC_MASK;
-  cw |= round_mode;
+  /* The x87 round control bits are shifted by 10 bits.  */
+  cw = ~(_FPU_RC_MASK  10);
+  cw |= round_mode  10;
 
   __asm__ __volatile__ (fldcw\t%0 : : m (cw));
 
@@ -213,9 +214,9 @@ set_fpu_rounding_mode (int round)
 
   __asm__ __volatile__ (%vstmxcsr\t%0 : =m (cw_sse));
 
-  /* The SSE round control bits are shifted by 3 bits.  */
-  cw_sse = ~(_FPU_RC_MASK  3);
-  cw_sse |= round_mode  3;
+  /* The SSE round control bits are shifted by 13 bits.  */
+  cw_sse = ~(_FPU_RC_MASK  13);
+  cw_sse |= round_mode  13;
 
   __asm__ __volatile__ (%vldmxcsr\t%0 : : m (cw_sse));
 }
@@ -224,13 +225,27 @@ set_fpu_rounding_mode (int round)
 int
 get_fpu_rounding_mode (void)
 {
+  int round_mode;
+
+#ifdef __x86_64__
+  unsigned int cw;
+
+  __asm__ __volatile__ (%vstmxcsr\t%0 : =m (cw));
+
+  /* The SSE round control bits are shifted by 13 bits.  */
+  round_mode = cw  13;
+#else
   unsigned short cw;
 
   __asm__ __volatile__ (fnstcw\t%0 : =m (cw));
 
-  cw = _FPU_RC_MASK;
+  /* The x87 round control bits are shifted by 10 bits.  */
+  round_mode = cw  10;
+#endif
 
-  switch (cw)
+  round_mode = _FPU_RC_MASK;
+
+  switch (round_mode)
 {
 case _FPU_RC_NEAREST:
   return GFC_FPE_TONEAREST;

[Patch, libfortran, committed] Remove configure check for unused fdopen function

[Janne Blomqvist]

Committed the patch below as obvious.

2012-01-12  Janne Blomqvist  j...@gcc.gnu.org

* configure.ac: Remove check for fdopen.
* runtime/backtrace.c (CAN_PIPE): Fix comment, remove check for
fdopen.
* configure: Regenerated.
* config.h.in: Regenerated.


Index: configure.ac
===
--- configure.ac(revision 183121)
+++ configure.ac(working copy)
@@ -263,7 +263,7 @@ AC_CHECK_MEMBERS([struct stat.st_blksize
 # Check for library functions.
 AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
 ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close fdopen \
+alarm access fork execl wait setmode execve pipe dup2 close \
 strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
 getcwd localtime_r gmtime_r strerror_r getpwuid_r ttyname_r clock_gettime \
 readlink getgid getpid getppid getuid geteuid)
Index: runtime/backtrace.c
===
--- runtime/backtrace.c (revision 183121)
+++ runtime/backtrace.c (working copy)
@@ -40,13 +40,12 @@ see the files COPYING3 and COPYING.RUNTI
 #include unwind.h


-/* Macros for common sets of capabilities: can we fork and exec, can
-   we use glibc-style backtrace functions, and can we use pipes.  */
+/* Macros for common sets of capabilities: can we fork and exec, and
+   can we use pipes to communicate with the subprocess.  */
 #define CAN_FORK (defined(HAVE_FORK)  defined(HAVE_EXECVE) \
   defined(HAVE_WAIT))
 #define CAN_PIPE (CAN_FORK  defined(HAVE_PIPE) \
-  defined(HAVE_DUP2)  defined(HAVE_FDOPEN) \
-  defined(HAVE_CLOSE))
+  defined(HAVE_DUP2)  defined(HAVE_CLOSE))

 #ifndef PATH_MAX
 #define PATH_MAX 4096



-- 
Janne Blomqvist

[Patch, libfortran, committed] Cleanup NEWUNIT allocation

[Janne Blomqvist]

Hi,

attached patch committed to trunk as obvious after regtesting.

2011-11-01  Janne Blomqvist  j...@gcc.gnu.org

* io/io.h (next_available_newunit): Remove prototype.
* io/unit.h (next_available_newunit): Make variable static,
initialize it.
(init_units): Don't initialize next_available_newunit.
(get_unique_unit_number): Use atomic builtin if available.


-- 
Janne Blomqvist
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index 23f07ca..3569c54 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -576,10 +576,6 @@ gfc_unit;
 extern gfc_offset max_offset;
 internal_proto(max_offset);
 
-/* Unit number to be assigned when NEWUNIT is used in an OPEN statement.  */
-extern GFC_INTEGER_4 next_available_newunit;
-internal_proto(next_available_newunit);
-
 /* Unit tree root.  */
 extern gfc_unit *unit_root;
 internal_proto(unit_root);
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index b4d10cd..33072fe 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -71,8 +71,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 /* Subroutines related to units */
 
-GFC_INTEGER_4 next_available_newunit;
+/* Unit number to be assigned when NEWUNIT is used in an OPEN statement.  */
 #define GFC_FIRST_NEWUNIT -10
+static GFC_INTEGER_4 next_available_newunit = GFC_FIRST_NEWUNIT;
 
 #define CACHE_SIZE 3
 static gfc_unit *unit_cache[CACHE_SIZE];
@@ -525,8 +526,6 @@ init_units (void)
   __GTHREAD_MUTEX_INIT_FUNCTION (unit_lock);
 #endif
 
-  next_available_newunit = GFC_FIRST_NEWUNIT;
-
   if (options.stdin_unit = 0)
 {/* STDIN */
   u = insert_unit (options.stdin_unit);
@@ -808,16 +807,19 @@ get_unique_unit_number (st_parameter_open *opp)
 {
   GFC_INTEGER_4 num;
 
+#ifdef HAVE_SYNC_FETCH_AND_ADD
+  num = __sync_fetch_and_add (next_available_newunit, -1);
+#else
   __gthread_mutex_lock (unit_lock);
   num = next_available_newunit--;
+  __gthread_mutex_unlock (unit_lock);
+#endif
 
   /* Do not allow NEWUNIT numbers to wrap.  */
-  if (next_available_newunit =  GFC_FIRST_NEWUNIT )
+  if (num  GFC_FIRST_NEWUNIT )
 {
-  __gthread_mutex_unlock (unit_lock);
   generate_error (opp-common, LIBERROR_INTERNAL, NEWUNIT exhausted);
   return 0;
 }
-  __gthread_mutex_unlock (unit_lock);
   return num;
 }

[Patch, libfortran, committed] Use lseek() to figure out if a file is seekable

[Janne Blomqvist]

Hi,

currently we try to figure out whether a fd is seekable by looking at
the mode returned by fstat(). Turns out this is not enough, as there
are some character special files that are seekable. Thus, change the
logic to try an lseek().

Committed as obvious.

Index: ChangeLog
===
--- ChangeLog   (revision 174945)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2011-06-11  Janne Blomqvist  j...@gcc.gnu.org
+
+   * io/unix.c (fd_to_stream): Figure out if a fd is seekable by
+   trying lseek().
+
 2011-06-10  Daniel Carrera  dcarr...@gmail.com

* caf/mpi.c (_gfortran_caf_sync_all,
Index: io/unix.c
===
--- io/unix.c   (revision 174945)
+++ io/unix.c   (working copy)
@@ -952,15 +952,15 @@ fd_to_stream (int fd)

   if (S_ISREG (statbuf.st_mode))
 s-file_length = statbuf.st_size;
-  else if (S_ISBLK (statbuf.st_mode))
+  else
 {
-  /* Hopefully more portable than ioctl(fd, BLKGETSIZE64, size)?  */
-  gfc_offset cur = lseek (fd, 0, SEEK_CUR);
+  /* Some character special files are seekable but most are not,
+so figure it out by trying to seek.  On Linux, /dev/null is
+an example of such a special file.  */
   s-file_length = lseek (fd, 0, SEEK_END);
-  lseek (fd, cur, SEEK_SET);
+  if (s-file_length  0)
+   lseek (fd, 0, SEEK_SET);
 }
-  else
-s-file_length = -1;

   if (!(S_ISREG (statbuf.st_mode) || S_ISBLK (statbuf.st_mode))
   || options.all_unbuffered


-- 
Janne Blomqvist

Re: [Patch, libfortran, committed] PR 48915 Update mixed-language programming section documentation

[Janne Blomqvist]

The previous patch was slightly over-zealous. Committed the following fix:

Index: gfortran.texi
===
--- gfortran.texi   (revision 173769)
+++ gfortran.texi   (working copy)
@@ -2611,7 +2611,7 @@ standard error.  Default: @code{GFC_STD_
 Default: off.
 @item @var{option}[3] @tab Unused.
 @item @var{option}[4] @tab If non zero, enable backtracing on run-time
-errors.  Default: enabled.
+errors.  Default: off.
 Note: Installs a signal handler and requires command-line
 initialization using @code{_gfortran_set_args}.
 @item @var{option}[5] @tab If non zero, supports signed zeros.
Index: ChangeLog
===
--- ChangeLog   (revision 173769)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2011-05-15  Janne Blomqvist  j...@gcc.gnu.org
+
+   PR libfortran/48915
+   * gfortran.texi (_gfortran_set_options): Even though -fbacktrace
+   is now the default, the library defaults to backtracing disabled.
+
 2011-05-14  Tobias Burnus  bur...@net-b.de

* lang.opt (fdump-core): Re-add as ignored option


On Sat, May 14, 2011 at 13:24, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
 Hi,

 I committed the attached patch as obvious. It updates the manual
 section on mixed-language programming to reflect the changes made as
 part of PR 48915.

 Index: gfortran.texi
 ===
 --- gfortran.texi       (revision 173750)
 +++ gfortran.texi       (working copy)
 @@ -2578,7 +2578,7 @@ int main (int argc, char *argv[])
  @table @asis
  @item @emph{Description}:
  @code{_gfortran_set_options} sets several flags related to the Fortran
 -standard to be used, whether backtracing or core dumps should be enabled
 +standard to be used, whether backtracing should be enabled
  and whether range checks should be performed.  The syntax allows for
  upward compatibility since the number of passed flags is specified; for
  non-passed flags, the default value is used.  See also
 @@ -2609,10 +2609,9 @@ Possible values are (bitwise or-ed) @cod
  standard error.  Default: @code{GFC_STD_F95_DEL | GFC_STD_LEGACY}.
  @item @var{option}[2] @tab If non zero, enable pedantic checking.
  Default: off.
 -@item @var{option}[3] @tab If non zero, enable core dumps on run-time
 -errors.  Default: off.
 +@item @var{option}[3] @tab Unused.
  @item @var{option}[4] @tab If non zero, enable backtracing on run-time
 -errors.  Default: off.
 +errors.  Default: enabled.
  Note: Installs a signal handler and requires command-line
  initialization using @code{_gfortran_set_args}.
  @item @var{option}[5] @tab If non zero, supports signed zeros.
 @@ -2627,8 +2626,8 @@ Default: enabled.  See -frange-check (@p

  @item @emph{Example}:
  @smallexample
 -  /* Use gfortran 4.5 default options.  */
 -  static int options[] = @{68, 255, 0, 0, 0, 1, 0, 1@};
 +  /* Use gfortran 4.7 default options.  */
 +  static int options[] = @{68, 255, 0, 0, 1, 1, 0, 1@};
   _gfortran_set_options (8, options);
  @end smallexample
  @end table
 Index: ChangeLog
 ===
 --- ChangeLog   (revision 173750)
 +++ ChangeLog   (working copy)
 @@ -1,5 +1,12 @@
  2011-05-14  Janne Blomqvist  j...@gcc.gnu.org

 +       PR libfortran/48915
 +       * gfortran.texi: Update mixed-language programming section
 +       reflecting the removal of the fdump-core option, and that
 +       -fbacktrace is enabled by default.
 +
 +2011-05-14  Janne Blomqvist  j...@gcc.gnu.org
 +
         PR libfortran/48915
         * gfortran.h (gfc_option_t): Remove flag_dump_core.
         * gfortran.texi (GFORTRAN_ERROR_DUMPCORE): Remove section.


 --
 Janne Blomqvist




-- 
Janne Blomqvist