Re: Original commit history for gfortran

[Tobias Schlüter]

Hi all,

I'm sorry if I made this turn into a discussion of the benefits of Free 
Software, just two short points ...


On 2011-06-19 18:58, Steve Kargl wrote:

On Sun, Jun 19, 2011 at 11:04:09PM +0700, "C. Bergstr?m" wrote:

Andy started the project and at the time of the fork still was the
majority contributor.


Perhaps, you need to read the Copyright notices in the
trans-*.[ch] files.  It was Paul Brook and Steven Bosscher
who initially wrote the majority of the code that hooked
Andy's parser up to the GCC middle and backend.


Let's not forget GCC itself, which really is the biggest part of g95 (of 
course, there would probably have been a g95 without gcc, as there would 
have been another compiler backend, but there wouldn't have been a g95 
without Andy).



If you have concerns about PathScale email me privately.  My intention
is to vet the codebase.  Vetting g95 is relatively easy, but there's a
chasm between it and gfortran I'm trying to map.  If that's successful
I'd like to figure out if/how PathScale can contribute.  if we continue
to get much more negatively this early on (I don't care the reason).
I'll just forget the whole thing.


All of the code in gfortran is assigned to the FSF.  Have you
approached the FSF with a request to dual licenses the code?
There are on the order of 100 contributors listed in the
gcc/fortran/ChangeLog* files.  Are you asking each individual to
re-license his/her contribution to gfortran?


Given Christopher's answer to my question, I think he wants to make sure 
that the code is REALLY assigned to the FSF so that his company doesn't 
run into troubles down the road.


Cheers,
- Tobi

Re: Original commit history for gfortran

[Tobias Schlüter]

Hi Christopher,

On 2011-06-18 14:39, "C. Bergström" wrote:

On 06/18/11 05:16 PM, Toon Moene wrote:

On 06/18/2011 12:12 PM, Toon Moene wrote:


On 06/18/2011 05:05 AM, Christopher Bergström wrote:


Hi

We're in the process of considering contributing to gfortran for a
special project, but when we started to vet the codebase we hit a bump
in lack of commit history.


Additional information is here:

http://sourceforge.net/projects/gcc-g95

The above gives you the history after the split from the g95 project:

http://sourceforge.net/projects/g95

in January 2003.


The original commit by Paul Brook of the gcc-g95 repository contents
to the GCC repository is here:

http://gcc.gnu.org/ml/gcc-cvs/2003-07/msg01087.html

So I converted the cvs repo to git so I could actually dig and compare a
little better..

Here's an example of what we're trying to understand

This file wasn't in g95, but then magically appears in Paul's initial
commit.
gcc/f95/arith.h

# Unless I've messed up somewhere along my path..
# Was this file in gcc the whole time and just an external dep?


I think the history of this particular change went like this: Steven 
Bosscher was concerned about making g95 more modular.  Part of that 
process was splitting the big g95.h file into several parts -- that's 
where arith.h comes from.  Another part of that endeavour was moving the 
various tree dumpers into dump-parse-tree.c -- which IMO defeated the 
original purpose of having them in their corresponding source files 
(namely documentation), but on the other hand made that part more 
self-contained.


As for the history, there was another sourceforge project dedicated to 
g95 -> gcc integration bsides gcc-g95, its name escapes me right now. 
IIRC some of the I/O library was developed there.


Between the closing of g95's tree and gcc-g95's launch some development 
happened in private trees as pointed out before, but apart from that and 
Andy's very initial work which happened without CVS, you should find all 
the history in public record.


I'm sorry that I'm writing the following paragraph, but I think I 
should.  I heard rumors that Andy was hired by Pathscale, so I'm a bit 
worried about your intentions.  You're not trying to vet the code for 
the parts of the code which are available to relicensing to Pathscale 
for commerical exploitation, are you?  That's something that may under 
very specific circumstances be allowed by the usual copyright 
assignment?  You will probably understand that Andy's past behavior 
(including blatant disregard for free-software licenses, Steve already 
told the story) might make me question the behavior of people associated 
with him, even though I feel very rude doing so, and even though you 
alrady expressed good intentions.


Cheers,
- Tobi

Re: Bootstrap broken on darwin / fink

[Tobias Schlüter]

Hi Jack,

Jack Howarth wrote:

You didn't show the configure options you used to build gcc trunk
against the fink libraries. You need at least...

--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include  --x-libraries=/usr/X11R6/lib

Note that we don't set CPPFLAGS or LDFLAGS to have -I/sw/include or
-L/sw/lib in the fink gcc packaging so that only those libraries that
we explicitly set are picked up from fink. All other cases should be
picked up from the system libraries.



I wasn't aware of this.  So far, I've only used --with-gmp=/sw and it 
worked like a charm, but I've not tried buildig gcc in a while, maybe I 
updated my fink tree in the meantime.  My guess is, that as libcpp 
doesn't use gmp it doesn't get the -I/sw/include, whereas gcc/ gets it 
from --with-gmp.  There are libiconvs in both /usr and /sw.


Both with --with-libiconv-prefix=/sw and --with-libiconv-prefix=/usr, 
the build still fails in the same place, i.e. the libiconv from /usr is 
not picked up even if explicitly requested.


Cheers,
- Tobi

Re: Bootstrap broken on darwin / fink

[Tobias Schlüter]

Joseph S. Myers wrote:

On Mon, 1 Jun 2009, Tobias Schlüter wrote:


The complaint is about:
  ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
  [...snip...]
  iconv_ret = iconv (cd, &inbuf, &inbytesleft,
 &outbuf, &outbytesleft);


The types are exactly the same as in the corresponding code in 
libcpp/charset.c.


  ICONV_CONST char *inbuf;
  iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft);

