[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-08-21 11:26 --- OK, right, I don't have time to fix this. I've looked at the rounding code, and carry propagation, and I think we'd need a new special case to handle that, but couldn't find a way to do it that doesn't break other cases. Jerry, Thomas, could you look into this? I find it has a pretty high annoyance factor, we're outputing wrong numbers. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at verizon dot net Severity|normal |major Last reconfirmed|2006-07-12 15:21:52 |2006-08-21 11:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:50 --- (In reply to comment #7) If you stll think that this is a libgfortran bug (I don't) you could add setvbuf(stdout, NULL, _IOLBF, 0); to unix.c:output_stream() so that stdout always is line-buffered even when !isatty(fileno(stdout)) Indeed, I think the bug is in the user's code, but I think there's no serious drawback to the setvbuf workaround you mention. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-06-12 16:30:13 |2006-09-20 07:50:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug target/28069] __m128 local variables don't get properly aligned.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:54 --- Not specific to mingw32. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|27537 |13685 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 |i686 Last reconfirmed|-00-00 00:00:00 |2006-09-20 07:54:00 date|| Version|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug target/19970] Java Disabled for MinGW
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:56 --- Any news on enabling libgcj by default? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
[Bug target/14666] Crossing from GNU/Linux to MinGW requires SEVERAL hacks
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:01 --- Cross-building for mingw32 now works for me, and this bug has been inactive long enough that we can close it. If someone has recent data on this, please reopen! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14666
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:05 --- I think this is fixed on 4.2: $ gcc a.c a.c:16:1: warning: setjmp redefined In file included from a.c:7: c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/setjmp.h:41:1: warning: this is the location of the previous definition a.c: In function `main': a.c:56: warning: passing arg 1 of `SetUnhandledExceptionFilter' from incompatible pointer type $ ./a.exe Install error handler let's go Error Handler let's go Can we close this bug? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug c/9601] -mrtd switch/stdcall attribute raises warnings for __buitltin functions
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:12 --- double __attribute__((cdecl)) sqrt (double); double __attribute__((stdcall)) log (double); double cos (double); With this code, we still (gcc-4.2) get: $ gcc -c -W -Wall -mrtd b.c b.c:1: warning: conflicting types for built-in function sqrt $ gcc -c -W -Wall b.c b.c:2: warning: conflicting types for built-in function log This is not related to mingw32, as the same warnings happen on i386-pc-mingw32 and i686-pc-linux-gnu. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Component|target |c GCC target triplet|i386-pc-mingw32 | Last reconfirmed|2003-07-11 15:03:36 |2006-09-20 08:12:19 date|| Summary|[win32] -mrtd switch/stdcall|-mrtd switch/stdcall |attribute raises warnings |attribute raises warnings |for __buitltin functions|for __buitltin functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601
[Bug fortran/26025] Optionally use BLAS for matmul
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-25 08:58 --- Patch proposed here: http://gcc.gnu.org/ml/fortran/2006-09/msg00325.html Janne, as I know you were interested in that feature, could you look at my patch if you have some time? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org URL||http://gcc.gnu.org/ml/fortra ||n/2006-09/msg00325.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26025
[Bug fortran/29210] New: Name parameter in complex constant not allowed in F95
The following code is legal F2003 but I believe it's not legal F95. It should be diagnosed as such. $ cat a.f90 real,parameter :: foo = 1.7 complex,parameter :: bar = (foo, foo) end -- Summary: Name parameter in complex constant not allowed in F95 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2006-09-25 09:19 --- Subject: Bug 21203 Author: fxcoudert Date: Mon Sep 25 09:19:36 2006 New Revision: 117191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117191 Log: PR fortran/21203 * error.c (show_loci): No need to risk an ICE to output a slightly nicer error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/13615] -Wuninitialized produces wrong error message for characters
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |minor GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|2005-12-30 18:42:58 |2006-09-25 12:31:32 date|| Summary|gfortran -Wuninitialized|-Wuninitialized produces |doesn't produce warning on |wrong error message for |characters |characters Version|3.3.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
[Bug fortran/23060] %VAL construct not implemented
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-09-28 07:58 --- Changing this into a bug, since it was implemented in g77. It might be working soon, since we will soon have ISO_C_BINDING val attribute, which does the same thing, so adding the %val construct will probably be very easy. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |normal GCC target triplet|i386-redhat-linux | Last reconfirmed|2006-03-05 03:41:17 |2006-09-28 07:58:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug fortran/23375] show location for runtime errors
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-09-28 07:59 --- Closing, as the error messages have been modified to include source location. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-09-28 08:02 --- Confirmed, and marked as blocking the F2003 meta-PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO||20585 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:02:35 date|| Summary|Fortran 2003: Support type- |Fortran 2003: Support type- |spec for array constructor, |spec for array constructor |i.e. (/ real :: 1., 2., 3. | |/) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-28 08:03:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-09-28 11:35
---
There's a TODO about this in front-end resolve.c. It's a good point to start...
static void
resolve_formal_arglist (gfc_symbol * proc)
{
gfc_formal_arglist *f;
gfc_symbol *sym;
int i;
/* TODO: Procedures whose return character length parameter is not constant
or assumed must also have explicit interfaces. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Last reconfirmed|2005-11-29 12:06:22 |2006-09-28 11:35:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug libfortran/23889] behaviour of random_seed()
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-09-28 14:05 --- After a year and not patch has been proposed for that enhancement, it looks like it won't be implemented in gfortran. Still, feel free to reopen this PR (or file a new one) if you have a patch ready. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23889
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-20 07:50:15 |2006-09-28 14:08:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-09-28 22:34
---
(In reply to comment #7)
Changing main() in ctesti.c to start with:
int main(int argc, char** argv) {
setvbuf(stdout, NULL, _IOLBF, 0);
fixes the redirection problem.
After some more testing, this fix doesn't work in all cases (e.g. in a shell of
MSYS window). I'm closing this PR: after all, this is not a bug in the
compiler, mixed-languages code is supposed to correctly flush both I/O systems
after operations. I would have liked to provide a workaround, only there
doesn't appear to be anythink general and robust enough.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug fortran/21435] fails to open nonexisting file with status scratch
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-29 09:18 --- Still present on mainline, probably not difficult to fix. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|libfortran |fortran Last reconfirmed|2005-12-28 06:36:31 |2006-09-29 09:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21435
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-09-29 13:21 --- Assigning this to myself, as I have a patch cooking. A testcase is (on i686-linux): $ cat cdabs.f subroutine foo(f) implicit none real*8 f complex*16 z z = (1.,1.) print *, f(z) end implicit none intrinsic cdabs call foo(cdabs) end $ gfortran cdabs.f ./a.out NaN $ gfortran cdabs.f -O3 ./a.out NaN zsh: segmentation fault ./a.out -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pbrook at gcc dot gnu dot |fxcoudert at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-09-29 13:22 --- And also: that's a regression wrt g77. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Known to fail||4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/27107] Make dependency on io/io.h broken
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-09-29 15:55 --- I have a patch for that, but it will have to wait until 4.3 is branched. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-21 14:05:05 |2006-09-29 15:55:19 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug fortran/29288] New: All intrinsics are allowed as actual arguments
(vaguely related to PR16580) We're currently not checking if an intrinsic is allowed to be used as an actual argument or not (and it's a regression wrt g77): $ ifort a.f fortcom: Error: a.f, line 2: This intrinsic procedure cannot be passed as an actual argument. [ICHAR] call BAR(ichar) ---^ compilation aborted for a.f (code 1) $ pgf90 a.f PGF90-S-0073-Intrinsic or predeclared, ichar, cannot be passed as an argument (a.f: 2) 0 inform, 0 warnings, 1 severes, 0 fatal for MAIN $ gfortran a.f /tmp/cckKTcIB.o(.text+0x5): In function `MAIN__': : undefined reference to `specific__ichar_1' /tmp/cckKTcIB.o(.text+0xa): In function `MAIN__': : undefined reference to `bar_' collect2: ld returned 1 exit status -- Summary: All intrinsics are allowed as actual arguments Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 16580 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug fortran/29288] All intrinsics are allowed as actual arguments
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-29 16:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-29 20:41 --- Subject: Bug 18791 Author: fxcoudert Date: Fri Sep 29 20:41:11 2006 New Revision: 117317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117317 Log: PR fortran/18791 * gfortran.dg/specifics_1.f90: New test. * gfortran.fortran-torture/execute/specifics.f90: Add tests for complex specifics. * m4/specific.m4: Special-case cabs so that its return type is real. Special-case conjg so that their suffices are _4, _8, _10 and _16 instead of _c4, _c8, _c10 and _c16. * intrinsics/f2c_specifics.F90: Special-case conjg functions so that their suffices are _4 and _8 instead of _c4 and _c8. * generated/_conjg_c4.F90: Regenerate. * generated/_conjg_c8.F90: Regenerate. * generated/_conjg_c10.F90: Regenerate. * generated/_conjg_c16.F90: Regenerate. * generated/_abs_c4.F90: Regenerate. * generated/_abs_c8.F90: Regenerate. * generated/_abs_c10.F90: Regenerate. * generated/_abs_c16.F90: Regenerate. Added: trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 trunk/libgfortran/generated/_abs_c10.F90 trunk/libgfortran/generated/_abs_c16.F90 trunk/libgfortran/generated/_abs_c4.F90 trunk/libgfortran/generated/_abs_c8.F90 trunk/libgfortran/generated/_conjg_c10.F90 trunk/libgfortran/generated/_conjg_c16.F90 trunk/libgfortran/generated/_conjg_c4.F90 trunk/libgfortran/generated/_conjg_c8.F90 trunk/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-01 07:43 --- Apart from the warnings in PR 26540, the situation is stable with the only warning being: ../../../trunk/libgfortran/io/list_read.c: In function list_formatted_read_scalar: ../../../trunk/libgfortran/io/list_read.c:1460: warning: argument type might be clobbered by longjmp or vfork I think this warning is not worth the trouble of rewriting this critical part of the code, potentially introducing a nasty regression or something like that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|2006-05-19 17:04:21 |2006-10-01 07:43:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-01 15:02 --- I'm about to submit a patch that globally fixes this problem of intrinsics as actual arguments, but this one is still eluding me. It's due to the implicit none statement, and it works otherwise. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-06-05 20:33:07 |2006-10-01 15:02:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/16580] gfortran ICE on test g77.f-torture/execute/intrinsic77.f
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:10 --- Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2006-10/msg00022.html Status|NEW |ASSIGNED GCC host triplet|i686-pc-cygwin | Keywords||patch Known to fail||4.2.0 4.1.2 Last reconfirmed|2006-07-09 10:14:53 |2006-10-02 07:10:19 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16580
[Bug fortran/29288] All intrinsics are allowed as actual arguments
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:11 --- Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2006-10/msg00022.html Keywords||patch Known to fail||4.2.0 4.1.2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:34 --- I'll do it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-02 07:34:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:39 --- Further reduced testcase (no need for a module): implicit none integer i i = len(123) call sub(len) end When the len in call sub(len) is resolved, it is never given its correct return type, which leads to the ICE. I still don't understand why the implicit none is doing this on us... Paul, any idea? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-02 08:11
---
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 116798)
+++ gcc/fortran/primary.c (working copy)
@@ -1084,6 +1084,10 @@
return MATCH_ERROR;
}
+ if (gfc_notify_std (GFC_STD_F2003, Fortran 2003: PARAMETER symbol in
+ complex constant at %C) == FAILURE)
+return MATCH_ERROR;
+
switch (sym-value-ts.type)
{
case BT_REAL:
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:21 --- Subject: Bug 29210 Author: fxcoudert Date: Mon Oct 2 09:21:45 2006 New Revision: 117368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117368 Log: PR fortran/29210 * primary.c (match_sym_complex_part): Named constants as real or imaginary part of complex a named constant are only allowed in Fortran 2003. * gfortran.dg/complex_parameter_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/complex_parameter_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/29210] [4.1 only] Name parameter in complex constant not allowed in F95
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.1.2 |4.1.2 Known to work||4.2.0 Summary|Name parameter in complex |[4.1 only] Name parameter in |constant not allowed in F95 |complex constant not allowed ||in F95 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/29317] New: gfortran.dg/exponent_1.f90 failure
gfortran.dg/exponent_1.f90 is failing at all optimization levels on x86_64-linux (see http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00081.html). Here is the problem: $ cat exponent_1.f90 real, parameter :: one = 1.0 print *, exponent(one) if (exponent(one) /= 1.0) call abort end $ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran : (reconfigured) ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran --enable-maintainer-mode : (reconfigured) ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran --enable-maintainer-mode Thread model: posix gcc version 4.2.0 20061001 (experimental) $ gfortran -static exponent_1.f90 ./a.out 0 zsh: abort ./a.out -- Summary: gfortran.dg/exponent_1.f90 failure Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: x86_64-unkown-linux-gnu GCC host triplet: x86_64-unkown-linux-gnu GCC target triplet: x86_64-unkown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug libfortran/18791] [4.1 only] CABS specifics declared of wrong type
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:37 --- Subject: Bug 18791 Author: fxcoudert Date: Mon Oct 2 09:37:09 2006 New Revision: 117369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117369 Log: PR fortran/18791 * gfortran.dg/specifics_1.f90: New test. * gfortran.fortran-torture/execute/specifics.f90: Add tests for complex specifics. * m4/specific.m4: Special-case cabs so that its return type is real. Special-case conjg so that their suffices are _4, _8, _10 and _16 instead of _c4, _c8, _c10 and _c16. * intrinsics/f2c_specifics.F90: Special-case conjg functions so that their suffices are _4 and _8 instead of _c4 and _c8. * generated/_conjg_c4.F90: Regenerate. * generated/_conjg_c8.F90: Regenerate. * generated/_conjg_c10.F90: Regenerate. * generated/_conjg_c16.F90: Regenerate. * generated/_abs_c4.F90: Regenerate. * generated/_abs_c8.F90: Regenerate. * generated/_abs_c10.F90: Regenerate. * generated/_abs_c16.F90: Regenerate. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specifics_1.f90 - copied unchanged from r117317, trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/generated/_abs_c10.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c16.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c4.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c8.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c10.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c16.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c4.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c8.F90 branches/gcc-4_1-branch/libgfortran/intrinsics/f2c_specifics.F90 branches/gcc-4_1-branch/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:38 --- Fixed on both 4.2 and 4.1 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.1 | Known to work|4.2.0 |4.2.0 4.1.1 Resolution||FIXED Summary|[4.1 only] CABS specifics |CABS specifics declared of |declared of wrong type |wrong type Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #28 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:41 --- The only g77 intrinsic now missing to gfortran is FSEEK (and this is PR 22359). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-07-26 12:07:43 |2006-10-02 09:41:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:09 --- If it's a regression wrt g77, then it's not an enhancement, it's a bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |normal GCC host triplet|i686-pc-linux-gnu | Keywords||rejects-valid Last reconfirmed|2006-03-05 03:41:04 |2006-10-02 11:09:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/25708] Module loading is not good at all
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:23 --- Confirmed and marked as an enhancement. After all, it's working :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:23:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
[Bug fortran/27478] getting : error: invalid operand to binary operator
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:35
---
That one is annoying. Reduced testcase is:
FUNCTION X()
ENTRY X1
IF (X .GT. 0) CALL FOO(X)
END
The error message is:
a.f: In function master.0.x:
a.f:3: error: invalid operand to binary operator
__result_master.0.xD.914
a.f:3: internal compiler error: verify_stmts failed
And the original tree dump is:
x ()
{
return master.0.x (0);
x1 ()
{
return master.0.x (1);
master.0.x (__entry)
{
real4 __result_master.0.x;
real4 x.0 [value-expr: __result_master.0.x];
switch (__entry)
{
case 0:;
goto L.2;
case 1:;
goto L.4;
}
L.2:;
L.4:;
if (x.0 0.0)
{
foo (x.0);
}
else
{
(void) 0;
}
return __result_master.0.x;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|2006-06-04 15:16:36 |2006-10-02 11:35:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug fortran/27703] Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:37 --- Closing this. We'd need a more precise definition to be able to do anything about that, although I don't see a reason why shared libraries wouldn't work on cygwin. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:54:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug fortran/29232] No warning/error for duplicate construct name
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:57:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/29240] optional argument for signal intrinsic not supported
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:59 --- Confirmed, as Intel, Portland and other compilers accept this. Marked as an enhancement, though, as g77 didn't support that anyway. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:59:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29240
[Bug fortran/29322] New: ICE with character optional arg
$ cat u.f90 if (isscan () /= 0) call abort contains integer function isscan (substr) character(*), optional :: substr if (.not.present(substr)) isscan = myscan (foo, over) end function isscan end $ gfortran u.f90 u.f90: In function MAIN__: u.f90:5: internal compiler error: Segmentation fault -- Summary: ICE with character optional arg Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29322
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-02 20:13 --- I think the following can workaround the middle-end problem: Index: trans-decl.c === --- trans-decl.c(revision 117368) +++ trans-decl.c(working copy) @@ -1866,6 +1866,7 @@ TREE_PUBLIC (decl) = 0; TREE_USED (decl) = 1; GFC_DECL_RESULT (decl) = 1; + TREE_ADDRESSABLE (decl) = 1; layout_decl (decl, 0); -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Component|fortran |middle-end Known to fail||4.2.0 Known to work||4.1.2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug fortran/29327] FAIL: gfortran.dg/specifics_1.f90
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-03 10:32 --- This should be fixed. I forgot to commit some part of my patch. Sorry for the inconvenience. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29327
[Bug fortran/21203] gfortran doesn't work on targets/variants without two floating point types
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2006-10-03 13:10 --- Changing the summary of this bug to reflect the actual problem. Downgrading to enhancement because it would be a weird GNU extension. And unless someone show real interest in gfortran working on these platforms and provides access to a test system, I don't think we'd implement a graceful degradation soon. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|build, ice-on-valid-code| Known to fail||4.1.2 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-03 13:10:10 date|| Summary|Segfault while compiling|gfortran doesn't work on |libgfortran/intrinsics/selec|targets/variants without two |ted_int_kind.f90|floating point types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-03 13:44 --- Subject: Bug 27478 Author: fxcoudert Date: Tue Oct 3 13:44:09 2006 New Revision: 117396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117396 Log: PR middle-end/27478 * trans-decl.c (gfc_get_fake_result_decl): Mark var as TREE_ADDRESSABLE. * gfortran.dg/entry_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-03 16:17 --- (In reply to comment #5) The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are falling on hppa2.0w-hp-hpux11.11. I updated to mpfr 2.2.0 and the tests are still failing. Possibly, I need a complete rebuild. I though I had done a complete rebuild, but I didn't. Rebuilding everything from scratch makes it work again. Sorry. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-04 06:59 --- I think this code is valid. Changing to ice-on-valid-code. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|2006-09-28 13:09:57 |2006-10-04 06:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-05 08:05 --- (In reply to comment #6) I am glad to see that you are pursuing that one. I nearly bust my head on it my notes indicate that I had a fix that broke everything else; no details, so not much help I'm afraid. I think that you had better take it that I got nowhere! Well, this is really about the resolution scheme, which I still don't fully understand, so I'm in the dark here too. I'll give it a longer shot over the next week-end. The bug that involves INDEX (PR???) is clearer. The mechanism, in trans-decl(gfc_get_extern_function_decl), for handling intrinsics simply does not allow that number of arguments. I tried to extend it by looking at isym-resolve.f1 and f2. It seemed to work but I did not have time to work on it. That bug is fixed by my submitted patch about INTRINSICS (http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/16580] gfortran ICE on test g77.f-torture/execute/intrinsic77.f
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-07 13:34 --- Subject: Bug 16580 Author: fxcoudert Date: Sat Oct 7 13:34:16 2006 New Revision: 117534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117534 Log: PR fortran/16580 PR fortran/29288 * gcc/fortran/intrinsic.c (add_sym): Define the actual_ok when a gfc_intrinsic_sym structure is filled. (gfc_intrinsic_actual_ok): New function. (add_sym_0s, add_sym_1s, add_sym_2s, add_sym_3s, add_sym_4s, add_sym_5s): Intrinsic subroutines are not allowed as actual arguments, so we remove argument actual_ok. (add_functions): Correct the values for actual_ok of all intrinsics. (add_subroutines): Remove the actual_ok argument, which was never used. * gcc/fortran/intrinsic.h (gfc_intrinsic_actual_ok): New prototype. * gcc/fortran/gfortran.h (gfc_resolve_index_func): New prototype. * gcc/fortran/resolve.c (resolve_actual_arglist): Check whether an intrinsic used as an argument list is allowed there. * gcc/fortran/iresolve.c (gfc_resolve_index_func): New function. (gfc_resolve_len): Change intrinsic function name to agree with libgfortran. * gcc/fortran/trans-decl.c (gfc_get_extern_function_decl): Add new case, because some specific intrinsics take 3 arguments. * gcc/fortran/intrinsic.texi: DIMAG is a GNU extension. * libgfortran/Makefile.am: Add the new files to the build process, and rules to build them. * libgfortran/Makefile.in: Regenerate. * libgfortran/m4/misc_specifics.m4: New file. * libgfortran/m4/specific.m4: Add new special cases for function with complex argument and real result, like abs_c* and aimag_c*. * libgfortran/intrinsics/f2c_specifics.F90: Add specifics for AIMAG, ASINH, ACOSH and ATANH. * libgfortran/generated/_aimag_c4.F90: New file. * libgfortran/generated/_aimag_c8.F90: New file. * libgfortran/generated/_asinh_r10.F90: New file. * libgfortran/generated/_acosh_r16.F90: New file. * libgfortran/generated/_aimag_c10.F90: New file. * libgfortran/generated/_atanh_r16.F90: New file. * libgfortran/generated/_acosh_r4.F90: New file. * libgfortran/generated/_acosh_r8.F90: New file. * libgfortran/generated/_asinh_r4.F90: New file. * libgfortran/generated/_asinh_r8.F90: New file. * libgfortran/generated/_asinh_r16.F90: New file. * libgfortran/generated/_atanh_r4.F90: New file. * libgfortran/generated/_atanh_r8.F90: New file. * libgfortran/generated/_acosh_r10.F90: New file. * libgfortran/generated/misc_specifics.F90: New file. * libgfortran/generated/_aimag_c16.F90: New file. * libgfortran/generated/_atanh_r10.F90: New file. * gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90: Add tests for using all possible intrinsics as actual arguments. * gcc/testsuite/gfortran.dg/specifics_1.f90: Add tests for using all possible intrinsics as actual arguments. * gcc/testsuite/gfortran.dg/specifics_2.f90: New file. * gcc/testsuite/gfortran.dg/specifics_3.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/specifics_2.f90 trunk/gcc/testsuite/gfortran.dg/specifics_3.f90 trunk/libgfortran/generated/_acosh_r10.F90 trunk/libgfortran/generated/_acosh_r16.F90 trunk/libgfortran/generated/_acosh_r4.F90 trunk/libgfortran/generated/_acosh_r8.F90 trunk/libgfortran/generated/_aimag_c10.F90 trunk/libgfortran/generated/_aimag_c16.F90 trunk/libgfortran/generated/_aimag_c4.F90 trunk/libgfortran/generated/_aimag_c8.F90 trunk/libgfortran/generated/_asinh_r10.F90 trunk/libgfortran/generated/_asinh_r16.F90 trunk/libgfortran/generated/_asinh_r4.F90 trunk/libgfortran/generated/_asinh_r8.F90 trunk/libgfortran/generated/_atanh_r10.F90 trunk/libgfortran/generated/_atanh_r16.F90 trunk/libgfortran/generated/_atanh_r4.F90 trunk/libgfortran/generated/_atanh_r8.F90 trunk/libgfortran/generated/misc_specifics.F90 trunk/libgfortran/m4/misc_specifics.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/intrinsics/f2c_specifics.F90 trunk/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16580
[Bug testsuite/28610] gfortran testsuite failures with sudo
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-07 14:57 --- This was fixed by revision 117533: 2006-08-12 Francois-Xavier Coudert [EMAIL PROTECTED] * gfortran.dg/stat_1.f90: Make test pass when run under sudo. * gfortran.dg/stat_2.f90: Likewise. * gfortran.dg/chmod_1.f90: Likewise. * gfortran.dg/chmod_2.f90: Likewise. * gfortran.dg/chmod_3.f90: Likewise. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28610
[Bug fortran/28585] Fortran 2003: Support NEW_LINE intrinsic
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-08 13:21 --- Subject: Bug 28585 Author: fxcoudert Date: Sun Oct 8 13:21:42 2006 New Revision: 117555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117555 Log: PR fortran/28585 * intrinsic.c (add_functions): Add new_line Fortran 2003 intrinsic. * intrinsic.h: Add gfc_simplify_new_line and gfc_check_new_line prototypes. * check.c (gfc_check_new_line): New function. * simplify.c (gfc_simplify_new_line): New function. * intrinsic.texi: Document new_line intrinsic. * gfortran.dg/new_line.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/new_line.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28585
[Bug libfortran/26540] some gcc-4.1.0/libgfortran/intrinsics/signal.c warning: cast from/to pointer to/from integer of different size on x86-64
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-08 14:27 --- Subject: Bug 26540 Author: fxcoudert Date: Sun Oct 8 14:27:22 2006 New Revision: 117556 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117556 Log: PR libfortran/26540 * intrinsics/signal.c (signal_sub, signal_sub_int): Use intptr_t if available to cast function pointers to int and back. * configure.ac: Check for intptr_t. * config.h.in: Regenerate. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/signal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug libfortran/26540] [4.1 only] intrinsics/signal.c warnings
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to fail||4.1.2 Known to work||4.2.0 Last reconfirmed|2006-05-21 14:11:19 |2006-10-08 14:28:27 date|| Summary|some gcc- |[4.1 only] |4.1.0/libgfortran/intrinsics|intrinsics/signal.c warnings |/signal.c warning: cast | |from/to pointer to/from | |integer of different size on| |x86-64 | Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug fortran/29387] New: ICE on character array function of variable length
$ cat a4.f90 PRINT *, LEN(SUB(3)) CONTAINS FUNCTION SUB(I) CHARACTER(LEN=I) :: SUB(1) END FUNCTION END $ gfortran a4.f90 a4.f90: In function sub: a4.f90:1: warning: Function does not return a value a4.f90: In function MAIN__: a4.f90:1: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:2160 The failing assertion is gcc_assert (se-loop info) -- Summary: ICE on character array function of variable length Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug fortran/29387] ICE on character array function of variable length
-- fxcoudert 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-10-08 19:46:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug fortran/29389] New: Statement functions are not recognized as pure when they are
The F95 standard says (12.6): A pure procedure is [...] or (4) A statement function that references only pure functions. But gfortran doesn't like that: $ cat a5.f90 INTEGER :: st1,i,a(4) st1(i)=i*i*i FORALL(i=1:4) a(i)=st1(i) print *, a print *, u(2) contains pure integer function u(x) integer,intent(in) :: x st2(i) = i*i u = st2(x) end function END $ gfortran a5.f90 In file a5.f90:12 u = st2(x) 1 Error: Function reference to 'st2' at (1) is to a non-PURE procedure within a PURE procedure In file a5.f90:3 FORALL(i=1:4) a(i)=st1(i) 1 Error: reference to non-PURE function 'st1' at (1) inside a FORALL block -- Summary: Statement functions are not recognized as pure when they are Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
[Bug fortran/29389] Statement functions are not recognized as pure when they are
-- fxcoudert 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-10-08 20:47:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
[Bug fortran/29391] New: LBOUND(TRANSPOSE(I)) doesn't work
I'm surprised this was not reported before, but can't find it in bugzilla. $ cat a6.f90 INTEGER :: I(-1:1,-1:1)=0 WRITE(6,*) LBOUND(TRANSPOSE(I)) END $ ifort a6.f90 ./a.out 1 1 $ gfortran a6.f90 ./a.out -1 -1 -- Summary: LBOUND(TRANSPOSE(I)) doesn't work Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
-- fxcoudert 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-10-08 21:09:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29392] New: Segfault on data character initialization
$ cat a9.f90 character(LEN=2) :: a(2) data ((a(I)(k:k),I=1,2),k=1,2) /4*'a'/ IF (ANY(a.NE.aa)) CALL ABORT() END $ gfortran a9.f90 In file a9.f90:2 data ((a(I)(k:k),I=1,2),k=1,2) /4*'a'/ 1 Warning: initialization string truncated to match variable at (1) a9.f90:0: internal compiler error: Segmentation fault The segfault happens at: at ../../trunk/gcc/fortran/data.c:194 194 memcpy (dest[start], rvalue-value.character.string, len); #0 create_character_intializer (init=0xce48e0, ts=Variable ts is not available. ) at ../../trunk/gcc/fortran/data.c:194 #1 0x0040e511 in gfc_assign_data_value (lvalue=0xce3240, rvalue=0xce3e80, index=0x7fbfffeaa0) at ../../trunk/gcc/fortran/data.c:323 #2 0x00448482 in traverse_data_var (var=0xcb1470, where=0xcb0f50) at ../../trunk/gcc/fortran/resolve.c:6094 #3 0x00448293 in traverse_data_var (var=0xcb11b0, where=0xcb0f50) at ../../trunk/gcc/fortran/resolve.c:6146 #4 0x00448293 in traverse_data_var (var=0xcb09f0, where=0xcb0f50) at ../../trunk/gcc/fortran/resolve.c:6146 #5 0x00448e1f in resolve_types (ns=0xce2330) at ../../trunk/gcc/fortran/resolve.c:6240 #6 0x0044b75d in gfc_resolve (ns=0xce2330) at ../../trunk/gcc/fortran/resolve.c:6918 #7 0x00440a68 in gfc_parse_file () at ../../trunk/gcc/fortran/parse.c:3212 There, we have: (gdb) p rvalue-value.character.string $4 = 0xcb0b30 a (gdb) p len $5 = -13513439 (gdb) p dest $6 = 0xcb0450 (gdb) p start $7 = 13513439 -- Summary: Segfault on data character initialization Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29392
[Bug fortran/29392] Segfault on data character initialization
-- fxcoudert 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-10-08 21:17:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29392
[Bug fortran/29393] New: Vector subscript rejected
$ cat a2.f90 integer, parameter :: A(-3:7,2)=0 integer, parameter, dimension(3) :: V = (/ 2, 4, 6 /) integer, parameter, dimension(3) :: B = A(V,1) END $ gfortran a2.f90 In file a2.f90:3 integer, parameter, dimension(3) :: B = A(V,1) 1 Error: Incompatible ranks 1 and 2 in assignment at (1) -- Summary: Vector subscript rejected Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29393] Vector subscript rejected
-- fxcoudert 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-10-08 21:31:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29393
[Bug fortran/29394] New: Invalid derived-type initialization in function
$ cat a11.f90 MODULE M1 TYPE T1 INTEGER :: I=7 END TYPE T1 CONTAINS SUBROUTINE S1(I) INTEGER, INTENT(IN) :: I TYPE(T1) :: D(1:I) PRINT *, D(2)%I PRINT *, D(:)%I IF (D(2)%I.NE.7) CALL ABORT() END SUBROUTINE S1 END MODULE M1 USE M1 CALL S1(2) END $ ifort a11.f90 ./a.out 7 7 7 $ gfortran -static a11.f90 ./a.out 0 0 0 zsh: abort ./a.out -- Summary: Invalid derived-type initialization in function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29394
[Bug fortran/29394] Invalid derived-type initialization in function
-- fxcoudert 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-10-08 21:36:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29394
[Bug fortran/29395] New: failure in implied do loop data initialization
$ cat a10.f90 integer :: i(2,2) data ((i(k,j), j = 1, k), k = 1, 2) / 3 * 0 / end $ gfortran a10.f90 In file a10.f90:2 data ((i(k,j), j = 1, k), k = 1, 2) / 3 * 0 / 1 Error: Parameter 'k' at (1) has not been declared or is a variable, which does not reduce to a constant expression -- Summary: failure in implied do loop data initialization Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29395
[Bug fortran/29395] failure in implied do loop data initialization
-- fxcoudert 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-10-08 21:42:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29395
[Bug fortran/29396] New: segfault with character pointer association
$ cat a3.f90
CHARACTER(LEN=2), DIMENSION(:), POINTER :: a
CHARACTER(LEN=4), DIMENSION(3), TARGET :: b
b=(/,,/)
a=b(:)(2:3)
a=aa
IF (ANY(b.NE.(/baab,baab,baab/))) CALL ABORT()
END
$ gfortran a3.f90
a3.f90:0: internal compiler error: Segmentation fault
gdb backtrace is:
Program received signal SIGSEGV, Segmentation fault.
0x004179b2 in gfc_check_pointer_assign (lvalue=0xce3ae0,
rvalue=0xce3de0) at ../../trunk/gcc/fortran/expr.c:2330
2330 if (lvalue-ts.type == BT_CHARACTER
(gdb) where
#0 0x004179b2 in gfc_check_pointer_assign (lvalue=0xce3ae0,
rvalue=0xce3de0) at ../../trunk/gcc/fortran/expr.c:2330
#1 0x0044a349 in resolve_code (code=0xce42c0, ns=0xce2380)
at ../../trunk/gcc/fortran/resolve.c:4967
#2 0x0044b765 in gfc_resolve (ns=0xce2380)
at ../../trunk/gcc/fortran/resolve.c:6919
#3 0x00440a68 in gfc_parse_file ()
at ../../trunk/gcc/fortran/parse.c:3212
2330 if (lvalue-ts.type == BT_CHARACTER
2331 lvalue-ts.cl-length rvalue-ts.cl-length
2332 abs (gfc_dep_compare_expr (lvalue-ts.cl-length,
2333 rvalue-ts.cl-length)) == 1)
(gdb) p lvalue-ts
$1 = {type = BT_CHARACTER, kind = 1, derived = 0x0, cl = 0xcb0800}
(gdb) p rvalue-ts
$2 = {type = BT_CHARACTER, kind = 1, derived = 0x0, cl = 0x0}
So rvalue-ts.cl-length should not be referenced.
--
Summary: segfault with character pointer association
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug fortran/29396] segfault with character pointer association
-- fxcoudert 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-10-08 21:46:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug fortran/29397] New: Problem with MAXLOC where mask involves a parameter array
$ cat a8.f90 INTEGER :: K(3)=1 INTEGER, PARAMETER :: J(3)=2 write(6,*) MAXLOC(K,J1) END $ gfortran a8.f90 ./a.out a.out: ../../../trunk/libgfortran/generated/maxloc0_4_i4.c:216: mmaxloc0_4_i4: Assertion `((mask)-dtype 6) == 8' failed. zsh: abort ./a.out If the PARAMETER -- Summary: Problem with MAXLOC where mask involves a parameter array Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug fortran/29397] Problem with MAXLOC where mask involves a parameter array
-- fxcoudert 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-10-08 21:50:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug fortran/29387] ICE on character array function of variable length
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-08 21:53 --- Another testcase for this bug: TYPE T1 INTEGER, POINTER :: I=NULL() END TYPE T1 IF(.NOT.ASSOCIATED(F1(10))) CALL ABORT() CONTAINS FUNCTION F1(I) RESULT(R) TYPE(T1), DIMENSION(:), POINTER :: R INTEGER :: I ALLOCATE(R(I)) END FUNCTION F1 END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug fortran/29395] failure in implied do loop data initialization
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-08 21:59 --- *** This bug has been marked as a duplicate of 23232 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29395
[Bug fortran/23232] DATA implied DO variables
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-08 21:59 --- *** Bug 29395 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/23232] DATA implied DO variables
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-08 21:59 --- (In reply to comment #4) *** Bug 29395 has been marked as a duplicate of this bug. *** $ cat a10.f90 integer :: i(2,2) data ((i(k,j), j = 1, k), k = 1, 2) / 3 * 0 / end $ gfortran a10.f90 In file a10.f90:2 data ((i(k,j), j = 1, k), k = 1, 2) / 3 * 0 / 1 Error: Parameter 'k' at (1) has not been declared or is a variable, which does not reduce to a constant expression -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-29 19:54:38 |2006-10-08 21:59:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-09 11:39 --- The same thing is true for all the array manipulation functions: integer :: i(-1:1,-1:1) = 0 integer :: j(-1:2) = 0 ! This is working correctly write(*,*) lbound(i(-1:1,-1:1)), ubound(i(-1:1,-1:1)) write(*,*) lbound(i(:,:)), ubound(i(:,:)) write(*,*) lbound(i(0:,-1:)), ubound(i(0:,-1:)) write(*,*) lbound(i(:0,:1)), ubound(i(:0,:1)) ! None of the following is working write(*,*) lbound(transpose(i)), ubound(transpose(i)) write(*,*) lbound(reshape(i,(/2,2/))), ubound(reshape(i,(/2,2/))) write(*,*) lbound(cshift(i,-1)), ubound(cshift(i,-1)) write(*,*) lbound(eoshift(i,-1)), ubound(eoshift(i,-1)) write(*,*) lbound(spread(i,1,2)), ubound(spread(i,1,2)) write(*,*) lbound(maxloc(i)), ubound(maxloc(i)) write(*,*) lbound(minloc(i)), ubound(minloc(i)) write(*,*) lbound(maxval(i,2)), ubound(maxval(i,2)) write(*,*) lbound(minval(i,2)), ubound(minval(i,2)) write(*,*) lbound(product(i,2)), ubound(product(i,2)) write(*,*) lbound(sum(i,2)), ubound(sum(i,2)) write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2)) write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2)) write(*,*) lbound(matmul(i,i)), ubound(matmul(i,i)) write(*,*) lbound(lbound(i)), ubound(lbound(i)) write(*,*) lbound(ubound(i)), ubound(ubound(i)) write(*,*) lbound(shape(i)), ubound(shape(i)) write(*,*) lbound(pack(i,.true.)), ubound(pack(i,.true.)) write(*,*) lbound(unpack(j,(/.true./),(/2/))), ubound(unpack(j,(/.true./),(/2/))) write(*,*) lbound(merge(i,i,.true.)), ubound(merge(i,i,.true.)) end The results for all write statements below the second comment are off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29400] New: ANY and COUNT used on parameter arrays
I found that bug while reducing PR29391, so it might be related (but I doubt it). $ cat a6.f90 integer,parameter :: i(1,1) = 0 write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2)) write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2)) write(*,*) lbound(matmul(i,i)) end $ gfortran a6.f90 ./a.out Operating system error: Cannot allocate memory Memory allocation failed If I remove the line with matmul, I get another error: $ gfortran a6.f90 ./a.out 0 1 0 1 zsh: segmentation fault ./a.out -- Summary: ANY and COUNT used on parameter arrays Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29400] ANY and COUNT used on parameter arrays
-- fxcoudert 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-10-09 11:53:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-09 12:36
---
The generated code for:
integer,parameter :: i(1,1) = 0
integer :: j(1)
j = lbound(any(i==1,2))
end
is weird:
MAIN__ ()
{
int4 j[1];
_gfortran_set_std (70, 127, 0);
{
int8 S.0;
S.0 = 1;
while (1)
{
if (S.0 1) goto L.1; else (void) 0;
{
struct array1_logical4 atmp.1;
int8 C.1248 = 2;
logical4 C.1247 = 0;
atmp.1.dtype = 273;
atmp.1.data = 0B;
atmp.1.offset = 0;
_gfortran_any_l4 (atmp.1, C.1247, C.1248);
j[NON_LVALUE_EXPR S.0 + -1] = (int4) atmp.1.dim[S.0 - 1].lbound;
_gfortran_internal_free (atmp.1.data);
}
S.0 = S.0 + 1;
}
L.1:;
}
}
Why are we passing a pointer to a logical4 as a second argument to
_gfortran_any_l4, and not an array descriptor.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-10-09 11:53:37 |2006-10-09 12:36:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-09 12:44 --- And while I'm there, a few possibly related bugs: $ cat pr29400-2.f90 integer,parameter :: i(1,1) = 0 logical :: l(2) l = any(i==1,2) end $ gfortran pr29400-2.f90 ./a.out Fortran runtime error: rank of return array incorrect $ cat pr29400-3.f90 integer,parameter :: i(1,1) = 0 logical :: l l = any(i==1) end $ gfortran pr29400-3.f90 ./a.out pr29400-3.f90: In function MAIN__: pr29400-3.f90:1: internal compiler error: in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.c:1339 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 Last reconfirmed|2006-10-09 12:36:31 |2006-10-09 12:44:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:31
---
For the TRANSPOSE case, the generated code shows that the {u,l}bounds simply
aren't set right:
$ cat pr29391.f90
integer :: i(-1:1,-1:1)=0, j(2)
j = lbound(transpose(i))
end
$ cat pr29391.f90.003t.original
MAIN__ ()
{
int4 j[2];
static int4 i[9] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
_gfortran_set_std (70, 127, 0);
{
int8 S.0;
S.0 = 1;
while (1)
{
if (S.0 2) goto L.1; else (void) 0;
{
struct array2_int4 atmp.2;
struct array2_int4 parm.1;
parm.1.dtype = 266;
parm.1.dim[0].lbound = -1;
parm.1.dim[0].ubound = 1;
parm.1.dim[0].stride = 1;
parm.1.dim[1].lbound = -1;
parm.1.dim[1].ubound = 1;
parm.1.dim[1].stride = 3;
parm.1.data = (void *) i[0];
parm.1.offset = 0;
atmp.2.dtype = parm.1.dtype;
atmp.2.dim[0].stride = parm.1.dim[1].stride;
atmp.2.dim[0].lbound = parm.1.dim[1].lbound;
atmp.2.dim[0].ubound = parm.1.dim[1].ubound;
atmp.2.dim[1].stride = parm.1.dim[0].stride;
atmp.2.dim[1].lbound = parm.1.dim[0].lbound;
atmp.2.dim[1].ubound = parm.1.dim[0].ubound;
atmp.2.data = parm.1.data;
atmp.2.offset = parm.1.offset;
j[NON_LVALUE_EXPR S.0 + -1] = (int4) atmp.2.dim[S.0 - 1].lbound;
}
S.0 = S.0 + 1;
}
L.1:;
}
}
The following patch ought to fix it:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 117560)
+++ gcc/fortran/trans-array.c (working copy)
@@ -787,11 +787,17 @@
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_lbound (dest, dest_index),
- gfc_conv_descriptor_lbound (src, src_index));
+ gfc_index_one_node);
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_ubound (dest, dest_index),
- gfc_conv_descriptor_ubound (src, src_index));
+ build2 (PLUS_EXPR, gfc_array_index_type,
+ gfc_index_one_node,
+ build2 (MINUS_EXPR, gfc_array_index_type,
+ gfc_conv_descriptor_ubound
+(src, src_index),
+ gfc_conv_descriptor_lbound
+(src, src_index;
if (!loop-to[n])
{
One last comment: I'm not sure the stride shouldn't be set to one. The patch
above regtests fine, and can compile correctly everything I threw at it, but
maybe I have not been clever enough to think of something that would trigger a
check on the stride.
Paul, could I have your opinion on the patch and the stride question? After you
comment, I'll go on designing patches for the other functions.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||paulthomas2 at wanadoo dot
||fr
Known to fail||4.2.0 4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29216] Derived type components of function results are not initialised
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-10 07:56 --- Paul, I'm not sure, but I think PR29394 is related to that one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29216
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-10 08:13 --- I'm very interested in that. I think it would really benefit the compiler: the Fortran front-end would gain much in stability (and ease of installation) and the C front-end could also benefit from this (as mentionned in PR29335). What's worrying me a bit is the versioning of MPFR. I'm writing it here because Vincent is in the Cc list of this bug, so maybe he can answer. The last MPFR release is dated 2005-09-09, and since then only patches without version information have been posted. That means we have no way to identify the MPFR library used exactly, to work around potential bugs or require fine-grained minimal version. Vincent, would it be possible that some version number is increased every time a patch is posted, so that the current version would be 2.2.16 or something like that? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-10 22:04 --- (In reply to comment #3) Are you sure that this renormalization of the bounds is required? After all: (i) indices should always be realtive to lbound, whatever it is; and (ii) why would anybody be interested to do this? After all, the temporary could be assigned to a variable with any lbound at all. I'm not sure I understand. The following code: INTEGER :: I(-1:1,-1:1)=0 WRITE(6,*) LBOUND(I) WRITE(6,*) LBOUND(I(:,:)) WRITE(6,*) LBOUND(TRANSPOSE(I)) END ought to output -1 -1 1 1 1 1 and not like we currently do: -1 -1 1 1 -1 -1 That's because of F95 13.14.53: Case (i): For an array section or for an array expression other than a whole array or array structure component, LBOUND(ARRAY, DIM) has the value 1. For a whole array or array structure component, LBOUND(ARRAY, DIM) has the value: (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have extent zero or if ARRAY is an assumed-size array of rank DIM, or (b) 1 otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:26
---
With the following patch:
Index: trans-array.c
===
--- trans-array.c (revision 117560)
+++ trans-array.c (working copy)
@@ -661,10 +661,12 @@
gfc_add_modify_expr (pre, tmp, size);
tmp = gfc_conv_descriptor_lbound (desc, gfc_rank_cst[n]);
- gfc_add_modify_expr (pre, tmp, gfc_index_zero_node);
+ gfc_add_modify_expr (pre, tmp, gfc_index_one_node);
tmp = gfc_conv_descriptor_ubound (desc, gfc_rank_cst[n]);
- gfc_add_modify_expr (pre, tmp, loop-to[n]);
+ gfc_add_modify_expr (pre, tmp,
+ fold_build2 (PLUS_EXPR, gfc_array_index_type,
+ loop-to[n], gfc_index_one_node));
tmp = fold_build2 (PLUS_EXPR, gfc_array_index_type,
loop-to[n], gfc_index_one_node);
@@ -787,11 +789,17 @@
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_lbound (dest, dest_index),
- gfc_conv_descriptor_lbound (src, src_index));
+ gfc_index_one_node);
gfc_add_modify_expr (se-pre,
gfc_conv_descriptor_ubound (dest, dest_index),
- gfc_conv_descriptor_ubound (src, src_index));
+ fold_build2 (PLUS_EXPR, gfc_array_index_type,
+ gfc_index_one_node,
+ fold_build2 (MINUS_EXPR, gfc_array_index_type,
+gfc_conv_descriptor_ubound
+ (src, src_index),
+gfc_conv_descriptor_lbound
+ (src, src_index;
if (!loop-to[n])
{
I get all intrinsics that work through temporaries working right:
integer :: i(-1:1,-1:1) = 0
integer :: j(-1:2) = 0
! Was already working
write(*,*) lbound(i(-1:1,-1:1)), ubound(i(-1:1,-1:1))
write(*,*) lbound(i(:,:)), ubound(i(:,:))
write(*,*) lbound(i(0:,-1:)), ubound(i(0:,-1:))
write(*,*) lbound(i(:0,:1)), ubound(i(:0,:1))
! Fixed
write(*,*) lbound(transpose(i)), ubound(transpose(i))
write(*,*) lbound(reshape(i,(/2,2/))), ubound(reshape(i,(/2,2/)))
write(*,*) lbound(cshift(i,-1)), ubound(cshift(i,-1))
write(*,*) lbound(eoshift(i,-1)), ubound(eoshift(i,-1))
write(*,*) lbound(spread(i,1,2)), ubound(spread(i,1,2))
write(*,*) lbound(maxloc(i)), ubound(maxloc(i))
write(*,*) lbound(minloc(i)), ubound(minloc(i))
write(*,*) lbound(maxval(i,2)), ubound(maxval(i,2))
write(*,*) lbound(minval(i,2)), ubound(minval(i,2))
write(*,*) lbound(any(i==1,2)), ubound(any(i==1,2))
write(*,*) lbound(count(i==1,2)), ubound(count(i==1,2))
write(*,*) lbound(merge(i,i,.true.)), ubound(merge(i,i,.true.))
write(*,*) lbound(lbound(i)), ubound(lbound(i))
write(*,*) lbound(ubound(i)), ubound(ubound(i))
write(*,*) lbound(shape(i)), ubound(shape(i))
! Still not working
write(*,*) lbound(product(i,2)), ubound(product(i,2))
write(*,*) lbound(sum(i,2)), ubound(sum(i,2))
write(*,*) lbound(matmul(i,i)), ubound(matmul(i,i))
write(*,*) lbound(pack(i,.true.)), ubound(pack(i,.true.))
write(*,*) lbound(unpack(j,(/.true./),(/2/))),
ubound(unpack(j,(/.true./),(/2/)))
end
So I only have PRODUCT, SUM, MATMUL, PACK and UNPACK to work on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:32 --- (In reply to comment #6) Forget that patch, it's breaking lots of things :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-11 13:17 --- I'll note that the Portland, Intel and g95 compilers do not see this issue either. SunStudio does, at runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 11:15 --- Created an attachment (id=12416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12416action=view) Patch for LBOUND/UBOUND This patch fixes this bug completely. It builds fine, regtest and works fine with a few other extra examples that I'll add as testcases. The idea behind it is explained here: http://gcc.gnu.org/ml/fortran/2006-10/msg00379.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:15 --- Created an attachment (id=12417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12417action=view) New patch This updated patch is the result of re-reading the Standard about assumed-size arrays. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #12416|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/23060] %VAL construct not implemented
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:19 --- [Paul changed this bug into enhancement] I'm changing this back (again) into a bug, not an enhancement, because it was supported by g77, and we're trying to make a drop-in replacement for g77 in most cases. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug fortran/29431] Not Implemented: complex character array constructors
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-13 07:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29431
[Bug libfortran/26540] [4.1 only] intrinsics/signal.c warnings
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:22 --- Since it's only a build-time warning, I won't backport that patch to 4.1 and I close the PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26540
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:38
---
(In reply to comment #3)
Can you upgrade and confirm that the code compiles?
No, Steve, it doesn't work for me either on i686-linux. I downloaded the code
from comment #2 (and to answer Paul: it doesn't contain any tab), and it fails
to compile with
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061012
--enable-languages=c,fortran
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.2.0 20061012 (experimental)
$ gfortran -c ircmva.f
In file ircmva.f:91
END
1
Internal Error at (1):
gfc_resolve_expr(): Bad expression type
while the same file compiles fine on x86_64-unknown-linux-gnu. The backtrace of
the ICE is:
Breakpoint 2, gfc_internal_error (
format=0x85d2f48 gfc_resolve_expr(): Bad expression type)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c:667
667 /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c: No such
file or directory.
in /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c
(gdb) where
#0 gfc_internal_error (
format=0x85d2f48 gfc_resolve_expr(): Bad expression type)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/error.c:667
#1 0x0808e082 in gfc_resolve_expr (e=0x9407790)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:3107
#2 0x0809162b in resolve_code (code=0x9407588, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4864
#3 0x08093edd in gfc_resolve_blocks (b=0x9407548, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4796
#4 0x080915fa in resolve_code (code=0x9407678, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4853
#5 0x08093edd in gfc_resolve_blocks (b=0x94062f8, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4796
#6 0x080915fa in resolve_code (code=0x9404c68, ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:4853
#7 0x08092e83 in gfc_resolve (ns=0x94013a8)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/resolve.c:6919
#8 0x08087d39 in gfc_parse_file ()
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/parse.c:3212
#9 0x080a928d in gfc_be_parse_file (set_yydebug=0)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/fortran/f95-lang.c:303
#10 0x083a6dc5 in toplev_main (argc=14, argv=0xbfc6ba64)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/toplev.c:1033
#11 0x080de53f in main (argc=2, argv=0x0)
at /home/fxcoudert/gfortran_nightbuild/trunk/gcc/main.c:35
gfc_internal_error is called in resolve.c because, in gfc_resolve_expr,
argument e has value:
(gdb) p *e
$2 = {expr_type = 0, ts = {type = BT_INTEGER, kind = 4, derived = 0x0,
cl = 0x0}, rank = 0, shape = 0x0, symtree = 0x96ae868, ref = 0x96d77e8,
where = {nextc = 0x96cc62b NUMCMP(NRCMP), ' ' repeats 40 times,
lb = 0x96cc608}, from_H = 0, inline_noncopying_intrinsic = 0, value = {
logical = 0, integer = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}},
real = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}},
complex = {r = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {
operator = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0},
function = {actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0},
character = {length = 0, string = 0x0}, constructor = 0x0}}
It has expr_type = 0, which should not happen. This happens for symbol numcmp:
(gdb) p *e-symtree
$3 = {priority = 15818, left = 0x0, right = 0x0, name = 0x96d07cd numcmp,
ambiguous = 0, n = {sym = 0x96d20b8, uop = 0x96d20b8, common = 0x96d20b8}}
(gdb) p *e-symtree-n.sym
$4 = {name = 0x96d07cd numcmp, module = 0x0, declared_at = {
nextc = 0x96b1f20 , NCMPVE, NCMPRF,, ' ' repeats 23 times,
lb = 0x96b1ef0}, ts = {type = BT_INTEGER, kind = 4, derived = 0x0,
cl = 0x0}, attr = {allocatable = 0, dimension = 1, external = 0,
intrinsic = 0, optional = 0, pointer = 0, save = 0, target = 0, dummy = 1,
result = 0, assign = 0, threadprivate = 0, data = 0, use_assoc = 0,
in_namelist = 0, in_common = 0, in_equivalence = 0, function = 0,
subroutine = 0, generic = 0, implicit_type = 0, untyped = 0, sequence = 0,
elemental = 0, pure = 0, recursive = 0, unmaskable = 0, masked = 0,
contained = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 0, referenced = 1,
is_main_program = 0, access = ACCESS_UNKNOWN, intent
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-13 07:54 --- I managed to trim it down to: implicit none integer :: n, i character(len=16),parameter :: s = if (s(9:16) == 90123456) then endif if (i 0) then write (i,*) n call foo(0) endif do i = 1, n end do end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
