Re: Make missing headers fatal (PR 15638)

On Tue, 31 Mar 2009, Manuel López-Ibáñez wrote:

> 2009/3/31 Joseph S. Myers <joseph <at> codesourcery.com>:
> > Having made cpplib use the compiler's diagnostic.c, making missing
> > headers an unconditional fatal error (as discussed in PR 15638) is
> > straightforward.  I've committed this patch; bootstrapped with no
> > regressions on i686-pc-linux-gnu.  (Fortran part committed as
> > obvious.)
> 
> This is a substantial change of behaviour. It needs to be documented
> in gcc-4.5/changes.html, please.

I have added this release note.

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.2
diff -u -r1.2 changes.html
--- changes.html	28 Mar 2009 07:37:09 -0000	1.2
+++ changes.html	1 Apr 2009 01:00:20 -0000
@@ -32,6 +32,13 @@

 <h3>C family</h3>

+  <ul>
+    <li>If a header named in a <code>#include</code> directive is not
+    found, the compiler exits immediately.  This avoids a cascade of
+    errors arising from declarations expected to be found in that
+    header being missing.</li>

[patch, fortran-dev] PR29962 - more simplifiers for transformational intrinsics

Attached patch adds simplifiers for transformational intrinsics ALL, ANY, 
COUNT, PRODUCT and SUM.

2009-04-01  Daniel Franke  <franke.daniel <at> gmail.com>

	PR fortran/25104
	PR fortran/29962
	* check.c (gfc_check_all_any): Check rank of DIM.
	(gfc_check_count): Likewise.
	* intrinsic.h (gfc_simplify_all): New prototype.
	(gfc_simplify_any): Likewise.
	(gfc_simplify_count): Likewise.
	(gfc_simplify_sum): Likewise.
	(gfc_simplify_product): Likewise.
	* intrinsic.c (add_functions): Added new simplifier callbacks.
	* simplify.c (transformational_result): New.
	(simplify_transformation_to_scalar): New.
	(simplify_transformation_to_array): New.
	(gfc_count): New.
	(gfc_simplify_all): New.
	(gfc_simplify_any): New.
	(gfc_simplify_count): New.
	(gfc_simplify_sum): New.
	(gfc_simplify_product): New.
	* expr.c (check_transformational): Allow additional transformational
	intrinsics in initialization expression.

2009-04-01  Daniel Franke  <franke.daniel <at> gmail.com>

[patch, fortran-dev] minimise static buffer usage for conformance check

In

	http://gcc.gnu.org/ml/fortran/2009-03/msg00323.html

Steve commented on the use of static buffers[80] for multiple symbol names, 
each with an allowed length of 63 characters each. This patch changes 
gfc_check_conformance() to a printf()-like syntax. Now, there's only one big 
static buffer in the function, instead of one small buffer for each caller.

2009-04-02  Daniel Franke  <franke.daniel <at> gmail.com>

	* gfortran.h (gfc_check_conformance): Modified prototype to printf-style.
	* expr.c (gfc_check_conformance): Accept error-message chunks in 
	printf-style. Changed all callers.

Bootstrapped and regression tested on i686-pc-linux-gnu. 
Ok for dev-branch and trunk?

Cheers

	Daniel

Index: gfortran.h
===================================================================
--- gfortran.h	(revision 145368)
+++ gfortran.h	(working copy)
@@ -2442,7 +2442,7 @@ gfc_try gfc_specification_expr (gfc_expr
 int gfc_numeric_ts (gfc_typespec *);

Implementing BLOCK

Hi all,

I was just thinking about ideas for implementing the Fortran 2008 BLOCK 
construct; that could be an interesting thing to do in parallel to the 
OOP stuff.

As I understand it (but haven't yet read the standard/draft about it), 
the main semantics of BLOCK is that it allows declaration of variables 
limited to an arbitrary smaller scope inside a procedure.  Another thing 
is that F2008 allows EXIT to also jump out of BLOCKs (and IF I guess, 
too?), but that should be a minor issue for implementation (seems so to 
me at least).

I believe it should be relatively straight-forward to implement a basic 
BLOCK concept; in gfortran's data structure, we could make BLOCKs new 
EXEC-codes which reference a namespace/symtree containing the variable 
declarations as well as inner code.  I hope that approach could reuse a 
lot of code already in place, for instance doing the trans'ing of local 
variable declarations as would be done at the start of a procedure.

Haven't checked the standard, but I would bet this is also allowed with 
BLOCK (and would make it nice to have, IMHO):

INTEGER :: n

...

n = <some number, not constant>

BLOCK

[ANNOUNCE] Trunk freeze for alias-improvements branch Fri. Apr. 3rd 8am UTC

The trunk will be frozen for the merge of the alias-improvements branch
tomorrow, Friday, April 3rd starting 8am UTC.  I will do a last merge
to the branch at that point, do a bootstrap & regtest cycle and
finally commit the merge to trunk.

Thanks for your cooperation.

Richard.

--

-- 
Richard Guenther <rguenther <at> suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: Implementing BLOCK

On Thu, Apr 02, 2009 at 12:27:33PM +0200, Daniel Kraft wrote:
> 
> I was just thinking about ideas for implementing the Fortran 2008 BLOCK 
> construct; that could be an interesting thing to do in parallel to the 
> OOP stuff.
> 

While I can't stop you or anyone else from working on
some piece of code, I'll note:

1) F2008 is not an approved standard.  It is subject to
   to change and anything you implement may become 
   incompatiable when F2008 is finally ratified.  This
   then would mean gfortran would have to carry around
   a vendor extension.

2) An enormous amount of the official F2003 Standard
   remains to be implemented.  Surely, there is some
   unimplemented item in this Standard that could benefit
   from your your attention.