You'll need to work out what's different on your system between gcc and 
libcpp to make it work in one place only.  Note that iconv.m4 comes from 
gettext; it's possible the configure support has since been refined 
upstream and should be updated.


In gcc/auto-host.h I have #define HAVE_ICONV_H, whereas in libcpp/ I 
haven't.  From PR31932, I presume that HAVE_ICONV_H should never be 
defined.  The check is explicitly made in AC_CHECK_HEADERS in 
gcc/configure.ac.  I can't see what happens if I remove the check as 
fink symlinks autoconf-2.59 to autoconf which in turn is a symlink to 
autoconf-2.63.


Cheers,
- Tobi

Bootstrap broken on darwin / fink

[Tobias Schlüter]

Hi,

I'm seeing this error:

/Users/tobi/src/hggcc/build/./prev-gcc/xgcc 
-B/Users/tobi/src/hggcc/build/./prev-gcc/ 
-B/usr/local/i386-apple-darwin8.11.1/bin/ 
-B/usr/local/i386-apple-darwin8.11.1/bin/ 
-B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem 
/usr/local/i386-apple-darwin8.11.1/include -isystem 
/usr/local/i386-apple-darwin8.11.1/sys-include-c  -g -O2 
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototype
 -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
-I../../gcc -I../../gcc/. -I../..
gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/sw/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd 
-I../libdecnumber../../gcc/

retty-print.c -o pretty-print.o
cc1: warnings being treated as errors
../../gcc/pretty-print.c: In function 'identifier_to_locale':
../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv' 
from incompatible pointer type
/sw/include/iconv.h:83: note: expected 'char **' but argument is of type 
'const char **'

make[3]: *** [pretty-print.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2


My libiconv identifies itself as
#define _LIBICONV_VERSION 0x010B/* version number: (major<<8) + minor */

The complaint is about:
  ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
  [...snip...]
  iconv_ret = iconv (cd, &inbuf, &inbytesleft,
 &outbuf, &outbytesleft);


Cheers,
- Tobi

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Tobias Schlüter]

Geoff Keating wrote:
It seems like mostly, anyone using the compiler farm has to use 
--with-mpfr, and otherwise people avoid it.


A random data point: if you use --with-gmp (as I have to), configure 
finds an mpfr in the same subdirectory, so you might want to look for 
that as well.


Cheers,
- Tobi

Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]

[Tobias Schlüter]

Gerald Pfeifer wrote:

On Tue, 14 Oct 2008, Tobias Schlüter wrote:
I'll take care of this, provided Gerald approves the change.  Gerald, if 
you think that copyright is a problem, I'll gladly rephrase it.


Thanks for the change, it looks like a good one.  You may want to make
one or the other adjustment for extra safety, but this should be on the 
harmless side.


I expanded the patch somewhat, so that the information appears in a 
somewhat more user-friendly place.  See below.


Committed after make info, make dvi and make html succeeded.

