headers
Tom Tromey | 1 Sep 01:09
Picon
Favicon

Re: Patch: make --enable-mapped-location work

>>>>> "Mark" == Mark Mitchell <mark <at> codesourcery.com> writes:

Mark> The Ada folks have, in the past, said that it was OK to make
Mark> this change, and that they would catch up.

That is my recollection as well.

Mark> I'm confident that Tom will get the Java front end in shape, and
Mark> that the Fortran folks will do the same with the Fortran front
Mark> end.

Yeah, I'll fix the Java regression, if it is one (the test results are
a bit inconsistent).  François-Xavier already started looking at the
Fortran regressions and has a fix for the first one.

It occurred to me today that I forgot to test treelang.  I will do
that soon.

I'm happy to submit a patch to change the default once everything goes
in.

Tom
Permalink | Reply | 0 comments |
headers
Janus Weil | 1 Sep 01:32

Re: [PATCH, Fortran] PROCEDURE declarations

Hi,
I fixed the bugs reported by the Tobi tag team, and another issue I
found myself:
A partly-implicit procedure (like "procedure(real):: p") inside an interface

interface if
  procedure p
end interface

was not rejected as "not explicit". I included test cases for all
three fixes and did another successful regtest.
Thanks for the reviews. Anything else?
Cheers,
Janus

2007-08-31  Janus Weil  <jaydub66 <at> gmail.com>
	    Paul Thomas  <pault <at> gcc.gnu.org>

	* decl.c (gfc_match_procedure): Handle PROCEDURE statements.
	* gfortran.h (struct gfc_symbol): New member "gfc_symbol *interface".
	(enum gfc_statement): New element "ST_PROCEDURE".
	(strcut symbol_attribute): New member "unsigned procedure".
	* interface.c (check_interface0): Extended error checking.
	* match.h: Add gfc_match_procedure.
	* parse.c (decode_statement,next_statement,gfc_ascii_statement,
	parse_interface): Implement PROCEDURE statements.
	* resolve.c (resolve_symbol): Ditto.
	* symbol.c (check_conflict): Ditto.
	(copy_formal_args): New function for copying formal argument lists.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Tromey | 1 Sep 01:37
Picon
Favicon

Re: Patch: make --enable-mapped-location work

>>>>> "Diego" == Diego Novillo <dnovillo <at> google.com> writes:

Diego> I personally don't care either way.  However, I only ask that
Diego> we either enable it unconditionally by default or we remove it
Diego> completely.

Yeah.  Additionally, if something like this comes up again, I would
like us to agree not to commit it until it is working.  I've disliked
tripping over these conditionals the last few years.

Tom
Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Sep 14:21
Picon

Re: [PATCH, Fortran] PROCEDURE declarations

Janus,
> no need to apologize. I think you're completely right (even if
> "doesn't make any sense" is really a bit strong). gfc_copy_attr is
> exactly what I want. The above piece of code survived from Paul's
> original patch and I just never gave it that much thought, because in
> principle it does the right thing. But actually it misses out to check
> for double attributes, so that for
I never claimed that it was anything other than kludge upon kludge; just 
to demonstrate the principle. :-)

Anyway, you have done well to get this far and it will certainly be very 
satisfactory if you can get as far as the implementation procedure pointers.

Cheers

Paul
Permalink | Reply | 44 comments |
headers
Dominique Dhumieres | 1 Sep 16:36
Picon
Picon
Favicon

Is this a known ICE?

Reduced test case derived from
http://groups.google.fr/group/comp.lang.fortran/browse_thread/thread/b0273757b128c551/337dd8a3240717d4#337dd8a3240717d4

  character(4), target :: tar2(2) = (/"abcd","efgh"/)
  character(2), pointer :: ptr2(:)
!  character(4), pointer :: ptr2(:) 
  ptr2 => tar2(:)(2:3)
!  ptr2 => tar2(:)                       
  print *, ptr2
end

gives an ICEi (the commented lines work):

ptr_test_red.f90: In function 'MAIN__':
ptr_test_red.f90:1: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:4511

with revision 128003, gcc version 4.3.0 20070720, and gcc version 4.2.1
(in the later case the error is:
ptr_test_red.f90:0: internal compiler error: Bus error).

Is this a known bug or should I fill a PR?

