Re: How does a target make Fortran work?

[Janus Weil]

Hi Paul,

Fortran problems are best discussed on fort...@gcc.gnu.org (in CC) ...

2018-07-12 21:22 GMT+02:00 Paul Koning :
> I tried to rebuild for target pdp11 with fortran enabled (in the past I've 
> just enabled C).  It builds fine but the resulting compiler crashes at 
> startup:
>
> Paul-Konings-MacBook-Pro:gcc pkoning$ ./xgcc -B. -O2 -S ../../hello.f
> f951: internal compiler error: gfc_validate_kind(): Got bad kind
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
> "hello.f" is the typical "hello world" program.  Some debugging got me to 
> here:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
> frame #0: 0x0001001c1c93 f951`gfc_init_kinds() [inlined] 
> gfc_validate_kind(type=BT_REAL, kind=, may_fail=false) at 
> trans-types.c:814 [opt]
>811  }
>812
>813if (rc < 0 && !may_fail)
> -> 814  gfc_internal_error ("gfc_validate_kind(): Got bad kind");
>815
>816return rc;
>817  }
> Target 0: (f951) stopped.
>
> So it's unhappy about some "kind", for BT_REAL.  I'm not sure what that 
> means.  Is it mapping the available data types to Fortran "KIND" values?  If 
> so, is there something the target has to do for this to work?  Note that this 
> isn't an IEEE target, so if the initialization is expecting IEEE float then 
> that may account for it.  But I have no idea what to do here, and the manual 
> offers no clue.

A "kind" in Fortran is the size of the data type in bytes. E.g.
"real(kind=4)" would be a 'single-precision' 32-bit float number,
while "real(kind=8)" would be a 'double-precision' 64-bit float
number. The default kind for REAL variables is 4 in gfortran, see:

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/KIND-Type-Parameters.html

Since pdp-11 seems to be a 16-bit platform, such a 32-bit
floating-point type might not be available there? Possibly it makes
sense to set the default REAL kind to 2 for such a target?

Cheers,
Janus

Re: Good news, bad news on the repository conversion

[Janus Weil]

2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> David Edelsohn :
>> > The truth is we're near the bleeding edge of what conventional tools
>> > and hardware can handle gracefully.  Most jobs with working sets as
>> > big as this one's do only comparatively dumb operations that can be
>> > parallellized and thrown on a GPU or supercomputer.  Most jobs with
>> > the algorithmic complexity of repository surgery have *much* smaller
>> > working sets.  The combination of both extrema is hard.
>>
>> If you come to the conclusion that the GCC Community could help with
>> resources, such as the GNU Compile Farm or paying for more RAM, let us
>> know.
>
> 128GB of DDR4 registered RAM would allow me to run conversions with my
> browser up, but be eye-wateringly expensive.  Thanks, but I'm not
> going to yell for that help

I for one would certainly be happy to donate some spare bucks towards
beastie RAM if it helps to get the GCC repo converted to git in a
timely manner, and I'm sure there are other GCC
developers/users/sympathizers who'd be willing to join in. So, where
do we throw those bucks?

Cheers,
Janus

Re: Good news, bad news on the repository conversion

[Janus Weil]

2018-07-09 2:27 GMT+02:00 Eric S. Raymond :
> There is good news bad news on the GCC repository conversion.
>
> The good news is that I have solved the only known remaining technical
> problem in reposurgeon blocking the conversion.  I've fixed the bug
> that prevented execute permissions from being carried by branch
> copies.

Great to hear that there is progress on that front!


> The bad news is that my last test run overran the memnory capacity of
> the 64GB Great Beast.  I shall have to find some way of reducing the
> working set, as 128GB DD4 memory is hideously expensive.

Or maybe you could use a machine from the GCC compile farm?

According to https://gcc.gnu.org/wiki/CompileFarm, there are three
machines with at least 128GB available (gcc111, gcc112, gcc119).

Cheers,
Janus

Re: Google Summer of Code 2018: Call for mentors and ideas

[Janus Weil]

Hi Christopher,

