Build failure in dwarf2out

[Paul Thomas]

I am being hit by this:

rf2out.c -o dwarf2out.o
../../trunk/gcc/dwarf2out.c: In function `file_name_acquire':
../../trunk/gcc/dwarf2out.c:7672: error: `files' undeclared (first use 
in this f

unction)
../../trunk/gcc/dwarf2out.c:7672: error: (Each undeclared identifier is 
reported

only once
../../trunk/gcc/dwarf2out.c:7672: error: for each function it appears in.)
../../trunk/gcc/dwarf2out.c:7672: error: `i' undeclared (first use in 
this funct

ion)
make[2]: *** [dwarf2out.o] Error 1
make[2]: Leaving directory `/svn/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/svn/build'
make: *** [all] Error 2

No matter how I configure the build on a system (Cygwin_NT/amd64) with 
which I have never had any problem before.


Can someone advise, please?

Paul

Re: Build failure in dwarf2out

[Paul Thomas]

Tim,
My guess is that the #define activating that region of code is 
erroneously triggered.  I am running the 2-day (on cygwin with a 
substandard BIOS) testsuite now.
I decided to set it to #if 0 just as I saw your mail - it is now 
building just fine; I haven't tested it yet but I guess, since it got 
past stage 2, all is well.


Nathan,

dwarf2 is throughly foreign territory for me - however, I notice your 
ChangeLog entry of 2006-10-24.  I suppose the patch must have included:


#if defined (DIR_SEPARATOR_2)
 {
   char *g = strrchr (files[i].path, DIR_SEPARATOR_2);

   if (g != NULL)
 {
   if (f == NULL || f < g)
 f = g;
 }
 }
#endif

This is breaks Cygwin_NT (CYGWIN_NT-5.2-WOW64 NONE-X6EIN5I8FN 
1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin)/amd64 build for any 
configuration that I have been able to dream up.


Cheers

Paul

Re: Polyhedron performance regression

[Paul Thomas]

Richard,


If I had to guess I would say it was the forwprop merge...

The what? :-)

Paul

Re: Polyhedron performance regression

[Paul Thomas]

Steven and Jerry,



If someone can confirm that this patch causes the drop, I can help
trying to find a fix.


amd64/Cygwin_NT

$ /irun/bin/gfortran -O3 -funroll-loops -ffast-math -march=opteron ac.f90

118372 20.2s
118475 20.4s  Bonzini's patch
118704 16.2s

I believe that the improvement is FX's and my patch for MOD.

Notice that this is a single core machine and that there is a PR out on 
the vectorizer.  Could this be the problem, since the suse tests are 
done on a two core machine, if I understood correctly?


Paul

Re: GFortran testsuite problems with "dg-do compile"

[Paul Thomas]

Brooks,


Is this the expected/desired behavior for "dg-do compile"?



I had always thought so :-)

Paul

Re: gfortran year end status report

[Paul Thomas]

FX Coudert wrote:

Thanks a lot Steve for taking time to prepare and write this mail.

FX


I second that - the only axe that I have to grind about it is that the 
majority of my commits were patches to patches of the same fix :-)


Paul

Re: Regression involving COMMON(?)

[Paul Thomas]

Andrew,
You were right:
I think this is caused by:
2005-04-25  Nathan Sidwell  <[EMAIL PROTECTED]>
* tree-ssa-alias.c (fieldoff_t): Remove.
(fieldoff_s): typedef the structure itself.  Create a vector of
objects.
(push_fields_onto_fieldstack): Return count of fields pushed.
Remove peeling of first field.  Adjust.
(fieldoff_compare): Adjust.
(create_overlap_variables_for): Adjust.
by the way Paul, what is the error?
For every each one of the FAILs -
internal compiler error: in push_fields_onto_fieldstack, at 
tree-ssa-alias.c:2834

Paul T 

Build failure under Cygwin_NT-5.0

[Paul Thomas]

The last few days have seen this failure:  I refreshed my source completely, 
on this occasion, to see if I could get round it.  I'll submit a PR tonight 
if somebody has not found the problem.


[EMAIL PROTECTED] /cygdrive/d/gcc-cvs/build
$ 
../gcc/configure --enable-maintainer-mode --enable-shared --disable-static --

prefix=/cygdrive/d/irun-cvs --with-gmp=/usr/local --with-mpfr=/usr/local --enab
le-languages=c,f95

