headers
Angelo Graziosi | 1 Dec 2007 18:52
Picon
Picon

Re: Failure in building GFortran on Cygwin


Corinna Vinschen wrote:

> I've made another version of the Cygwin DLL, 1.5.25-3

With this new version of Cygwin, the problem, with which I started this
thread, seems to be solved!

Now the build of GFortran (20071201, trunk 130556) is completed without
problems.

Many thanks,

   Angelo.

---
http://www.webalice.it/angelo.graziosi

              Facesti come quei che va di notte,
              che porta il lume dietro e se' non giova,
              ma dopo se' fa le persone dotte.

                                      DANTE, Purgatorio, XXII 67-69
Permalink | Reply | 752 comments |
headers
Jerry DeLisle | 1 Dec 2007 20:31
Picon

Re: Failure in building GFortran on Cygwin

Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> 
>> I've made another version of the Cygwin DLL, 1.5.25-3
> 
> With this new version of Cygwin, the problem, with which I started this
> thread, seems to be solved!
> 
> Now the build of GFortran (20071201, trunk 130556) is completed without
> problems.
> 
> 
> Many thanks,
> 
>    Angelo.
> 
Yes, many thanks Corinna.

Jerry
Permalink | Reply | 751 comments |
headers
FX Coudert | 1 Dec 2007 22:16
Picon

[libgfortran,committed] Silence a few warnings on mingw32

Committed patch as rev. 130561 to fix a couple of warnings when  
building libgfortran on x86_64-pc-mingw32.

FX
Attachment (a): application/octet-stream, 2683 bytes
Permalink | Reply | 6 comments |
headers
Jack Howarth | 2 Dec 2007 00:30
Picon

fix PR32765 on darwin9 properly

   Could someone check-in the patch posted at...

http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00019.html

The original fix...

2007-08-15  Jack Howarth  <howarth <at> bromo.med.uc.edu>

        PR target/32765
        * testsuite/libgomp.fortran/pr32550.f90: Use -static-libgcc on Darwin.
        * testsuite/libgomp.fortran/crayptr2.f90: Likwise.

..isn't completely working on Darwin9 because the darwin-specific dg-options
in the crayptr2 testcase is above the default dg-options which overrides it.

http://gcc.gnu.org/ml/gcc-testresults/2007-12/msg00035.html

We can eliminate the test failures in libgomp.fortran/crayptr2.f90 on
*-apple-darwin9 but just moving the darwin-specific dg-options down
so that it is in use...

Index: libgomp/testsuite/libgomp.fortran/crayptr2.f90
===================================================================
--- libgomp/testsuite/libgomp.fortran/crayptr2.f90	(revision 130558)
+++ libgomp/testsuite/libgomp.fortran/crayptr2.f90	(working copy)
 <at>  <at>  -1,6 +1,6  <at>  <at> 
 ! { dg-do run }
-! { dg-options "-fopenmp -fcray-pointer -static-libgcc" { target *-*-darwin* } }
 ! { dg-options "-fopenmp -fcray-pointer" }
+! { dg-options "-fopenmp -fcray-pointer -static-libgcc" { target *-*-darwin* } }
(Continue reading)

Permalink | Reply | 2 comments |
headers
FX Coudert | 2 Dec 2007 00:40
Picon

Re: fix PR32765 on darwin9 properly

> ..isn't completely working on Darwin9 because the darwin-specific  
> dg-options
> in the crayptr2 testcase is above the default dg-options which  
> overrides it.

I don't understand what is darwin9-specific about it. How did it  
every work?

FX
Permalink | Reply | 1 comment |
headers
Jack Howarth | 2 Dec 2007 00:56
Picon

Re: fix PR32765 on darwin9 properly

FX,
   Actually it never did work. I noticed that shortly after
