Re: Call to arms: testsuite failures on various targets

[Jerry DeLisle]

FX Coudert wrote:
wrt to the Subject of the mail, I'm not sure "Call to arms" means what I 
thought it meant, after all... I really wanted it to sound like "call 
for help" or "call for more arms". Sorry if there was any confusion in 
the tone.


FX


I thought it was great!

Jerry

Typo in man page (atanh)

[Jerry DeLisle]

The following from man atanh has an error.  Should not refer tp acosh()

DESCRIPTION
   The  atanh()  function calculates the inverse hyperbolic tangent 
of x;
   that is the value whose hyperbolic tangent  is  x.   If  the 
absolute
   value of x is greater than 1.0, acosh() returns not-a-number 
(NaN) and

   errno is set.

Does anyone know where this is created.

Regards,

Jerry

Re: Someone broke bootstrap with gfortran, again!

[Jerry DeLisle]

Steve Kargl wrote:

Does this look familiar to anyone?

I was having troubles doing a build after a cvs update.  I had to delete 
everything in the build directory and rerun configure and then it would 
build ok. Not sure its the same problem you are seeing, but it happened 
today.  I am running on i686-pc-linux-gnu.


Jerry

Bootstrap breakage in Fortran

[Jerry DeLisle]

There was a breakage in Fortran that has now been fixed.

In case anyone runs into it. Resolved by:

M   gcc/fortran/ChangeLog
M   gcc/fortran/iresolve.c
M   gcc/fortran/simplify.c
r241000 = 7b8ebc39f2db57dcadd8b8f22b6b7561d187c279 (refs/remotes/svn/trunk)

Related to a recent patch adding COTAN function.

Regards,

Jerry

I see this maybe related to PR71375 ?

[Jerry DeLisle]

After a build of trunk this morning:

f951: internal compiler error: in altivec_init_builtins, at 
config/rs6000/rs6000.c:17547

0x10da4df3 altivec_init_builtins
../../trunk/gcc/config/rs6000/rs6000.c:17547
0x10da4df3 rs6000_init_builtins
../../trunk/gcc/config/rs6000/rs6000.c:16823
0x102c8797 gfc_init_builtin_functions
../../trunk/gcc/fortran/f95-lang.c:1244
0x102cb5f7 gfc_create_decls
../../trunk/gcc/fortran/f95-lang.c:181
0x102cb5f7 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:197
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

On

Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/home/jerryd/gcc/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerryd/gcc/usr 
--enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp 
--disable-bootstrap

Thread model: posix
gcc version 7.0.0 20161021 (experimental) (GCC)


On gcc112 , compile farm, Fedora release 21 (Twenty One)

Jerry

Breakage on trunk, a fix

[Jerry DeLisle]

I had to do this to get my build to work.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 5d96e5fd..140ff807 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2196,7 +2196,7 @@ continues.
 @itemx --with-target-bdw-gc-lib=@var{list}
 Specify search directories for the garbage collector header files and
 libraries. @var{list} is a comma separated list of key value pairs of the
-form @samp{@var{multilibdir}@=@var{path}}, where the default multilib key
+form @samp{@var{multilibdir}=@var{path}}, where the default multilib key
 is named as @samp{.} (dot), or is omitted (e.g.
 @samp{--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32}).

The error was:

../../trunk/gcc/doc/install.texi:2199: use braces to give a command as an 
argument to @=

make[2]: *** [doc/gccinstall.info] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2

I do not know who is to fix.

Regards

Jerry

Re: Removing an output file when test case has terminate

[Jerry DeLisle]

On 03/29/2015 04:50 AM, Janne Blomqvist wrote:

On Sun, Mar 29, 2015 at 2:28 PM, Thomas Koenig  wrote:

I want to add a test case to the gfortran testsuite for PR 65563.
If all goes right, running the test case will

a) terminate the program with an error message (to be checked for)

b) create a file, which needs to be cleaned up after the test case
is run.

a) is clear, but how do I do b)?  I haven't found anything in the
list of dg-final actions for this.  (Due to the specifics of the test
case, I also cannot name my file "foo.mod" and let the automatic module
cleanup do the job for me :-)

Any ideas?


What I did for PR 64770, were the testcase created a file
"pr64770test.dat", was to add a line

! { dg-final { remote_file build delete "pr64770test.dat" } }

to the end of the testcase. See gfortran.dg/open_new_segv.f90 for the
whole testcase.

Don't know if this is the correct way to do it, but it seems to work.




You can also try:

open(10, status="scratch")

It will be deleted when closed. Also on failed test, instead of calling abort, 
use STOP 500 or similar. STOP will close files.


Jerry

Is trunk now open for regular patches?

[Jerry DeLisle]

I see trunk is bumped to Version 6 now.  Are we in Stage 1?

Jerry

Re: RFC: Followup to PR91593

[Jerry DeLisle]

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:

Hi all,


--- snip ---


diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fc046efbe34 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1031,7 +1031,7 @@ btoa_big (const char *s, char *buffer, int len, 
GFC_UINTEGER_LARGEST *n)

    else
  {
    const char *p = s + len - 1;
-  for (i = 0; i < len; i++)
+  for (i = 0; i < len - 1; i++)
  {
    char c = *p;



--- snip ---

The first attempt to fix (above) is completely off.  I have tried various 
combinations of code changes and I am beginning to think the warning is bogus:


In function ‘btoa_big’,
inlined from ‘write_b’ at ../../../trunk/libgfortran/io/write.c:1217:11:
../../../trunk/libgfortran/io/write.c:1052:6: warning: writing 1 byte into a 
region of size 0 [-Wstringop-overflow=]

 1052 |   *q = '\0';
  |   ~~~^~

Using gdb I have watched the pointer address stored in q and the setting of the 
string of bytes doing the binary to ascii conversion. I have also checked the 
length of the buffer being used and its is what I would expect with length of 129.


However, the warning only goes away if I add an additional 8 bytes to the buffer 
(suspicious).


So doing the following eliminates the warning:

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 4ef35561fdd..fd0e46851e4 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1204,7 +1204,7 @@ void
 write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
 {
   const char *p;
-  char itoa_buf[GFC_BTOA_BUF_SIZE];
+  char itoa_buf[GFC_BTOA_BUF_SIZE + 8];
   GFC_UINTEGER_LARGEST n = 0;

   if (len > (int) sizeof (GFC_UINTEGER_LARGEST))

Any suggestions? I am certainly not seeing it.

Regards,

Jerry

Re: RFC: Followup to PR91593

[Jerry DeLisle]

On 10/1/19 12:40 PM, Martin Sebor wrote:

On 9/30/19 9:40 PM, Jerry DeLisle wrote:

Copying gcc list for additional thoughts on a possible bogus warning.

On 9/29/19 9:02 AM, Jerry DeLisle wrote:


--- snip ---


In case it helps, the warning is for the access:

   # .MEM_68 = VDEF <.MEM_71>
   MEM[(char *)_86] = 0;

where _86 is set to

   _86 = &itoa_buf + _43;

and _43 has the range [136, 17179869176].  (The warning needs to
be enhanced a bit to mention the accessed object in this case.)
itoa_buf's DECL_SIZE_UNIT evaluates to 129.

The call to btoa_big in write_b:

   p = btoa_big (source, itoa_buf, len, &n);

is made with len > 16.  If len > sizeof itoa_buf  / 8 then it does
look like btoa_big would write past the end of itoa_buf because it
writes len * 8 bytes into it.  I don't know if the function can be
called with len that large but if not, adding this just above
the call suppresses the warning.

   if (len > sizeof itoa_buf / 8)
 __builtin_unreachable ();

Martin



Thanks Martin, this does help me understand why the warning. Yes, len cannot be 
greater than 16. I decided to just use memset in write_b where the buffer is 
created to avoid the assignment that triggers the warning. Your suggestion may 
likewise work. In my comments describing the warning as bogus, by bogus, I mean 
"not applicable" to the situation.


I notice many warnings flying by when building gcc/gfortran. My preference would 
be to clear as many off as possible so that we can actually notice warnings when 
they are applicable and not miss them among a crowd of warnings.


I don't know if this makes sense to anyone and I do appreciate your response.

Jerry

[patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran

[Jerry DeLisle]

The attached patch introduces an installation script and support structure to
build OpenCoarrays using mpich, allowing multi-image gfortran, (latest Fortran
standards).

This patch is preliminary and intended to allow testing and comments to start.

I would like to get this into gcc 7 release as a manually invoked script. Later,
in gcc 8, I would like to modify such that it is automatically invoked right
after gfortran and libgfortran are installed, ie end of make install. (assuming
this approach is acceptable to the community)

The manual script is invoked with libgfortran as the current working directory
and passing to it the location of the just installed gfortran installation
directory. This is done to ensure OpenCoarrays uses the just installed gfortran
and gcc for compilation. A typical invocation is:

mk-multi-image/mk-multi-image.sh --install-prefix /home/jerry/dev/usr

At least on Fedora 25, one must use 'module load mpi' before invoking the script
to set things up to find an existing mpich installation. The intent will be to
build mpich if it is not found by the script.

The script uses portions of Bash 3 Boilerplate which are under MIT license.
These are separated out into the use-case subdirectory.

The OpenCoarrays tarball is downloaded from the github repository, sha256sum
checked, unpacked, and built in a temporary folder. The boiler plate provides
quite a few options for setting installation parameters.

The build requires cmake/make and runs tests using ctest. There are currently 4
coarray test failures that are known issues being actively worked.

The installation places libcaf_mpi.a in the install-prefix lib directory and
executables, caf and cafrun, in the bin directory.

TODO:

1. Change name of 'use-case' directory to 'utilities' to clarify its function.

2. Set tracked versus untracked downloads before release of the script.
Currently this is set to false to avoid artificially inflating download
statistics on github during testing. Simplify the code for this
tracked/untracked feature.

3. Move the usage text file into the 'utility' directory.

4. Address both lib and lib64 versions of the library and where they are 
installed.

5 Test and refine the finding and using/building mpich. We used mpich only as a
first implementation. Our intent will be to add other alternative communication
libraries in the future.  (Will be testing on a Cray machine and others as made
available)

4. Resolve any issues/comments identified during this RFC phase.

Your comments are welcome. This is a first step in full integration of
multi-image coarrays into gfortran.

Regards,

Jerry
diff --git a/libgfortran/mk-multi-image/mk-multi-image.sh b/libgfortran/mk-multi-image/mk-multi-image.sh
new file mode 100755
index 000..def8032
--- /dev/null
+++ b/libgfortran/mk-multi-image/mk-multi-image.sh
@@ -0,0 +1,246 @@
+#!/usr/bin/env bash
+
+#  Copyright (C) 2017 Free Software Foundation, Inc.
+#  Contributed by Jerry DeLisle in collaboration with Damian Rousan.
+#
+# This file is part of the GNU Fortran runtime library (libgfortran).
+#
+# Libgfortran is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# Libgfortran is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# Under Section 7 of GPL version 3, you are granted additional
+# permissions described in the GCC Runtime Library Exception, version
+# 3.1, as published by the Free Software Foundation.
+
+# You should have received a copy of the GNU General Public License and
+# a copy of the GCC Runtime Library Exception along with this program;
+# see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+# <http://www.gnu.org/licenses/>.
+
+# mk-multi-image.sh
+#
+# --- This script downloads and installs OpenCoarrays to directly support mult-image 
+# execution in libgfortran. Execute this script the last step of the libgfortran 
+# make install.
+
+# Portions of this script derive from or call sub-scripts of BASH3 Boilerplate. See
+# the B3B_USE_CASE subdirectory for the substantial portions of the Software and the
+# required permission notices of the MIT License (MIT).
+
+
+export LIBGFORTRAN_SRC_DIR="${LIBGFORTRAN_SRC_DIR:-${PWD%/}}"
+if [[ ! -d "${LIBGFORTRAN_SRC_DIR}/caf" ]]; then
+  echo "File not found: ${LIBGFORTRAN_SRC_DIR}/caf"
+  echo "Please run this script inside the libgfortran source directory or "
+  echo "set LIBGFORTRAN_SRC_DIR to the libgfortran source directory path."
+  exit 1
+fi
+export B3B_USE_CASE="${B3B_USE_CASE:-${LIBGFORTRAN_SRC_DIR}/mk-multi-image/use

Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran

[Jerry DeLisle]

On 01/26/2017 05:25 AM, FX wrote:
> Hi Jerry,
> 
> A few questions:
> 
>   - why mpich? doesn’t opencoarrays support any MPI implementation?

We picked it as one that I had available and only as a starting point, we plan
to add support for other libraries as we go. (OpenCoarrays itself does support
other libraries)

>   - I am a bit surprised by the complexity of the script… couldn’t we provide 
> a Makefile for opencoarrays, to be compatible with our other build 
> requirements?

I agree, this script is using Boiler Plate which allows a lot of flexibility and
provides some diagnostics and handling of script errors. It builds on things the
OpenCoarrays team is familiar with and was the quickest way to go initially. My
first draft script was about 50 lines with comments, but it had no error checks.
I will be able to reduce what you see when I narrow down to one tracked release
package.

>   - do we want to work towards seamless implementation of coarrays into 
> gfortran, or coexistence as a separate package (as is currently the case, for 
> example in Mac Homebrew, where it ships as a separate — but compatible — 
> package)?

I think we do want to head toward seamless. I have explored even copying the
source directly into the caf directory of libgfortran and merging the .h files,
but this takes some time to do and would leave two sets of sources to maintain.
Regarding things like Homebrew, or rpm packages, it will require us to learn how
to do these packages which none of us know right now.

Ultimately, since multi images is part of the Fortran language, it should just
happen transparently with the gcc regular build process.

Jerry

Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran

[Jerry DeLisle]

On 01/28/2017 03:22 AM, FX wrote:
> Hi Damian,
> 
>> It would be difficult or impossible for several OpenCoarrays
>> developers to contribute without OpenCoarrays remaining separate for
>> several reasons.
> 
> No, I understand that. What I meant is: do want to provide seamless 
> integration, so that libgfortran builds would automatically detect if an MPI 
> environment is available, and if so build opencoarrays. The only “hard" 
> dependency is whether we have an mpicc, it seems.
> 
> However, the big issue is that of build-time requirements, which are not 
> compatible with GCC: opencoarrays depends on cmake and bash, so it is in that 
> respect very different from GMP and MPFR, which do not have stricter 
> requirement than GCC itself.
> 
> I’ve started today to look at the OpenCoarrays source, and I admit I am quite 
> lost… it seems that the build machinery is much larger than the source 
> itself. Technically, it seems doable to OpenCoarrays a “Makefile.gfortran” 
> that would build OpenCoarrays, without the need for bash or cmake. Does this 
> sound right to you?
> 
> 
>>> Ultimately, since multi images is part of the Fortran language, it should 
>>> just
>>> happen transparently with the gcc regular build process.
>>
>> We’re all in agreement here so hopefully Jerry’s submission will be
>> approved.
> 
> Currently, I don’t think we can integrate it in this form, due to build 
> requirements. Maybe the threshold is lower for integrating it into GCC’s 
> contrib scripts directory?
> 
> FX
> 

The script could certainly be part of the contrib scripts which use bash. On
Fedora as an example there are gcc-gfortrn packages and mpich packages, ideally
the package maintainers of gcc/gfortran could easily include libcaf-mpi, caf,
and cafrun in the package. Or, of course a separate package could be developed.
Whoever does the package could simply use the script to generate the targets.

I have not encountered a system without cmake yet, I did test the script with my
cmake missing to confirm that it does actually build cmake if needed before it
proceeds, and then uses make. We have bash scripts already in libgfortran that
get invoked either during configuration or by build.

I don't see any real strong argument to not invoke the script with our make
install as a normal process, perhaps with a --enable-opencoarrays during
configuration.  I would see that as a next phase after gcc7, in gcc8.

Also keep in mind we have target systems that do not use the common software
packaging methods and must rely on the gcc/gfortran build method, so this script
is a way to "integrate" with minimal effect on gfortran source.  It is in its
own subdirectory, isolated from everything else and for gcc7 only manually
invoked.  This gets it out there, gets exposure, and gets it further tested.

Since my original post, I have significantly cleaned up the script and have been
testing on several platforms.  I will post the cleaned up script later today.

Jerry

Fwd: [patch, contrib] Add support to install libcaf-mpi for multi-image coarray Fortran

[Jerry DeLisle]

I forgot to copy gcc list for this request for comments and approval to commit.

Regards,

Jerry


 Forwarded Message 
Subject: [patch, contrib] Add support to install libcaf-mpi for multi-image
coarray Fortran
Date: Wed, 15 Feb 2017 22:20:49 -0800
From: Jerry DeLisle 
To: GCC Patches , fort...@gcc.gnu.org 


The attached patch adds a new subdirectory called mk-libcaf-multi under contrib
which contains scripts which will download OpenCoarrays, build libcaf-mpi.a, and
install it in the user provided --install-prefix.

As given the script is only manually executed by a user interested in doing so.

Eventually we would like to fully integrate the build of libcaf-mpi into gcc to
provide full multi-image support for gfortran.  These scripts provide an
intermediate means of doing so, bringing gfortran pretty close to full Fortran
2008 and 2015 standards.

Providing this will greatly expand user testing and development of gfortran
based CoArray Fortran (CAF) and simplify for users enabling this modern feature.

Tested on linux-x86-64 (Fedora 25) and MAC Darwin. Requires the user to
previously have installed  mpich for the mpi library. The build uses cmake and
bash 3 scripts to enable a lot of useful argument checking and diagnostics.

For those not familiar with Coarrays in Fortran and want or need to explore
these advanced features, using this script is a very helful way to get started.

Others may chime in with comments or questions.

OK for trunk?

Regards,

Jerry


diff --git a/contrib/mk-libcaf-multi/mk-libcaf-multi.sh b/contrib/mk-libcaf-multi/mk-libcaf-multi.sh
new file mode 100755
index 000..753b035
--- /dev/null
+++ b/contrib/mk-libcaf-multi/mk-libcaf-multi.sh
@@ -0,0 +1,269 @@
+#!/usr/bin/env bash
+
+#  Copyright (C) 2017 Free Software Foundation, Inc.
+#  Contributed by Jerry DeLisle in collaboration with Damian Rousan.
+#
+# This file is part of the GNU Fortran runtime library (libgfortran).
+#
+# Libgfortran is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# Libgfortran is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# Under Section 7 of GPL version 3, you are granted additional
+# permissions described in the GCC Runtime Library Exception, version
+# 3.1, as published by the Free Software Foundation.
+
+# You should have received a copy of the GNU General Public License and
+# a copy of the GCC Runtime Library Exception along with this program;
+# see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+# <http://www.gnu.org/licenses/>.
+
+# mk-multi-image.sh
+#
+# --- This script downloads and installs OpenCoarrays to directly support mult-image 
+# execution in libgfortran. Execute this script the last step of the libgfortran 
+# make install.
+
+# Portions of this script derive from or call sub-scripts of BASH3 Boilerplate. See
+# the B3B_USE_CASE subdirectory for the substantial portions of the Software and the
+# required permission notices of the MIT License (MIT).
+
+
+export LIBGFORTRAN_SRC_DIR="${LIBGFORTRAN_SRC_DIR:-${PWD%/}}"
+if [[ ! -d "${LIBGFORTRAN_SRC_DIR}/caf" ]]; then
+  echo "File not found: ${LIBGFORTRAN_SRC_DIR}/caf"
+  echo "Please run this script inside the libgfortran source directory or "
+  echo "set LIBGFORTRAN_SRC_DIR to the libgfortran source directory path."
+  exit 1
+fi
+export B3B_USE_CASE="${B3B_USE_CASE:-${LIBGFORTRAN_SRC_DIR}/../contrib/mk-libcaf-multi/utils}"
+if [[ ! -f "${B3B_USE_CASE:-}/bootstrap.sh" ]]; then
+  echo "Please set B3B_USE_CASE to the bash3boilerplate utils directory path."
+  exit 2
+else
+  source "${B3B_USE_CASE}/bootstrap.sh" "$@"
+fi
+
+# Set expected value of present flags that take no arguments
+export __flag_present=1
+
+if [[ "${arg_D}" == "${__flag_present}" || "${arg_L}" == "${__flag_present}" || "${arg_U}" == "${__flag_present}" || ${arg_V}"" == "${__flag_present}" ]]; then 
+   print_debug_only=7
+   if [ "$(( LOG_LEVEL < print_debug_only ))" -ne 0 ]; then
+ debug "Supressing info and debug messages: -v present."
+ suppress_info_debug_messages
+#export LOG_LEVEL=5
+   fi
+fi
+
+# If one of the --print-* arguments is present (or its single-letter equivalanet), we 
+# print its value and exit normally.  Here we print with echo instead of a B3B function u
+# because the output might be used in an assignment to a variable in another script e.g., 
+# version=`mk-multi-image.sh -V`
+
+if [[ "${arg_L}" == &quo

Re: Warning annoyances in list_read.c

[Jerry DeLisle]

On 03/26/2017 11:45 AM, Steve Kargl wrote:
> On Sun, Mar 26, 2017 at 11:27:59AM -0700, Jerry DeLisle wrote:
>>
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
> 
> IMNSHO, the correct fix is to complain loudly to whomever
> added -Wimplicit-fallthrough to compiler options.  It should
> be removed (especially if is has been added to -Wall).
> 
> You can also probably add -Wno-implicit-fallthrough to 
> libgfortran/configure.ac at 
> 
> # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC.
> if test "x$GCC" = "xyes"; then
>   AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays 
> -fno-underscoring"
> 

Problem I have is I don't know who to complain to. I think there is a bit of a
glass wall going on here anyway, so what would be the point of complaining if
the retrievers of the message all have the ON-OFF switch in the OFF position.
(After all, I do not have a PHD, I am not a computer science graduate, why
bother looking down ones nose at a low life such as myself, OMG its an engineer,
what the hell does he know.)

Maybe these warnings are being turned on as a matter of policy, but truth is,
when I build 50 times a day, the warnings flying by are masking the errors or
other warnings that may be important. For example, I inadvertently passed a ptr
to a function rather than the *ptr.

The warning that ensued flew by mixed in with all the other crap warnings and I
did not see it. That cost me wasted cycle time (remember, I am not an expert and
should not be expected to see such things. Hell, for that matter I should not
even be doing any of this work. :)

Cheers everybody, its been dark and gray all day.

Jerry

New prerequisites to support multi image COARRAY in gfortran

[Jerry DeLisle]

Gerald, (or who does this)

Since shared memory parallel programming with Fortran is now a Standard feature
of the language, we would like to support full parallelism through the use of
mpich and OpenCorrays.

We choose mpich as a default only because it is very stable. We choose
OpenCoarrays because it works well with gfortran and the developers have also
supported significant portions of the gfortran frontend (not to mention that it
is the only such library available). Choosing these as defaults for gfortran
does not exclude any user from using any other libraries in the future since the
final connection occurs at link time when a user compiles with -fcoarray=lib.

In order to support testing of installation of the new packages we are
requesting that the package tarballs be placed on the gcc.gnu.org along with the
other gcc prerequisite packages here:

ftp://gcc.gnu.org/pub/gcc/infrastructure/

There will be two stable released packages with appropriate shasum information
to be added. I can provide the links to those packages for download or send them
to you directly.

Requesting approval for this first step. (Later steps (more than one) will
provide patches for review of the contrib/download_prerequisites script. Another
step will be modifying OpenCoarrays build structure to align with the Gnu/gcc
build process. I believe mpich is already suitable, but will be testing.)

Is this OK?

Regards,

Jerry

Re: New prerequisites to support multi image COARRAY in gfortran

[Jerry DeLisle]

On 04/04/2017 10:44 AM, FX wrote:
>> We choose mpich as a default only because it is very stable.
> 
> Why are why tying ourselves to one MPI implementation?
> 
> FX
> 

Not tying ourselves at all. This just gives users who install gcc manually with
the ./configure process a default to use and only if they are using the download
prerequisites script which is optional. Distributions can still provide multiple
choices with package managers.

The final tie is at link time where a user may specify any compatible library
they choose. We do have a base of users who do not use package managers by the
way. So the goal is a minimal installation of a fully functional Fortran.

Jerry

Testing on Ryzen - Re: [patch, libfortran] AMD-specific versions of library matmul

[Jerry DeLisle]

GCC folks, if possible could someone install the dejagnu machinery on the Ryzen 
machines on the compile farm? Not sure who to ask.


On 05/25/2017 07:29 AM, Thomas Koenig wrote:

Hi Jerry,


Yes, OK.  Maybe test Ryzen first?


Sure, I can wait for a bit :-)
I just confirmed access to the Ryzen machines so I plan to get set up and test 
there.


I have had access for some time now. I did not realize they had a few Ryzen 
machines now. I got right in.


Of course they do not have all the prerequisites installed on the machine so I 
used contrib/download_prerequsites and the build completed fine.


Next issue is they do not have the dejagnu machinery on the machine either so we 
need to get someone to install that unless there is a contrib script that will 
do the trick. (or maybe I am doing something wrong, make check did not work)


In the meantime I will get the patch applied and test with our timing routines.

Jerry

GCC server write access

[Jerry DeLisle]

Can I get the contact info for someone who has write access to:

ftp://gcc.gnu.org/pub/gcc/infrastructure/

I would like to add two files there for testing of some patches to integrate
OpenCoarrays into gfortran build.

Help will be much appreciated. We need this to start testing.

Regards,

Jerry

Re: Strange commit from fortran-dev branch

[jerry DeLisle]

On 06/05/2011 12:17 PM, H.J. Lu wrote:

Hi,

Your commit:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00145.html

includes some bogus entries:

 trunk/gcc/go/gofrontend/expressions.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/expressions.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/expressions.cc.working
 trunk/gcc/go/gofrontend/go.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/go.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/go.cc.working
 trunk/gcc/go/gofrontend/gogo-tree.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/gogo-tree.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/gogo-tree.cc.working
 trunk/gcc/go/gofrontend/gogo.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/gogo.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/gogo.cc.working
 trunk/gcc/go/gofrontend/gogo.h.merge-left.r167407
 trunk/gcc/go/gofrontend/gogo.h.merge-right.r172891
 trunk/gcc/go/gofrontend/gogo.h.working
 trunk/gcc/go/gofrontend/parse.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/parse.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/parse.cc.working
 trunk/gcc/go/gofrontend/parse.h.merge-left.r167407
 trunk/gcc/go/gofrontend/parse.h.merge-right.r172891
 trunk/gcc/go/gofrontend/parse.h.working
 trunk/gcc/go/gofrontend/statements.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/statements.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/statements.cc.working
 trunk/gcc/go/gofrontend/statements.h.merge-left.r167407
 trunk/gcc/go/gofrontend/statements.h.merge-right.r172891
 trunk/gcc/go/gofrontend/statements.h.working
 trunk/gcc/go/gofrontend/types.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/types.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/types.cc.working
 trunk/gcc/go/gofrontend/unsafe.cc.merge-left.r167407
 trunk/gcc/go/gofrontend/unsafe.cc.merge-right.r172891
 trunk/gcc/go/gofrontend/unsafe.cc.working

Can you fix it?

Thanks.


H.J.

I am working on it.  Both the gcc/go and libgo directories had numerous 
conflicts during merge even though we never touch those directories for 
gfortran.  Why it would add those I have no idea.  At the time of my commit 
there were no conflicts showing. Regardless, I will clean it up as I go here.


The goal is to get gcc/fortran and libgfortran on the branch up to date with 
trunk.

Jerry

Jerry

Re: Strange commit from fortran-dev branch

[jerry DeLisle]

On 06/05/2011 01:58 PM, H.J. Lu wrote:

On Sun, Jun 5, 2011 at 12:17 PM, H.J. Lu  wrote:

Hi,

Your commit:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00145.html

includes some bogus entries:

trunk/gcc/go/gofrontend/expressions.cc.merge-left.r167407
trunk/gcc/go/gofrontend/expressions.cc.merge-right.r172891
trunk/gcc/go/gofrontend/expressions.cc.working
trunk/gcc/go/gofrontend/go.cc.merge-left.r167407
trunk/gcc/go/gofrontend/go.cc.merge-right.r172891
trunk/gcc/go/gofrontend/go.cc.working
trunk/gcc/go/gofrontend/gogo-tree.cc.merge-left.r167407
trunk/gcc/go/gofrontend/gogo-tree.cc.merge-right.r172891
trunk/gcc/go/gofrontend/gogo-tree.cc.working
trunk/gcc/go/gofrontend/gogo.cc.merge-left.r167407
trunk/gcc/go/gofrontend/gogo.cc.merge-right.r172891
trunk/gcc/go/gofrontend/gogo.cc.working
trunk/gcc/go/gofrontend/gogo.h.merge-left.r167407
trunk/gcc/go/gofrontend/gogo.h.merge-right.r172891
trunk/gcc/go/gofrontend/gogo.h.working
trunk/gcc/go/gofrontend/parse.cc.merge-left.r167407
trunk/gcc/go/gofrontend/parse.cc.merge-right.r172891
trunk/gcc/go/gofrontend/parse.cc.working
trunk/gcc/go/gofrontend/parse.h.merge-left.r167407
trunk/gcc/go/gofrontend/parse.h.merge-right.r172891
trunk/gcc/go/gofrontend/parse.h.working
trunk/gcc/go/gofrontend/statements.cc.merge-left.r167407
trunk/gcc/go/gofrontend/statements.cc.merge-right.r172891
trunk/gcc/go/gofrontend/statements.cc.working
trunk/gcc/go/gofrontend/statements.h.merge-left.r167407
trunk/gcc/go/gofrontend/statements.h.merge-right.r172891
trunk/gcc/go/gofrontend/statements.h.working
trunk/gcc/go/gofrontend/types.cc.merge-left.r167407
trunk/gcc/go/gofrontend/types.cc.merge-right.r172891
trunk/gcc/go/gofrontend/types.cc.working
trunk/gcc/go/gofrontend/unsafe.cc.merge-left.r167407
trunk/gcc/go/gofrontend/unsafe.cc.merge-right.r172891
trunk/gcc/go/gofrontend/unsafe.cc.working

Can you fix it?


I checked in this patch:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00150.html

to revert it.

OK thanks,  I still see some local conflicts on libstd++ so i am going to 
delete/clean the local tree and recheckout and see where we are.


Thanks,

Jerry

Re: Strange git commit on master branch in gcc git mirror

[jerry DeLisle]

On 06/06/2011 04:40 AM, Richard Guenther wrote:

On Mon, Jun 6, 2011 at 12:14 PM, Tobias Burnus  wrote:

On 06/06/2011 11:47 AM, Richard Guenther wrote:


Looks like an accident, modifying both trunk and branches/fortran-dev.
But the git mirror splits it between the trunk and fortran-dev branches.


Jerry, can you fix it up please?


This has been fixed else thread (cf. "Strange commit from fortran-dev
branch") by HJ's commit: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00150.html

(The question are: Why does "svn merge" produce merge errors for
directories/files untouched in the branch? libgo was never modified in
"fortran-dev" and should thus match the trunk to 100%. I also do not quite
understand how a merge of the trunk into a branch via "svn merge; svn
commit" can create files in the trunk.)


You probably didn't branch the whole tree on fortran-dev?  This way you
have a partial branch/trunk checkout and I guess svn merge is just confused
when you merge from trunk to trunk.

So, don't branch in a way that a checkout produces a mix of branch/trunk.

This whole thing has me puzzled. The branch was created before go and libgo 
existed on trunk. Then I did a plain vanilla merge and got a whole bunch of tree 
conflicts just for those two directories.  Then I attempted to manually resolve 
those tree conflicts.  So Tobias question remains open.


Since yesterday after HJ fixed up, I deleted the whole local fortran-dev branch 
and did a clean checkout of fortran-dev.  I have now done another plain vanilla 
merge of trunk into my local fortran-dev and again I get tree conflicts for go 
and libgo.  I have proceeded to one by one resolve these by copying over the 
current trunk file.  In some cases I have to do an svn add, other places I have 
to do svn resolve.


I have never had to do this before, so I am sorry if I am messing up, The tree 
conflicts just "appeared" out of nowhere.  I see also see about 4 files in 
libstd++ showing this now.


After this cleanup I plan to commit to fortran-dev again and hope we are OK. I 
am open to suggestions.


Jerry

Re: in asm: where does ".zero 2102063220" come from?

[Jerry DeLisle]

Daniel Franke wrote:

Hi all.

I'm in the process of revamping the fortran-frontend to use trees instead of 
linked lists in its array-constructor representation (initial patch at [1]). 
By now, I'm hunting down the last regressions. For one regression, I have no 
idea how to deal with it.


The problem: for some reason the .o file for a small fortran program may be 
blown up to multiple GB. The diff below shows the differences in assembler of 
the testcase gfortran.dg/actual_array_substr_2.f90, once compiled with current 
trunk, once with my local tree. The only difference is the ".zero $bignumber" 
- it's not overly far fetched to link $bignumber with the object file size. 

It is to assume that I either dropped a required initialization or introduced 
one that should not be there. Simply reading the diff doesn't help me much as 
(a) it's rather big by now and (b) whenever I identified a candidate and put a 
breakpoint there, execution never actually stopped there ^^


Hints where these .zero lines are generated and why, where to put a breakpoint 
and what to look for -- or anything else that puts me on the right track --

would be appreciated.

Try to get a look at the -fdump-tree-original output.  This should happen long 
before any asm is generated.  Post it here if you are still stuck.


Regards,

Jerry

Re: Proposed gfortran development branch

[Jerry DeLisle]

NightStrike wrote:

On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
 wrote:

On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:

I agree about the bisecting-in-case-of-bugs issue.

However, what I see happening in practice is that all GCC developers
keep on doing their development work on branches - only the gfortran
developers are left out, because they do not have a branch.

Of course we can create branches for all the subprojects that are
pending on the creation of a 4.4 branch and freeing up trunk - it just
doesn't seem very efficient to us.

Of course I pleaded with the FSF (on the Steering Committee mailing list
*and* the gcc list) for speed in the case of the 4.4 branch - in vain.

We might be heading for a fork a la the EGCS fork - and I don't like it.
 It took a lot of effort (I was part of the EGCS cabal and I didn't
even do a lot of that foot-work).


"Those who do not learn from history are doomed to repeat it."
George Santayana

http://home.schmorp.de/egcs.html

 Why are we doing this?  It's become increasingly clear in the course
 of hacking events that the FSF's needs for gcc2 are at odds with the
 objectives of many in the community who have done lots of hacking and
 improvment over the years.  GCC is part of the FSF's publicity for the
 GNU project, as well as being the GNU system's compiler, so stability
 is paramount for them.  On the other hand, Cygnus, the Linux folks,
 the pgcc folks, the Fortran folks and many others have done
 development work which has not yet gone into the GCC2 tree despite
 years of efforts to make it possible.

This can be amended by replacing "so stability is paramount for them"
with "so utopian philosophical pander is paramount for them"

--
Steve


http://gcc.gnu.org/ml/gcc/2009-03/msg00439.html

I would agree that going back to stage 3 is really a good solution.  I 
have also read several of the historical threads that are similar to this.


First, a clarification.  This proposed development branch is in no way 
intended to be a fork.  That would be disrespectful of the gcc community 
and I could not support such a thing.


Creating the branch allows us to continue joint effort much like other 
gcc developers do already.  This is nearly an ideal time because we are 
talking significant changes that go beyond Fortran95 and move well into 
Fortran 2003/2008.  That's what development branches ae for.


If the 4.4 delay continues only a little while or a longer time, we are 
capable of managing the merging in an orderly manner.


Therefore I believe the Yea's have it and I will attempt to create the 
branch hopefully this weekend.  We will follow our usual practice of 
peer review before commits.


Paul, do you have time to organize an IRC meeting to discuss order of 
commits and any other concerns? or Tobias?


Regards,

Jerry

[fortran-dev] Fortran development branch created.

[Jerry DeLisle]

The fortran development branch has been created.  The purpose is to 
allow continuation of development of new Fortran 95 and Fortran 2003 
features.  A primary objective will be testing these features before 
committing over to mainline, when appropriate.


A complete list of objectives can be found on the Fortran Wiki.

URL: svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/branches/fortran-dev
Repository Root: svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 144975

Regards,

Jerry

gfortran-dev branch bootstrap breakage

[Jerry DeLisle]

I just completed a sync to trunk that I have not committed back yet and I get 
the following error during bootstrap on the local branch.


libbackend.a(plugin.o): In function `plugin_default_version_check':
/home/jerry/gcc/objdev/gcc/../../gccdev/gcc/plugin.c:825: undefined reference to
 `plugin_gcc_version'

There was a patch that went in about 3 days ago related to this.

r146962.

That patch is in place in my local gfortran-dev branch.

local branch svn is at r147078

Suggestions anyone?

Jerry

Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]

[Jerry DeLisle]

Tobias Burnus wrote:

Dave Korn wrote:

Dave Korn wrote:

Dave Korn wrote:

Tobias Burnus wrote:

I agree that for "main" the call to "__main()" should happend and thus
expand_main_function should be called. I'm not sure in about the exact
assumptions of the middle end. In principle, it would be OK if the
MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
The only potential inconvenience I see, is the mentioned reference to
MAIN__ instead of  in middle-end warnings, which can
confuse users.

  Is it legitimate to have a space in an IDENTIFIER_NODE?  I have a cheeky idea:



-  gfc_get_symbol (name, ns, &main_program);
+  identifier = gfc_get_string ("PROGRAM %s", name);



  That should give reasonable warnings from the middle end, no?  I don't know
what it might do to debugging though.


Currently one can use "b MAIN__" and "b helloworld" in the debugger:

(gdb) b helloworld
Breakpoint 1 at 0x400737: file test.f90, line 3.
(gdb) b MAIN__
Note: breakpoint 1 also set at pc 0x400737.
Breakpoint 2 at 0x400737: file test.f90, line 3.
(gdb) b main
Breakpoint 3 at 0x4007b9: file test.f90, line 9.

I have another idea: Just handle "PROGRAM main" specially by using the
name "MAIN__". It should be still quite readable in the middle-end
diagnostics. Furthermore, it matches the assembler name and using "b
main" one still get something useful - and it is less confusing for
everyone (middle end, users of -fdump-tree-original etc.) if there is
only a single "main".

Tobias


Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 148004)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -289,7 +289,10 @@ gfc_get_label_decl (gfc_st_label * lp)
 static tree
 gfc_sym_identifier (gfc_symbol * sym)o commit
 {
-  return (get_identifier (sym->name));
+  if (sym->attr.is_main_program && strcmp (sym->name, "main") == 0)
+return (get_identifier ("MAIN__"));
+  else
+return (get_identifier (sym->name));
 }


@@ -3874,6 +3877,8 @@ create_main_function (tree fndecl)
   tmp =  build_function_type_list (integer_type_node, integer_type_node,
   build_pointer_type (pchar_type_node),
   NULL_TREE);
+  main_identifier_node = get_identifier ("main");
+  ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
   ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
   DECL_EXTERNAL (ftn_main) = 0;
   TREE_PUBLIC (ftn_main) = 1;



Tobias and Dave,

I tested the above on x86-64 Linux.  OK to commit.

Jerry

Regular LAPACK testing

[Jerry DeLisle]

I would like to get regular LAPACK regression testing and automatic reporting 
set up.


Is there a gcc.gnu server somewhere that I can get access to to set this up and 
have it run once daily?


This is mostly to catch gfortran regressions as well as an occasional back-end 
or middle-end bug.


After setting this up I would like to close PR5900

Regards,

Jerry

BFD Error a regression?

[Jerry DeLisle]

With latest svn trunk and Bud's splay patch.  I don't think this is related to 
Bud's patch because regression testing and NIST testing passed fine.


While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the following 
error message:


I am not sure I can reduce the case. But I can try if this is something new.

Look familiar?

Regards,

Jerry

BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h 
line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.

make[1]: *** [complex16] Error 1
make[1]: *** Waiting for unfinished jobs
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h 
line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.

make[1]: *** [double] Error 1
make[1]: Leaving directory `/home/jerry/fortran/lapack/SRC'
make: *** [lapacklib] Error 2

Re: BFD Error a regression?

[Jerry DeLisle]

Nick Clifton wrote:

Hi Jerry,

While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the 
following error message:


BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


If you are able to reproduce this bug, then please try using the latest 
version of the binutils from the mainline of the CVS repository.  If the 
bug still exists there please submit a binutils bug report (at: 
http://sourceware.org/bugzilla/) and we will be happy to investigate. 
(If you can include a simple test case that reproduces the problem, 
preferably without needing to build a special compiler, that will help 
immensely).


Cheers
  Nick

I observed that ar and ranlib are invoked by make to build the LAPACK libraries. 
 I was using make -j3 to do this.  When I do not use the -j option the build 
proceeds normally, so I am OK here.


There are several hundred object files being pulled together here.  I don't 
think I can reproduce the problem with a smaller set.  I will just avoid the option.


Thanks,

Jerry

Memory leaks in compiler

[Jerry DeLisle]

With the Fortran test case I am using for PR34722.  I did a valgrind check with 
the following command:


valgrind --leak-check=full f951 inquire_12.f90

The possible problem in mpfr has been around a while.

The other two problems look like middle-end or back-end problems.  Does this 
warrant a PR?  Against what component?


Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr 
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp 
--with-mpfr-lib=/home/jerry/gcc/usr/lib 
--with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap

Thread model: posix
gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC)

I get the following:

==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks.
==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated.
==14240== For counts of detected errors, rerun with: -v
==14240== searching for pointers to 1,036 not-freed blocks.
==14240== checked 2,346,928 bytes.
==14240==
==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8
==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951)
==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53)
==14240==by 0x4C34424: mpfr_cache (cache.c:57)
==14240==by 0x4C18E48: mpfr_log (log.c:133)
==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111)
==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165)
==14240==by 0x443BC2: gfc_init_1 (misc.c:259)
==14240==by 0x47684D: gfc_init (f95-lang.c:288)
==14240==by 0x6D74F4: toplev_main (toplev.c:2128)
==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so)
==14240==
==14240==
==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8
==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB1B4DB: xrealloc (xmalloc.c:177)
==14240==by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176)
==14240==by 0x4FC09D: insn_locators_alloc (vecprim.h:27)
==14240==by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862)
==14240==by 0x65C925: execute_one_pass (passes.c:1118)
==14240==by 0x65CAEB: execute_pass_list (passes.c:1171)
==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404)
==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152)
==14240==by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523)
==14240==by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640)
==14240==by 0x49368B: gfc_generate_function_code (trans-decl.c:3403)
==14240==
==14240==
==14240== 5,672 (5,224 direct, 448 indirect) bytes in 71 blocks are definitely 
lost in loss record 4 of 8

==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB1B567: xmalloc (xmalloc.c:147)
==14240==by 0x51E842: df_install_refs (df-scan.c:2425)
==14240==by 0x51EADA: df_refs_add_to_chains (df-scan.c:2551)
==14240==by 0x52029F: df_record_exit_block_uses (df-scan.c:3808)
==14240==by 0x5218D0: df_scan_blocks (df-scan.c:597)
==14240==by 0x51499D: rest_of_handle_df_initialize (df-core.c:742)
==14240==by 0x65C925: execute_one_pass (passes.c:1118)
==14240==by 0x65CAEB: execute_pass_list (passes.c:1171)
==14240==by 0x65CAFD: execute_pass_list (passes.c:1172)
==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404)
==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152)
==14240==
==14240== LEAK SUMMARY:
==14240==definitely lost: 5,632 bytes in 74 blocks.
==14240==indirectly lost: 448 bytes in 2 blocks.
==14240==  possibly lost: 64 bytes in 2 blocks.
==14240==still reachable: 304,817 bytes in 958 blocks.
==14240== suppressed: 0 bytes in 0 blocks.
==14240== Reachable blocks (those to which a pointer was found) are not shown.
==14240== To see them, rerun with: --leak-check=full --show-reachable=yes

Re: Memory leaks in compiler

[Jerry DeLisle]

Jerry DeLisle wrote:
With the Fortran test case I am using for PR34722.  I did a valgrind 
check with the following command:


valgrind --leak-check=full f951 inquire_12.f90

Here is a reduced test case.  I will submit a PR. It has nothing to do with my 
iostat patch for pr34722.


program gamsanal
end


Jerry

Re: Memory leaks in compiler

[Jerry DeLisle]

Bernhard Fischer wrote:

On Fri, Jan 11, 2008 at 11:30:12AM -0800, Jerry DeLisle wrote:
With the Fortran test case I am using for PR34722.  I did a valgrind check 
with the following command:


valgrind --leak-check=full f951 inquire_12.f90

The possible problem in mpfr has been around a while.

The other two problems look like middle-end or back-end problems.  Does 
this warrant a PR?  Against what component?


Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr 
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp 
--with-mpfr-lib=/home/jerry/gcc/usr/lib 
--with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap

Thread model: posix
gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC)

I get the following:

==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==14240== malloc/free: in use at exit: 310,961 bytes in 1,036 blocks.
==14240== malloc/free: 2,207 allocs, 1,171 frees, 1,296,169 bytes allocated.
==14240== For counts of detected errors, rerun with: -v
==14240== searching for pointers to 1,036 not-freed blocks.
==14240== checked 2,346,928 bytes.
==14240==
==14240== 64 bytes in 2 blocks are possibly lost in loss record 1 of 8
==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951)
==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53)
==14240==by 0x4C34424: mpfr_cache (cache.c:57)
==14240==by 0x4C18E48: mpfr_log (log.c:133)
==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111)
==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165)
==14240==by 0x443BC2: gfc_init_1 (misc.c:259)
==14240==by 0x47684D: gfc_init (f95-lang.c:288)
==14240==by 0x6D74F4: toplev_main (toplev.c:2128)
==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so)
==14240==
==14240==
==14240== 408 bytes in 3 blocks are definitely lost in loss record 2 of 8
==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB1B4DB: xrealloc (xmalloc.c:177)
==14240==by 0x8B1265: vec_heap_o_reserve_1 (vec.c:176)
==14240==by 0x4FC09D: insn_locators_alloc (vecprim.h:27)
==14240==by 0xA759F8: tree_expand_cfg (cfgexpand.c:1862)
==14240==by 0x65C925: execute_one_pass (passes.c:1118)
==14240==by 0x65CAEB: execute_pass_list (passes.c:1171)
==14240==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404)
==14240==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152)
==14240==by 0x8E73C3: cgraph_assemble_pending_functions (cgraphunit.c:523)
==14240==by 0x8E6894: cgraph_finalize_function (cgraphunit.c:640)
==14240==by 0x49368B: gfc_generate_function_code (trans-decl.c:3403)


Didn't look, but perhaps something like this?
I don't see where locations_locators_locs and locations_locators_vals
are freed either, but they seem to still be in use after locators_finalize...

Index: gcc-4.3/gcc/cfglayout.c
===
--- gcc-4.3/gcc/cfglayout.c (revision 131470)
+++ gcc-4.3/gcc/cfglayout.c (working copy)
@@ -274,6 +274,9 @@ insn_locators_finalize (void)
   if (curr_rtl_loc >= 0)
 epilogue_locator = curr_insn_locator ();
   curr_rtl_loc = -1;
+
+  VEC_free (int, heap, block_locators_locs);
+  VEC_free (tree, gc, block_locators_blocks);
 }
 
 /* Set current location.  */



No, this does not fix it.

Jerry

Re: Memory leaks in compiler

[Jerry DeLisle]

Kaveh R. GHAZI wrote:

On Fri, 11 Jan 2008, Vincent Lefevre wrote:


==14240==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==14240==by 0xB2F778: __gmp_default_allocate (in /mnt/sdb2/obj43/gcc/f951)
==14240==by 0x4C2B62D: mpfr_init2 (init2.c:53)
==14240==by 0x4C34424: mpfr_cache (cache.c:57)
==14240==by 0x4C18E48: mpfr_log (log.c:133)
==14240==by 0x4C2A4D1: mpfr_log10 (log10.c:111)
==14240==by 0x40A29F: gfc_arith_init_1 (arith.c:165)
==14240==by 0x443BC2: gfc_init_1 (misc.c:259)
==14240==by 0x47684D: gfc_init (f95-lang.c:288)
==14240==by 0x6D74F4: toplev_main (toplev.c:2128)
==14240==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so)

I'd say that this is a "bug" in GCC, that doesn't call mpfr_free_cache()
before exiting. Now, this isn't really necessary in practice since the
memory will be freed anyway.




Jerry - does this fix it?

--Kaveh


2008-01-16  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

* toplev.c (toplev_main): Call mpfr_free_cache().

diff -rup orig/egcc-SVN20080116/gcc/toplev.c egcc-SVN20080116/gcc/toplev.c
--- orig/egcc-SVN20080116/gcc/toplev.c  2008-01-03 23:37:34.0 +0100
+++ egcc-SVN20080116/gcc/toplev.c   2008-01-16 06:13:24.0 +0100
@@ -2276,6 +2276,8 @@ toplev_main (unsigned int argc, const ch
   if (!exit_after_options)
 do_compile ();

+  mpfr_free_cache ();
+
   if (errorcount || sorrycount)
 return (FATAL_EXIT_CODE);



Hi Kaveh,

Yes this fixes the mpfr related memory leak.  The cgraph related leaks are still 
in trunk.


Jerry

Current failures on Cygwin

[Jerry DeLisle]

Here are gfortran failures I am seeing on Cygwin as of a few hours ago.  I 
noticed some of these are at -O3, implying some optimization passes at fault. 
IIRC nint_2.f90 and default_format_denormal_1.f90 are not new.  The rest of 
these are fairly recent.


Maybe we need a meta-bug to track these.

Regards,

Jerry

Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/array_constructor_24.f execution test
FAIL: gfortran.dg/array_constructor_24.f execution test
FAIL: gfortran.dg/array_constructor_24.f execution test
FAIL: gfortran.dg/array_constructor_24.f execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/default_format_denormal_1.f90 execution test
FAIL: gfortran.dg/nint_2.f90 execution test
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/use_only_1.f90 (internal compiler error)
FAIL: gfortran.dg/use_only_1.f90 (test for excess errors)
WARNING: gfortran.dg/use_only_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/g77/970915-0.f (internal compiler error)
FAIL: gfortran.dg/g77/970915-0.f (test for excess errors)
Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/gomp/gomp.exp ...
Running /home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.dg/vect/vect.exp ...
Running 
/home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ...
Running 
/home/Jerry/gcc/gcc44/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ...

FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O0
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O1
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -Os

Re: Current failures on Cygwin

[Jerry DeLisle]

Tim Prince wrote:

I verified your report of 2 new problems (new since 2 weeks ago, the 
last time I could bootstrap on cygwin):

use_only_1.f90 segfaults the compiler at all optimization levels.
array_constructor_24.f seems to get into a non-terminating loop at 
run-time, which segfaults eventually, with the problem showing up only 
at -O3.




g77/970915-0.f is also segfaulting on compilation with no optimization.

Jerry

Re: Current failures on Cygwin

[Jerry DeLisle]

Janus Weil wrote:

Jerry DeLisle wrote:

Tim Prince wrote:
I verified your report of 2 new problems (new since 2 weeks ago, the 
last time I could bootstrap on cygwin):

use_only_1.f90 segfaults the compiler at all optimization levels.
array_constructor_24.f seems to get into a non-terminating loop at 
run-time, which segfaults eventually, with the problem showing up 
only at -O3.

g77/970915-0.f is also segfaulting on compilation with no optimization.


I'm afraid use_only_1.f90 and g77/970915-0.f are actually my fault 
(caused by rev. 134867). Will fix them soon.

Cheers,
Janus


The patch for the use_only_1.f90 and gcc/970915-0.f has been committed and I 
confirm these two are fixed on Cygwin.  The array_constructor_24.f is a 
different issue and still hangs.


Jerry

Re: Failure building GFortran (Cygwin)

[Jerry DeLisle]

Ian Lance Taylor wrote:

CC'ed to Eric.  This may require some configury patches somewhere.

Ian

Angelo Graziosi <[EMAIL PROTECTED]> writes:


The point isn't that to find workarounds.

The point is, so as stand the things, unless a new Cygwin 1.5.25-16
(or 1.5.26-1 ?), the build of GFortran-trunk and friends is
*officially* broken for cygwin-users.


Thanks,
   Angelo.


Dave Korn ha scritto:

Angelo Graziosi wrote on 29 June 2008 11:38:


Oops, I have discovered this, in libiberty/ChangeLog

2008-06-19  Eric Blake  <[EMAIL PROTECTED]>

Adjust strsignal to POSIX 200x prototype.
* strsignal.c (strsignal): Remove const.

  You may need to build and install cygwin from CVS[*] to get the
corresponding newlib fix and install it into your system headers in
/usr/include.  Or you could patch your /usr/include/string.h locally.  See

http://sourceware.org/ml/newlib/2008/msg00342.html

for the other half of Eric's patch.

cheers,
  DaveK

[*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which
case you could rebuild your current DLL from its source package and backport
the patch linked above.


A PR should be opened for this. Has that been done?  Is it marked as a 
regression and as a blocker?


Who has responsibility to fix this?

Regards,

Jerry

Re: Is that OK to borrow code from coreutils?

[Jerry DeLisle]

Steven Bosscher wrote:

On Wed, Jul 9, 2008 at 11:48 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
  

In that chmod() is not defined by the Fortran Standard,
how can you infer that libgfortran's implementation is
incorrect?

  

Please read a decent UNIX system book or look how
system () is implemented in glibc.



Well, there's a helpful answer!

You obviously want to change libgfortran for some reason.  It seems
only normal to me that you make an effort to explain why you think
this is necessary.  AFAIK the chmod in libgfortran, and in libg2c
before that, has never been a problem for anyone.  And with the basic
rule "If it ain't broke, don't fix it" in mind, there is no reason to
change the implementation to something more sophisticated.

So what problem are you trying to solve?  Got a test case?  Please
don't point back to the PR again, you're not explaining the problem
there either, only the symptom.  Surely, you didn't wonder off into
libgfortran land if you didn't have a piece of real world code that
has issues with the current libgfortran chmod? ;-)
  
I vote that the PR be closed as invalid and drop this whole subject.  I 
have reviewed the PR and this thread.  Ripples in the pond and butterfly 
wings.


Jerry

Re: REAL(16) ...on x86/x86-64

[Jerry DeLisle]

Steve Kargl wrote:

On Mon, Aug 25, 2008 at 03:15:42PM -0700, Steve Kargl wrote:

On Mon, Aug 25, 2008 at 11:50:16PM +0200, Dominique Dhumieres wrote:

REAL(16) needs to be done in software -- on x86, x86-64 -- as it is not
supported in hardware; if you want to use more than REAL(8) on x86,
x86-64 you can use REAL(10).  Or you use a system such as PowerPC which
supports REAL(16) in silicon.
As far as I can tell, the ifc implementation is a "real" one where the 
full 128 bits are used to code the real number.  So far i did not have the 
time to play with it.


Now concerning gfortran and since gcc requires gmp and mpfr, how difficult 
(efficient) would it be to use these libraries to implement REAL(xxx)?


Getting +, -, *, and / working is almost trivial.  The hard part is 
getting REAL(16) working in all the fun corners of the standard 
as well as getting IO working.  Here's a start where one may need

to distinguish between hardware FP and software emulation.




With the patch I sent earlier with an off-by-1 fix in exponents, I get

 Kind: 4 8 10 16
Precision: 6 15 18 33
   Digits: 24 53 64 113
Radix: 2 2 2 2
Min. exp.: -125 -1021 -16381 -16381
Max. exp.: 128 1024 16384 16384

on x86_64-*-freebsd.

program probe
   real(4)  a
   real(8)  b
   real(10) c
   real(16) d
   print '(A,4(I0,x))', ' Kind: ', kind(a), kind(b), kind(c), kind(d)
   print '(A,4(I0,x))', 'Precision: ', precision(a), precision(b), &
   &  precision(c), precision(d)
   print '(A,4(I0,x))', '   Digits: ', digits(a), digits(b), digits(c), &
   &  digits(d)
   print '(A,4(I0,x))', 'Radix: ', radix(a), radix(b), radix(c), radix(d)
   print '(A,4(I0,x))', 'Min. exp.: ', minexponent(a), minexponent(b), &
   &  minexponent(c), minexponent(d)
   print '(A,4(I0,x))', 'Max. exp.: ', maxexponent(a), maxexponent(b), &
   &  maxexponent(c), maxexponent(d)
end program probe


This looks like a nice start.  We already have support for real(16) I/O working 
so that will be a minor piece.


There exists float-128 routines within the gcc libraries now.  We need to figure 
out how to adapt/configure and use these.


Steve, will you carry this patch forward to get +,-,*, and / working?

In the meantime, is there someone knowledgeable of the flt-128 library that can 
guide us in this area.  Maybe between Steve and I we can get it working with 
some mentoring on the configuration stuff. (target gcc 4.5)


Jerry

Regressions on latest trunk

[Jerry DeLisle]

The following are failing:

Running /mnt/sdb2/gcc43/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/interface_12.f90  -O2  execution test
FAIL: gfortran.dg/interface_12.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/interface_12.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/interface_12.f90  -O3 -fomit-frame-pointer -funroll-all-loops 
-finline-functions  execution test

FAIL: gfortran.dg/interface_12.f90  -O3 -g  execution test
FAIL: gfortran.dg/result_in_spec_1.f90  -O2  execution test
FAIL: gfortran.dg/result_in_spec_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/result_in_spec_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
 execution test
FAIL: gfortran.dg/result_in_spec_1.f90  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions  execution test

FAIL: gfortran.dg/result_in_spec_1.f90  -O3 -g  execution test

Seem to pass with no optimization.

I was having no problems yesterday, so I suspect this is within the last 24 
hours or so.  This is on x86-64-linux-gnu, clean bootstrap, clean trunk. Updated 
a few hours ago.


Jerry

[Fwd: Re: Problem compiling NONMEM with mingw gfortran 4.3.0 builds]

[Jerry DeLisle]

Forwarding to gcc list since there seems to be a C related problem here as well. 
Example code below.


 Original Message 
Subject: Re: Problem compiling NONMEM with mingw gfortran 4.3.0 builds
Date: Sat, 21 Jul 2007 10:13:32 -0700
From: Jerry DeLisle <[EMAIL PROTECTED]>
To: Danny Smith <[EMAIL PROTECTED]>, Fortran List <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

Danny,

I experimented with your simple Hello World in C running on Cygwin, writing to
CONOUT$.  It does not error out, but does nothing.

On the gfortran side it creates a file named CONOUT$.

I would like to intercept this file name on mingw and cygwin systems and attempt
to map it to stdio in the gfortran runtime library. (band aid fix)

A couple of questions:

1) Is there a #define somewhere that I can use to conditionally compile this
"band aid" just for mingw and cygwin?  I have looked in config.h and did not
find anything useful.

2) At least on cygwin, since the example does not work for the C version (I have
not tried mingw, but presume it works there) is there a "system" level fix for
this problem that would be more appropriate?

Best regards,

Jerry

Examples:

$ cat test.c
#include 
#include 
#include 

int main()
{
 int fd= _open ("CONOUT$", _O_RDWR);
  if (fd >= 0)
   _write (fd, "Hello world", sizeof ("Hello world"));
 return 0;
}

$ cat test.f
   open(unit=29,file="CONOUT$")
   write(29,100)
100format('Hello, world!')
   end