[EMAIL PROTECTED] /cygdrive/d/gcc-cvs/build
$ make bootstrap

after a little while.

/cygdrive/d/gcc-cvs/build/./gcc/xgcc -B/cygdrive/d/gcc-cvs/build/./gcc/ -B/cygdr
ive/d/irun-cvs/i686-pc-cygwin/bin/ -B/cygdrive/d/irun-cvs/i686-pc-cygwin/lib/ 
-i
system /cygdrive/d/irun-cvs/i686-pc-cygwin/include -isystem 
/cygdrive/d/irun-cvs
/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. 
-

iquote../../../gcc/libgfortran/io -std=gnu99 -Wall -Wstrict-prototypes -Wmissing
-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c 
../../.

./gcc/libgfortran/runtime/environ.c -o environ.o
../../../gcc/libgfortran/runtime/environ.c: In function 'init_integer':
../../../gcc/libgfortran/runtime/environ.c:104: error: invariant not 
recomputed

when ADDR_EXPR changed
&_ctype_D.1948[1];

../../../gcc/libgfortran/runtime/environ.c:104: internal compiler error: 
verify_

stmts failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [environ.lo] Error 1
make[3]: Leaving directory 
`/cygdrive/d/gcc-cvs/build/i686-pc-cygwin/libgfortran

'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/cygdrive/d/gcc-cvs/build/i686-pc-cygwin/libgfortran

'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/cygdrive/d/gcc-cvs/build'
make: *** [bootstrap] Error 2 

Re: Build failure under Cygwin_NT-5.0

[Paul Thomas]

Andrew,



This is PR 21766.  Patch here: 
.




You will have to explain this to me very slowly, preferably in baby talk

Paul T 

Re: Build failure under Cygwin_NT-5.0

[Paul Thomas]

I applied Danny's patch and got to:

al/include -I/usr/local/include \
../../gcc/gcc/config/i386/winnt.c
../../gcc/gcc/config/i386/winnt.c: In function `i386_pe_mark_dllexport':
../../gcc/gcc/config/i386/winnt.c:286: warning: implicit declaration of 
function

`DECL_NON_ADDR_CONST_P'
../../gcc/gcc/config/i386/winnt.c:286: error: invalid lvalue in assignment
../../gcc/gcc/config/i386/winnt.c: In function `i386_pe_mark_dllimport':
../../gcc/gcc/config/i386/winnt.c:349: error: invalid lvalue in assignment
../../gcc/gcc/config/i386/winnt.c: In function 
`i386_pe_encode_section_info':

../../gcc/gcc/config/i386/winnt.c:460: error: invalid lvalue in assignment
make[1]: *** [winnt.o] Error 1
make[1]: Leaving directory `/cygdrive/d/gcc-cvs/build/gcc'
make: *** [all-gcc] Error 2

I tried to copy the symbian version of the patch by eliminating all mention 
of DECL_NON_ADDR_CONST_P, winnt.c then compiled but the build bombed out in 
varasm.c for the same reason.


Since I haven't the slightest idea of what I am doing, I left it there!

Paul T 

Re: Cygwin build failure

[Paul Thomas]

Thanks Francois-Xavier and Andrew for replying,


That's PR 21766 (appropriately named "Bootstrap failure on
i686-pc-cygwin"). Opened almost a month ago. GCC mainline doesn't
build on cygwin or mingw since that time.



Seeing that almost no comment had been made by the maintainers on it,
and no correct patch proposed, it looks like we're gonna have to live
with it for a long time... :(


Ah..., I naively thought that it would have been fixed whilst I was away! 
What a bloody nuisance.


PS: Detailled info on your problems:


This one is because you're reconfiguring in a non-empty tree. There is
a PR number for it, but I don't remember it...


I thought that it was empty; I'l try again.

Thanks

Paul T

[Fwd: ezmlm warning]

[Paul Thomas]

Hi,

Is this spam, a temporary glitch at gcc-central or what?  I checked my 
mailbox and all is well.


Paul Thomas

--- Begin Message ---
Hi! This is the ezmlm program. I'm managing the
[EMAIL PROTECTED] mailing list.


Messages to you from the fortran mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

If this message bounces too, I will send you a probe. If the probe bounces,
I will remove your address from the fortran mailing list,
without further notice.


I've kept a list of which messages from the fortran mailing list have 
bounced from your address.

Copies of these messages may be in the archive.
To retrieve a set of messages 123-145 (a maximum of 100 per request),
send an empty message to:
   <[EMAIL PROTECTED]>

To receive a subject and author list for the last 100 or so messages,
send an empty message to:
   <[EMAIL PROTECTED]>

Here are the message numbers:

   8038
   8148
   8149
   8147
   8152
   8153
   8154
   8151
   8155
   8150
   8157
   8156
   8158
   8159
   8160
   8161
   8162
   8163
   8164
   8165
   8166
   8167
   8168
   8169
   8170
   8171
   8172

--- Enclosed is a copy of the bounce message I received.

Return-Path: <>
Received: (qmail 10817 invoked for bounce); 5 Oct 2005 03:43:27 -
Date: 5 Oct 2005 03:43:27 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1128213407sourceware.org22936393"
Subject: failure notice

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)