Cheers,
- Tobi

2008-10-19  Tobias Schlüter  <[EMAIL PROTECTED]>

* doc/install.texi: Document in-tree building of gcc and mpfr.

Index: install.texi
===
--- install.texi(revision 141230)
+++ install.texi(working copy)
@@ -307,7 +307,9 @@ systems' @command{tar} programs will als
 Necessary to build [EMAIL PROTECTED]  If you do not have it installed in your
 library search path, you will have to configure with the
 @option{--with-gmp} configure option.  See also
[EMAIL PROTECTED] and @option{--with-gmp-include}.
[EMAIL PROTECTED] and @option{--with-gmp-include}.  Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
 
 @item MPFR Library version 2.3.2 (or later)
 
@@ -319,8 +321,12 @@ fixed when using this version.  It is st
 to the recommended version of MPFR.
 
 The @option{--with-mpfr} configure option should be used if your MPFR
-Library is not installed in your default library search path.  See
-also @option{--with-mpfr-lib} and @option{--with-mpfr-include}.
+Library is not installed in your default library search path.  See also
[EMAIL PROTECTED] and @option{--with-mpfr-include}.
+Alternatively, if a MPFR source ditribution is found in a subdirectory
+of you GCC sources named @file{mpfr}, it will be built together with
[EMAIL PROTECTED]
+
 
 @item @command{jar}, or InfoZIP (@command{zip} and @command{unzip})
 
@@ -496,6 +502,12 @@ components of the binutils you intend to
 (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
 @file{opcodes}, @dots{}) to the directory containing the GCC sources.
 
+Likewise, the GMP and MPFR libraries can be automatically built together
+with GCC.  Unpack the GMP and/or MPFR source distributions in the
+directory containing the GCC sources and rename their directories to
[EMAIL PROTECTED] and @file{mpfr}, respectively (or use symbolic links with the
+same name).
+
 @html
 
 

Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]

[Tobias Schlüter]

Matt Fago wrote:
I and several other people have been bit by this, and I am currently trying to 
help someone else build gcc with gmp/mpfr. It seems to me that the easiest thing 
to do is an in-tree build -- it would be great if it were documented. How about 
something like the below? While generalizing the binutils paragraph would be 
more concise, building gmp/mpfr is now often required and I though giving it a 
separate paragraph was more clear.


Note I don't have write access, but I'd hope someone could commit something 
similar.


I'll take care of this, provided Gerald approves the change.  Gerald, if 
you think that copyright is a problem, I'll gladly rephrase it.


Thanks,
- Tobi


*** download.html   2008-10-14 10:24:31.0 -0600
--- download-new.html   2008-10-14 10:29:49.0 -0600
*** components of the binutils you intend to
*** 107,112 
--- 107,118 
  (bfd, class="file">binutils, gas, 
gprof, class="file">ld,
  opcodes, class="dots">...) to the directory containing the GCC sources.


+A similar method can also be used to automatically build gmp and/or mpfr
+ 'in-tree.' Unpack the gmp and mpfr source distributions in the gcc source
+ directory and rename them to gmp and
+ mpfr (or use symbolic links with
+ the same name).
+
 
  Return to the GCC Installation page

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Tobias Schlüter]

Adrian Bunk wrote:

On Tue, Oct 14, 2008 at 02:37:13PM +0200, Tobias Schlüter wrote:

Markus Milleder wrote:

Adrian Bunk schrieb am 13.10.2008 17:41:15:

E.g. the next stable release of Debian will likely ship with 2.3.1 .
So in this specific case fulfilling a 2.3.1 requirement would be easy,
while a 2.3.2 requirement would make it much harder to build gcc 4.4 .


Much harder ?

I don't think anybody who tries to build GCC from source will have any
problem building MPFR first.
They don't even need to do this, as mpfr can be built in-tree.  It then  
also won't interfere with a system-wide mpfr.

...
This is moot because for the reason given above, these hypothetical  
regressions are restricted to gcc if the person building gcc is careful.


"careful" = uses an undocumented trick ?

Or where at http://gcc.gnu.org/install/ is this documented?


Hm, maybe it's not.  I'm too lazy to search through all the 
documentation of the GNU build system.   While this may be written 
someplace, it would certainly be a good thing to generalize the 
paragraph about binutils in <http://gcc.gnu.org/install/download.html>.


