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
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
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
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
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
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 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
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 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
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
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
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
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
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
I see trunk is bumped to Version 6 now. Are we in Stage 1?
Jerry
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
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.
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/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/
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
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 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
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
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
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
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
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
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
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
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.
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 (
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
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
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
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:
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
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
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 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
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
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
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
42 matches
Mail list logo
