[Bug ada/19037] constant renaming creates new constant
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19037
[Bug fortran/25051] NULL doesn't get its argument type (rank)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-08 06:19 --- Oh, my example is just PR 20858. I think they are the same problem but I don't know for sure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||20858 Summary|NULL doesn't get its|NULL doesn't get its |argument type |argument type (rank) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25051
[Bug fortran/25051] ranks do not match in pointer assignment with NULL
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-08 06:17 --- Hmm, (I have not looked at the source yet but) I suspect we are not recording the type of NULL so that we get a NULL without a kind. This shows that I am more likely correct: REAL, POINTER, DIMENSION(:,:) :: i INTEGER, POINTER, DIMENSION(:,:) :: a a=>NULL(i) END -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ranks do not match in |ranks do not match in |pointer assignment |pointer assignment with NULL http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25051
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-08 06:13 --- (In reply to comment #7) > In fact, it regtests OK, apart from the above. I want to say that PR 20881 is the same issue too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||20881 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug fortran/20877] result may not be entry
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-08 06:09 --- We should be erroring out before adding the symbol to namespace, which is not happening. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20877
[Bug fortran/20894] parentheses ignored
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-08 06:03 --- This looks like another case for PR 14771. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||14771 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20894
[Bug fortran/19260] & not required when splitting a token in continuation
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-08 06:00 --- (In reply to comment #2) > Isn't this a dup of bug 19101? No but it is related to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug fortran/18315] missing error for incompatible array assignment involving lbound
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-08 05:53 --- Lahey's says: 2317-S: "SOURCE.F90", line 5, column 3: Shape of arrays on left and right sides of assignment do not conform. I think what is happening is that lbound's type is becoming a scalar and not an array with size of 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18315
[Bug fortran/20869] EXTERNAL and INTRINSIC cannot be used together
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-08 05:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/20869] error needed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-08 05:44 --- Actually this is not a dup of bug 20373. I don't know where I got that from. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20869
[Bug fortran/19262] more than thirty-nine continuation lines should issue a std-warn
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-08 05:43 --- I think in fortran 2003, the number of continuations went up, way up to around 255. (this is based on the May 2004 draft): A statement shall not have more than 255 continuation lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19262
[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-08 05:35 --- (In reply to comment #8) > Another one is the following (without any possible aliasing problems): Actually that is still a violation of the aliasing rules, as you are acessing a character as a Foo. Yes that is violation, though I think GCC does not define it as one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug tree-optimization/8781] Pessimization of C++ (functional) code
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-08 05:32 --- Hmm, maybe there is really something else going on here: struct noop_tD.1999 D.2016; struct noop_tD.1999 predD.2575; predD.2575 = (struct noop_tD.1999) D.2016; Hmm, why is there a cast there? They are the same types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
[Bug glibc] Problem in configuring glibc
Hello everyone, I am trying to compile glibc2.3.5 on Red Hat 9.0(2.4.20-8) on a x86 machine with binutilies 2.16.1 installed on it but i am are getting an error : . checking for stdint.h... yes checking for unistd.h... yes checking for long double... yes checking size of long double... 12 running configure fragment for sysdeps/i386/elf checking for i386 TLS support... yes running configure fragment for nptl/sysdeps/unix/sysv/linux running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... no configure: error: forced unwind support is required . Can any body direct me how to proceed further ? -- Regards, Sandeep
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-01-08 05:18 --- I am no longer working on this bug, from what I hear it is really just to change the check "n_branch != 1" to "n_branch > 2" but I don't know if that is true or not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |12/msg00832.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug fortran/25714] concat of strings create an extra temporary variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
[Bug fortran/25714] New: concat of strings create an extra temporary variable
Take: character(2) :: c character(1) :: a character(1) :: b c = a//b end We get: _gfortran_concat_string (2, str.1, 1, &a, 1, &b); _gfortran_copy_string (2, &c, 2, str.1); We should be able to get: _gfortran_concat_string (2, &c, 1, &a, 1, &b); Instead and get rid of the tempory variable of str.1. -- Summary: concat of strings create an extra temporary variable Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2006-01-08 02:43 --- Subject: Re: [meta-bug] g77 features lacking in gfortran On Sun, Jan 08, 2006 at 02:30:51AM -, Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: > > I find this very offensive. As you will have noticed we have a problem report > about this, which is not closed as "WONTFIX", and thus we're definitely not > just calling this feature "excremental". Also, you're saying that Paul Thomas > (who wrote the original bug report where this wording is used) is > unprofessional and undedicated. The latter is easily disproved by taking a > look at the ChangeLog. In fact, everybody working on gfortran is doing so > out of dedication, as noone of us is getting paid for this work, and everybody > has access to commercial compilers. > > This construct in non-standard for the reasons quoted by Steve and and so far > the people working on gfortran have considered the importance of this bug > second to the other bugs they were fixing. If somebody cares enough he may > bring forth a patch, which -- provided sufficient quality -- will be > integrated, and we will be one step closer to a complete Fortran 66 compiler. > Wow. You took the words out of my mouth. It took me nearly 40 minutes to write my last reply. Self editing of some rather pointed comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-01-08 02:30 --- Subject: Re: [meta-bug] g77 features lacking in gfortran malitzke at metronets dot com wrote: > --- Comment #8 from malitzke at metronets dot com 2006-01-07 20:30 > --- > Not all of the underlying are just g77 features. Some like 18540/25705 are > legal f90, f95, f06 code an just calling them "excremental" is unprofessional. > This diminishes the 90% plus of dedicated people working on GCC. If something > is clearly impoosible to continue as part of fortran then an effort to change > the specs should be made. I find this very offensive. As you will have noticed we have a problem report about this, which is not closed as "WONTFIX", and thus we're definitely not just calling this feature "excremental". Also, you're saying that Paul Thomas (who wrote the original bug report where this wording is used) is unprofessional and undedicated. The latter is easily disproved by taking a look at the ChangeLog. In fact, everybody working on gfortran is doing so out of dedication, as noone of us is getting paid for this work, and everybody has access to commercial compilers. This construct in non-standard for the reasons quoted by Steve and and so far the people working on gfortran have considered the importance of this bug second to the other bugs they were fixing. If somebody cares enough he may bring forth a patch, which -- provided sufficient quality -- will be integrated, and we will be one step closer to a complete Fortran 66 compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-01-08 02:22 --- Fixed on 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug libfortran/25598] [4.1/4.2 Regression] gfortran - Fortran runtime error: Invalid argument
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-01-08 02:21 --- Fixed in 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25598
[Bug libfortran/25598] [4.1/4.2 Regression] gfortran - Fortran runtime error: Invalid argument
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-01-08 02:17 --- Subject: Bug 25598 Author: jvdelisle Date: Sun Jan 8 02:17:54 2006 New Revision: 109470 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109470 Log: 2005-01-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25598 * gfortran.dg/backspace_3.f: New test. * gfortran.dg/backspace_4.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/backspace_3.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/backspace_4.f Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25598
[Bug libfortran/25598] [4.1/4.2 Regression] gfortran - Fortran runtime error: Invalid argument
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-01-08 02:16 --- Subject: Bug 25598 Author: jvdelisle Date: Sun Jan 8 02:16:11 2006 New Revision: 109469 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109469 Log: 2006-01-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25598 * io/file_pos.c (unformatted_backspace): Assure the new file position to seek is not less than zero. (st_backspace): Set unit bytes_left to zero. * io/transfer.c (next_record_r): Fix line lengths, no functional change. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/file_pos.c branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25598
Pixels That Rock
Sorry for the previous blank email. I saw your name and email address on a website and thought you might be interested in taking a look at my new site. www.pixelsthatrock.com If you are interested in trading links or something let me know. Thanks! - Dan
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-01-08 01:58 --- Subject: Re: [meta-bug] g77 features lacking in gfortran On Sun, Jan 08, 2006 at 12:33:29AM -, malitzke at metronets dot com wrote: > > Last things first: The code posted in 25705 is copyrighted 1994 and published > in Computer Physics Communications; hence just modification by a third party > could be legally questionable. The two academics (one in computer Science) > conceivably were cogniscent of the f90 standard. So, contact the original authors! Posting the copryrighted code to a mailing list is also questionable. > Anyhow, standards should be quoted in context, I have the Sep 2002 > working draft (only abrogating f77, f90, and f95, per Annex B) which > per Para 8.1.1.2 matches the quotation in comment 10. However, the > 105 label precedes the first executable statement. Now, line > 18 of 8.1 reads as follows: > > Any of these constructs may be named. If a construct is named, the > name shall be the first lexical token of the first statement of the > construct and the last lexical token of the construct. In fixed source > form, the name preceding the construct shall be placed after character > position 6. > > Therefore, the 105 GOTO address clearly is not inside the construct, > because it immediately follows the ELSE and precedes character position > 6 of the construct proper; and 8.1.1.2 does not apply. There are no named constructs in the code posted! The 105 in is a *statement label*. A named construct in fixed form would be c234567 n = 2 AAA: if (n == 1) then n = 100 else if (n == 2) then AAA n = 200 else AAA n = 0 end if AAA print *, n end > If label 105 would not precede the block, but be inside, then error message, > pertaining to the inside of the block would be proper. It is in a block. If we remove the unneeded lines, you have 506 IF(IX.EQ.0. AND. IY.EQ.1) THEN A IF(IBACK3.EQ.0) THEN AB IF(MGO.EQ.0) THEN ABD N=4 AB ELSEIF(MGO.EQ.1) THEN ABE IF(IBACK3.EQ.1) THEN ABEF GO TO 105 ! rmg questionable goto ABE ELSE ABEG N=4 ABE ENDIF AB ELSE ABD GO TO 108 AB ENDIF A ELSE AC 105 IRHO=NU AC RETURN A ENDIF A 108 MEMR=IRHO ENDIF Everything marked with an A is in the constituent block of the outermost IF...ENDIF. Everything marked with the AB is in the constituent block of the IF(IBACK3.EQ.0) THEN ... ELSE. Everything marked with AC is in the constituent block of the ELSE ... ENDIF that corresponds the IF(IBACK3.EQ.0) THEN. The "GO TO 105" is transferring control into the AC block, which is prohibited! > Also, if commercial compilers would have a clear basis to issue an error > message, they probably would do so and get off the hook. The wording in 8.1.1.2 is such that a compiler is not required by the standard to issue an error here. The words are "Transfer of control to the interior of a block from outside the block is prohibited." The "is" provides wiggle room for a vendor. If the "is" were "shall be", then an error message would be required. > As I am clearly no the author the the code, I have no real position > to defend. As my post 25705 makes clear legalistic arguments should > be avoided. We're trying to write a Fortran 95 conforming compiler. We can't avoid legalistic arguments. I'm sorry if this view offends you. > I also coded a parallel C program and used f2c on the code fragment > posted. In both cases gcc-4.1.0 emitted object code without complaint. > In this respect C and fortran are both block structured languages > without nesting of subroutines. Therefore, if gcc-4.1.0 can handle > it for C a parallel construct should do it for fortran. C and Fortran are two different languages with two different standards. f2c is at best a Fortran 77 compiler. The behavior you want may be permitted by Fortran 77, but I would need to study the Fortran 77 standard before I make any judgement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-01-08 01:56 --- Subject: Bug 24268 Author: jvdelisle Date: Sun Jan 8 01:56:22 2006 New Revision: 109468 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109468 Log: 2005-01-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/24268 * gfortran.dg/fmt_white.f: Update test. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/fmt_white.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug fortran/24268] gfortran rejects valid format statement
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-01-08 01:53 --- Subject: Bug 24268 Author: jvdelisle Date: Sun Jan 8 01:53:06 2006 New Revision: 109467 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109467 Log: 2006-01-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/24268 * io.c (next_char_not_space): New function that returns the next character that is not white space. (format_lex): Use the new function to skip whitespace within a format string. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24268
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-08 00:51 --- (In reply to comment #11) > As I am clearly no the author the the code, I have no real position to defend. > As my post 25705 makes clear legalistic arguments should be avoided. I also > coded a parallel C program and used f2c on the code fragment posted. In both > cases gcc-4.1.0 emitted object code without complaint. In this respect C and > fortran are both block structured languages without nesting of subroutines. > Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it > for fortran. C is different than Fortran. I am not clear why you are bring that up at all. Also ICC warns about the code which is why I put in PR 25705 which makes me question the code and if other compiler also warns (or even errors out) about it (by default), it is even more questionable. Also fortran does have nesting of subroutines, I don't get why you said it is not, it is a feature of Fortran 90. You can do something like: function g(f) REAL :: g REAL :: f g = h() contains function h() REAL :: h h = f +1.0 end function end function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug rtl-optimization/24257] [4.1/4.2 Regression] ICE: in extract_insn with -O -fgcse -fgcse-sm
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 00:45 ---
I looked at what is going on here with "GNU C version 4.1.0 20060107
(prerelease) (x86_64-unknown-linux-gnu)"
We produce the invalid insn in replace_store_insn, where we have:
(gdb) p debug_rtx(del)
(insn 19 17 21 0 (parallel [
(set (mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0 S4 A32])
(ashift:SI (mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0
S4 A32])
(subreg:QI (reg/v:SI 64 [ n ]) 0)))
(clobber (reg:CC 17 flags))
]) 413 {*ashlsi3_1} (nil)
(nil))
gen_move_insn is used to produce a move for this:
replace_store_insn (reg=0x2afcc000, del=0x2afc73c0, bb=0x2afb9780,
smexpr=0xcdae70) at gcse.c:6296
6296 mem = smexpr->pattern;
(gdb) p debug_rtx(del)
(insn 19 17 21 0 (parallel [
(set (mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0 S4 A32])
(ashift:SI (mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0
S4 A32])
(subreg:QI (reg/v:SI 64 [ n ]) 0)))
(clobber (reg:CC 17 flags))
]) 413 {*ashlsi3_1} (nil)
(nil))
$8 = void
(gdb) next
6297 insn = gen_move_insn (reg, SET_SRC (single_set (del)));
(gdb) p debug_rtx(mem)
(mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0 S4 A32])
$9 = void
(gdb) next
6298 insn = emit_insn_after (insn, del);
(gdb) p debug_rtx(insn)
(insn 57 0 0 (set (reg:SI 65)
(ashift:SI (mem/s:SI (reg/v/f:DI 63 [ s ]) [3 .buf+0 S4 A32])
(subreg:QI (reg/v:SI 64 [ n ]) 0))) -1 (nil)
(nil))
$10 = void
(gdb) p recog_memoized (insn)
$11 = -1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #11 from malitzke at metronets dot com 2006-01-08 00:33 --- Last things first: The code posted in 25705 is copyrighted 1994 and published in Computer Physics Communications; hence just modification by a third party could be legally questionable. The two academics (one in computer Science) conceivably were cogniscent of the f90 standard. Anyhow, standards sould be quoted in context, I have the Sep 2002 working draft (only abrogating f77, f90, and f95, per Annex B) which per Para 8.1.1.2 matches the quotation in comment 10. However, the 105 label precedes the first executable statement. Now, line 18 of 8.1 reads as follows: Any of these constructs may be named. If a construct is named, the name shall be the first lexical token of the first statement of the construct and the last lexical token of the construct. In fixed source form, the name preceding the construct shall be placed after character position 6. Therefore, the 105 GOTO address clearly is not inside the construct, because it immediately follows the ELSE and precedes character position 6 of the construct proper; and 8.1.1.2 does not apply. If label 105 would not precede the block, but be inside, then error message, pertaining to the inside of the block would be proper. Also, if commercial compilers would have a clear basis to issue an error message, they probably would do so and get off the hook. As I am clearly no the author the the code, I have no real position to defend. As my post 25705 makes clear legalistic arguments should be avoided. I also coded a parallel C program and used f2c on the code fragment posted. In both cases gcc-4.1.0 emitted object code without complaint. In this respect C and fortran are both block structured languages without nesting of subroutines. Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it for fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-01-08 00:14 --- Working on a patch. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org Keywords|diagnostic |accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug target/25662] [4.0/4.1 Regression] Unrecognizable insn with -O on PPC
--- Comment #7 from dje at gcc dot gnu dot org 2006-01-07 22:23 --- Subject: Bug 25662 Author: dje Date: Sat Jan 7 22:23:27 2006 New Revision: 109456 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109456 Log: 2005-01-07 Ian Lance Taylor David Edelsohn <[EMAIL PROTECTED]> PR rtl-optimization/25662 * optabs.c (simplify_expand_binop): Use simplify_binary_operation for constant operands instead of simplify_gen_binary. * simplify-rtx.c (simplify_gen_binary): Swap commutative operands after trying simplify_binary_operation Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2006-01-07 22:17 --- Subject: Re: [meta-bug] g77 features lacking in gfortran On Sat, Jan 07, 2006 at 09:55:07PM -, kargl at gcc dot gnu dot org wrote: > > > Well, in looking at the code in 25705, I think the code is nonconforming via > 8.1.1.2 of the Fortran 95 standard. I don't have a copy of the Fortran 90 > standard, but I suspect that it will also show that the code is nonconforming. > I'll also note that Lahey's web base checking utility calls out the "goto 105" with a warning. NAG's Fortran 95 compiler issues an error similar to gfortran's message. The exact text of 8.1.1.2 is: Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a block and transfers from the interior of a block to outside the block may occur. This statement is followed with NOTE 8.3 For example, if a statement inside the block has a statement label, a GO TO statement using that label is only allowed to appear in the same block. My advice would be to fix the code to make it portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug other/25712] cc1: error: unrecognized command line option "-fdump-tree-vars"
--- Comment #1 from steven at gcc dot gnu dot org 2006-01-07 22:00 --- http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00416.html -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25712
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #9 from kargl at gcc dot gnu dot org 2006-01-07 21:55 --- (In reply to comment #8) > Not all of the underlying are just g77 features. Some like 18540/25705 are > legal f90, f95, f06 code an just calling them "excremental" is unprofessional. > This diminishes the 90% plus of dedicated people working on GCC. If something > is clearly impoosible to continue as part of fortran then an effort to change > the specs should be made. Well, in looking at the code in 25705, I think the code is nonconforming via 8.1.1.2 of the Fortran 95 standard. I don't have a copy of the Fortran 90 standard, but I suspect that it will also show that the code is nonconforming. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #7 from paulthomas2 at wanadoo dot fr 2006-01-07 21:46 --- Subject: Re: named common block confused as procedure - runtime segfault > The enclosed patch catches Andrew's PR but also snags on > g77/19990905-1.f (The Burley test case). In fact, it regtests OK, apart from the above. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #6 from paulthomas2 at wanadoo dot fr 2006-01-07 21:44 ---
Subject: Re: named common block confused as procedure
- runtime segfault
Steve and Andrew,
>--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-07 20:19 ---
>Andrew, Lahey's code checking utility gives
>
>Compiling program unit f at line 1:
>Compiling program unit test at line 5:
>Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90.
>Compiling file SOURCE.F90.
>
>NAG's compiler also compiles the code without an error or warning.
>
>
>
>
The enclosed patch catches Andrew's PR but also snags on
g77/19990905-1.f (The Burley test case). I will sit down with the
standard and sort out what is and is not required of global symbols,
contained symbols and scopes in general. If nothing else, the enclosed
will catch some nasties that are escaping at the moment.
Best regards
Paul
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 109449)
--- gcc/fortran/resolve.c (working copy)
*** resolve_function (gfc_expr * expr)
*** 1157,1162
--- 1157,1172
try t;
int temp;
+ gfc_gsymbol * gsym;
+
+ gsym = NULL;
+ if (expr->symtree && expr->symtree->n.sym)
+ gsym = gfc_find_gsymbol (gfc_gsym_root, expr->symtree->n.sym->name);
+
+ if ((gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_FUNCTION))
+ gfc_warning_now ("reference at %L to %s which is not a function",
+&expr->where, expr->symtree->n.sym->name);
+
/* Switch off assumed size checking and do this again for certain kinds
of procedure, once the procedure itself is resolved. */
need_full_assumed_size++;
*** resolve_call (gfc_code * c)
*** 1510,1515
--- 1520,1535
{
try t;
+ gfc_gsymbol * gsym;
+
+ gsym = NULL;
+ if (c->symtree && c->symtree->n.sym)
+ gsym = gfc_find_gsymbol (gfc_gsym_root, c->symtree->n.sym->name);
+
+ if ((gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_SUBROUTINE))
+ gfc_warning_now ("CALL at %L to %s which is not a subroutine",
+&c->loc, c->symtree->n.sym->name);
+
/* Switch off assumed size checking and do this again for certain kinds
of procedure, once the procedure itself is resolved. */
need_full_assumed_size++;
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 109448)
--- gcc/fortran/match.c (working copy)
*** gfc_match_common (void)
*** 2247,2252
--- 2247,2253
gfc_array_spec *as;
gfc_equiv * e1, * e2;
match m;
+ gfc_gsymbol *gsym;
old_blank_common = gfc_current_ns->blank_common.head;
if (old_blank_common)
*** gfc_match_common (void)
*** 2263,2268
--- 2264,2278
if (m == MATCH_ERROR)
goto cleanup;
+ gsym = gfc_get_gsymbol (name);
+ if (gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_COMMON)
+ {
+ gfc_error ("Symbol '%s' at %C is already an external symbol that is
not COMMON",
+sym->name);
+ goto cleanup;
+ }
+ gsym->type = GSYM_COMMON;
+
if (name[0] == '\0')
{
t = &gfc_current_ns->blank_common;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug other/25712] New: cc1: error: unrecognized command line option "-fdump-tree-vars"
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/tree-ssa/loop-15.c -O2 -fdump-tre e-vars -fno-show-column -S -o loop-15.s(timeout = 300) cc1: error: unrecognized command line option "-fdump-tree-vars" compiler exited with status 1 output is: cc1: error: unrecognized command line option "-fdump-tree-vars" FAIL: gcc.dg/tree-ssa/loop-15.c (test for excess errors) Excess errors: cc1: error: unrecognized command line option "-fdump-tree-vars" ERROR: gcc.dg/tree-ssa/loop-15.c: error executing dg-final: no files matched glo b pattern "loop-15.c.t[0-9][0-9].vars" UNRESOLVED: gcc.dg/tree-ssa/loop-15.c: error executing dg-final: no files matche d glob pattern "loop-15.c.t[0-9][0-9].vars" -- Summary: cc1: error: unrecognized command line option "-fdump- tree-vars" Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25712
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #8 from malitzke at metronets dot com 2006-01-07 20:30 --- Not all of the underlying are just g77 features. Some like 18540/25705 are legal f90, f95, f06 code an just calling them "excremental" is unprofessional. This diminishes the 90% plus of dedicated people working on GCC. If something is clearly impoosible to continue as part of fortran then an effort to change the specs should be made. -- malitzke at metronets dot com changed: What|Removed |Added CC||malitzke at metronets dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-07 20:19 --- Andrew, Lahey's code checking utility gives Compiling program unit f at line 1: Compiling program unit test at line 5: Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. NAG's compiler also compiles the code without an error or warning. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-07 19:27 --- (In reply to comment #3) > Index: gcc/fortran/resolve.c > === > *** gcc/fortran/resolve.c (revision 109449) > --- gcc/fortran/resolve.c (working copy) > *** resolve_function (gfc_expr * expr) > *** 1157,1162 > --- 1157,1172 > try t; > int temp; The only question I have with this patch is the following still passes (this is the main reason why I filed PR 25710 because I could not get the testcase in there and this testcase working): function f() REAL :: f f = 1.0 end function call f contains SUBROUTINE f end SUBROUTINE end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug target/21715] [4.0/4.1 regression] code-generation performance regression
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-07 18:41 --- GCC 4.1-20060107 still produces the code reported in the original bug report: : 0: 48 89 f8mov%rdi,%rax 3: 48 f7 d8neg%rax 6: 48 21 c7and%rax,%rdi 9: 48 89 f8mov%rdi,%rax c: c3 retq What patch may have fixed this on the trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
[Bug target/20754] ACATS cxg1005 fails at runtime on hppa-linux
--- Comment #9 from danglin at gcc dot gnu dot org 2006-01-07 18:37 ---
I'm changing this to a target bug. The bug is in the define for
SECONDARY_MEMORY_NEEDED_RTX(MODE):
#define SECONDARY_MEMORY_NEEDED_RTX(MODE) \
gen_rtx_MEM (MODE, gen_rtx_PLUS (Pmode, stack_pointer_rtx, GEN_INT (-16)))
There are a number of places where this memory location gets used during
final code generation. I don't think we can add clobbers.
When we define SECONDARY_MEMORY_NEEDED_RTX as above, reload introduces
store-load insns into the RTL to copy a value from a general/floating
register to a floating/general register. Subsequently, scheduling may
copy separate the load and store insns. This then can introduce a conflict
with the use of this memory location during code generation.
I'm not sure about the validity of scheduling moving the "fldws
-16(%r30),%fr21L"
over a call. The call_insn is marked as a const or pure call:
(call_insn/u 80 4722 4769 0 cxg1005.adb:88 (parallel [
(set (reg:SC 28 %r28)
(call (mem:SI (symbol_ref/v:SI
("@cxg1005__test_block__complex_p
ack__compose_from_cartesian__3___395") ) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) 204 {call_val_symref} (insn_list:REG_DEP_TRUE 60
(insn_list:REG_DEP_O
UTPUT 63 (insn_list:REG_DEP_ANTI 66 (insn_list:REG_DEP_ANTI 65
(insn_list:REG_DE
P_OUTPUT 20 (insn_list:REG_DEP_ANTI 22 (insn_list:REG_DEP_OUTPUT 21
(insn_list:R
EG_DEP_TRUE 79 (insn_list:REG_DEP_ANTI 64 (nil))
(expr_list:REG_DEAD (reg:SF 32 %fr4)
(expr_list:REG_UNUSED (reg:SI 2 %r2)
(expr_list:REG_UNUSED (reg:SI 1 %r1)
(nil
(expr_list:REG_DEP_TRUE (use (reg:SF 32 %fr4))
(nil)))
The decision as to whether the function is pure is made before reload and
that doesn't change when the SECONDARY_MEMORY_NEEDED_RTX MEM is used (ie.,
we use a special location in the frame of the caller for the copy. This
problem can be avoided if we always ensure that the function has a frame.
However, this adds instructions and still doesn't fix the issue that the
MEM might be used between the store and load in other situations.
Thus, I think the best fix is to remove the SECONDARY_MEMORY_NEEDED_RTX
define and do the register copy in the move patterns directly. This keeps
the MEM from being exposed in the RTL. We lose the performance benefit
of scheduling the store and load. However, we don't need a frame to
do floating-general copies.
As an aside, the problem is introduced in the RTL in the sched2 pass:
call_insn/u 80 4722 5740 0 cxg1005.adb:88 (parallel [
(set (reg:SC 28 %r28)
(call (mem:SI (symbol_ref/v:SI
("@cxg1005__test_block__complex_p
ack__compose_from_cartesian__3___395") ) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) 204 {call_val_symref} (insn_list:REG_DEP_OUTPUT 63
(insn_list:REG_DEP
_ANTI 4765 (insn_list:REG_DEP_ANTI 4763 (insn_list:REG_DEP_OUTPUT 12
(insn_list:
REG_DEP_OUTPUT 10 (insn_list:REG_DEP_OUTPUT 17 (insn_list:REG_DEP_ANTI 22
(insn_
list:REG_DEP_OUTPUT 15 (insn_list:REG_DEP_ANTI 4767 (insn_list:REG_DEP_ANTI
4768
(insn_list:REG_DEP_OUTPUT 4677 (insn_list:REG_DEP_ANTI 5372
(insn_list:REG_DEP_
ANTI 5391 (insn_list:REG_DEP_ANTI 5392 (insn_list:REG_DEP_ANTI 5393
(insn_list:R
EG_DEP_ANTI 5394 (insn_list:REG_DEP_ANTI 5395 (insn_list:REG_DEP_ANTI 5396
(insn
_list:REG_DEP_ANTI 5397 (insn_list:REG_DEP_ANTI 5398 (insn_list:REG_DEP_ANTI
539
9 (insn_list:REG_DEP_ANTI 5400 (insn_list:REG_DEP_OUTPUT 5390
(insn_list:REG_DEP
_TRUE 79 (insn_list:REG_DEP_TRUE 5373 (insn_list:REG_DEP_ANTI 64
(nil)))
(expr_list:REG_DEAD (reg:SF 32 %fr4)
(expr_list:REG_UNUSED (reg:SI 2 %r2)
(expr_list:REG_UNUSED (reg:SI 1 %r1)
(nil
(expr_list:REG_DEP_TRUE (use (reg:SF 32 %fr4))
(nil)))
(note 5740 80 4766 0 ("cxg1005.adb") 87)
(insn 4766 5740 5741 0 cxg1005.adb:87 (set (reg:SF 66 %fr21 [orig:778+4 ]
[778])
(mem:SF (plus:SI (reg/f:SI 30 %r30)
(const_int -16 [0xfff0])) [0 S4 A32])) 77 {*pa.md:4325}
(ins
n_list:REG_DEP_ANTI 5391 (insn_list:REG_DEP_TRUE 5373 (insn_list:REG_DEP_ANTI
64
(insn_list:REG_DEP_TRUE 4763 (insn_list:REG_DEP_TRUE 4765 (nil))
(nil))
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Component|ada |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #22 from steven at gcc dot gnu dot org 2006-01-07 18:33 --- I compiled the test case nodom.c with "xgcc (GCC) 4.1.0 20060107 (prerelease)" and ran the resulting executables with "time ./a.out". And the numbers speak for themselves: x86-64 (Nocona): options: -O2 real0m0.400s0m0.394s0m0.392s user0m0.408s0m0.404s0m0.400s sys 0m0.004s0m0.000s0m0.000s options: -O2 -fno-tree-dominator-opts real0m0.428s0m0.433s0m0.427s user0m0.436s0m0.440s0m0.436s sys 0m0.000s0m0.004s0m0.000s x86-64 -m32 (Nocona) options: -O2 -m32 real0m0.394s0m0.364s0m0.387s user0m0.404s0m0.372s0m0.396s sys 0m0.000s0m0.000s0m0.000s options: -O2 -m32 -fno-tree-dominator-opts real0m0.554s0m0.553s0m0.557s user0m0.568s0m0.564s0m0.572s sys 0m0.000s0m0.000s0m0.000s x86-64 -m32 -march=pentium4 options: -O2 -m32 -march=pentium4 real0m0.335s0m0.338s0m0.343s user0m0.344s0m0.344s0m0.352s sys 0m0.000s0m0.000s0m0.000s options: -O2 -m32 -fno-tree-dominator-opts -march=pentium4 real0m0.405s0m0.407s0m0.400s user0m0.416s0m0.416s0m0.408s sys 0m0.000s0m0.000s0m0.000s 'nuff said. Closing as fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-07 18:23 --- Using ``.ident "GCC: (GNU) 4.1.0 20060107 (prerelease)"'' on AMD64 with -m32, I get the following assembly outputs: options: -O2 -fno-tree-dominator-opts .L2: movl$videoram, %eax movl$-2, %edx jmp .L5 .p2align 4,,7 .L14: addl$18, %edx .L5: testl %edx, %edx movb$5, (%eax) js .L6 addl$21, %eax subl$40, %edx .L6: incl%eax cmpl%eax, %ecx jne .L14 incl%ebx movb$5, videoram+209 cmpl$1000, %ebx jne .L2 options: -O2 .L2: movb$5, videoram movl$videoram, %eax movl$-2, %edx .L18: incl%eax cmpl%eax, %ecx je .L20 .p2align 4,,7 .L5: addl$18, %edx movb$5, (%eax) js .L18 addl$21, %eax subl$40, %edx incl%eax cmpl%eax, %ecx jne .L5 .L20: incl%ebx movb$5, videoram+209 cmpl$1000, %ebx jne .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
[Bug libgcj/24940] libjava/configure uses $SED without defining it
--- Comment #3 from jakub at gcc dot gnu dot org 2006-01-07 18:14 --- Subject: Bug 24940 Author: jakub Date: Sat Jan 7 18:14:24 2006 New Revision: 109453 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109453 Log: PR libgcj/24940 * shlibpath.m4: Replace $SED with sed. * configure: Rebuilt. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/configure branches/gcc-4_1-branch/libjava/shlibpath.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24940
[Bug libgcj/24940] libjava/configure uses $SED without defining it
--- Comment #2 from jakub at gcc dot gnu dot org 2006-01-07 18:13 --- Subject: Bug 24940 Author: jakub Date: Sat Jan 7 18:13:36 2006 New Revision: 109452 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109452 Log: PR libgcj/24940 * shlibpath.m4: Replace $SED with sed. * configure: Rebuilt. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/shlibpath.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24940
[Bug fortran/25707] support for Fortran 2003 USE statements, INTRINSIC and NONINTRINSIC
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-07 18:09 --- Actually, you got the syntax slightly wrong (sorry for not noticing it right away). The standard (and from my reading of the ibm docs it seems that they agree with the standard) specifices the use statement as use [[, module-nature] ::] module-name [etc...] where module-nature is either intrinsic or non_intrinsic. That is, if module-nature is specified the ',' and '::' are mandatory, so the statement in comment #1 must be of the form use, intrinsic :: iso_fortran_env -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25707
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-07 18:04 ---
On AMD64 with GNU C version 4.2.0 20060107, I get this .optimized dump:
;; Function foo (foo)
foo (r)
{
int r$b;
int r$a;
char r$d;
:
r$b = r.b;
r$a = r.a;
r$d = r.d;
.m = r.m;
.b = r$b;
.a = r$a;
.d = r$d;
return ;
}
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2005-05-08 18:01:19 |2006-01-07 18:04:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
[Bug fortran/25709] BIND (Fortran 2003) is not supported at all
--- Comment #3 from jb at gcc dot gnu dot org 2006-01-07 18:02 --- Confirmed -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-07 18:02:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
[Bug fortran/25707] support for Fortran 2003 USE statements, INTRINSIC and NONINTRINSIC
--- Comment #1 from jb at gcc dot gnu dot org 2006-01-07 17:58 --- Confirmed. Incidentally, you can find the final draft of F2003 (which differs very little from the published standard) at http://www.j3-fortran.org/doc/year/04/04-007.pdf -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-07 17:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25707
[Bug fortran/25709] BIND (Fortran 2003) is not supported at all
--- Comment #2 from kargl at gcc dot gnu dot org 2006-01-07 17:39 --- BTW, this feature is actively being worked upon. See http://gcc.gnu.org/ml/fortran/2005-12/msg00270.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #3 from pault at gcc dot gnu dot org 2006-01-07 17:07 ---
(In reply to comment #2)
> Note I think fixing PR 25710 and the mentioned problem of not keeping symbols
> correctly will fix this bug. I have been trying to fix this but it is hard.
I notice that there is a handle in gfortran.h to deal with this:
/* Global symbols are symbols of global scope. Currently we only use
this to detect collisions already when parsing.
TODO: Extend to verify procedure calls. */
typedef struct gfc_gsymbol
{
BBT_HEADER(gfc_gsymbol);
const char *name;
enum { GSYM_UNKNOWN=1, GSYM_PROGRAM, GSYM_FUNCTION, GSYM_SUBROUTINE,
GSYM_MODULE, GSYM_COMMON, GSYM_BLOCK_DATA } type;
int defined, used;
locus where;
}
gfc_gsymbol;
extern gfc_gsymbol *gfc_gsym_root;
and in symbol.c
/* Search a tree for the global symbol. */
gfc_gsymbol *
gfc_find_gsymbol (gfc_gsymbol *symbol, const char *name)
{
friends
Astonishingly, none of this is ever used!
The experimental patch below picks up pr25710 but not this one. COMMON blocks
need to be given a gsymbol, methinks.
Paul
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 109449)
--- gcc/fortran/resolve.c (working copy)
*** resolve_function (gfc_expr * expr)
*** 1157,1162
--- 1157,1172
try t;
int temp;
+ gfc_gsymbol * gsym;
+
+ gsym = gfc_find_gsymbol (gfc_gsym_root, expr->symtree->n.sym->name);
+
+ if ((gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_FUNCTION)
+||
+ (expr->symtree && !expr->symtree->n.sym->attr.external &&
!expr->symtree->n.sym->attr.subroutine))
+ gfc_warning_now ("CALL at %L to procedure %s which is not a function",
+&expr->where, expr->symtree->n.sym->name);
+
/* Switch off assumed size checking and do this again for certain kinds
of procedure, once the procedure itself is resolved. */
need_full_assumed_size++;
*** resolve_call (gfc_code * c)
*** 1510,1515
--- 1520,1535
{
try t;
+ gfc_gsymbol * gsym;
+
+ gsym = gfc_find_gsymbol (gfc_gsym_root, c->symtree->n.sym->name);
+
+ if ((gsym && gsym->type != GSYM_UNKNOWN && gsym->type != GSYM_SUBROUTINE)
+||
+ (c->symtree && !c->symtree->n.sym->attr.external &&
!c->symtree->n.sym->attr.subroutine))
+ gfc_warning_now ("CALL at %L to procedure %s which is not a subroutine",
+&c->loc, c->symtree->n.sym->name);
+
/* Switch off assumed size checking and do this again for certain kinds
of procedure, once the procedure itself is resolved. */
need_full_assumed_size++;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug rtl-optimization/16803] PowerPC - invariant code motion could be removed from loop.
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-07 16:24 --- I forgot to say the loop now looks like: L4: sthx r0,r2,r11 addi r2,r2,2 bdnz L4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16803
[Bug rtl-optimization/16803] PowerPC - invariant code motion could be removed from loop.
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-07 16:23 --- Fixed in 4.2.0 by the patch which fixed PR 18527. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16803
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 16:20 --- This was NOT fixed by the patch which fixed PR 18527. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug tree-optimization/25644] Not vectorizing F90 array expressions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 16:04 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25644
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-07 16:03 --- Fixed for 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug c/25682] [4.0/4.1/4.2 Regression] ICE when using old sytle offsetof (with non zero start) as array size
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 16:01 --- This only happens with a non NULL pointer. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1/4.2 Regression] ICE |when using old sytle|when using old sytle |offsetof as array size |offsetof (with non zero ||start) as array size http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25682
[Bug c/24372] Internal error due to really long assignement statement
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 15:33 --- No feedback in 3 months (T-7 days). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24372
[Bug bootstrap/22396] bootstrap of f95 enabled gcc fails because gfortran.1 is missing
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 15:33 --- No feedback in 3 months (T-2 days). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22396
[Bug bootstrap/25695] [4.2 Regression] bootstrap no longer does a comparision
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 15:11 --- Oh, unlike the makefile in gcc/Makefile, there is @ there that makes everyone confused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25695
[Bug fortran/20870] reference to size of assumed-size array
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-07 14:14 ---
Subject: Bug 20870
Author: pault
Date: Sat Jan 7 14:14:08 2006
New Revision: 109449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109449
Log:
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* trans-array.c (gfc_reverse_ss): Remove static attribute.
(gfc_walk_elemental_function_args): Replace gfc_expr * argument for
the function call with the corresponding gfc_actual_arglist*. Change
code accordingly.
(gfc_walk_function_expr): Call to gfc_walk_elemental_function_args
now requires the actual argument list instead of the expression for
the function call.
* trans-array.h: Modify the prototype for
gfc_walk_elemental_function_args
and provide a prototype for gfc_reverse_ss.
* trans-stmt.h (gfc_trans_call): Add the scalarization code for the
case
where an elemental subroutine has array valued actual arguments.
PR fortran/25029
PR fortran/21256
PR fortran/20868
PR fortran/20870
* resolve.c (check_assumed_size_reference): New function to check for
upper
bound in assumed size array references.
(resolve_assumed_size_actual): New function to do a very restricted
scan
of actual argument expressions of those procedures for which incomplete
assumed size array references are not allowed.
(resolve_function, resolve_call): Switch off assumed size checking of
actual arguments, except for elemental procedures and intrinsic
inquiry functions, in some circumstances.
(resolve_variable): Call check_assumed_size_reference.
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* gfortran.dg/elemental_subroutine_1.f90: New test.
* gfortran.dg/elemental_subroutine_2.f90: New test.
PR fortran/25029
PR fortran/21256
* gfortran.dg/assumed_size_refs_1.f90: New test.
PR fortran/20868
PR fortran/20870
* gfortran.dg/assumed_size_refs_2.f90: New test.
* gfortran.dg/initialization_1.f90: Change warning message.
Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_2.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_2.f90
Modified:
trunk/MAINTAINERS
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
Added: trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90?root=gcc&view=auto&rev=109449
==
--- trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 Sat Jan 7 14:14:08
2006
@@ -1,0 +1,64 @@
+!==assumed_size_refs_1.f90==
+! { dg-do compile }
+! Test the fix for PR25029, PR21256 in which references to
+! assumed size arrays without an upper bound to the last
+! dimension were generating no error. The first version of
+! the patch failed in DHSEQR, as pointed out by Toon Moene
+! in http://gcc.gnu.org/ml/fortran/2005-12/msg00466.html
+!
+! Contributed by Paul Thomas <[EMAIL PROTECTED]>
+!
+program assumed_size_test_1
+ implicit none
+ real a(2, 4)
+
+ a = 1.0
+ call foo (a)
+
+contains
+ subroutine foo(m)
+real, target :: m(1:2, *)
+real x(2,2,2)
+real, external :: bar
+real, pointer :: p(:,:), q(:,:)
+allocate (q(2,2))
+
+! PR25029
+p => m ! { dg-error "upper bound in the last
dimension" }
+q = m ! { dg-error "upper bound in the last
dimension" }
+
+! PR21256( and PR25060)
+m = 1 ! { dg-error "upper bound in the last
dimension" }
+
+m(1,1) = 2.0
+x = bar (m)
+x = fcn (m)! { dg-error "upper bound in the last
dimension" }
+m(:, 1:2) = fcn (q)
+call sub (m, x)! { dg-error "upper bound in the last
dimension" }
+call sub (m(1:2, 1:2), x)
+print *, p
+
+call DHSEQR(x)
+
+ end subroutine foo
+
+ elemental function fcn (a) result (b)
+real, intent(in) :: a
+real :: b
+b = 2.0 * a
+ end function fcn
+
+ elemental subroutine sub (a, b)
+real, intent(inout) :: a, b
+b = 2.0 * a
+ end subroutine sub
+
+ SUBROUTINE DHSEQR( WORK )
+REAL WORK( * )
+EXTERNAL DLARFX
+INTRINSIC MIN
+WORK( 1 ) = 1.0
+CALL DLARFX( MIN( 1, 8 ), WORK )
+ END SUBROUTINE DHSEQR
+
+end pr
[Bug fortran/25029] Assumed size array can be associated with array pointer without upper bound of last dimension
--- Comment #7 from pault at gcc dot gnu dot org 2006-01-07 14:14 ---
Subject: Bug 25029
Author: pault
Date: Sat Jan 7 14:14:08 2006
New Revision: 109449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109449
Log:
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* trans-array.c (gfc_reverse_ss): Remove static attribute.
(gfc_walk_elemental_function_args): Replace gfc_expr * argument for
the function call with the corresponding gfc_actual_arglist*. Change
code accordingly.
(gfc_walk_function_expr): Call to gfc_walk_elemental_function_args
now requires the actual argument list instead of the expression for
the function call.
* trans-array.h: Modify the prototype for
gfc_walk_elemental_function_args
and provide a prototype for gfc_reverse_ss.
* trans-stmt.h (gfc_trans_call): Add the scalarization code for the
case
where an elemental subroutine has array valued actual arguments.
PR fortran/25029
PR fortran/21256
PR fortran/20868
PR fortran/20870
* resolve.c (check_assumed_size_reference): New function to check for
upper
bound in assumed size array references.
(resolve_assumed_size_actual): New function to do a very restricted
scan
of actual argument expressions of those procedures for which incomplete
assumed size array references are not allowed.
(resolve_function, resolve_call): Switch off assumed size checking of
actual arguments, except for elemental procedures and intrinsic
inquiry functions, in some circumstances.
(resolve_variable): Call check_assumed_size_reference.
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* gfortran.dg/elemental_subroutine_1.f90: New test.
* gfortran.dg/elemental_subroutine_2.f90: New test.
PR fortran/25029
PR fortran/21256
* gfortran.dg/assumed_size_refs_1.f90: New test.
PR fortran/20868
PR fortran/20870
* gfortran.dg/assumed_size_refs_2.f90: New test.
* gfortran.dg/initialization_1.f90: Change warning message.
Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_2.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_2.f90
Modified:
trunk/MAINTAINERS
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
Added: trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90?root=gcc&view=auto&rev=109449
==
--- trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 Sat Jan 7 14:14:08
2006
@@ -1,0 +1,64 @@
+!==assumed_size_refs_1.f90==
+! { dg-do compile }
+! Test the fix for PR25029, PR21256 in which references to
+! assumed size arrays without an upper bound to the last
+! dimension were generating no error. The first version of
+! the patch failed in DHSEQR, as pointed out by Toon Moene
+! in http://gcc.gnu.org/ml/fortran/2005-12/msg00466.html
+!
+! Contributed by Paul Thomas <[EMAIL PROTECTED]>
+!
+program assumed_size_test_1
+ implicit none
+ real a(2, 4)
+
+ a = 1.0
+ call foo (a)
+
+contains
+ subroutine foo(m)
+real, target :: m(1:2, *)
+real x(2,2,2)
+real, external :: bar
+real, pointer :: p(:,:), q(:,:)
+allocate (q(2,2))
+
+! PR25029
+p => m ! { dg-error "upper bound in the last
dimension" }
+q = m ! { dg-error "upper bound in the last
dimension" }
+
+! PR21256( and PR25060)
+m = 1 ! { dg-error "upper bound in the last
dimension" }
+
+m(1,1) = 2.0
+x = bar (m)
+x = fcn (m)! { dg-error "upper bound in the last
dimension" }
+m(:, 1:2) = fcn (q)
+call sub (m, x)! { dg-error "upper bound in the last
dimension" }
+call sub (m(1:2, 1:2), x)
+print *, p
+
+call DHSEQR(x)
+
+ end subroutine foo
+
+ elemental function fcn (a) result (b)
+real, intent(in) :: a
+real :: b
+b = 2.0 * a
+ end function fcn
+
+ elemental subroutine sub (a, b)
+real, intent(inout) :: a, b
+b = 2.0 * a
+ end subroutine sub
+
+ SUBROUTINE DHSEQR( WORK )
+REAL WORK( * )
+EXTERNAL DLARFX
+INTRINSIC MIN
+WORK( 1 ) = 1.0
+CALL DLARFX( MIN( 1, 8 ), WORK )
+ END SUBROUTINE DHSEQR
+
+end pr
[Bug fortran/22146] ICE when calling ELEMENTAL subroutines
--- Comment #7 from pault at gcc dot gnu dot org 2006-01-07 14:14 ---
Subject: Bug 22146
Author: pault
Date: Sat Jan 7 14:14:08 2006
New Revision: 109449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109449
Log:
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* trans-array.c (gfc_reverse_ss): Remove static attribute.
(gfc_walk_elemental_function_args): Replace gfc_expr * argument for
the function call with the corresponding gfc_actual_arglist*. Change
code accordingly.
(gfc_walk_function_expr): Call to gfc_walk_elemental_function_args
now requires the actual argument list instead of the expression for
the function call.
* trans-array.h: Modify the prototype for
gfc_walk_elemental_function_args
and provide a prototype for gfc_reverse_ss.
* trans-stmt.h (gfc_trans_call): Add the scalarization code for the
case
where an elemental subroutine has array valued actual arguments.
PR fortran/25029
PR fortran/21256
PR fortran/20868
PR fortran/20870
* resolve.c (check_assumed_size_reference): New function to check for
upper
bound in assumed size array references.
(resolve_assumed_size_actual): New function to do a very restricted
scan
of actual argument expressions of those procedures for which incomplete
assumed size array references are not allowed.
(resolve_function, resolve_call): Switch off assumed size checking of
actual arguments, except for elemental procedures and intrinsic
inquiry functions, in some circumstances.
(resolve_variable): Call check_assumed_size_reference.
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* gfortran.dg/elemental_subroutine_1.f90: New test.
* gfortran.dg/elemental_subroutine_2.f90: New test.
PR fortran/25029
PR fortran/21256
* gfortran.dg/assumed_size_refs_1.f90: New test.
PR fortran/20868
PR fortran/20870
* gfortran.dg/assumed_size_refs_2.f90: New test.
* gfortran.dg/initialization_1.f90: Change warning message.
Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_2.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_2.f90
Modified:
trunk/MAINTAINERS
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
Added: trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90?root=gcc&view=auto&rev=109449
==
--- trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 Sat Jan 7 14:14:08
2006
@@ -1,0 +1,64 @@
+!==assumed_size_refs_1.f90==
+! { dg-do compile }
+! Test the fix for PR25029, PR21256 in which references to
+! assumed size arrays without an upper bound to the last
+! dimension were generating no error. The first version of
+! the patch failed in DHSEQR, as pointed out by Toon Moene
+! in http://gcc.gnu.org/ml/fortran/2005-12/msg00466.html
+!
+! Contributed by Paul Thomas <[EMAIL PROTECTED]>
+!
+program assumed_size_test_1
+ implicit none
+ real a(2, 4)
+
+ a = 1.0
+ call foo (a)
+
+contains
+ subroutine foo(m)
+real, target :: m(1:2, *)
+real x(2,2,2)
+real, external :: bar
+real, pointer :: p(:,:), q(:,:)
+allocate (q(2,2))
+
+! PR25029
+p => m ! { dg-error "upper bound in the last
dimension" }
+q = m ! { dg-error "upper bound in the last
dimension" }
+
+! PR21256( and PR25060)
+m = 1 ! { dg-error "upper bound in the last
dimension" }
+
+m(1,1) = 2.0
+x = bar (m)
+x = fcn (m)! { dg-error "upper bound in the last
dimension" }
+m(:, 1:2) = fcn (q)
+call sub (m, x)! { dg-error "upper bound in the last
dimension" }
+call sub (m(1:2, 1:2), x)
+print *, p
+
+call DHSEQR(x)
+
+ end subroutine foo
+
+ elemental function fcn (a) result (b)
+real, intent(in) :: a
+real :: b
+b = 2.0 * a
+ end function fcn
+
+ elemental subroutine sub (a, b)
+real, intent(inout) :: a, b
+b = 2.0 * a
+ end subroutine sub
+
+ SUBROUTINE DHSEQR( WORK )
+REAL WORK( * )
+EXTERNAL DLARFX
+INTRINSIC MIN
+WORK( 1 ) = 1.0
+CALL DLARFX( MIN( 1, 8 ), WORK )
+ END SUBROUTINE DHSEQR
+
+end pr
[Bug fortran/21256] Illegal use of assumed-sized array in an array expression
--- Comment #6 from pault at gcc dot gnu dot org 2006-01-07 14:14 ---
Subject: Bug 21256
Author: pault
Date: Sat Jan 7 14:14:08 2006
New Revision: 109449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109449
Log:
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* trans-array.c (gfc_reverse_ss): Remove static attribute.
(gfc_walk_elemental_function_args): Replace gfc_expr * argument for
the function call with the corresponding gfc_actual_arglist*. Change
code accordingly.
(gfc_walk_function_expr): Call to gfc_walk_elemental_function_args
now requires the actual argument list instead of the expression for
the function call.
* trans-array.h: Modify the prototype for
gfc_walk_elemental_function_args
and provide a prototype for gfc_reverse_ss.
* trans-stmt.h (gfc_trans_call): Add the scalarization code for the
case
where an elemental subroutine has array valued actual arguments.
PR fortran/25029
PR fortran/21256
PR fortran/20868
PR fortran/20870
* resolve.c (check_assumed_size_reference): New function to check for
upper
bound in assumed size array references.
(resolve_assumed_size_actual): New function to do a very restricted
scan
of actual argument expressions of those procedures for which incomplete
assumed size array references are not allowed.
(resolve_function, resolve_call): Switch off assumed size checking of
actual arguments, except for elemental procedures and intrinsic
inquiry functions, in some circumstances.
(resolve_variable): Call check_assumed_size_reference.
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* gfortran.dg/elemental_subroutine_1.f90: New test.
* gfortran.dg/elemental_subroutine_2.f90: New test.
PR fortran/25029
PR fortran/21256
* gfortran.dg/assumed_size_refs_1.f90: New test.
PR fortran/20868
PR fortran/20870
* gfortran.dg/assumed_size_refs_2.f90: New test.
* gfortran.dg/initialization_1.f90: Change warning message.
Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_2.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_2.f90
Modified:
trunk/MAINTAINERS
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
Added: trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90?root=gcc&view=auto&rev=109449
==
--- trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 Sat Jan 7 14:14:08
2006
@@ -1,0 +1,64 @@
+!==assumed_size_refs_1.f90==
+! { dg-do compile }
+! Test the fix for PR25029, PR21256 in which references to
+! assumed size arrays without an upper bound to the last
+! dimension were generating no error. The first version of
+! the patch failed in DHSEQR, as pointed out by Toon Moene
+! in http://gcc.gnu.org/ml/fortran/2005-12/msg00466.html
+!
+! Contributed by Paul Thomas <[EMAIL PROTECTED]>
+!
+program assumed_size_test_1
+ implicit none
+ real a(2, 4)
+
+ a = 1.0
+ call foo (a)
+
+contains
+ subroutine foo(m)
+real, target :: m(1:2, *)
+real x(2,2,2)
+real, external :: bar
+real, pointer :: p(:,:), q(:,:)
+allocate (q(2,2))
+
+! PR25029
+p => m ! { dg-error "upper bound in the last
dimension" }
+q = m ! { dg-error "upper bound in the last
dimension" }
+
+! PR21256( and PR25060)
+m = 1 ! { dg-error "upper bound in the last
dimension" }
+
+m(1,1) = 2.0
+x = bar (m)
+x = fcn (m)! { dg-error "upper bound in the last
dimension" }
+m(:, 1:2) = fcn (q)
+call sub (m, x)! { dg-error "upper bound in the last
dimension" }
+call sub (m(1:2, 1:2), x)
+print *, p
+
+call DHSEQR(x)
+
+ end subroutine foo
+
+ elemental function fcn (a) result (b)
+real, intent(in) :: a
+real :: b
+b = 2.0 * a
+ end function fcn
+
+ elemental subroutine sub (a, b)
+real, intent(inout) :: a, b
+b = 2.0 * a
+ end subroutine sub
+
+ SUBROUTINE DHSEQR( WORK )
+REAL WORK( * )
+EXTERNAL DLARFX
+INTRINSIC MIN
+WORK( 1 ) = 1.0
+CALL DLARFX( MIN( 1, 8 ), WORK )
+ END SUBROUTINE DHSEQR
+
+end pr
[Bug fortran/20868] reference to upper bound of assumed-size array
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-07 14:14 ---
Subject: Bug 20868
Author: pault
Date: Sat Jan 7 14:14:08 2006
New Revision: 109449
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109449
Log:
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* trans-array.c (gfc_reverse_ss): Remove static attribute.
(gfc_walk_elemental_function_args): Replace gfc_expr * argument for
the function call with the corresponding gfc_actual_arglist*. Change
code accordingly.
(gfc_walk_function_expr): Call to gfc_walk_elemental_function_args
now requires the actual argument list instead of the expression for
the function call.
* trans-array.h: Modify the prototype for
gfc_walk_elemental_function_args
and provide a prototype for gfc_reverse_ss.
* trans-stmt.h (gfc_trans_call): Add the scalarization code for the
case
where an elemental subroutine has array valued actual arguments.
PR fortran/25029
PR fortran/21256
PR fortran/20868
PR fortran/20870
* resolve.c (check_assumed_size_reference): New function to check for
upper
bound in assumed size array references.
(resolve_assumed_size_actual): New function to do a very restricted
scan
of actual argument expressions of those procedures for which incomplete
assumed size array references are not allowed.
(resolve_function, resolve_call): Switch off assumed size checking of
actual arguments, except for elemental procedures and intrinsic
inquiry functions, in some circumstances.
(resolve_variable): Call check_assumed_size_reference.
2006-01-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/22146
* gfortran.dg/elemental_subroutine_1.f90: New test.
* gfortran.dg/elemental_subroutine_2.f90: New test.
PR fortran/25029
PR fortran/21256
* gfortran.dg/assumed_size_refs_1.f90: New test.
PR fortran/20868
PR fortran/20870
* gfortran.dg/assumed_size_refs_2.f90: New test.
* gfortran.dg/initialization_1.f90: Change warning message.
Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_2.f90 (with props)
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_1.f90
trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_2.f90
Modified:
trunk/MAINTAINERS
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
Added: trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90?root=gcc&view=auto&rev=109449
==
--- trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 (added)
+++ trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 Sat Jan 7 14:14:08
2006
@@ -1,0 +1,64 @@
+!==assumed_size_refs_1.f90==
+! { dg-do compile }
+! Test the fix for PR25029, PR21256 in which references to
+! assumed size arrays without an upper bound to the last
+! dimension were generating no error. The first version of
+! the patch failed in DHSEQR, as pointed out by Toon Moene
+! in http://gcc.gnu.org/ml/fortran/2005-12/msg00466.html
+!
+! Contributed by Paul Thomas <[EMAIL PROTECTED]>
+!
+program assumed_size_test_1
+ implicit none
+ real a(2, 4)
+
+ a = 1.0
+ call foo (a)
+
+contains
+ subroutine foo(m)
+real, target :: m(1:2, *)
+real x(2,2,2)
+real, external :: bar
+real, pointer :: p(:,:), q(:,:)
+allocate (q(2,2))
+
+! PR25029
+p => m ! { dg-error "upper bound in the last
dimension" }
+q = m ! { dg-error "upper bound in the last
dimension" }
+
+! PR21256( and PR25060)
+m = 1 ! { dg-error "upper bound in the last
dimension" }
+
+m(1,1) = 2.0
+x = bar (m)
+x = fcn (m)! { dg-error "upper bound in the last
dimension" }
+m(:, 1:2) = fcn (q)
+call sub (m, x)! { dg-error "upper bound in the last
dimension" }
+call sub (m(1:2, 1:2), x)
+print *, p
+
+call DHSEQR(x)
+
+ end subroutine foo
+
+ elemental function fcn (a) result (b)
+real, intent(in) :: a
+real :: b
+b = 2.0 * a
+ end function fcn
+
+ elemental subroutine sub (a, b)
+real, intent(inout) :: a, b
+b = 2.0 * a
+ end subroutine sub
+
+ SUBROUTINE DHSEQR( WORK )
+REAL WORK( * )
+EXTERNAL DLARFX
+INTRINSIC MIN
+WORK( 1 ) = 1.0
+CALL DLARFX( MIN( 1, 8 ), WORK )
+ END SUBROUTINE DHSEQR
+
+end pr
[Bug bootstrap/25695] [4.2 Regression] bootstrap no longer does a comparision
--- Comment #2 from bonzini at gnu dot org 2006-01-07 10:01 --- Huh? We do in the toplevel make target "compare". Paolo -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25695
[Bug bootstrap/25670] [4.2 Regression] build fail with 'make all-gcc'
--- Comment #2 from bonzini at gnu dot org 2006-01-07 10:01 --- *** Bug 25694 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25670
[Bug other/25694] selective non-bootstrap build broken
--- Comment #3 from bonzini at gnu dot org 2006-01-07 10:01 --- *** This bug has been marked as a duplicate of 25670 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25694