Anyway, if you're afraid of regressions nothing prevents you from 
building another mpfr out-of-tree (which is documented), and use that, 
so the point is still moot.  If you use a static library there is no 
chance it will interfere with anything.


Greetings,
- Tobi

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Tobias Schlüter]

Markus Milleder wrote:

Adrian Bunk schrieb am 13.10.2008 17:41:15:

E.g. the next stable release of Debian will likely ship with 2.3.1 .
So in this specific case fulfilling a 2.3.1 requirement would be easy,
while a 2.3.2 requirement would make it much harder to build gcc 4.4 .


Much harder ?

I don't think anybody who tries to build GCC from source will have any
problem building MPFR first.


They don't even need to do this, as mpfr can be built in-tree.  It then 
also won't interfere with a system-wide mpfr.



I can see how a distribution will probably want to have at least the
MPFR version GCC demands, which would force an MPFR upgrade to
accompany a GCC 4.4 package.


And upgrading from 2.3.1 to let's say 3.0.0 might be a bad choice if
the new version contains regressions.


This is moot because for the reason given above, these hypothetical 
regressions are restricted to gcc if the person building gcc is careful.


Cheers,
- Tobi

Status of Mercurial mirror

[Tobias Schlüter]

Hi,

the Mercurial repository has not been updated since svn revision 133268
which happened yesterday morning GMT.  With all this talk about git 
recently, I'm wondering if the Mercurial repository is still alive?


Cheers,
- Tobi

Re: Interoperability of Fortran array and C vector?

[Tobias Schlüter]

Sa Liu wrote:
I noticed that in fortran/convert.c the convert() function calls 
convert_to_vector() if the target type is VECTOR_TYPE. When is that 
function triggered in Fortran frontend? Since Fortran language doesn't 
support vector type, why does it convert something to a vector expression?


At the top it says:
/* This file contains the functions for converting C expressions
   to different data types.  The only entry point is `convert'.
   Every language front end must have a `convert' function
   but what kind of conversions it does will depend on the language.  */

/* copied from the f77 frontend I think */

/* copied from c-convert.c without significant modification*/

I don't think this file has ever been modified in any non-mechanical 
way.  So I'd assume that its contents are historical / accidental.


Cheers,
- Tobi

--
Tobias Schlüter
Am Coulombwall 1, Zi. 326
85748 Garching b. München
Tel.: +49/89/289-14139

Re: Someone has caused regressions in gfortran

[Tobias Schlüter]

Jan Hubicka wrote:

Thanks, I sent the patch for testing and lets see if it solves the
problem.


If the testsuite passes, and you intend to commit this, please add a FIXME.

Cheers,
- Tobi


Honza

Index: trans-decl.c
===
--- trans-decl.c(revision 127902)
+++ trans-decl.c(working copy)
@@ -1217,6 +1217,8 @@ build_function_decl (gfc_symbol * sym)

   type = gfc_get_function_type (sym);
   fndecl = build_decl (FUNCTION_DECL, gfc_sym_identifier (sym), type);
+  if (!sym->attr.contained)
+DECL_UNINLINABLE (fndecl) = 1;

   /* Perform name mangling if this is a top level or module procedure.  */
   if (current_function_decl == NULL_TREE)


I have neither built nor regtested this, and I won't be able to do it
in the next few days. If you feel like trying, please go ahead.

FX

Re: Can realloc be marked as a mallloc-like function?

[Tobias Schlüter]

H.J. Lu wrote:

It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are

1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.

BTW, glibc also marks realloc with __attribute_malloc__.


There was an absurdely long thread on this topic starting at 
.  I didn't dig through 
it to find the answer.


HTH,
- Tobi

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

[Tobias Schlüter]

Brooks Moses wrote:
I'm not entirely sure that I agree with formalizing this for the Fortran 
maintainers in bulk, at least without discussion.  My understanding (and 
it's entirely possible that I've missed something) was that this wasn't 
so much a formal rule as a general custom -- and, being a custom rather 
than a formal rule, unobjectionable to break when appropriate.


I have no objection to this as a custom for GFortran, certainly -- I 
think it's a very good idea, and as a custom I very much support it. 
However, there have historically been reasonable exceptions to it.  In 
particular, I've committed several documentation patches without review, 
and I have seen a few small patches submitted by maintainers for 
comments rather than a formal review and then committed when there were 
no dissenting comments.  My understanding at the time was that these 
were entirely acceptable things to do; is this still true, or no?