2018-02-15 11:52 GMT+01:00 Christopher Dimech :
> I am the administrator of GNU Behistun, a package designed
> to image the internal constituents of the subsurface using seismic waves.
> It is written in Fortran and uses gfortran. I am not sure how well you
> think it fits in your GSoC project. Does related work under your proposal
> have to focus on development of the gcc compiler itself, or would it also
> allow work on peripheral associations.

I don't quite think this is appropriate for GCC as a mentoring org. It
might fit better under the "GNU" umbrella, which also seems to be a
mentoring org in this year's GSoC and lists all kinds of GNU projects:

https://www.gnu.org/software/soc-projects/ideas-2018.html

Cheers,
Janus



> -
> Christopher Dimech
> GNU Behistun Chief Administrator
> - Geophysical Simulation
> - Geological Subsurface Mapping
> - Disaster Preparedness and Mitigation
> - Natural Resource Exploration and Exploitation
>
>
>> Sent: Tuesday, February 13, 2018 at 2:01 PM
>> From: "Martin Jambor" 
>> To: gcc@gcc.gnu.org
>> Subject: Re: Google Summer of Code 2018: Call for mentors and ideas
>>
>> Hi,
>>
>> I am happy to announce that we were selected as a Google Summer of Code
>> 2018 mentor organization.
>>
>> At this point I am being asked to "invite mentors," so I will soon
>> invite all the people who have expressed interest in the January email
>> thread (or on IRC).
>>
>> If anybody has an additional idea for a GSoC project, please share it
>> with us here and perhaps also add it to the Wiki page.
>>
>> If anybody else thinks of being a mentor this year, please write me an
>> email, the sooner the better.  I suspect that a google account is
>> mandatory, though.
>>
>> Any other ideas/comments/suggestions are also welcome.
>>
>> Martin
>>

Re: Google Summer of Code 2018: Call for mentors and ideas

[Janus Weil]

Hi Martin,

> I am happy to announce that we were selected as a Google Summer of Code
> 2018 mentor organization.

good to hear!


> At this point I am being asked to "invite mentors," so I will soon
> invite all the people who have expressed interest in the January email
> thread (or on IRC).
>
> If anybody has an additional idea for a GSoC project, please share it
> with us here and perhaps also add it to the Wiki page.
>
> If anybody else thinks of being a mentor this year, please write me an
> email, the sooner the better.

I'd be happy to (co-)mentor any Fortran-related project, should one come up.

Cheers,
Janus

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

2016-12-16 19:46 GMT+01:00 Pedro Alves :
 And in particular: How do the current uses of
 std::string in GCC deal with this problem? (Do they?)
>>>
>>> Doesn't look like they do.
>>
>> Huh, that's a problem then, isn't it?
>
> Right.  The easiest way to trigger it I think is if something
> computes some size incorrectly, and calls for example string::reserve(-1)
> or string::resize(-1) by mistake (likewise for std::vector, etc.).
> malloc will fail, new will throw bad_alloc, and GCC will abort and
> maybe generate a core dump, instead of gracefully printing
> something like:
>
>cc1: out of memory allocating  bytes ...
>
> and existing with error status.

So, it seems like it would be a good idea to follow your suggestion
from PR 78822:


> You can replace the global operator new/new[] to call xmalloc instead of 
> malloc.
> Then memory allocation by std::string etc. ends up in xmalloc -> 
> xmalloc_failed.
> That's what I did for GDB:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/common/new-op.c;h=c67239cbe87c1f7e22e234a1a2cc2920f9ed22a4;hb=HEAD

I'm certainly not the right person to implement this in GCC, though
(and I'll probably discard my idea of using std::string for PR 78822
and follow the alternative implementation from comment 14).

But I think that, given the amount of STL containers already used in
GCC, it should definitely be clarified whether this is necessary ...

Cheers,
Janus

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

