headers
Jerry DeLisle | 1 Oct 2009 04:37
Picon

Re: [patch, fortran] Improve bounds checking error messages

On 09/30/2009 05:54 PM, Jerry DeLisle wrote:
> On 09/30/2009 02:04 PM, Dennis Wassel wrote:
>> PING?
>> (I will be on holiday till 16th from tomorrow - please don't expect
>> any answers in case there are any objections)
>>
>> Thanks,
>> Dennis
>>
> I will commit after a fresh build and regression test.
>
> Jerry
>

Committed:

Sending        ChangeLog
Sending        trans-array.c
Transmitting file data ..
Committed revision 152355.

Regards,

Jerry
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Oct 2009 04:38
Picon

Re: [patch, fortran] Improve bounds checking error messages

On 09/30/2009 07:22 PM, Steve Kargl wrote:
> On Wed, Sep 30, 2009 at 05:54:41PM -0700, Jerry DeLisle wrote:
>> On 09/30/2009 02:04 PM, Dennis Wassel wrote:
>>> PING?
>>> (I will be on holiday till 16th from tomorrow - please don't expect
>>> any answers in case there are any objections)
>>>
>>> Thanks,
>>> Dennis
>>>
>> I will commit after a fresh build and regression test.
>>
>
> Jerry,
>
> Are you satisfied with the error message text?  Dennis
> seemed alittle apprehensive about the use of "below" and
> "above" in describing the out-of-bounds index with
> respect the lower and upper bounds.
>

Yes, It seemed natural and clear to me.

Jerry
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Oct 2009 08:20
Picon

Fwd: GCC 4.5 Status Report (2009-10-01)

-------- Original Message --------
Subject: GCC 4.5 Status Report (2009-10-01)
Date: Thu, 1 Oct 2009 01:23:46 +0200 (CEST)
From: Richard Guenther

Status
======

The trunk is in Stage 3.  Stage 3 will end on Nov 30th after which
the trunk will be open for regression and documentation fixes only.
Stage 3 is for general bugfixing, what is considered a bugfix is
up to the maintainers.  At the discretion of the maintainers patches
that were finished during Stage 1 but have not yet been reviewed or
committed may be still applied.  Please have the release quality
in mind when approving late patches.

Once the remaining pieces have been approved the trunk will freeze
for the merge of the LTO branch which Diego will announce.

There are still new ports pending review and approval.  As usual
new ports can be accepted also during Stage 3.

Surprisingly the quality data improved, a good start into Stage 3!

Quality Data
============

Priority	  #	Change from Last Report
--------	---	-----------------------
P1		 19     - 3
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kaveh R. GHAZI | 1 Oct 2009 11:56
Picon
Favicon

[PATCH]: PR fortran/33197, use MPC for complex "arc" functions

Support for the "arc" functions has been added to the MPC repository and
will be in the forthcoming mpc-0.8 release.  This patch to GCC adds
complex "arc" support to the fortran frontend using MPC.

Since it's about 11:55 pm Sept 30th in Hawaii, I'm hoping to swoop in
under the permissive stage1 deadline noted here. :-)
http://gcc.gnu.org/ml/gcc/2009-09/msg00659.html

Some guidance for a testcase would be appreciated.

Bootstrapped --enable-languages=c,fortran on x86_64-unknown-linux-gnu
both without MPC and with MPC svn revision 689.  No regressions.

Okay for mainline?

		Thanks,
		--Kaveh

2009-09-30  Kaveh R. Ghazi  <ghazi <at> caip.rutgers.edu>

	PR fortran/33197
	* gfortran.h (HAVE_mpc_arc): Define.
	* simplify.c (gfc_simplify_acos): Handle complex acos.
	(gfc_simplify_acosh): Likewise for acosh.
	(gfc_simplify_asin): Likewise for asin.
	(gfc_simplify_asinh): Likewise for asinh.
	(gfc_simplify_atan): Likewise for atan.
	(gfc_simplify_atanh): Likewise for atanh.

diff -rup orig/egcc-SVN20091001/gcc/fortran/gfortran.h egcc-SVN20091001/gcc/fortran/gfortran.h
(Continue reading)

Permalink | Reply | 6 comments |
headers
Janus Weil | 1 Oct 2009 13:35
Picon
Favicon
Gravatar

Re: [Patch,Fortran] Add polymorphic type support (OOP, RTTI) - merge from Fortran-dev branch

Hi Tobias,

>>> attached patch adds more OOP; it is just the difference between the 4.5
>>> trunk and the Fortran-dev branch (with one additional line).
>
> I have now committed the unmodified patch to the trunk as Rev. 152345.

thanks a lot for taking care of the merge. I will have a look at your
comments later (I will be back home tomorrow).

Also: Now that all the OOP stuff has landed on trunk, I would
encourage all interested users (Salvatore, Damian, anyone else?) to
test the current implementation, so that we can quickly fix the
remaining bugs.

Cheers,
Janus

>  * * *
>
> Some comments - (a)-(d) go mostly to Janus, the comment afterwards
> mostly to Paul.
>
> a) SAME_TYPE_AS and EXTENDS_TYPE_OF: I think one could add a
> compile-time simplifier.
>
> b) As shown my posted test program, the following often does not work
> (nested select_type blocks, ...). I think one could have a static global
> linked list, which gets pushed the current variable when entering the
> block and popped when leaving. In the block one then walks through the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kaveh R. Ghazi | 2 Oct 2009 07:39
Picon
Favicon