Mostly what I want is some discussion about what we expect this to mean 
as a formal rule, and how strictly we're expecting to interpret it.  For 
values of "we" meaning both the GFortran maintainers, and the wider GCC 
maintainer community.


I think all rules have to give in to reality.  In gfortran it's happened 
in the past that patches that went unreviewed, went in based on the 
convictions of the author that their patch is right.  I don't think this 
is a bad thing, as long as we find that we can trust eachother.  Which I 
believe is the case in the Fortran FE community.


(I think I'd also like to register a very small polite complaint about 
the introduction of a new category of maintainers without any sort of 
announcement or discussion on the gcc@ list, at least insofar as I could 
find by searching on "autopoiesis" in the archives.)


Kenneth has explained how this came about, and how this is not a new, 
formal category as the non-algorithmic maintainers were in the 
follow-up, and I'm fine with that.  OTOH I do object (with a smiley) to 
being labeled something that -- even though I can understand its meaning 
from the ancient greek I studied -- I haven't the slightest idea how to 
pronounce (sorry, "autopoiesis" is not in the dictionaries that I 
checked).  I think "non-autonomous" would do the job perfectly well, 
without putting community members who didn't study philosophy into the dark.


Cheers,
- Tobi

Re: How can a front-end know what integer mode corresponds to int_fastN_t?

[Tobias Schlüter]

FX Coudert <[EMAIL PROTECTED]> wrote on Mon, 16 Oct 2006:

For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.

For intN_t and int_leastN_t, I can see how to get them by looking at
the width of the different integer modes. For intmax_t, it is defined
in c-common.h as:

#define INTMAX_TYPE ((INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
 ? "int"\
 : ((LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
? "long int"\
: "long long int"))

But I cannot see how the front-end can know the integer mode for
int_leastN_t. We're likely to include this functionality for the 4.3
release, so I'll be happy to get a large number of suggestions around
on how to implement that.



The code in trans-types.c already matches Fortran types to C types, so  
you might get some inspiration there.


- Tobi


This message was sent using IMP, the Internet Messaging Program.

Re: Compilation time has more than doubled on some Polyhedron tests

[Tobias Schlüter]

Richard Guenther wrote:
> I guess the fix for PR tree-optimization/22555 could make some difference
> if fortran uses a lot of structures with embedded arrays.  Basically this
> enables decomposing these structures for aliasing purposes and should
> generate better code.

It is perhaps noteworthy that the build times for the base run of Diego's
SPECFP tester have increased by approx. twenty percent, with no visible gain
in execution speed, between Jan 5th and Jan 6th, see

and


- Tobi

Re: Compilation time has more than doubled on some Polyhedron tests

[Tobias Schlüter]

In looking at compiles times, I missed looking at memory usage:

Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
> 
>  tree SSA rewrite  :   0.45 ( 2%) usr   0.02 ( 5%) sys   0.36 ( 2%) wall  
>  35265 kB (27%) ggc
>  tree SSA incremental  :   0.71 ( 4%) usr   0.02 ( 5%) sys   0.77 ( 4%) wall  
>   6145 kB ( 5%) ggc
>  tree operand scan :   0.44 ( 2%) usr   0.07 (18%) sys   0.55 ( 3%) wall  
>  17385 kB (13%) ggc
>  expand:   0.39 ( 2%) usr   0.00 ( 0%) sys   0.46 ( 2%) wall  
>   9703 kB ( 8%) ggc
>  TOTAL :  19.26 0.4019.91 
> 129144 kB

20060106:
>  tree SSA rewrite  :   0.93 ( 3%) usr   0.03 ( 8%) sys   1.08 ( 3%) wall  
>  65009 kB (33%) ggc
>  tree SSA incremental  :   1.84 ( 5%) usr   0.02 ( 5%) sys   1.87 ( 5%) wall  
>  13262 kB ( 7%) ggc
>  tree operand scan :   0.88 ( 3%) usr   0.05 (13%) sys   0.97 ( 3%) wall  
>  29929 kB (15%) ggc
>  expand:   0.97 ( 3%) usr   0.01 ( 3%) sys   1.01 ( 3%) wall  
>  13943 kB ( 7%) ggc
>  TOTAL :  33.82 0.3834.64 
> 194932 kB