2016-12-16 18:53 GMT+01:00 Pedro Alves :
> On 12/16/2016 05:33 PM, Janus Weil wrote:
>
>> "You would need to make sure it uses a xmalloc based allocator first
>> or at least calls xmalloc_failed upon allocation failure, otherwise it
>> will be a serious regression."
>>
>> I'm really not an expert on GCC's memory management principles and how
>> it uses xmalloc over malloc. I'd love to hear further comments on the
>> above sentence (e.g. whether that is really necessary, and if yes, how
>> to accomplish it).
>
> I gave a suggestion in the PR.
>
> Basically, you can replace the global operator new to call xmalloc
> instead of malloc.  See the GDB url in the PR for an example.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822#c19

Thanks for the comment!


>> And in particular: How do the current uses of
>> std::string in GCC deal with this problem? (Do they?)
>
> Doesn't look like they do.

Huh, that's a problem then, isn't it?

Cheers,
Janus

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

To get to more specific questions ...

> Basically the only STL construct used in the Fortran FE right now
> seems to be std::swap, and a single instance of std::map in
> trans-common.c.

I see that fortran/trans-common.c has:

#define INCLUDE_MAP

and apparently there is also a INCLUDE_STRING macro. I guess if I want
to use std::string I don't #include , but #define
INCLUDE_STRING, right? Why are those macros needed, exactly?

Cheers,
Janus

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

Hi Nick,

2016-12-16 18:16 GMT+01:00 N.M. Maclaren :
> On Dec 16 2016, Janus Weil wrote:
>>
>> What I'd like to know is: In the current state of things in GCC, is it
>> possible/reasonable to use any of the STL containers (like
>> std::vector, std::string, whatever) in GCC and its front ends (in
>> particular gfortran)?
>>
>> That question has two parts:
>> 1) Is it technically possible at all? Are there drawbacks/pitfalls?
>> (In particular Jakub mentioned possible memory management issues, i.e.
>> xmalloc vs malloc etc.)
>
>
> I can say something about this, which is not gcc-specific.  The executive
> summary is that there shouldn't be any problem if you KISS, but heaven
> help you if you don't.