Re: [PATCH]: PR fortran/33197, use MPC for complex "arc" functions

From: "Tobias Burnus" <burnus <at> net-b.de>

> Regarding a test case: What kind of guidance do you need?

Well I was considering just copying one of the 
gfortran.dg/complex_intrinsic_*.f90 tests as a starting point.  However I 
noticed that some of them are "run" tests.  But complex_intrinsic_7.f90 is a 
wierd compile test that looks for "abort" calls in the dump file rather than 
just executing the test.  I suppose that "works" in a cross-config testrun 
but still it looks odd. :-)  Which style should I follow?

Also I wasn't aware of the need to check fortran_large_real targets.  None 
of the other complex_intrinsic_* tests seem to do that.

        Thanks,
        --Kaveh
Permalink | Reply | 4 comments |
headers
Tobias Burnus | 2 Oct 2009 09:31
Picon

Re: [PATCH]: PR fortran/33197, use MPC for complex "arc" functions

On 10/02/2009 07:39 AM, Kaveh R. Ghazi wrote:
> From: "Tobias Burnus" <burnus <at> net-b.de>
>
>> Regarding a test case: What kind of guidance do you need?
>
> Well I was considering just copying one of the
> gfortran.dg/complex_intrinsic_*.f90 tests as a starting point. 
> However I noticed that some of them are "run" tests.  But
> complex_intrinsic_7.f90 is a wierd compile test that looks for "abort"
> calls in the dump file rather than just executing the test.  I suppose
> that "works" in a cross-config testrun but still it looks odd. :-)

Well, the advantage is that you are really testing the compile-time
support; a run test would allow for no compile-time folding and for
calling the library at run time. Besides, a compile test is faster than
a run-time test. (An alternative would be to check for the digits in the
dump or use the numbers in initialization expressions.)
An advantage for using a run-time test in case of complex acos etc.
would be that the check would always work: Either via MPC at compile
time or - until MPC 0.8 is available - at run time. (Be careful,
however, as the run-time libraries may not properly support operations
involing/resulting in a real or imaginary +/-INF or NaN - or they may do
different branch cuts.)

> Which style should I follow?
Pick one which you like :-)

> Also I wasn't aware of the need to check fortran_large_real targets. 
> None of the other complex_intrinsic_* tests seem to do that.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tobias Burnus | 2 Oct 2009 17:36
Picon

[Fortran,Patch] PR41479 - fix INTENT(OUT) initialization

Hello all,

this patch is for
  "[4.3/4.4/4.5 Regression] intent(out) for types with default initialization"
After this fix, two regressions are left: PR 41494 and PR 41403.

The problem is that for derived types with INTENT(OUT), the default
initializer is only used if the derived type has no allocatable components!
As gfc_init_default_dt also takes care of allocatable compounds, it was enough
to take care of allocatable compounds only for DT without default initializers.

Additionally, the check whether the actual argument is present does not make
sense most of the time. I think there are only two cases where the check is
needed: (a) For optional arguments and (b) for entry master functions
(default_initialization_3.f90).

The initialization of the test case is now:

init (struct container_t & restrict container)
{
  {
    struct container_t D.1388;
    struct container_t container_t.0;

    container_t.0.n = 42;
    container_t.0.a.data = 0B;
    D.1388 = *container;
    *container = container_t.0;
    if (D.1388.a.data != 0B)
      {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Kraft | 3 Oct 2009 16:08
Picon

[Patch, Fortran] PR fortran/41403: Fix miscompilation of assigned goto

Hi all,

the attached patch fixes PR 41403 which is about miscompilation of
assigned goto statements.  It's one of the two remaining gfortran
regressions that Tobias mentioned in his recent post, so only one (about
inefficient zero'ing) remains.

Assigned goto has the form:

GOTO variable [, label-list]

with an optional label-list.  If the list is present, the label assigned
to variable must be one of its elements; so the list does not really
change the semantics for already valid code (it is only a further
restriction that could be checked at run-time or maybe used to output
simpler code).

The existing implementation of assigned goto with label-list was to
compare label-addresses, which may fail with optimization as Richard
pointed out in the PR.  If no label-list is present, this comparison
does not happen and the stored label-address is simply jumped to, which
should be ok in any case.

This patch is somewhat a "bogus solution" in that I simply disregard a
label-list after parsing and syntax checking.  As I understand assigned
goto and pointed out above, this does not change the semantics of the
statement for valid code, and it gets rid of the fragile label address
comparison and fixes the PR thus.

The side-effect is that there's no longer a runtime error if a label is
(Continue reading)

Permalink | Reply | 4 comments |
headers
Toon Moene | 3 Oct 2009 16:13

Re: Trunk is closed for LTO merge

Diego Novillo wrote:

> I have started the final merge from the lto branch into trunk.  Please
> refrain from committing any changes until I open mainline again.

Will the merge allow lto by default (so that we do not have to specify 
--enable-lto) ?

Or do we have to force it, like on the branch ?

--

-- 
Toon Moene - e-mail: toon <at> moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Permalink | Reply | 6 comments |

Gmane