An increase by > 50%.  Here and before I extracted the numbers from your
compilations of induct.f90.

It looks like we're generating significantly more trees now, which would of
course explain the increase in time spent checking.

- Tobi

Re: Compilation time has more than doubled on some Polyhedron tests

[Tobias Schlüter]

Dominique Dhumieres wrote:
> On an AMD, the 20060105 build gives
>  tree SSA verifier :   9.55 (50%) usr   0.09 (23%) sys   9.62 (48%) wall  
> 19 kB ( 0%) ggc
>  tree STMT verifier:   1.56 ( 8%) usr   0.00 ( 0%) sys   1.61 ( 8%) wall  
>  0 kB ( 0%) ggc
> TOTAL :  19.26 0.4019.91   129144 kB

> The 20060106 build gives
>  tree SSA verifier :  18.53 (55%) usr   0.05 (13%) sys  18.54 (54%) wall  
> 19 kB ( 0%) ggc
>  tree STMT verifier:   2.36 ( 7%) usr   0.00 ( 0%) sys   2.28 ( 7%) wall  
>  0 kB ( 0%) ggc
> TOTAL :  33.82 0.3834.64   194932 kB

So it looks like the bulk of the change is accounted for in the tree-checking.

(As for the answer to my question about --enable checking, with -ftime-report
the compiler is quite explicit about this:
> Extra diagnostic checks enabled; compiler may run slowly.
> Configure with --disable-checking to disable checks.
Unless --disable-checking is given, these checks are enabled everywhere but in
releases.)

> Not knowing what to look for, I'll need further directives about
> what to do next.

If you want a faster compiler, you can always build with --disable-checking.
But since we're probably performing redundant checks, I've added Richard
Günther to CC:, who seems to be the only person who committed changes during
that timeframe, maybe he has an idea where we're now excessively checking trees.

Thanks,
- Tobi

Re: What happened to bubblestrap?

[Tobias Schlüter]

[ forwarding to gcc@gcc.gnu.org ]

Jerry DeLisle wrote:
> I just did a fresh build testing a patch here and then I try make bubblestrap 
> and "no target 'bubblestrap'

I'm curious myself.  Was this an intentional result of the toplevel bootstrap
stuff?

- Tobi

Re: question on checkout?

[Tobias Schlüter]

Giovanni Bajo wrote:
> The section is unneeded and duplicates the first paragraph of SvnBasic. 
> Please,
> make sure to not insert duplicate information in the Wiki, prefer to link. I
> have removed the duplicate.

Sorry, I had missed that section when I looked for it.

Thanks,
- Tobi

SVN: question on checkout?

[Tobias Schlüter]

> http://gcc.gnu.org/wiki/SvnSetup has the following example for 
> checking out the GCC sources under "Checking out a tree"
> 
>   svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk 
> 
> but this doesn't work for me.  Rather, I'm getting:
> 
>   % svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
>   Permission denied (publickey,gssapi-with-mic).
>   svn: Connection closed unexpectedly
> 
> Should this just read
>   svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
> -or- 
>   svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
> instead?

Since I added that info originally, I fixed the section on using [EMAIL 
PROTECTED]
to make this clearer.  Basically, you use it the same way you would use ssh:
give the username if it's different on the remote system, don't bother 
otherwise.

- Tobi

Re: RFC: future gfortran development and subversion

[Tobias Schlüter]

Paul Thomas wrote:
>>>I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
>>>archives, and the docs.  I never came across this solution.
>>>   
>>>
> 
> Could somebody please distill the wisdom from this thread onto the 
> Wiki?  I can understand why Steve might send 5 hours on it.  It's bad 
> that one person winds up doing it and unforgivable if everybody does.
> 
> How about adding to the list of common things that an aspiring 
> contributor might want to do?

I've already added this to the section on svn switch in the wiki.

- Tobi

Re: RFC: future gfortran development and subversion

[Tobias Schlüter]

