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
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 n
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 o
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)
Rela
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:1682
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
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 f
I see trunk is bumped to Version 6 now. Are we in Stage 1?
Jerry
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
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
rtran/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.
+# Contr
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
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 t
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
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 wh
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 becau
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
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 mac
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
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/
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.m
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.
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 p
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 br
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 foun
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_gc
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 O
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.
Af
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 tr
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 pleas
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
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
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
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 (
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.
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 eventual
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
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-trun
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 implemen
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
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
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:
42 matches
Mail list logo
