Build failure in dwarf2out

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 ..

Re: Build failure in dwarf2out

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 i

Re: Polyhedron performance regression

Richard, If I had to guess I would say it was the forwprop merge... The what? :-) Paul

Re: Polyhedron performance regression

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 improv

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

Brooks, Is this the expected/desired behavior for "dg-do compile"? I had always thought so :-) Paul

Re: gfortran year end status report

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(?)

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

Build failure under Cygwin_NT-5.0

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-share

Re: Build failure under Cygwin_NT-5.0

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

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

Re: Cygwin build failure

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 c

[Fwd: ezmlm warning]

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 bou

Re: Heads up: many recent Fortran SPEC regressions

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

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

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

Re: RFC: future gfortran development and subversion

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

Re: RFC: future gfortran development and subversion

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

Re: RFC: future gfortran development and subversion

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

svn: Is it there yet?

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?

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?

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 PROTECTE

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

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

Re: build1, build1_v and friends

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

Re: build1, build1_v and friends

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}

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 consisten

Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}

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

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

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

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

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

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 worki

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

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

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

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 recommen

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

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 i

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

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

Fortran regressions on Cygwin_NT

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/g

Gfortran annual report for 2008

lomqvist, 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_in