Dominique
Permalink | Reply | 3 comments |
headers
Tobias Burnus | 1 Sep 16:57
Picon

Re: Is this a known ICE?

Hi Dominique,

Dominique Dhumieres wrote:
> Is this a known bug or should I fill a PR?
>   
Yes this is known. The email was by Paul who is currently fixing that
bug ;-)

I'm not sure which of the two PRs it is, might be also both:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871

Tobias
Permalink | Reply | 2 comments |
headers
Dominique Dhumieres | 1 Sep 17:04
Picon
Picon
Favicon

Re: Is this a known ICE?

> The email was by Paul who is currently fixing that bug ;-)

Yes, I realized that the second time I looked at the post
(usually I am looking only to the name of those who answer!-)

Note that the part I discarted does not give an ICE, but
a wrong answer.

Dominique
Permalink | Reply | 0 comments |
headers
Thomas Koenig | 1 Sep 22:26

Re: [PATCH, fortran] PR20441 -finit-local-zero

Asher Langton wrote:

Hi Asher,

> Here's an updated patch.  I've added -finit-character=<n>, where 0 <=
> n <= 127 is an ASCII value.  Derived types aren't initialized, but
> I've documented this in the manual.  I've added a test that checks
> initialization of SAVE'd variables.  This has been bootstrapped (+make
> pdf) and regression tested on x86_64-unknown-linux-gnu.

Equivalenced variables are not initialized by your patch:

$ cat foo.f
      program main
      call foo
      end
      subroutine foo
      equivalence(i,j)
      print *,j
      end
$ g77 -finit-local-zero foo.f && ./a.out
 0
$ gfortran -finit-local-zero foo.f && ./a.out
           1

This behavior is different from g77, so I think it should be either
documented, or the behavior changed to match g77.  Of course, if the
user specifies -finit-integer and -finit-real and equivalences the
values, he's on his own :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manfred Schwarb | 1 Sep 23:45
Picon
Picon

Re: wrong code with -fforce-addr


> 
> > On Wed, Aug 29, 2007 at 07:45:31PM +0200, Manfred Schwarb wrote:
> > > 
> > >       SUBROUTINE FI635(...)
> > >       INTEGER       KSCALE
> > >       REAL          SCALE
> > > <..some code calculating KSCALE..>
> > >       SCALE = 2.0**KSCALE
> > >       PRINT *,'SCALE ',SCALE,KSCALE
> > > 
> > > In the working case, I get
> > >  SCALE    1.000000               0
> > > in the non-working case, I have
> > >  SCALE    0.000000               0
> > > 
> > > If I add further prints, I suddenly get no output at all.
> > > It looks a bit like there is memory corruption, but I ran with efence
> > > and tried valgrind, I didn't find anything.
> > > 
> > > I'm a bit in a loss. How to debug such a mess?
> > > I also tried to run ftnchek, but it has quite some problems
> > > with this fortran95 code.
> > > 
> > 
> > Can you post the entire subroutine that shows the problem?
> > You may have already mentioned the version, but could you
> > also include 'gfortran -v' output?
> 
> I encountered it first with a 2 weeks' old version, but I have
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janus Weil | 2 Sep 00:16

Re: [PATCH, Fortran] PROCEDURE declarations

Hi all,
I just made another structural change to my implementation of
procedure declarations: Up to now I had just one matcher function
"gfc_match_procedure", which handled all occurrences of the PROCEDURE
keyword.
But actually the patch supports two distinct situations where PROCEDURE is used:

* The first one is the general PROCEDURE statement, which can specify
an interface and some attributes for the procedure, as in

PROCEDURE(intrfc), public, bind(c):: proc

Here PROCEDURE acts similar to EXTERNAL.

* The second situation is inside an interface declaration:

INTERFACE gen
  PROCEDURE a
  MODULE PROCEDURE b
  SUBROUTINE c
  END SUBROUTINE
END INTERFACE

Here the syntax is quite different (e.g. no attributes may be specified etc).

I think it makes sense to practice a better separation of both cases
in the code, which makes it more readable and error proof. And apart
from that it makes it easier to implement the remaining parts of the
PROCEDURE syntax, e.g. procedure pointers, procedure pointer
components and type-bound procedures.
(Continue reading)

Permalink | Reply | 42 comments |

Gmane