headers
Brooks Moses | 1 Jun 03:43

Re: ISO C Binding merge palns

Steve Kargl wrote:
> The surgery is done!  Danny has renamed the fortran-experiments-fix
> branch back the fortran-experiments branch.  To prevent any unforeseen
> future breakage, it may be advisable to delete your local working 
> copy of the fortran-experiments branch and then checkout a clean
> version.
> 
> svn checkout svn+ssh://gcc.gnu.org/svn/gcc/branches/fortran-experiments

Or, for the low-bandwidth version of this, copy your "trunk" repository 
and then do

   svn switch 
svn+ssh://brooks <at> gcc.gnu.org/svn/gcc/branches/fortran-experiments

in the root of it.

- Brooks
Permalink | Reply | 1 comment |
headers
Brooks Moses | 1 Jun 03:49

Re: ISO C Binding merge palns

Brooks Moses wrote:
> Steve Kargl wrote:
>> svn checkout svn+ssh://gcc.gnu.org/svn/gcc/branches/fortran-experiments
> 
> Or, for the low-bandwidth version of this, copy your "trunk" repository 
> and then do
> 
>    svn switch svn+ssh://brooks <at> gcc.gnu.org/svn/gcc/branches/fortran-experiments
> 
> in the root of it.

Er, obviously with your username in place of the "brooks@" there (or 
with no username at all there, if it's the same as your local login 
name).  Oops.

- Brooks
Permalink | Reply | 0 comments |
headers
Brooks Moses | 1 Jun 07:39

Fortran-experiments failures on powerpc-apple-darwin8.9.0

Hello, all -

I figured I should probably go ahead and start testing this branch on my 
PowerPC machine, so's to avoid any unpleasant surprises after merge.

And, as might be expected, we're getting a few failures -- though the 
good news is that it looks like it's only one actual problem that isn't 
showing up on other platforms.

Also, oddly enough, sizeof.f90 passes; I gather it's failing for other 
machines?  (I haven't tried out the branch on my i686-Debian box yet.)

Details below, for the new failures.  When I post one failure on a 
runtime test, assume it applies for all optimization levels.

- Brooks

---------------------------------------------------------------------

Executing on host: 
/Users/brooks/gcc-fortran-experiments/build3/gcc/testsuite/gfortran/../../gfortran 
-B/Users/brooks/gcc-fortran-experiments/build3/gcc/testsuite/gfortran/../../ 
/Users/brooks/gcc-fortran-experiments/svn-source/gcc/testsuite/gfortran.dg/bind_c_dts.f90 
   -O0   -pedantic-errors

/Users/brooks/gcc-fortran-experiments/svn-source/gcc/testsuite/gfortran.dg/bind_c_dts_driver.c 

-L/Users/brooks/gcc-fortran-experiments/build3/powerpc-apple-darwin8.9.0/./libgfortran/.libs

-L/Users/brooks/gcc-fortran-experiments/build3/powerpc-apple-darwin8.9.0/./libgfortran/.libs
(Continue reading)

Permalink | Reply | 0 comments |
headers
FX Coudert | 1 Jun 08:02
Picon
Gravatar

Re: -malign-double failure on i686-pc-linux-gnuaout

> This surprised me too. I ran config.guess from my automake RPM  
> package and that was the result on my Fedora Core #6 installation.  
> As far as I'm aware it is a standard installation - I certainly  
> made no special modifications to the basic system (other than build  
> the svn gfortran anyway!).

You probably want to override this build triplet with i686-pc-linux-gnu.

FX
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Jun 09:37
Picon

Re: [Patch, fortran] PR32156 - [4.3 Regression] ICE with characters

Paul,

Paul Richard Thomas wrote:
> You will excuse me if I fixed this one as 'obvious'.
> In fact, I am not entirely happy with this fix and left a TODO to
> reflect this.  There is something not right with string concatenation
> in the front-end that fails to transmit the string length correctly.
> I have made several attempts to get to the bottom of this and have
> completely failed.  I will not forget about it:)

Would it make sense to open a PR for the TODO just to make sure it does
not get forgotten?

Tobias

The commit logs are available at:
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00956.html
http://gcc.gnu.org/viewcvs?view=rev&revision=125240

The patch is:

--- trunk/gcc/fortran/trans-array.c	2007/05/31 21:11:31	125240
+++ trunk/gcc/fortran/trans-array.c	2007/05/31 21:12:10	125241
@@ -1635,8 +1635,18 @@
       if (!ss->string_length)
 	gfc_todo_error ("complex character array constructors");