--- End Message ---

Re: Heads up: many recent Fortran SPEC regressions

[Paul Thomas]

Jakub,

Have you made any progress on fixing this?  I would rather that the 
debug information is not available than that equivalence is broken.


Best regards

Paul

Re: Heads up: many recent Fortran SPEC regressions

[Paul Thomas]

Jakub,


Well, certainly the graphs on Diego's page returned ~ up to normal values
when you committed the fix.

 


I agree - it IS fixed.

Thanks

Paul

Re: RFC: future gfortran development and subversion

[Paul Thomas]

FX,



The fortran patches are always fortran-contained, and I think if the 
community thinks it worth to have a different development model (until 
some point in the future, defined in advance) why shouldn't it be so?


This might well be the value of keeping the binaries going.  From what I 
can see, most people using gfortran in anger are updating from your 
site, rather than using the distros.


I think that keeping two lines going is a pain but just about OK; better 
would be to undertake the periodic synchronizations from Head to 4.1, 
even if we are a bit resource limited.  As it is, this latter makes for 
some of the divergence because not all patches make their way to the 
distribution version.


By the way, I just posted on the Wiki a comparison of DF6.0 and gfortran 
using the Polyhedron benchmarks.  It's not too bad at all but there are 
a couple of sore thumbs.  I have just done the ifc to gfortran 
comparison on FC3, which basically looks the same (one bloody thumb is 
repaired because the comparison is not between a native user of system 
resources and another that does so via Cygwin.).  I will try to collate 
and post the results in a day or so.


Paul

Re: RFC: future gfortran development and subversion

[Paul Thomas]

Dear All,


I spent nearly 5 hours yesterday reading the svn FAQ, mailing list
archives, and the docs.  I never came across this solution.
   

Could somebody please distill the wisdom from this thread onto the 
Wiki?  I can understand why Steve might send 5 hours on it.  It's bad 
that one person winds up doing it and unforgivable if everybody does.


How about adding to the list of common things that an aspiring 
contributor might want to do?


Paul T

Re: RFC: future gfortran development and subversion

[Paul Thomas]

Thomas,


Currently, gfortran is in a half-usable state.  It is not yet
ready as a replacement for g77 (see PR 19292) and there are quite
a lot of things it gets wrong with Fortran 95.


I think that this is way too strong.   Of the outstanding PR19292 "bugs":

5900 The penultimate entry says -

I would like to propose that this bug be closed.  This is about as good as it
gets.  We should set up some automatic regression testing on LAPACK from hence
forth.

13939 Concerns ugly commas - do we want this?  If so, it can be done.

14067 The final comment is "The ICE is fixed, but this could still do with a 
warning."

14994 SECNDS missing - I would say that this should be done. I have used an 
interface to get round this one.

15234 libgfortran doesn't compile on Tru64 UNIX V4.0F - ??? 5.0 is no problem 
with a gcc-3.x

16465 parser chokes with ffixed-line-length-7 - is this essential?

16580 hm, gfortran ICE on test g77.f-torture/execute/intrinsic77.f is this 
a show stopper?

17737 ICE when variable appears in two data statements - invalid code.

18026 boz initialization of REALs fails.  Penultimate comment "
I've removed the "reject-valid" keyward because the code is not valid
Fortran 95.  From section 5.2.10, we have:"

18737 ICE on invalid use of external keyword - this should be fixed.

19425 Duplicate SAVE attribute problem - illegal f95 and questionable f77

20441 -finit-local-zero is missing from gfortran - a useful legacy requirement 
IMHO.

20811 gfortran include problem (regression from g77) - this should be fixed.  A 
good tyro project.