thanks for this lengthy comment, but that's really not the kind of
discussion I wanna get into here. (And I don't actually agree to all
of your points, but that doesn't matter.)

What I want to discuss is deeply GCC-specific, the central point
being: If I use some STL container in one of the front ends (like
gfortran), does that mess with GCC's idea of memory management? To
quote Jakub from PR 78822, commenting on my proposal to use
std::string in gfortran:

"You would need to make sure it uses a xmalloc based allocator first
or at least calls xmalloc_failed upon allocation failure, otherwise it
will be a serious regression."

I'm really not an expert on GCC's memory management principles and how
it uses xmalloc over malloc. I'd love to hear further comments on the
above sentence (e.g. whether that is really necessary, and if yes, how
to accomplish it). And in particular: How do the current uses of
std::string in GCC deal with this problem? (Do they?)

Cheers,
Janus

using C++ STL containers in GCC/gfortran source code

[Janus Weil]

Hi all,

I recently ran into some discussion with Jakub about using std::string
in gfortran (see PR 78822), which got me curious about some general
points ...

What I'd like to know is: In the current state of things in GCC, is it
possible/reasonable to use any of the STL containers (like
std::vector, std::string, whatever) in GCC and its front ends (in
particular gfortran)?

That question has two parts:
1) Is it technically possible at all? Are there drawbacks/pitfalls?
(In particular Jakub mentioned possible memory management issues, i.e.
xmalloc vs malloc etc.)
2) If technically possible, is it encouraged? I didn't find any
statement about STL in the GCC coding conventions
(https://gcc.gnu.org/codingconventions.html).

Looking through the current GCC code base, it seems that mostly the Go
FE is making extensive use of the things like std::string and
std::vector, while other parts only use such things rarely.

Basically the only STL construct used in the Fortran FE right now
seems to be std::swap, and a single instance of std::map in
trans-common.c. Would there be a general problem with using
std::string in gfortran?

Cheers,
Janus

Re: wiki syntax changes?

[Janus Weil]

2016-12-14 12:33 GMT+01:00 Jakub Jelinek :
> On Wed, Dec 14, 2016 at 12:21:11PM +0100, Janus Weil wrote:
>> 2016-12-14 11:49 GMT+01:00 Jakub Jelinek :
>> > On Wed, Dec 14, 2016 at 11:26:45AM +0100, Janus Weil wrote:
>> >> I have recently noticed some changes in the appearance of these wiki 
>> >> pages:
>> >>
>> >> https://gcc.gnu.org/wiki/Fortran2003Status
>> >> https://gcc.gnu.org/wiki/Fortran2008Status
>> >>
>> >> The tables on these pages use HTML-like formatting tags like
>> >>
>> >> 
>> >>
>> >> which certainly have been working in the past, but now seem to be ignored.
>> >>
>> >> https://gcc.gnu.org/wiki/HelpOnMoinWikiSyntax#HTML-like_Options_for_Tables
>> >>
>> >> lists at least the bgcolor option, which just as the other two has
>> >> stopped working (while coloring tags like <#FF> still work). Can
>> >> anyone tell me why this happened and what to do about it?
>> >
>> > See e.g. https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01471.html
>> > and related discussions and www patches.
>> > Basically, all the formatting etc. stuff now has to come from a CSS,
>> > i.e. class=whatever where whatever is define in gcc.css.
>>
>> I see. Thanks for the comment, Jakub.
>>
>> I guess for the 'static' web pages using a CSS file is no big deal,
>> but for the wiki this doesn't sound like a very flexible solution. As
>> mentioned, there is a workaround for the color, and I hope one can
>> also find workarounds for the other items (width & tablewidth).
>>
>> Do we already have a gcc.css, and if yes where?
>
> There is gcc.css in the wwwdocs CVS repo.  But looking at the wiki pages,
> I see just:
>  href="/moin_static199/modern/css/common.css">
>  href="/moin_static199/modern/css/screen.css">
>  href="/moin_static199/modern/css/print.css">
>  href="/moin_static199/modern/css/projection.css">
> being included.  Dunno who configured the wiki, and if it would be possible to
> add a gcc specific gcc-wiki.css or something similar.  I think Gerald as the
> web maintainer would be the best person to talk to.

Well, from my side it's not worth to put much effort into this right
now. I have worked around the issues on the mentioned pages in other
ways.

If the removal of support for HTML tags creates problems on other wiki
pages as well, then one should probably think about adding a
gcc-wiki.css (if possible). Not sure if that's the case.

Btw, https://gcc.gnu.org/wiki/HelpOnThemes mentions a "clever idea to
make CSS wiki editable", which sounds like a useful idea to me (if I
understand it correctly).

Cheers,
Janus

Re: wiki syntax changes?

[Janus Weil]

2016-12-14 11:49 GMT+01:00 Jakub Jelinek :
> On Wed, Dec 14, 2016 at 11:26:45AM +0100, Janus Weil wrote:
>> I have recently noticed some changes in the appearance of these wiki pages:
>>
>> https://gcc.gnu.org/wiki/Fortran2003Status
>> https://gcc.gnu.org/wiki/Fortran2008Status
>>
>> The tables on these pages use HTML-like formatting tags like
>>
>> 
>>
>> which certainly have been working in the past, but now seem to be ignored.
>>
>> https://gcc.gnu.org/wiki/HelpOnMoinWikiSyntax#HTML-like_Options_for_Tables
>>
>> lists at least the bgcolor option, which just as the other two has
>> stopped working (while coloring tags like <#FF> still work). Can
>> anyone tell me why this happened and what to do about it?
>
> See e.g. https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01471.html
> and related discussions and www patches.
> Basically, all the formatting etc. stuff now has to come from a CSS,
> i.e. class=whatever where whatever is define in gcc.css.

I see. Thanks for the comment, Jakub.

I guess for the 'static' web pages using a CSS file is no big deal,
but for the wiki this doesn't sound like a very flexible solution. As
mentioned, there is a workaround for the color, and I hope one can
also find workarounds for the other items (width & tablewidth).

Do we already have a gcc.css, and if yes where?

Cheers,
Janus

wiki syntax changes?

[Janus Weil]

Hi all,

I have recently noticed some changes in the appearance of these wiki pages:

https://gcc.gnu.org/wiki/Fortran2003Status
https://gcc.gnu.org/wiki/Fortran2008Status

The tables on these pages use HTML-like formatting tags like



which certainly have been working in the past, but now seem to be ignored.

https://gcc.gnu.org/wiki/HelpOnMoinWikiSyntax#HTML-like_Options_for_Tables

lists at least the bgcolor option, which just as the other two has
stopped working (while coloring tags like <#FF> still work). Can
anyone tell me why this happened and what to do about it?

Cheers,
Janus

Re: Vandalised wiki page

[Janus Weil]

>> Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
>> is being spammed a lot. Somebody should employ some kind of spam protection.
>
> The attack is still ongoing, CC'ing overseers

In fact the spam level on the wiki has been rather high for some time
now, but since yesterday it practically exploded. We should definitely
think about some way to prevent this (cf. e.g.
http://moinmo.in/AntiSpamFeatures). Is it feasible to require new wiki
accounts be authorized by an admin?

Cheers,
Janus

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Janus Weil]

>> I think one should handle member functions (cf. example below). I am not
>> sure whether other things
>> like type extension or accessibility should be handled.
>
> DWARF has attributes for accessibility (e.g., public, private).  If the
> attributes are similar to those for C++, you should generate them in a
> similar fashion.

I would say they are sufficiently similar in order to also use them for Fortran.


> I'm not sure what "type extension" means.

Well, this is just the Fortran terminology for what would be called
'inheritance' in C++.


> You might translate the Fortran program into comparable C++ and
> see what g++ generates, then try to match it with gfortran.

That might be a good starting point. Thanks for your comments.

Cheers,
Janus

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Janus Weil]

Hi Tobias,

> during the GCC Gathering I realized during the LTO debugging symbol
> discussion that gfortran does not generate debug information for the OOP
> features (cf. PR 49475).

Btw, how was the London meeting? Anything interesting to report (Fortran-wise)?


> The first issue to solve is which DWARF information one should generate. I
> have only very limited knowledge of DWARF, except that I quickly scanned
> "5.5.3 Derived or Extended Structs, Classes and Interfaces" and "5.5.7
> Member Function Entries" (of http://www.dwarfstd.org/doc/DWARF4.pdf).
>
> I think one should handle member functions (cf. example below). I am not
> sure whether other things like type extension or accessibility should be
> handled.

Well, in principle all of those should be handled, I guess.

I don't have any experience with DWARF either, but maybe I'll look
into it, once I have gotten some of the more nasty OOP
bugs/regressions out of the way.

How would one tackle this practically? All the DWARF stuff is
generated in the middle-end, I assume (and probably the type
extension/member function info is already there for C++, right?). So,
the question is: What do we need to do in the front end, in order to
make the middle-end emit the right DWARF info?

Cheers,
Janus

Re: Original commit history for gfortran

[Janus Weil]

2011/6/19 "C. Bergström" :
> In this case I serve the end user/community and not directly open source.
>  Why?  Would it be good for Fortran if a F2K3 front-end was freely available
> under a commercially friendly license?  (This is a deeper question I'd love
> feedback on)

From my point of view a freely available F2K compiler is the only hope
for something like a "Fortran community" to keep exisiting (or even
for the language itself to survive). Of course this does not mean at
all that there is no space for high-quality commercial compilers. I
even think that the commercial compiler vendors might profit from the
existence of a freely available compiler.

Note that right now we have barely *any* compiler which can claim to
have a complete F2K implementation (though a few are quite close).
Among the freely available ones, gfortran is surely the one which is
closest.


>    a. I see people moving away from Fortran and more towards C++.  (Sorry no
> empirical data to back this, but how do we stop this trend)

This is surely true. The only way to stop it is to provide a Fortran
implementation of those features that make C++ so attractive (e.g.
object orientation, etc). Such an implementation must be freely
available and on the same quality level as, say, g++.


>    d. Would there be any negative impact to gfortran if PGI/Intel took the
> front-end?  (Or even worse PathScale *gasp*)

What exactly do you mean by "taking" the front-end?


> Not all commercial companies are bad (Redhat, Canonical.. etc).  From my
> perspective it's commercial companies that generally pay people to work full
> time and get real engineering in open source done.

Agreed. Another example being Google, which helped me a lot to
contribute to gfortran (via several Summer of Code stipends).


> 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.

If you want this discussion to take a more positive direction, maybe
you should try to explain your intentions a bit more clearly instead
of making cloudy allusions. What exactly are you aiming for?

Cheers,
Janus

Re: Accepted applications for Google Summer of Code 2010

[Janus Weil]

> This year GCC received 10 slots for Google Summer of Code.  The full
> list of the accepted projects is at
> http://gcc.gnu.org/wiki/SummerOfCode.

A quick question: Why is this list not available on the GSoC site for GCC?

http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gcc

For other projects, one can find the list of accepted proposals on
their page, but not so for GCC (where instead one still sees the
application template). Is this something the GCC mentors can influence
in the web app, or should one contact the Google/Melange folks about
this issue?


> Congratulations to all the accepted applications.  Looking forward to
> all those contributions!

I want to say thanks for being accepted again. This is already the
fourth time I'm participating, and it has always been a pleasure to
work with the GCC community (and especially the gfortran
sub-community).

Cheers,
Janus

Fwd: static linking on Cygwin

[Janus Weil]

I'm redirecting my question here, since it also applies to "gcc
-static" on Cygwin.

Cheers,
Janus



-- Forwarded message ------
From: Janus Weil 
Date: 2010/4/23
Subject: static linking on Cygwin
To: gfortran 


Hi all,

I have just tried the gfortran 4.3.4 build on Cygwin/WinXP (I'm not a
regular Windows/Cygwin user though).

One thing I noticed is that compiling with -static fails:

/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_

It works, however, when adding -static-libgcc. On Linux compiling with
-static works fine, also without -static-libgcc. Can someone explain
this behaviour to me? Is this a feature or a bug?

Cheers,
Janus

Re: MPC version 0.8 released!

[Janus Weil]

> Please test this version and report back in this thread (not to me
> privately) the results of "make check".  Also include your target triplet,
> and the versions of your compiler, gmp and mpfr.

I just tested on i386-apple-darwin10.0.0 with:

 * gcc version 4.2.1 (Apple Inc. build 5646)
 * GMP 4.3.1
 * MPFR 2.4.1

===
All 57 tests passed
===

Cheers,
Janus

Re: Fortran bootstrap broken

[Janus Weil]

2009/5/18 Janus Weil :
> 2009/5/18 Tobias Burnus :
>> Can you try whether the following patch works? If so, you can
>> commit it as obvious. (I cannot test/commit it until this evening.)
>>
>> Tobias
>>
>> Index: intrinsic.c
>> ===
>> --- intrinsic.c (revision 147659)
>> +++ intrinsic.c (working copy)
>> @@ -303,7 +303,7 @@
>>       type = (bt) va_arg (argp, int);
>>       kind = va_arg (argp, int);
>>       optional = va_arg (argp, int);
>> -      intent = va_arg (argp, int);
>> +      intent = (sym_intent) va_arg (argp, int);
>>
>>       if (sizing != SZ_NOTHING)
>>        nargs++;
>
> This seems to work. I will commit it.

Sendinggcc/fortran/ChangeLog
Sendinggcc/fortran/intrinsic.c
Transmitting file data ..
Committed revision 147662.

Re: Fortran bootstrap broken

[Janus Weil]

2009/5/18 Tobias Burnus :
> Can you try whether the following patch works? If so, you can
> commit it as obvious. (I cannot test/commit it until this evening.)
>
> Tobias
>
> Index: intrinsic.c
> ===
> --- intrinsic.c (revision 147659)
> +++ intrinsic.c (working copy)
> @@ -303,7 +303,7 @@
>       type = (bt) va_arg (argp, int);
>       kind = va_arg (argp, int);
>       optional = va_arg (argp, int);
> -      intent = va_arg (argp, int);
> +      intent = (sym_intent) va_arg (argp, int);
>
>       if (sizing != SZ_NOTHING)
>        nargs++;

This seems to work. I will commit it.

I'm really sorry I broke bootstrap. I usually don't test my Fortran
patches with a full bootstrap (to save time), since I assumed
bootstrapping would not be essential for the Fortran front end.

Sorry for the inconvenience,
Janus

Re: New GNU Fortran reviewers.

[Janus Weil]

> So I welcome Daniel, Janus and Mikael in our ranks.

Thanks for the promotion :)

Re: build error from trunk sources

[Janus Weil]

Building trunk rev. 139857 on linux/x86_64, I get the following failure:

...
cc1: warnings being treated as errors
/home/local/jweil/gcc44/trunk/gcc/sel-sched-ir.c:946: error:
'cmp_v_in_regset_pool' defined but not used
...

Cheers,
Janus


2008/9/1 M R Swami Reddy <[EMAIL PROTECTED]>:
> Hello,
>
> I am trying the build the crx-elf target gcc compiler tools from gcc trunk
> sources, but the below error message displayed.
>
> Could any one suggest the reason for build fail?
>
> ===Error log
> In file included from /trunk/gcc/sel-sched-dump.c:37:
> /trunk/gcc/sel-sched-ir.h:93: error: expected specifier-qualifier-list
> before āds_tā
> /trunk/gcc/sel-sched-ir.h:137: error: expected specifier-qualifier-list
> before āds_tā
> /trunk/gcc/sel-sched-ir.h:239: error: expected specifier-qualifier-list
> before ādeps_tā
> /trunk/gcc/sel-sched-ir.h:280: error: expected specifier-qualifier-list
> before ādeps_tā
> /trunk/gcc/sel-sched-ir.h:369: error: expected ā=ā, ā,ā, ā;ā, āasmā or
> ā__attribute__ā before āsched_lists_poolā
> /trunk/gcc/sel-sched-ir.h: In function ā_list_allocā:
> /trunk/gcc/sel-sched-ir.h:374: warning: implicit declaration of function
> āpool_allocā
> /trunk/gcc/sel-sched-ir.h:374: error: āsched_lists_poolā undeclared (first
> use in this function)
> ===
>
> Thanks
> Swami

Re: Current failures on Cygwin

[Janus Weil]

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

Re: failed to compile trunk svn rev 126124

[Janus Weil]

Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127.



2007/6/29, Basile STARYNKEVITCH <[EMAIL PROTECTED]>:

Is it just me, or not?

On my system (Debian/Sid/AMD64 with gcc = 4.1.2 from Debian)

.
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/src/Lang/gcc-trunk/_Obj/build-x86_64-unknown-linux-gnu/fixincludes'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libcpp'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/libdecnumber'
make[3]: Entering directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H 
-I. -I. -I/usr/src/Lang/gcc-trunk/gcc
-I/usr/src/Lang/gcc-trunk/gcc/. -I/usr/src/Lang/gcc-trunk/gcc/../include 
-I/usr/src/Lang/gcc-trunk/gcc/../libcpp/include
  -I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber 
-I/usr/src/Lang/gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber
/usr/src/Lang/gcc-trunk/gcc/cse.c -o cse.o
/usr/src/Lang/gcc-trunk/gcc/cse.c:7015: error: 'TODO_verify_rtl_sharing' 
undeclared here (not in a function)
make[3]: *** [cse.o] Error 1
make[3]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/usr/src/Lang/gcc-trunk/_Obj'
make: *** [all] Error 2

Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Google Summer of Code: Mentor wanted for Fortran project

[Janus Weil]

Hello,

I just applied to Google Summer of Code for working on GCC this summer. 
I want to implement some Fortran 2003 features, in particular procedure 
pointers and type-bound procedures. You can find my complete application 
at http://www.stud.uni-giessen.de/~su5092/gsoc/application.pdf


Now I learned that there are currently no Fortran developers signed up 
as SoC mentors for GCC. It would be really great if someone with a 
decent knowledge of gfortran would be willing to be my mentor, so I can 
work on this project. This really wouldn't take up too much of your 
time. I just need someone to answer some of my questions every now and 
then and to give me some hints on how to proceed.


For more info on the SoC program, check out http://code.google.com/soc/. 
I would be very grateful if someone could do the job. I really think 
gfortran urgently needs some decent object oriented features.


Cheers,
Janus