--

-- 
Steve

Re: Implementing BLOCK

Hi Steve,

thanks for your comments!  I agree with you, but please let me clarify 
some things why I had this in mind:

Steve Kargl wrote:
> While I can't stop you or anyone else from working on
> some piece of code, I'll note:
> 
> 1) F2008 is not an approved standard.  It is subject to
>    to change and anything you implement may become 
>    incompatiable when F2008 is finally ratified.  This
>    then would mean gfortran would have to carry around
>    a vendor extension.

Well, I think it is good for the standard/draft to maybe get some 
feedback and comments either through people testing the ideas proposed 
or through questions/concerns raised in the development process.  Simply 
waiting for the standard to be finished before work and concern on our 
side starts is surely not the most productive way to go?

But I agree we do not want to carry around vendor extensions--so I'd 
propose that our F2008 implementations are declared experimental and we 
should feel free to abandon any behaviour implemented should the 
standard change; so no promise for backwards-compatibility here.  Anyone 
using those features is very welcome to test them out, but should note 
that his code might break when the standard changes and gfortran 
re-implements the behaviour.  (Similar to our accepting TYPE() 
passed-object dummy arguments for TBPs at the moment; it was clear from 
the beginning that we won't support this as an extension for the future 

Re: Implementing BLOCK

Hi Daniel and Steve,

Daniel Kraft wrote:
> Steve Kargl wrote:
>> 1) F2008 is not an approved standard.  It is subject to to change and
>> anything you implement may become    incompatiable when F2008 is
>> finally ratified.  This then would mean gfortran would have to carry
>> around a vendor extension.

It is very unlikely to see substantial changes. It is not merely a
working draft but already a candidate draft (CD), which passed already
the first round of comments of the ISO member states: "The CD ballot
votes [...] were 8 for approval, 3 for abstention (France, Japan,
Spain), 3 for approval with comments (Canada, Germany, USA) and 1 (UK)
for disapproval. This means that the draft is registered with ITTF". The
first resolution meeting in Tokyo has also passed and the current draft
N1760 already incorporates the changes. However, until the standard is
published it will take until mid 2010. See
http://www.nag.co.uk/sc22wg5/, especially N1776 (current draft) and
N1693 (schedule).

> Well, I think it is good for the standard/draft to maybe get some
> feedback and comments either through people testing the ideas proposed
> or through questions/concerns raised in the development process. 
> Simply waiting for the standard to be finished before work and concern
> on our side starts is surely not the most productive way to go?

It depends, I would be careful not to implement stuff which is disputed.
I like to see some items of the draft of the Technical Report (TR) 29113
for further interoperability with C be implemented, but at leasts parts

[Patch, Fortran] PR39594 - 4.3/4.4 regression with COMMON variable as actual argument

Hello all,

as Jakub has found out the problem was introduced when procedure
pointers in COMMON were supported. Before every COMMON member was had
also the flavour FL_VARIABLE, but with procpointer it stayed FL_UNKNOWN.

The patch does do two things:

a) It added the FL_VARIABLE flavour in resolve.c - here one already
knows that it can never become a proc pointer. (That patch is nice, but
it does not help with the regression; I still think it belongs there for
completeness.)

b) It does something similar in primary.c. It took me a while to realize
that although sym->referenced is set, this does not become fully active
as for FL_UNKNOWN some settings are reset. Again, setting the flavour is
not needed, but I think it is cleaner to do so before doing a "break".

Build and being regtested on x86-64-linux.  OK for the 4.5 trunk and for
the 4.4? (I assume there is nothing from the RM side which speaks
against it?)

Tobias

Re: [Patch, Fortran] PR39594 - 4.3/4.4 regression with COMMON variable as actual argument

For someone being employed at a virtual institute, having a virtual
patch should be OK. But maybe you prefer an actual patch 

Tobias

Tobias Burnus wrote:
> Hello all,
>
> as Jakub has found out the problem was introduced when procedure
> pointers in COMMON were supported. Before every COMMON member was had
> also the flavour FL_VARIABLE, but with procpointer it stayed FL_UNKNOWN.
>
> The patch does do two things:
>
> a) It added the FL_VARIABLE flavour in resolve.c - here one already
> knows that it can never become a proc pointer. (That patch is nice, but
> it does not help with the regression; I still think it belongs there for
> completeness.)
>
> b) It does something similar in primary.c. It took me a while to realize
> that although sym->referenced is set, this does not become fully active
> as for FL_UNKNOWN some settings are reset. Again, setting the flavour is
> not needed, but I think it is cleaner to do so before doing a "break".
>
> Build and being regtested on x86-64-linux.  OK for the 4.5 trunk and for
> the 4.4? (I assume there is nothing from the RM side which speaks
> against it?)
>
> Tobias
>