-      ss->expr->ts.cl->backend_decl = ss->string_length;
+      /* It is surprising but still possible to wind up with expressions that
+	 lack a character length.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Richard Thomas | 1 Jun 23:10
Picon

Re: [Patch, fortran] PR32156 - [4.3 Regression] ICE with characters

Tobias,

> Would it make sense to open a PR for the TODO just to make sure it does
> not get forgotten?

There is no need - I have finally become completely tired of these
bugs coming every few months and want to do a spring clean.  I am
working on a one-stop character length resolution function and a
one-stop character length conversion function.  I don't know yet how
many lines of code are going to disappear but it must be many
hundreds.  Two other PRs have already fallen in this process.

Cheers

Paul
Permalink | Reply | 1 comment |
headers
Steve Ellcey | 1 Jun 23:17
Picon

Fortran Patch for uninitialized variable in gfc_conv_array_parameter

I have been getting segfaults from the Fortran compiler when compiling
gfortran.dg/actual_array_constructor_1.f90 and
gfortran.dg/actual_array_constructor_2.f90.  It looks like the problem
is an uninitialized variable.  gfc_conv_array_parameter creates a tree
variable (tmp) and passes the address of it to get_array_ctor_strlen but
get_array_ctor_strlen will dereference and use it (len) before it sets
it so gfc_conv_array_parameter should be initialized before calling
get_array_ctor_strlen.

Should I check this in as obvious?  I tested it quickly but haven't done
a full bootstrap.

Steve Ellcey
sje <at> cup.hp.com

2007-06-01  Steve Ellcey  <sje <at> cup.hp.com>

	* trans-array.c (gfc_conv_array_parameter): Initialize tmp.
Index: trans-array.c
===================================================================
--- trans-array.c	(revision 125253)
+++ trans-array.c	(working copy)
@@ -4819,7 +4819,7 @@ gfc_conv_array_parameter (gfc_se * se, g
 {
   tree ptr;
   tree desc;
-  tree tmp;
+  tree tmp = NULL_TREE;
   tree stmt;
   tree parent = DECL_CONTEXT (current_function_decl);
(Continue reading)

Permalink | Reply | 2 comments |
headers
FX Coudert | 1 Jun 23:31
Picon
Gravatar

Re: Fortran Patch for uninitialized variable in gfc_conv_array_parameter

> 2007-06-01  Steve Ellcey  <sje <at> cup.hp.com>
>
> 	* trans-array.c (gfc_conv_array_parameter): Initialize tmp.

OK, and thanks! (I've seen the ia64 failures, tried to reproduce it  
on a itanium-linux system I have access to, and it just died for  
unresolved unwind symbols, so I got no further than that)
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 2 Jun 23:04
Picon

[patch, fortran] PR18923 segfault after subroutine name confusion

:ADDPATCH fortran:

This patch completes the fix for this PR.  The scrambled symbols were coming
from improperly allocating namespace pointers after an error with a CONTAINS block.

The key is to do the right thing when rejecting a statement.  The tmp namespace
pointer is needed to make sure we tie up the loose ends correctly. The test for 
tmp->refs is to avoid an assert later for keyword_symbol_1.f90 in the testsuite.

This patch partially fixes pr25252 which suffers the CONTAINS problem fixed here
as well as something else.  I am on that trail now.

Regression tested on x86-64-gnu-linux.  I will add the two cases from the PR now 
that the errors have been stabilized.

OK for trunk?

Regards,

Jerry

2007-06-02  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>

	PR fortran/18923
	* parse.c (decode_statement): Don't call gfc_undo_symbols on MATCH_ERROR
	for ST_FUNCTION since it is called in reject_statement.
	(parse_contained): If error, loop back after reject_statement and try
	again.  Free the namespace if an error occured.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dominique Dhumieres | 3 Jun 00:45
Picon
Picon
Favicon

Failure of array_constructor_13.f90 with 4.3.0 20070601 powerpc-apple-darwin7

With 4.3.0 20070601 powerpc-apple-darwin7, array_constructor_13.f90 gives an ICE:

array_constructor_13.f90: In function 'MAIN__':
array_constructor_13.f90:22: internal compiler error: Bus error

Is this known? should I fill a PR or reopen the old one?

TIA

Dominique
Permalink | Reply | 2 comments |

Gmane