21565 namelist in block data is illegal - I had better deal with this, hadn't I?

22175 BYTE Type Statement - Last comment "We do have a patch adding that 
enhancement."

22244 dimension information is lost for multi-dimension array - primarily gdb 
and optimization problem.

22282 loc intrinsic and %loc construction is not implemented in gfortran - 
do-able but not a disaster.

22290 Optimize Assigned GOTO to cause error with -O1 or higher - we seem to 
have a fix for this(?)

22359 fseek intrinsic appears to be unimplemented - should be done (using C 
fseek?).

23060 %VAL construct not implemented - do we want this? If so, it is do-able.

23912 MOD function requires same kind arguments - very fixable.

I would say that this is a 33:33:33 mix of fixed:do-able:ignorable/wrong - 
let's have a blitz on it.

Paul

Re: RFC: future gfortran development and subversion

[Paul Thomas]

So, collecting together the response to last night's mail:

Status of PR 19292 metabug:-


5900 The penultimate entry says -

I would like to propose that this bug be closed.  This is about as 
good as it
gets.  We should set up some automatic regression testing on LAPACK 
from hence

forth.


Let's close it then - how about it, one of you Lapack afficianados?



13939 Concerns ugly commas - do we want this?  If so, it can be done.

14067 The final comment is "The ICE is fixed, but this could still do 
with a warning."


14994 SECNDS missing - I would say that this should be done. I have 
used an interface to get round this one.


I will do this.



15234 libgfortran doesn't compile on Tru64 UNIX V4.0F - ??? 5.0 is no 
problem with a gcc-3.x


16465 parser chokes with ffixed-line-length-7 - is this essential?

16580 hm, gfortran ICE on test g77.f-torture/execute/intrinsic77.f 
is this a show stopper?


17737 ICE when variable appears in two data statements - invalid code.


I'll put this on my TODO list.



18026 boz initialization of REALs fails.  Penultimate comment "
I've removed the "reject-valid" keyward because the code is not valid
Fortran 95.  From section 5.2.10, we have:"

18737 ICE on invalid use of external keyword - this should be fixed.


It is on my personal TODO list, I'll move it to the top of the pile.



19425 Duplicate SAVE attribute problem - illegal f95 and questionable f77


Patch submitted (pinskia reply)



20441 -finit-local-zero is missing from gfortran - a useful legacy 
requirement IMHO.


20811 gfortran include problem (regression from g77) - this should be 
fixed.  A good tyro project.


21565 namelist in block data is illegal - I had better deal with this, 
hadn't I?


On the TODO list.



22175 BYTE Type Statement - Last comment "We do have a patch adding 
that enhancement."


Asher Langton has done it. (FX reply)



22244 dimension information is lost for multi-dimension array - 
primarily gdb and optimization problem.


22282 loc intrinsic and %loc construction is not implemented in 
gfortran - do-able but not a disaster.


Part of the Cray patch (FX reply) that Steve will commit next week-ish.



22290 Optimize Assigned GOTO to cause error with -O1 or higher - we 
seem to have a fix for this(?)


Patch here: (FW reply)
http://gcc.gnu.org/ml/fortran/2005-10/msg00194.html

But has not been reviewed.   I will look at it next week but might need 
help/advice.



22359 fseek intrinsic appears to be unimplemented - should be done 
(using C fseek?).


FX intends to do - timescale? + putc, getc and so on.



23060 %VAL construct not implemented - do we want this? If so, it is 
do-able.


23912 MOD function requires same kind arguments - very fixable.

I would say that this is a 33:33:33 mix of 
fixed:do-able:ignorable/wrong - let's have a blitz on it.


On the basis of the replies, the proportions are more like 50:25:25.  If 
somebody wants to do my TODOs, feel welcome.  Are you back FengWang?  
You are the one saddled with legacy code and must, I suppose, have an 
interest in some of these?


Paul

svn: Is it there yet?

[Paul Thomas]

Daniel,

I have been trying, unsuccessfully, to discern from the list if 
mainline/head/gcc-4_1-branch is available from the svn repository.


Is it available and what will it be called, please?

Cheers

Paul T

Re: svn: Is it there yet?

[Paul Thomas]

Ian,


It is available.  It is simply called 'trunk'.  There is no actual 4.1
branch yet.  See
   http://gcc.gnu.org/svn.html
   http://gcc.gnu.org/ml/gcc/2005-10/msg01083.html
 


Ah!  I thought that this was the sandpit branch.