the original checkin but didn't complain becasue the fix
only works on darwin9 (which wasn't out yet).
              Jack

On Sat, Dec 01, 2007 at 11:40:15PM +0000, FX Coudert wrote:
>> ..isn't completely working on Darwin9 because the darwin-specific 
>> dg-options
>> in the crayptr2 testcase is above the default dg-options which overrides 
>> it.
>
> I don't understand what is darwin9-specific about it. How did it every 
> work?
>
> FX
Permalink | Reply | 0 comments |
headers
jimmie.davis | 2 Dec 2007 03:36
Favicon

[RFC] Changing the implementation language of the fortran front-end

Hello,

Do we have any feelings on the feasibility of changing the fortran
front-end from C to say C++ (or fortran, or ada for those most
rebellious) ?

The ability to use STL containers, IMHO, would make the code easier to
read, simpler, and (also IMHO) better all around.

Downsides:

#1.  Have to build g++ and the g++ libraries prior to compiling
gfortran.
#2.  The executable (might) be larger.

Upsides:
#1.  STL.

I don't think it would be hugely hard to make this change.........

Comments ?

--bud
Permalink | Reply | 6 comments |
headers
Richard Guenther | 2 Dec 2007 10:17
Picon

Re: [RFC] Changing the implementation language of the fortran front-end

On Dec 2, 2007 3:36 AM,  <jimmie.davis <at> l-3com.com> wrote:
> Hello,
>
> Do we have any feelings on the feasibility of changing the fortran
> front-end from C to say C++ (or fortran, or ada for those most
> rebellious) ?
>
> The ability to use STL containers, IMHO, would make the code easier to
> read, simpler, and (also IMHO) better all around.
>
> Downsides:
>
> #1.  Have to build g++ and the g++ libraries prior to compiling
> gfortran.
> #2.  The executable (might) be larger.
>
> Upsides:
> #1.  STL.
>
>
> I don't think it would be hugely hard to make this change.........
>
> Comments ?

The parts interfacing to the middle-end (trans-*.c) probably requires
to "harden"
some middle-end interfaces against abuses of C++ keywords and some other things.
But this would be actually a good thing, since quite some of the middle-end
developers would like to go towards using C++ in the middle-end itself.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Koenig | 2 Dec 2007 10:39
Picon
Favicon

Re: [RFC] Changing the implementation language of the fortran front-end

On Sat, 2007-12-01 at 20:36 -0600, jimmie.davis <at> l-3com.com wrote:

> Downsides:
> 
> #1.  Have to build g++ and the g++ libraries prior to compiling
> gfortran.
> #2.  The executable (might) be larger.

#3. Some fortran maintainers may not know c++ well enough to
work in it.

If that change was made, I would have to resign from fortran
maintainership.

	Thomas
Permalink | Reply | 0 comments |
headers
Bernhard Fischer | 2 Dec 2007 11:08
Picon

Re: [libgfortran,committed] Silence a few warnings on mingw32

On Sat, Dec 01, 2007 at 09:16:57PM +0000, FX Coudert wrote:
> Committed patch as rev. 130561 to fix a couple of warnings when building 
> libgfortran on x86_64-pc-mingw32.

+       * intrinsic/stat.c (stat_i4_sub_0, stat_i8_sub_0): Mark parameter
+       with unused attribute.
[]
+++ intrinsics/stat.c   (working copy)
 <at>  <at>  -60,7 +60,7  <at>  <at>  internal_proto(stat_i4_sub_0);*/

 static void
 stat_i4_sub_0 (char *name, gfc_array_i4 *sarray, GFC_INTEGER_4 *status,
-              gfc_charlen_type name_len, int is_lstat)
+              gfc_charlen_type name_len, int is_lstat __attribute__ ((unused)))

Same for any __attribute__[[:space:]]*\(\([_]*unused[_]*\)\) in the
tree..

Shouldn't these rather use the ATTRIBUTE_UNUSED (as per ansidecl.h) ?
Permalink | Reply | 4 comments |

Gmane