Steve Kargl wrote:
> On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> 
>>>694Msvn40   <-- svn 4.0 branch 694Msvn41   <-- svn 4.1 branch 694M
>>>trunk   <-- svn mainline
>>>
>>>Now add one or two additional svn directories for large change sets and
>>>this becomes intolerable.  (Before anyone spews "disk space is cheap", I'll
>>>gladly accept any scsi U320 disks you wish to send to me).
>>
>>If you have multiple directories containing the same branch it should
>>be possible to set up a very small svk repository which essentially doesn't
>>more than keep a common pristine copy for all the two or three checkouts you
>>want to keep (i.e. no or only very little history).  A little information on
>>using svk has made it into the wiki, but it's not yet very informative.

Oh yes, this is an interesting question.  In CVS I could just delete
directories that I didn't care about in my local checkout.  Is something like
this possible in svn?  Simply deleting libada results in it being added again
during the next 'svn up'.

- Tobi

Re: RFC: future gfortran development and subversion

[Tobias Schlüter]

[ I've added gcc@ to the CC list and reproduced the message in full, FX
already got the "buy a bigger harddisk" answer there, I think it makes sense
to show that other people care about this, too ]

Steve Kargl wrote:
> I fear the impending switch to subversion will have a negative impact on
> the future development of gfortran due the rather limited number of people
> who actually supply patches and the sudden increase in hardware 
> requirements.   For example, I find
> 
> troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241Mgcc40   <-- CVS 4.0
> branch 275Mgcc41   <-- CVS mainline 694Mtrunk   <-- svn mainline
> 
> gfortran on 4.0 and mainline are sufficiently out of sync that the backport
> of changes is becoming difficult. Additionally, some of us, who have large
> changes or test large changes, have more than one copy of CVS mainline.
> 
> With the impending branch of 4.1, this will look like
> 
> 241Mgcc40   <-- CVS 4.0 branch 275Mgcc41   <-- CVS 4.1 branch 275M
> gcc42   <-- CVS mainline
> 
> which is tolerable (even with a few copies of mainline for large change
> sets).  But, svn would give
> 
> 694Msvn40   <-- svn 4.0 branch 694Msvn41   <-- svn 4.1 branch 694M
> trunk   <-- svn mainline
> 
> Now add one or two additional svn directories for large change sets and
> this becomes intolerable.  (Before anyone spews "disk space is cheap", I'll
> gladly accept any scsi U320 disks you wish to send to me).

If you have multiple directories containing the same branch it should
be possible to set up a very small svk repository which essentially doesn't
more than keep a common pristine copy for all the two or three checkouts you
want to keep (i.e. no or only very little history).  A little information on
using svk has made it into the wiki, but it's not yet very informative.

> Now, to my proposal for future gfortran development post 4.1 branching.
> When (if) svn becomes the source code revision tool, I propose that all
> future work be done solely on mainline.  No individual patches can be
> merged into 4.1.  The 4.0 branch will be dead.  Periodically, say bi-weekly
> or monthly, we do a merge from mainline into 4.1.  The aim is to keep 4.1
> and mainline sufficiently in sync and to minimize the requirements of
> additional hardware (except for the day or two required for the merge) and
> to maximize our time investment.

This should actually be feasible with svn merge, before on cvs this would have
been a tedious task.  I fear that this approach will fail to insufficient
volunteer time, though.

- Tobi

Re: help: interfacing between C and fortran program

[Tobias Schlüter]

Ingo Krabbe wrote:
> Am Mittwoch, 14. September 2005 08:39 schrieb Gaurav Gautam, Noida:
>>I have a function written in fortran say fun(x, y), with x and y as integer
>>(scalars) . Function returns integer.
>>
>>
>>I need to call this function from a C program. How do I do it.
>>Can some one help me.
>>
>>Does Gfortran and gcc support this. ??
...
> # info g77 "Other Languages" "Interoperating"
> 
> There you will find all you need !

Except for a few differences, which will probably not affect you, see the
documentation of the -ff2c command-line option of gfortran.  Additionally,
procedures which require an explicit interface (and which therefore couldn't
be written in Fortran 77) pass array descriptors.  Those are not documented
outside gfortran's source code.

- Tobi

Re: RFA: Darwin x86 alignment

[Tobias Schlüter]