Thanks

Paul

Re: svn: Is it there yet?

[Paul Thomas]

Mike,



When created, you will be able to find it with ls, and it will be called:

branches/gcc-4_1-branch.

I will look forward to seeing it! The reason that I asked in the first 
place is the responce to trying to update from trunk:


[EMAIL PROTECTED] gcc-svn]# svn up svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
svn: 'svn+ssh://[EMAIL PROTECTED]/svn/gcc' is not a working copy

Presumably, I just hang on to my pending patches until the day?

from the Bear of Little Brain

Paul T

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Paul Thomas]

Toon,

I just read your contribution to the 2005 gcc summit about gfortran and 
HIRLAM.  The two PRs(18283 and 21034) you wrote about are now fixed.  
LOC is now available.  That just leaves some of the extra functionality 
of FLUSH(IOSTAT?), does it not?  Would it compile completely if I were 
to add that functionality?


Given the scale of your code, it would be a triumph worth reporting if 
we could get it up and running with gfortran.


Best regards

Paul

Re: build1, build1_v and friends

[Paul Thomas]

Paul Thomas wrote:


Richard,

gfortran is failing to build, evidently because of your patch.   There 
are maybe 20-30 occurrences of build1 and build1_v scattered through 
the gfortran trans- files.  What do I do to rectify this?


I have reverted to r10790(ie. just before your group of patches) and the 
build goes through fine.  I have done absolutely no investigation 
because I am tyring to sort out a Sherlock Holmes "three piper" in gfortran.


If we have to replace the build1's with something, please let me know 
and I will implement it.


Best regards

Paul Thomas

Re: build1, build1_v and friends

[Paul Thomas]

Richard,



If we have to replace the build1's with something, please let me know 
and I will implement it.



I completely missed r107917... I will set about doing it.

Paul T

Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}

[Paul Thomas]

Richard,



As less intrusive first step I can bring the fortran variants in line
with the middle-end ones, especially wrt correctness.  We at least
should correct these issues.

For what it is worth, I applaud your effort - I think that the gfortran 
middle-end should be made completely consistent with the rest of gcc. 
The nature of your proposed patch is such that it should apply 
relatively easily to all and any of the trees; ie. a given 
function/macro is replaced by its rest-of-gcc equivalent. A nagging 
worry that I have is that the gcc middle-end is still not very well 
documented. The majority of the active gfortran developers are not 
full-timers and already find the gfortran variants fairly hard going at 
times (speaking first and foremost for myself, of course!) without 
having to delve deeper into gcc MiddleWorld. That said, I would get on 
with it if I were you.


Cheers

Paul T

Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}

[Paul Thomas]

Janne,


Well, it's not like gfortran is any better documented. At least with
gcc middle-end, there is a much larger amount of people familiar with
it who can concievably help.

 

I would agree with that.  However, getting acquainted with one level of 
undocumented complexity is one thing but two, as a part-time activity, 
is quite an act.  That said, gfortran is not too badly commented and, 
with the Doxygen documentation, it is possible to get around the 
front-end quite easily.


Paul

Re: Bad indentation and strange code in fortran/trans-array.c

[Paul Thomas]

H. J,


<>Also why are there duplicated


On the face of , that is very odd. It looks as if the charlen_ is 
obtained, the type obtained and the charlen done over again. I will have 
a look today.


Thanks

Paul

Re: Bad indentation and strange code in fortran/trans-array.c

[Paul Thomas]

H. J

This regtests OK and simplifies things somewhat:

Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 110407)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 3911,3917 
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;
! if (expr->ts.type == BT_CHARACTER)
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
--- 3911,3919 
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;
!
! if (expr->ts.type == BT_CHARACTER
! && expr->ts.cl->backend_decl == NULL_TREE)
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 3920,3935 
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}
! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);

/* ... which can hold our string, if present. */
! if (expr->ts.type == BT_CHARACTER)
! {
! loop.temp_ss->string_length = TYPE_SIZE_UNIT (loop.temp_ss->data.temp. 
type);

! se->string_length = loop.temp_ss->string_length;
! }
! else
! loop.temp_ss->string_length = NULL;
loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}
--- 3922,3933 
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}
!
! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);

/* ... which can hold our string, if present. */
! se->string_length = loop.temp_ss->string_length;
!
loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}

giving:

if (need_tmp)
{
/* Tell the scalarizer to make a temporary. */
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;

if (expr->ts.type == BT_CHARACTER
&& expr->ts.cl->backend_decl == NULL_TREE) /* GET THE CHARLEN */
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
loop.temp_ss->string_length = gfc_conv_mpz_to_tree
(expr->ts.cl->length->value.integer,
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}

loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts); /* 
PASS IT TO TEMP */


/* ... which can hold our string, if present. */
se->string_length = loop.temp_ss->string_length; /* THEN WE MUST WRITE 
TO SE */


loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}

Paul T

Re: Bad indentation and strange code in fortran/trans-array.c

[Paul Thomas]

H. J. Lu wrote:


On Thu, Feb 02, 2006 at 12:39:41AM +0100, Paul Thomas wrote:
 


H. J

This regtests OK and simplifies things somewhat:

   



What is this format? I don't think I can apply it cleanly?

 

I am not surprised - I tried to cut and paste from a large patch that I 
am working on.


I'll resend tonight.

Paul

Re: Build error on trunk due to new ./configure

[Paul Thomas]

Andrew Pinski wrote:



On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:


Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No wonder that `genmode' cannot be linked with
../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a
VAX-ELF file) :-)




This was just fixed by:
2006-03-14  Richard Guenther  <[EMAIL PROTECTED]>

* configure: Regenerate with autoconf 2.13.

Please update and try again.

-- Pinski

Re: Build error on trunk due to new ./configure

[Paul Thomas]

Andrew (and everybody else),

I upgraded autoconf because the build crashed when I tried to regenerate 
the fortran library.  There were already symbols present that were not 
recognised by my autoconf (I kept no record of which  - it was the 
default with FC3).  I upgraded to the version recommended in the error 
message..



i686-linux-gnu). No wonder that `genmode' cannot be linked with


../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a
VAX-ELF file) :-)


This was just fixed by:
2006-03-14  Richard Guenther  <[EMAIL PROTECTED]>

* configure: Regenerate with autoconf 2.13. 


..thanks, Richard.  I did not realise that there would be this fall-out 
from the upgrade - equally, though, the pollution was already there.


Cheers

Paul

[Bug fortran/17298] Scalarization of non-elemental intrinsic: __transfer1 / Build failure

[Paul Thomas]

Steve,



Note, your patch conflicted with one of the other 7 patches
I tested today.  You'll need to make sure the merge is
correct.

I presume that is my missing argument patch? I was going to commit it 
just now but ran into:


-c ../../trunk/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:36,
from ../../trunk/gcc/tsystem.h:90,
from ../../trunk/gcc/crtstuff.c:68:
/usr/include/bits/types.h:146: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [crtbegin.o] Error 1
make[3]: Leaving directory `/svn/gcc-4.2/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/svn/gcc-4.2/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/svn/gcc-4.2/build'
make: *** [all] Error 2

... so I guess that I will have to take care of the conflict because I 
cannot come back to it until tomorrow morning.


Now that I am out of last weeks mess, I will start reviewing once more. 
Thanks for doing the honours - 7 in one session is too many.


Paul

Re: Can we limit one bug fix per checkin please?

[Paul Thomas]

Andrew Pinski wrote:


It happened again. This checkin:
   

Yes, we did discuss it before - sorry, HJ; I am trying to get as much 
done before I am forced to reduce my work on gfortran. It is much easier 
to do multiple patches but I will desist.




Yes the standard thing is one checkin pre fix ...snip...
 


OK - will do. However, all that said, I am onto it

Paul

Fortran regressions on Cygwin_NT

[Paul Thomas]

The failures below have all come up in the last few days using

GNU Fortran (GCC) 4.3.0 20070815 (experimental)

on Cygwin_NT/amd64

Cheers

Paul

FAIL: gfortran.dg/g77/980310-3.f (internal compiler error)
FAIL: gfortran.dg/g77/980310-3.f (test for excess errors)
Running /svn/trunk/gcc/testsuite/gfortran.dg/gomp/gomp.exp ...
Running /svn/trunk/gcc/testsuite/gfortran.dg/vect/vect.exp ...
Running 
/svn/trunk/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ..

.
Running 
/svn/trunk/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ..

.
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O0
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O1
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  
-O3 -fo

mit-frame-pointer
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  
-O3 -fo

mit-frame-pointer -funroll-loops
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  
-O3 -fo

mit-frame-pointer -funroll-all-loops -finline-functions
FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  
-O3 -g


FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution,  -Os

Gfortran annual report for 2008

[Paul Thomas]

Gfortran maintainers have kept up the momentum of 2006 and the number
of known F95 bugs has gone down sharply, the diagnostic capability
has increased and new F2003/8 features added.

Hopefully, the contributors can continue to move forward with bug
fixes, conformance to Fortran 95 standard, and the implementation of
Fortran 2003/8 features.  However, this needs new blood in the ranks,
particularly since Steve Kargl and Bud Davis have hung up their
maintainer hats and some of the other regulars are struggling with
competition between gfortran and daytime jobs or moves between
countries.

If you have any interest in helping out, please do not hestitate to
contact one of us or to mail the gfortran list, for help on how to
get started.

An important source of help to us is bug reporting.  Best of all is for
bugs to be posted in Bugzilla with well reduced testcases.  There is a
group of regulars out there whose efforts are really appreciated. It is
noticable that threads on comp.lang.fortran are becoming increasingly
important; particularly to resolve thorny issues of Standard
interpretation but also for picking up bugs. A favourite was "Most
elegant syntax for inverting a permutation?" which led to corrections
of problems with assignment and FORALL.

As an aside, it should be noted that the main part of this report
was written by Steve Kargl.  Many thanks, Steve!  Thank you for all
your contributions over the years and, should you change your mind,
we all look forward to you rejoining us.

A few highlights from the past year are:

 1) Chris Rickett's ISO C Binding patch.  He did ~95% of work with
Tobias Burnus, F-X Coudert and Steve Kargl throwing the odd fix
here and there.
 2) Daniel Franke and Brooks Moses wrote, rewrote, and re-organized
large portions of the gfortran manual.  This is a thankless task
that has resulted in a great improvement to the documentation
of gfortran.
 3) Brooks and Pault finally implemented TRANSFER(), which was a
glaring omission in gfortran's conformance to the F95 standard.
 4) Janus Weil was gfortran's first Google SoC student.  He worked
on the Fortran 2003 PROCEDURE feature.  Procedure pointers will
be implemented in 2008.
 5) An important milestone only a few may notice is that the number
of bug reports against conformance to F95 is diminishing.  This
has been a collective effort with all the maintainers keeping an
eye on the "bug-bashing" part of the gfortran wiki, mentioned at
the end of this report.
 6) Janne Blomqvist finally got his symbol versioning patch into the
tree.
 7) F-X Coudert, Thomas Koenig, Jerry DeLisle, Janne Blomqvist, and
Daniel Franke(and others) have expended a large amount of effort
on making libgfortran more robust, faster, cleaner, etc.
 8) Subreference array pointers, which was the last missing F95
    feature, were implemented by Paul Thomas.  This feature permits
likes of "my_int_pointer => my_type(:)%int_cmp".
 9) At some stage in the year, some underlying bugs were fixed that
allowed J.L.Schonfelder's ISO Varying String testsuite to run
faultlessly with Rich Townsend's version of the ISV library, which
uses allocatable components, aka TR 15581.
10) The backtrace/code-dump option was added by F-X Coudert.
11) The -finit-* options were added by Asher Langton.
12) Although the postion of gfortran in the Polyhedron performance
tables has not changed much, the diagnostic rating has creapt up
from 34% to 42%.

There were 497 commits to the gfortran front-end in 2007.  A ChangeLog
for a multi-author patch is credited to the first listed name. The
number of commits by committer are:

Rafael Avila de Espindola   3
Janne Blomqvist 9
Steven Bosscher 1
Paul Brook  2
Tobias Burnus 103
Nick Clifton2
Francois-Xavier Coudert99
Jerry DeLisle  49
Steve Ellcey2
Bernhard Fischer6
Daniel Franke  55
Kaveh R. Ghazi  5
Richard Guenther7
Richard Henderson   1
Aldy Hernandez  1
Kazu Hirata 7
Jan Hubicka 2
Dominique d'Humieres1
Daniel Jacobowitz   1
Jakub Jelinek  11
Steven G. Kargl24
Thomas Koenig  14
Anton Korobeynikov  1
Asher Langton   2
Sandra Loosemore2
Manuel Lopez-Ibanez 1
H.J. Lu 4
Lee Millward4
Mark Mitchell   1
Brooks Moses   50
Dirk Mueller1
Joseph Myers2
Andrew Pinski   3
Christopher D. Rickett 19
Duncan Sands1
Roger Sayle22
Tobias Schlueter