Mark Kettenis wrote:
>From: Dale Johannesen <[EMAIL PROTECTED]>
>Date: Thu, 21 Jul 2005 16:56:01 -0700
> 
>On x86 currently the alignments of double and long long are linked:
>they are either 4 or 8 depending on whether -malign-double is set.
>This follows the documentation of -malign-double.  But it's wrong for
>what we want the Darwin ABI to be:  the default should be that double
>is 4 bytes and long long is 8 bytes.
> 
> I have a strong suspicion there is a reason why the two are linked,
> and that that reason is FORTRAN.  A lot of FORTRAN code assumes
> EQUIVALENCE of floating-point and integer types of equal size.  Such
> code will in all likelyhood break if those types have different
> alignment.  For x86 this means that int/float and long long/double
> will have to have the same alignment.

This might indeed be a problem, as the alignments not only have to be the same
if they appear in an equivalence, but also in arrays or when using the
TRANSFER intrinsic.  Out of the types dicussed, the standard only specifies
this for default INTEGERs (=int in C) and default REALs (=float in C), but
users do expect this to consistently extend to bigger types, otherwise they
consider the compiler buggy instead of their code.

More precisely, the standard says this: a scalar variable of a certain type
occupies a certain number of "storage units".  Default INTEGERs, and REALs
take one storage unit, default COMPLEX and DOUBlE PRECISION (= REAL*8 = double
in C) take two storage units.  Finally, arrays of these types take a sequence
of contiguous storage units.  Details can be found in section 14.6.3 of the
Fortran 95 standard.  These sequences of storage units can be equivalenced
(i.e. a certain overlap between the sequences is requested by the user.  This
is only allowed for variables of the same type, but the extension to different
types is common and widely used).  Furthermore the TRANSFER intrinsic can be
used to copy the binary representation of variable/array A into variable/array
B; it is therefore also sensitive to memory layout.

- Tobi

Re: Build failure under Cygwin_NT-5.0

[Tobias Schlüter]

Paul Thomas wrote:
> Andrew,
> 
> 
>>This is PR 21766.  Patch here: 
>>.
>>
> 
> 
> You will have to explain this to me very slowly, preferably in baby talk

Heh, I thought the same when I read the desription of what happens :-)

- Tobi

Re: GCC 4.0 Freeze

[Tobias Schlüter]

Jack Howarth wrote:
>Even if there were complete g77 compatibility in g95, folks may want
> to stick with the g77 version from gcc 3.4 for awhile purely for
> performance reasons. In doing some test runs of the APBS 
> Adaptive Poisson-Boltzmann Solver program, I discovered that the g95
> built binary runs 60% slower than the g77 built version. This was
> on MacOS X 10.3.8 using the version from Feb 24, 2005.

Can you try to isolate the problem and file a bug report?  I.e. if it is a
problem with gfortran also.

- Tobi

Re: Will people install gfortran in 4.0?

[Tobias Schlüter]

Gerald Pfeifer wrote:
> On Mon, 21 Feb 2005, Tobias Schlüter wrote:
> 
>>>To add a concrete example, unlike g77 in earlier versions of GCC, gfortran 
>>>is not and will not be part of the standard gcc40 port in FreeBSD.
>>
>>Do you have a pointer to where this decision is explained?
> 
> That took place in private e-mail, but I happen to be that maintainer
> of FreeBSD's lang/gcc40 port, so I should be able to recall the relevant 
> points. ;-)

Out of curiosity, what are these points?  Will FreeBSD be shipping g77
instead, or is Fortran simply not important to FreeBSD?

- Tobi

Re: Will people install gfortran in 4.0?

[Tobias Schlüter]

(added [EMAIL PROTECTED] to the CC list, as that is the appropriate list for
this dicussion)

Gerald Pfeifer wrote:
> To add a concrete example, unlike g77 in earlier versions of GCC, gfortran 
> is not and will not be part of the standard gcc40 port in FreeBSD.

Do you have a pointer to where this decision is explained?

Thanks,
- Tobi

Re: Major regression on mainline

[Tobias Schlüter]

Thomas Koenig wrote:
> On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
>>I suspect that the problem is that the transformations fold_indirect_ref_1
>>is doing on arrays don't mix well with how fortran handles arrays.
> 
> 
> I have been trying to look at the problem in the BLAS sources,
> and I find it hard to debug because it goes away when print
> statements are added to the source (I hate that...)
> 
> Anyway, this looks like a character-related failure.  The first error
> in the single precision level 2 BLAS routines is the following:

Your analysis is correct, see http://gcc.gnu.org/PR20030 :-) A fix has already
been committed.

Regards,
- Tobi