[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #33 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-15 10:17 --- Subject: Re: Invariant DO loop variables and subroutines jv244 at cam dot ac dot uk wrote: --- Comment #32 from jv244 at cam dot ac dot uk 2009-08-15 10:05 --- (In reply to comment #29) It's the other way around: If output were to modify any of its arguments, the program would be illegal. Therefore, the compiler can assume that this doesn't happen. Intent(in) would be redundant for this particular case (though useful, so the compiler could easier detect errors). that's true for pX, but value can be modified by output. I.e. this is (afaict) valid fortran that write the numbers from 1 to 10 n=10 DO i=1,n n=0 write(6,*)i ENDDO Actually, we're buggy there, and my patch fixes it. I'm just now trying out testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #35 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-15 10:58 --- Subject: Re: Invariant DO loop variables and subroutines tkoenig at gcc dot gnu dot org wrote: --- Comment #34 from tkoenig at gcc dot gnu dot org 2009-08-15 10:57 --- (In reply to comment #33) Actually, we're buggy there, and my patch fixes it. I'm just now trying out testcases. Are we really buggy? No, I looked at the wrong thing, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #14 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-13 23:33 --- Subject: Re: Invariant DO loop variables and subroutines tkoenig at gcc dot gnu dot org wrote: --- Comment #13 from tkoenig at gcc dot gnu dot org 2009-08-13 18:55 --- (In reply to comment #12) That's exactly what Thomas is achieving by adding parentheses. Thomas, If you want to tackle something more difficult, I'm willing to do this over the weekend in order to warm up my knowledge of gfortran's internals. I'm glad if you take this on. Will you do this for scalar actual arguments corresponding to intent(in) dummy arguments, and for scalar writes as well? I'll start with the latter, and see if I can achieve the former afterwards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #7 from =?ISO-8859-1?Q?Tobias_Schl=FCter?= tobias dot schlueter at physik dot uni-muenchen dot de 2009-08-12 18:11 --- Subject: Re: Invariant DO loop variables and subroutines tkoenig at gcc dot gnu dot org wrote: --- Comment #6 from tkoenig at gcc dot gnu dot org 2009-08-12 17:53 --- We get a dramatic speedup when enclosing the arguments to print in parentheses: This is something we can do for - write and print statements - intent(in) arguments - any do variable passed as an argument within the loop An interesting approach. As long as you don't print array slices in the loops this should work around the escaping pointer problem. It comes at the risk of creating excessive copies. Actually, perhaps the right way of achieving this is not to add OP_PARENTHESES in the frontend, but to do a copy when creating the call. Cheers, - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
--- Comment #15 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-11-09 12:44 ---
Subject: Re: gfortran excessive memory usage with COMMON
blocks in modules
fxcoudert at gcc dot gnu dot org wrote:
Because in that case, mod2.mod already has two copies of the common:
(('mpipriv' 2 0 0 'mpipriv') ('mpipriv' 2 0 0 'mpipriv'))
and I don't think that's desirable. I think that the module loading is
actually
wrong here: the code in gfc_get_common (match.c) takes special care to
duplicate this common name by creating a unique name for it. While I believe
that mangling is necessary, the mangled name shouldn't be unique but simply
prefixed, so that of the same name are merged, while prevented to clash with
the namespace of the use'ing procedure.
I wrote this code originally, and I agree with your analysis.
Index: match.c
===
--- match.c (revision 129869)
+++ match.c (working copy)
@@ -2608,23 +2608,19 @@ gfc_common_head *
gfc_get_common (const char *name, int from_module)
{
gfc_symtree *st;
- static int serial = 0;
- char mangled_name[GFC_MAX_SYMBOL_LEN + 1];
+ char mangled_name[GFC_MAX_SYMBOL_LEN + 12];
Should be + 13 (need one char for '\0').
+/* A use associated common block is only needed to correctly layout
+ the variables it contains. */
+snprintf (mangled_name, GFC_MAX_SYMBOL_LEN, _frommodule_%s, name);
GFC_MAX_SYMBOL_LEN + 12, otherwise you could create ambiguities with
really long common names. Previously this wasn't possible due to the
serial number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
--- Comment #17 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-11-10 01:16 --- Subject: Re: gfortran excessive memory usage with COMMON blocks in modules fxcoudert at gcc dot gnu dot org wrote: --- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-11-09 23:59 --- (In reply to comment #15) I wrote this code originally, and I agree with your analysis. But regtesting doesn't agree with my analysis... in case of common with bind(c,name=...), this patch hampers the diagnosis of commons with the same name but different labels. I've tried hard to get it rolling that way, because I agree it's cleaner, but I couldn't. I'll propose a different approach (a hack, to avoid writing twice the same combination of name and binding label) to the list when it finishes regtesting. There was no BIND(C) when I wrote it :-) I'll give it a look tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #42 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-25 15:48 --- Subject: Re: wrong types in character array/scalar binop dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25 15:41 --- Subject: Re: wrong types in character array/scalar binop While on x86_64-gnu-linux the dump has: int8 S.5; the variable on hppa-unknown-linux-gnu is: int4 S___5; I wonder why the variables names differ. I'm not aware of any backend feature that controls this. Maybe (random shot in the dark) hp's assembler doesn't allow for dots in symbol names, and gcc, when generating the name for the symbol takes this into account even though this is on Linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #46 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-25 19:50 ---
Subject: Re: wrong types in character array/scalar binop
dave at hiauly1 dot hia dot nrc dot ca wrote:
Subject: Re: wrong types in character array/scalar binop
ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : T,
I'm still don't understand how we get underscores. We have in defaults.h:
#ifndef ASM_FORMAT_PRIVATE_NAME
# define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
do { const char *const name_ = (NAME); \
char *const output_ = (OUTPUT) = \
(char *) alloca (strlen (name_) + 32); \
sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABELNO)); \
} while (0)
#endif
#ifndef ASM_PN_FORMAT
# ifndef NO_DOT_IN_LABEL
# define ASM_PN_FORMAT %s.%lu
# else
# ifndef NO_DOLLAR_IN_LABEL
# define ASM_PN_FORMAT %s$%lu
# else
# define ASM_PN_FORMAT __%s_%lu
# endif
# endif
#endif /* ! ASM_PN_FORMAT */
To the best of my knowledge, we don't define either ASM_FORMAT_PRIVATE_NAME
or NO_DOT_IN_LABEL. I believe NO_DOLLAR_IN_LABEL is defined on those PA
targets that include elfos.h.
~/src/hggcc/gcc/config tobi$ find . | xargs grep ASM_PN
./alpha/vms.h:#define ASM_PN_FORMAT %s___%lu
./h8300/h8300.h:#define ASM_PN_FORMAT %s___%lu
./ia64/ia64.h:#define ASM_PN_FORMAT (TARGET_GNU_AS ? %s.%lu : %s?%lu)
./mmix/mmix.h:#define ASM_PN_FORMAT %s::%lu
./mn10300/mn10300.h:#define ASM_PN_FORMAT %s___%lu
./pa/pa.h:#define ASM_PN_FORMAT %s___%lu
./v850/v850.h:#define ASM_PN_FORMAT %s___%lu
It looks like you do :-)
I wonder why this name-mangling is necessary, it's not like these names
are going to appear in the assembly, is it?
Cheers,
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #15 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-21 20:13 --- Subject: Re: Diagnose different string lengths in array constructors at run time dominiq at lps dot ens dot fr wrote: --- Comment #14 from dominiq at lps dot ens dot fr 2007-10-21 20:05 --- Now I understand the strange result I reported in comment #5. What is happening is that there is a second nonprintable character. If I redirect the output to a file I see it (in general ^@). From what I understand of the code the substring x(1:len(trim(x))) is not computed correctly by: if (ref-u.ss.start-expr_type != EXPR_CONSTANT || ref-u.ss.end-expr_type != EXPR_CONSTANT) break; probably not computed at all, as noticed by Tobias Schlüter in the patch in http://gcc.gnu.org/ml/fortran/2007-10/msg00212.html The next iteration of the testcase will contain code that verifies that the string length actually gets calculated :-} -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 10:45 --- Subject: Re: Diagnose different string lengths in array constructors at run time dominiq at lps dot ens dot fr wrote: program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = (/y(1:len(trim(y))), x(1:len(trim(x)))/) ! causes segfault print *, ', z(1), ' ', z(2), ' end program array_char gives [karma] f90/bug% gfc -fbounds-check pr33727_bad.f90 [karma] f90/bug% a.out 'cd' 'a' I am expecting this test to fail at runtime and the other one. Am I missing something. This is weird, and can't really be (well, in a hypothetical world where only the bounds check goes wrong), as the whole array has only a single string length, so I would expect it to either print two length one strings or two length two strings, not one lenghth one string and one length two string. I have also noticed something strange with the following valid(?) code: program array_char implicit none character (len=2) :: x, y character (len=2) :: z(2) x = a y = cd z = z = (/y(1:len(trim(x))), x(1:len(trim(x)))/) print *, ', z(1), ' ', z(2), ' end program array_char which gives 'c' 'a' while I am expecting 'c ' 'a ' Looks like another bug, should I fill a new PR? Yes. This looks related to the previous one, again the string length seems to be taken from the wrong place. Are these with or without Paul's patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 14:04 --- Subject: Re: Diagnose different string lengths in array constructors at run time dominiq at lps dot ens dot fr wrote: --- Comment #7 from dominiq at lps dot ens dot fr 2007-10-11 12:34 --- This is weird, and can't really be (well, in a hypothetical world where only the bounds check goes wrong), as the whole array has only a single string length, so I would expect it to either print two length one strings or two length two strings, not one lenghth one string and one length two string. I am not sure to understand the above. Each element of z is a string of length 2, y(1:len(trim(y))) is also of length 2, while x(1:len(trim(x))) is of length one, so the constructor should give an error. Yes, I agree with the latter. What I menat is the following: after the data has been added to the array, the compiler should use the string length of the array, so if you do CHARACTER*10 z z = (/ something /) print *, z all printed strings should be length 10, no the contents of the constructor. Are these with or without Paul's patch? with otherwise I got an ICE. ok, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-11 14:09 --- Subject: Re: Diagnose different string lengths in array constructors at run time Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: all printed strings should be length 10, no the contents of the constructor. ^^ read: independent of -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33689] [Regression 4.3] Array with constant bound rejected as automatic array
--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-08 18:02 --- Subject: Re: [Regression 4.3] Array with constant bound rejected as automatic array burnus at gcc dot gnu dot org wrote: --- Comment #3 from burnus at gcc dot gnu dot org 2007-10-08 17:58 --- Works: r129068; fails: r129069. http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00174.html r129069 | tobi | 2007-10-07 13:45:15 +0200 (So, 07 Okt 2007) | 14 lines PR 20851 fortran/ * expr.c (check_inquiry): Typo fix in error message. (check_init_expr): Same * 3. (check_restricted): Verify that no dummy arguments appear in restricted expressions in ELEMENTAL procedures. * resolve.c (resolve_fl_variable): Exchange order of checks to avoid side-effect. Just great, looks like we were relying on a side-effect before. I'll have a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33689
[Bug fortran/33626] Parentheses get wrong kind during matching
--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-03 16:36 --- Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: --- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26 --- (In reply to comment #1) Created an attachment (id=14291) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view) [edit] Putative patch I thought about that, because it seems right, but the the question is: what was the intent of the original situation, which only copied typespec only for unknown types? I'm thinking that was a case of playing it overly safe as the comment indicates. OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 for which I have no explanation at the moment, I'll have to doublecheck if it disappears without my patch. I'll test it. Thanks! - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33626
[Bug fortran/33626] Parentheses get wrong kind during matching
--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-03 16:46 --- Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: --- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40 --- (In reply to comment #4) OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 for which I have no explanation at the moment, I'll have to doublecheck if it disappears without my patch. Hum... Why do I keep sending regular regressions heads-up, can you remind me? ;-) Ouch, a warning regression seemd so unlikely to happen in the tree that I thought it would be my fault, even though I very well remembered that you had sent an e-mail pointing out failures of default_format_1.f90 (which I'm seeing as well). Note to self: always memorize e-mail's from FX in their entirety :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33626
[Bug fortran/33626] Parentheses get wrong kind during matching
--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-03 17:06 --- Subject: Re: Parentheses get wrong kind during matching fxcoudert at gcc dot gnu dot org wrote: --- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52 --- (In reply to comment #6) failures of default_format_1.f90 (which I'm seeing as well) You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's what you've got these days)? That's not supposed to happen, I thought it'd be only on powerpc-darwin (which I have xfail'ed)! Could you compile it and run it under gdb, and see where it aborts? (I expect it to be the line about tiny, in which case it'd be the same failure as powerpc.) I checked all tests individually, and both the tests related to tiny(0.0_8) fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33626
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #20 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-07-04 10:51 --- Subject: Re: [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings jv244 at cam dot ac dot uk wrote: --- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 --- (In reply to comment #18) I'll spend this afternoon on it, rather than going on the conference excursion. depending on location/weather, I'd go for the conference excursion ;-) Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more important than anything else :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-05-19 11:22 --- Subject: Re: INTRINSIC symbols can be given the wrong type dfranke at gcc dot gnu dot org wrote: Thus, we should make sure that each intrinsic starts with the correct type to begin with and emit a warning/error if someone attempts to change that type (wherever the right place for this may be)? The idea is probably that giving all intrinsics types right from the beginning would be unnecessarily blowing up namespaces, and therefore memory and compile-time consumption (and maybe module files) What one can possibly do, though it might require quite a bit of care, is modifying variable_decl() to check if the symbol is an intrinsic declared with the correct type before adding it to the namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug fortran/31608] wrong types in array transfer
--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-04-19 09:08 --- Subject: Re: wrong types in array transfer burnus at gcc dot gnu dot org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 --- Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) Well, we do. That doesn't make it any less embarassing :) But indeed this is the same as 1 .eq. (/1,2/) which evaluates to (/.true.,.false./), should have thought of this earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-03-20 20:17 --- Subject: Re: short-circuit in -fbounds-check I'm on your side, mimo, no need to convince me :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-03-20 21:04 --- Subject: Re: short-circuit in -fbounds-check pinskia at gcc dot gnu dot org wrote: But I'll stop this discussion here, and will stay with g95 when I want to bound-check my program. Why short circuiting is legal and so is not short circuiting. Yes Gfortran's behavior is semi inconstaint but that does not make gfortran's behavior incorrect. In fact I want to say Gfortran's behavior with -fbounds-check with not short circuiting is actually a good thing because you catch more invalid/undefined fortran code that way. How about we stop this discussion? I don't think anyone was volunteering to implement a solution anyway. To sum up the alternatives: you repeated the argument for one side above. Other people want their program to do the same thing whether bounds checking is enabled or not -- except in the case where the non bounds-checking program would have made an out-of-bounds access. Neither party is right, I consider this latter behavior preferable. Thank you, and goodbye. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #30 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-12 01:21 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-12 01:15 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- (In reply to comment #6) Fortran is not release-critical and this bug appears to be purely within the Fortran front end. Should I commit the patch for the next release candidate once the branch is unfrozen? Personally, I don't believe this a sufficiently important bug (being an ICE on weird invalid code designed deliberately to break the compiler), but if you don't want this regression in the release, I'll happily commit it in time for the next release candidate. Mark always says that if it's not c++ ;) Since it's a regression, I believe it's your call. The test could be xfail'd if you decide the benefits aren't worth the risk. User-visibility of the bug is probably zero, so I don't think this is important enough :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 21:49 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 --- I forgot that OS X is not supported by gcc 4.1 What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' This is with $ as -version Apple Computer, Inc. version cctools-622.3.obj~2, GNU assembler version 1.38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 22:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 --- The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' Sound familiar, aren't you speaking of MacIntel? I have done some testing on MacIntel with a prebuild gfortran and I remember having some problems with as. I did not build gcc 4.1 recently on PPC 10.4.8, but I have build 4.2 without problem with as Apple Computer, Inc. version cctools-622.5.obj~13, GNU assembler version 1.38 Yes MacIntel, sorry, I should have said that. 4.2 is indeed fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-09 04:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 --- I think there is definitively a problem with the as provided on MacIntel. If you are interested I can dig my archives, I think I have some trace of the problem. Unfortunately I have only a limited access to a MacIntel machine. Thank you, but I think MacIntel is officially unsupported with 4.1. Tant pis. I'll use the Linux box to further investigate the problem there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-16 10:52 --- Subject: Re: ICE in operand_subword_force, at emit-rtl.c:1353 franke dot daniel at gmail dot com [EMAIL PROTECTED] wrote on Sat, 14 Oct 2006: Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM Because this doesn't trigger the buggy codepath :-) Sometime in the past someone went to some lengths to support this kind of invalid code. Had they read the standard closely, they could have saved themselves some work. (Also compare with #3) I don't see the relation. Cheers, - Tobi This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-13 19:19 --- Subject: Re: ICE in operand_subword_force, at emit-rtl.c:1353 franke dot daniel at gmail dot com [EMAIL PROTECTED] wrote on Fri, 13 Oct 2006: As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)): Oh, that's what you meant with equal lengths :-) This is indeed not required by the standard. And indeed, this triggers the same bug: the ICE has nothing to do with the assignment, it is the code dealing with the array constructor that is making us ICE. Thanks! This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/20460] Nasty extensions that should always warn
--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-05-07 16:46 --- Subject: Re: Nasty extensions that should always warn fxcoudert at gcc dot gnu dot org [EMAIL PROTECTED] wrote on Sun, 07 May 2006: Anyhow, we know have -std=legacy for such features, including REAL DO loop indices. The remaining question is: do we want to mark REAL array indices as legacy (there's currently no warning about them in -std=gnu mode)? (we didn't have STD_LEGACY when this PR was opened) I think this would be a good idea. IMO bad Fortran 77 habits can qualify as legacy nowadays. This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-01-08 22:16 --- Subject: Re: Jumping into blocks gives error rather than warning steven at gcc dot gnu dot org wrote: --- Comment #9 from steven at gcc dot gnu dot org 2006-01-08 21:45 --- Actually we already know for sure that the label exists and that it is a valid jump target. From resolve_branch: Indeed, I had missed that we already keep track of all existing labels when parsing via the code in gfc_get_st_label. I'll give your code a spin and submit it, when it passes testing. Ok? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #13 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-01-08 22:53 --- Subject: Re: Jumping into blocks gives error rather than warning steven at gcc dot gnu dot org wrote: --- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 22:23 --- Yes please. And what do you think of the other idea to speed things up? I know nothing about bitmaps :-) I've just finished up coding a version which puts them into a balanced binary tree, this should fix one quadratic bottleneck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[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./rant 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/15809] ICE Using Pointer Functions
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-21 18:08 --- Subject: Re: ICE Using Pointer Functions pgf90 compiles Paul Thomas' example, giving an empty string as output from the subroutine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-11-07 23:43 ---
Subject: Re: Unclassifiable statement on implicitly typed
character substring
steven at gcc dot gnu dot org wrote:
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29
---
We get to check_substring: in match_varspec:
PROGRAM P
IMPLICIT CHARACTER*8 (Y)
YLOCAL='A'
YBTABLE=YLOCAL(1:2)
END
check_substring:
if (primary-ts.type == BT_CHARACTER)
{
switch (match_substring (primary-ts.cl, equiv_flag, substring))
{
case MATCH_YES:
if (tail == NULL)
primary-ref = substring;
But at this point, while we have matched YLOCAL in the second assignment, we
still haven't picked up a type for it. So primary-ts.type == BT_UNKNOWN and
we never even try to match the substring.
I'm not sure if YLOCAL should have just picked up a type earlier. Thoughts,
Tobi?
It should have picked up a type in the first assignment. Why it doesn't, I
don't know. Apparently, the failure is conditional on the facts that A) there
already exists a symbol and B) this symbol doesn't have a type at that point.
I'll look into this in more depth tomorrow. I remember that last time I
looked into these issues (back before Jakub fixed PR18833), I noticed that the
matching of primaries had been completely reworked in g95, and I can't think
of any other bug relating to that than this one, so this bug might well turn
out to be a snake pit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug libfortran/21820] Really, really, horrible IO performance
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-01 22:31 --- Subject: Re: Really, really, horrible IO performance jblomqvi at cc dot hut dot fi wrote: It depends on what you consider really, really horrible IO performance. ;-) Getting rid of mmap (the patch referred to above) improved performance by a factor of 25, and I think before I made those measurements there were some patches committed which made the mmap window bigger or somesuch, improving performance compared to the situation when the bug was filed. So IMHO we have made huge improvements. OTOH we still lose to ifort by a factor of 6 or so. The major reason is that ifort does bulk transfers for implied do loops, while gfortran doesn't. Changing the code to use array transfers makes gfortran only about a factor of 1.5 slower than ifort. Personally, I think we can keep the bug around for reference, but change the priority to enhancement. We could probably close this as a duplicate of PR16339. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
[Bug fortran/23815] Add -byteswapio flag
--- Comment #5 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-10-11 19:01 --- Subject: Re: Add -byteswapio flag tkoenig at gcc dot gnu dot org wrote: --- Comment #4 from tkoenig at gcc dot gnu dot org 2005-10-11 18:40 --- I'm trying to work on this. I would prefer a syntax open(...,convert=little_endian) or something like that. This wouldn't allow taking sources and data files from a big-endian platform to a little-endian platform without either conversion of the data files or modifications to the sources, so this will also have to be settable at runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug fortran/15809] ICE Using Pointer Functions
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-09-02 15:38 --- Subject: Re: ICE Using Pointer Functions erik dot edelmann at iki dot fi wrote: Yes, it's the latter bug that Richard's patch fixes. I could add that I posted a patch to fix the other bug here: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01861.html I'm not yet sure if this is the best way to deal with the problem, though. I vaguely remember seeing a case where allowing a PARM_DECL fixed a bug, but wasn't still not quite right. I'll try to find out what this was (hopefully I'll have somethign written somewhere on it) - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-08-14 22:02 ---
Subject: Re: MAXPATHLEN usage in fortran/{scanner,module}.c
Steve Kargl wrote:
The attached patches uses alloca to remove the use of PATH_MAX
from gfortran. It also fixes one other nearby hardcoded buffer.
This has been bubblestrapped and regression tested on amd64-*-freebsd.
2005-08-01 Steven G. Kargl [EMAIL PROTECTED]
PR fortran/23065
* gfortran.h: Remove PATH_MAX definition.
* module.c (write_module,gfc_dump_module): Use alloca to allocate
buffers.
* scanner.s (gfc_release_include_path,form_from_filename): Ditto.
^
typo.
--- 1131,1142
const char *fileext;
int i;
! /* Find end of file name. Note, filename is either a NULL pointer or
! a NUL terminated string. */
i = 0;
! while (filename[i] != '\0')
i++;
/* Find last period. */
while (i = 0 (filename[i] != '.'))
i--;
If filename ever were a NULL pointer this would break, but it won't ever be
because gfc_post_options explicitly sets it to the empty string if no filename
is supplied on the command line.
The patch is ok if you remove the if in the beginning of gfc_new_file, i.e.
change
try
gfc_new_file (const char *filename, gfc_source_form form)
{
try result;
if (filename != NULL)
{
gfc_source_file = gfc_getmem (strlen (filename) + 1);
strcpy (gfc_source_file, filename);
}
else
gfc_source_file = NULL;
to gcc_assert(filename) plus the if part.
thanks,
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065
[Bug fortran/20363] interface body has incorrect scope
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-28 10:45 --- Subject: Re: interface body has incorrect scope Quoting erik dot edelmann at iki dot fi [EMAIL PROTECTED]: The (draft) f2k standard apperantly considers interfaces with names to be generic interfaces, even when the interface block contains only one procedure. This is probably so because procedures can later be added to the same generic name, say interface a module procedure b end interface interface a module procedure c end interface etc. The only one of these that can have a name is INTERFACE_GENERIC, which is treated as nameless in find_special() by g95. This means that either find_special() is meaningless in g95, or g95 has a bug. In the latter case, we would most likely introduce the same bug in gfortran with my patch. I'm, however, becoming more and more convinced that find_special() is meaningless (in both compilers) (but I'm not 100 % sure of course). I think I agree with this, but I'm still not 100% sure I've understood everything that's relevant. - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20363
[Bug fortran/20363] interface body has incorrect scope
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-27 13:21 --- Subject: Re: interface body has incorrect scope Quoting erik dot edelmann at iki dot fi [EMAIL PROTECTED]: I've taken a look at another compiler (i.e. g95). The difference is in (gfc|g95)_match_interface(). While we do case INTERFACE_GENERIC: ... current_interface.sym = gfc_new_block = sym; g95 does: case INTERFACE_GENERIC: ... g95_new_block = NULL; The result of this is that in find_special(), when we get to the point if (s-state != COMP_INTERFACE || s-sym == NULL) goto normal; /* Nameless interface */ (or corresponding point in gfortran source code), g95 will 'goto normal', while we continue. In other words; g95 treats generic interfaces as nameless interfaces. This brings me to a question: what is a named interface? I had assumed that it would the same thing as a generic interface, but in g95 code it is apperantly not. (I'm at the office so wrapping is weird, my e-mail address is weird and I don't have the standard nor the source handy) IIRC in g95 generic interface names are not part of the usual symbol tree, but instead they're stored completely apart, so that the symbol doesn't get in the way as it does in our case, and therefore the check in find_special can remain the same. Therefore it's unfortunately not clear if the behavior with your patch is equivalent to g95's. I couldn't think of anything that breaks with your patch, which leaves us with either the option of applying your patch (and then having to remember reverting your change if someone finds time to overhaul symbol handling) or overhauling symbol handling right away :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20363
[Bug fortran/18833] ICE 'missing spec' on integer/char equivalence
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-22 14:01 --- Subject: Re: ICE 'missing spec' on integer/char equivalence federico dot carminati at cern dot ch wrote: this is valid f90/95 code. Equivalence cannot contain sym%val as far as I understand, but they can cointain derived types as long as they are sequenced. I'm not sure if oyu meant to say the right thing, so let me clarify: sym%name and sym are allowed if sym is of a type with the sequence attribute. I haven't yet looked over the posted program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
[Bug fortran/18833] ICE 'missing spec' on integer/char equivalence
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-22 14:49 --- Subject: Re: ICE 'missing spec' on integer/char equivalence federico dot carminati at cern dot ch wrote: --- Additional Comments From federico dot carminati at cern dot ch 2005-07-22 14:20 --- Subject: Re: ICE 'missing spec' on integer/char equivalence Errr... I was a bit cryptic. You cannot put in an equivalence anything like sym%var, but you can put a whole derived data type, as long as it is sequenced. See the attached example. Regards, Fed Ugh, yes, I agree with you (if you add variable after derived data type), I misread the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
[Bug fortran/20363] interface body has incorrect scope
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-11 20:12 --- Subject: Re: interface body has incorrect scope paulthomas2 at wanadoo dot fr wrote: --- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-11 20:02 --- Subject: Re: interface body has incorrect scope That seems to be as good as one could want! Paul, do you have any idea what find_special could be intended for? It seems obvious that it does the wrong thing in the case of this PR, and I can't see any case where it would be needed, but I would be surprised if there's no intent behind it, and in another compiler the function is still present, does the same thing, and is called in the same places. Are there maybe any other changes in symbol handling compensating for this? Erik, I'll give this some more thought before I commit your patch, so don't worry if I take a few days. - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20363
[Bug fortran/18022] problem with structure and calling a function
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-10 17:37 ---
Subject: Re: problem with structure and calling a function
paulthomas2 at wanadoo dot fr wrote:
--- 2213,2226
tree tmp;
stmtblock_t block;
stmtblock_t body;
!
! /* Special case a single function returning an array. Note
! that derived type components on lhs do not benefit from
! this optimization and so are excluded by testing that
! the expression and symbol types are the same. */
! if (expr2-expr_type == EXPR_FUNCTION expr2-rank 0
!expr1-symtree-n.sym-ts.derived
! == expr1-ts.derived)
{
tmp = gfc_trans_arrayfunc_assign (expr1, expr2);
if (tmp)
I should probably have said why I don't like this: this will probably not work
with derived types which have a component of the same type as is common e.g.
in linked lists.
Hm, thinking about it a second longer makes it seem that this is really wrong:
expr1-ts.type should be BT_REAL in our case, so you're checing something
random, but maybe I've stared at code too long today, having turned in our
second-round ICFPC submission and reviewing patches.
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
[Bug fortran/18022] problem with structure and calling a function
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-07-09 15:06 --- Subject: Re: problem with structure and calling a function paulthomas2 at wanadoo dot fr wrote: I think that your pointer example is another bug. Whether it should be considered to be in gfc_trans_pointer_assignment itself or in gfc_conv_expr_descriptor should be thought through. It seems to me that fixing the latter would open the same can of worms that we have discussed for gfc_trans_assignment. This time, I am not sure that there is solution, except for the third. Using temporaries will not work, since the temporary would have to be updated each time the target value changed. Modifying the stride will not work for the same reasons as for a non-pointer assignment. If size is used, can we be sure that the rest of the compiler will pick it up? I was a little surprised that the code I gave is allowed at all, given that this opens all kinds of cans of worms. Say, type a real*8 :: x integer*1 :: i end type type(a), target :: v(50) real, pointer :: p(:) p = v(:)%x Lovely, now we have to skip something which probably has a different size and probably alignment. I don't agree that gfc_trans_pointer_assignment can be made out to be the culprit -- pointer assignment to an array-valued pointer means assignment of an array descriptor, so we have to be able to generate correct array descriptors even in these pathological cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-06-15 08:22 --- Subject: Re: libgfortran doesn't compile on IRIX 5.3 ro at gcc dot gnu dot org wrote: --- Additional Comments From ro at gcc dot gnu dot org 2005-06-15 00:02 --- Fixed for 4.1.0, patch pending for 4.0.2, 3.4.5. There's no libgfortran in 3.4.5 :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-06-15 09:37 --- Subject: Re: libgfortran doesn't compile on IRIX 5.3 Quoting ro at techfak dot uni-bielefeld dot de [EMAIL PROTECTED]: Fixed for 4.1.0, patch pending for 4.0.2, 3.4.5. There's no libgfortran in 3.4.5 :-) True enough, but the fix is for a generic fixincludes bugs which also affects the 3.4 branch. Bruce approved it for all active branches, which includes 3.4.5. Well, that makes sense :-) - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-22 18:10 --- Subject: Re: COMPLEX function returns incompatible with g77 Tobias Schlüter wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 --- Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. I'm also inclined to doing this, 4.0.1 will probably be vastly more usable than 4.0, but I'd still like to get feedback from the list. It's really a minor incompatibility. Especially since a lot of people seem to use '-fno-second-underscore'. I'll commit this during the week, unless somebody objects. Toon's approval together with no objections so far is enough for me, but I wanted to give everybody a last chance to object. - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20900] use-associated variable may not be equivalenced
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-19 19:22 --- Subject: Re: use-associated variable may not be equivalenced jv244 at cam dot ac dot uk wrote: --- Additional Comments From jv244 at cam dot ac dot uk 2005-05-19 17:54 --- (In reply to comment #1) There's no 11.7 neither in the F95 nor the F2K drafts I'm having. This is invalid by the constraints in 5.5.1 in the F95 draft. Is there any other constraint you were aiming at? No, off-by-one, refering to 'note 11.8' in 11.3.2 which mentions the same constraint. Thanks, I had only checked note 11.7 :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20900
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-18 11:19 --- Subject: Re: COMPLEX function returns incompatible with g77 toon at moene dot indiv dot nluug dot nl wrote: --- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 11:32 --- Subject: Re: COMPLEX function returns incompatible with g77 tobi at gcc dot gnu dot org wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 --- Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. I'm also inclined to doing this, 4.0.1 will probably be vastly more usable than 4.0, but I'd still like to get feedback from the list. It's really a minor incompatibility. Especially since a lot of people seem to use '-fno-second-underscore'. - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-18 11:21 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Tobias dot Schlueter at physik dot uni-muenchen dot de wrote: --- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-14 15:25 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Quoting corsepiu at gcc dot gnu dot org [EMAIL PROTECTED]: As I tried to express before, I think this PR actually trips several bugs at once. * A bug in error f95's handling, which probably causes the seg fault. The compiler simply must not seg fault. Exactly, I assume this has to do with the fact that we're trying to initialize a zero-length parameter array, which is somewhat unusual, and thus probably not well-tested and buggy. I won't have access to my box, but if someone has a few spare minutes, I'd suggest he tries this code: This did work correctly, so that's one possible problem less. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-05-14 15:25 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 Quoting corsepiu at gcc dot gnu dot org [EMAIL PROTECTED]: As I tried to express before, I think this PR actually trips several bugs at once. * A bug in error f95's handling, which probably causes the seg fault. The compiler simply must not seg fault. Exactly, I assume this has to do with the fact that we're trying to initialize a zero-length parameter array, which is somewhat unusual, and thus probably not well-tested and buggy. I won't have access to my box, but if someone has a few spare minutes, I'd suggest he tries this code: INTEGER, PARAMETER :: i(0) = (/ /) or, if this doesn't break, TYPE a INTEGER i END TYPE a TYPE(a), PARAMETER :: i(0) = (/ /) I'm fairly sure that this will give the same segfault Ralf is seeing. * A configuration problem: The configure scripts should be able to detect if a target doesn't meet its expectations. While this is true, this is not necessarily a compile-time problem. the mapping between the compiler's internal types and Fortran types is made at execution time of the compiler. * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented. Fortran requires that there be a floating point type (DOUBLE PRECISION) which takes twice the space of the usual REAL variables. It should probably be possible to use gfortran on platforms which don't have this, but given the amount of Fortran code that is tied to this assumption, I don't think this would be worthwhile. E.g. COMMON block layout depends crucially on this. But the bug we're dealing with has to do with INTEGER kinds, once we've cleared the issues WRT those, we can have this discussion again. Unless everything unxepectedly works out of the box :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug libfortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-29 16:29 --- Subject: Re: MATMUL failing with ALLOCATED matrices, unless base indices given paulthomas2 at wanadoo dot fr wrote: --- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-29 14:59 --- Exactly - I was aware of this because the namelist functions do not use base/offset at all. Yes, that is the point that Thomas was making, when he raised it in the first place. Again, exactly. Looks like I'm really slow :-) I'm all in favor of Thomas ssize_t patch now. As for the care that I am taking - after the business with namelist, I feel like the monkey and the billiard ball- I'll see if I can find it on the web. You will see why it is appropriate. I broke the bootstrap yesterday, I guess I'm in no position to judge how careful other people are :-) - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18857
[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-25 20:47 --- Subject: Re: MATMUL failing with ALLOCATED matrices, unless base indices given paulthomas2 at wanadoo dot fr wrote: Does this do it for you? - it works with those assertions eliminated. It doesn't work for me, a.out: ../../../gcc-clean/libgfortran/generated/matmul_r4.c:161: matmul_r4: Assertion `a-base == 0' failed. Aborted but I'm not sure if understood your question. I'm kinda surprised it works with the assertions removed, as I don't see anything in the implementation which deals with a-base != 0. Does it also work if you change the lower bound in the second dimension in one of the pointer assignments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18857
[Bug fortran/20861] error needed
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-23 13:48 --- Subject: Re: error needed Any pointers as to why this is invalid? 12.4.1.2 Hm, I can't see that there. Looks like I'll have to find out which term has a definition different from what I'm thinking ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20861
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:16 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 12:48 --- (In reply to comment #5) It is annoying enough that the preprocessor is invoked via cc1. Is there a reason for this, besides that it is the example given in the specfiles? Besides that is the only preprocessor any more, there is not a seperate one anymore, it is integrated into cc1 now. We're using the traditional preprocessor. This is a separate executable, cpp, which is built separately. So the question remains: why do we run cc1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:39 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:20 --- (In reply to comment #8) We're using the traditional preprocessor. This is a separate executable, cpp, which is built separately. So the question remains: why do we run cc1? cpp just calls cc1. There used to be a cpp0 but that was removed a while back, long before gfortran was added, there was code in cc1 which made us not warn about the g77 options, that should be brought back. Oh, ok. OTOH one could maybe strip out options that are meaningless to preprocessing before calling cc1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-09 15:07 --- Subject: Re: libgfortran doesn't compile on IRIX 5.3 coudert at clipper dot ens dot fr wrote: /var/tmp/gfortran-20050109/irun/mips-sgi-irix6.5/sys-include -mabi=32 -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran -I. -iquote../../../../gcc/libgfortran/io -O2 -g -O2 -std=gnu99 -O2 -g -O2 -Wall -Wall -c ../../../../gcc/libgfortran/generated/exp_c8.c -DPIC -o .libs/exp_c8.o ../../../../gcc/libgfortran/generated/exp_c8.c:29: error: conflicting types for 'cabs' /var/tmp/gfortran-20050109/ibin/gcc/include/math.h:676: error: previous declaration of 'cabs' was here The difference of these two I can't explain, may be something deep inside configure process. I don't know how to debug further than that. I can provide the complete build directory for analysis if needed. Maybe the preprocessed files will be helpful? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug fortran/19334] ISHFT has the wrong type for constant values
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-09 15:36 --- Subject: Re: ISHFT has the wrong type for constant values pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:29 --- int1 C.454 = 0_S8; The 8 is where the problem is, it is just plainly wrong, it should be 1. 8 bits, unless I'm completely mistaken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19334
[Bug fortran/15553] Array copy operation produces garbage
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-07 11:19 --- Subject: Re: Array copy operation produces garbage Thomas dot Koenig at online dot de wrote: --- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07 10:37 --- (In reply to comment #8) Still fails on i686-pc-linux: Is this something that should be put into the test suite, so it is possible to get a better overview of when and on which machines this fails? gcc's policy is no known failures in the testsuite, so I'm afraid this is not possible. I do think this is a good idea, but only to the extent that other people's development work is not interfered with by spurious testsuite FAILs / XPASSes, which is inevitable in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-21 00:04 --- Subject: Re: Gfortran produces wrong output (c/f to g77) Deji Akingunola wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2004-12-20 22:40 --- The problem is an out-of-bounds array access to sa, note its dimensions and the values the loop index takes on. I'm sorry I don't get the above, what do you mean by 'out-of-bound array access to sa' (what's sa). I wonder why it's tagged invalid while other compilers does successfully execute the same code. Does it mean one has to pass some special options to gfortran to produce the right result. Thanks. The code has a bug. It's not gfortran's fault that it doesn't work with gfortran. 'sa' is an array in that code. It is accessed out of bounds in the loop of the main program. This is caught at runtime, if the code is compiled with '-fbounds-check'. The problem only appears on i686 by hazard. 'The code works if compiled with other compilers' doesn't mean 'the code is correct and bug-free', unfortunately. If you're still not convinced, lean back, look at the following five lines of code (which are extracted from your testcase), and try to figure out what the code means for all possible values of 'i'. parameter(n=8) real sa(n) do 20,i=1,2*n-1,2 sa(i)=a(i)**2+a(i+1)**2 20 continue Regards, - Tobi ps I think you really want that loop to look like do i=2, 2*n, 2 sa(i/2) = a(i-1)**2 + a(i)**2 end do or something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-15 12:30 --- Subject: Re: opening unit 6 messes up print Thomas dot Koenig at online dot de wrote: My thinking is that writing to * (or PRINTing) should go to standard output, and that unit 6 just happens to be a convention for a preconnected unit that does the same thing. I really don't think this is worth doing, as we have the evironment variable I pointed you to. So if the user really does want to use unit 6 for some other purposes than stdout, he is free to do so, and so the status quo doesn't prevent anybody from doing anything. I also think that it is a good thing that there's a way of redirecting * output to a file: say, the user wants to do something like: read *, print_to_file if (print_to_file) then open(6,file=stdout) end if Is this possible with ifort? - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-12 18:53 --- Subject: Re: set_exponent breaks with integer*8 exponent dje at gcc dot gnu dot org wrote: --- Additional Comments From dje at gcc dot gnu dot org 2004-12-12 17:38 --- The patch fixes the problem on big-endian systems. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug fortran/17175] set_exponent breaks with integer*8 exponent
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-12-10 13:48 --- Subject: Re: set_exponent breaks with integer*8 exponent paulthomas2 at wanadoo dot fr wrote: --- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-10 13:35 --- You have fixed this one, haven't you? cvs 20041205 runs it fine. I don't think so, maybe it's got hidden by another change. However, in testing, I found another nasty: y = 1/2 + 1/8 !y= 0.125 + 0.5 !!works OK 1/2 .EQ. 0 in Fortran, same for 1/8, this is integer division :-) - Tobi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17175
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-11-05 11:20 --- Subject: Re: spurious warnings with -W -Wunused martin at mpa-garching dot mpg dot de wrote: --- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-05 08:31 --- Since the patch has been approved (http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02547.html), could someone please commit it? Or is it better to wait for the complete fix? I hope to get there today, I've had very little time for gfortran work recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug fortran/17918] gfortran .mod files have unusual entries about private common blocks
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-10-11 16:25 --- Subject: Re: gfortran .mod files have unusual entries about private common blocks [ I've added the bug database to the CC list again, this way this discussion will be archived somewhere and can be referenced ] Konstantin Olchanski wrote: Tobi, I understand how Fortran (=77) common blocks work, but your desription of Fortran-90+ common blocks puzzles me. Our code is written like this: foo.cmn: common /foo/ blah... module a include foo.cmn end module a module b use a include foo.cmn end module b module c use b include foo.cmn end module c Somewhere between module b and c, the current gfortran becomes confused and generates bogus errors about size mismatches between common blocks and invalid variables from the common block. Absoft, Intel and PathScale compilers accept our code, so I think it is valid Fortran-90. gfortran barfs, so I assume it is wrong (in a democratic way). This is wrong code, the other compilers are wrong. I only have the draft Fortran 95 standard, but since this restriction also appears in F2K (as Constraint C590) I'm sure this will also be in the final Fortran 95 standard. What it says is this (eliding irrelavant stuff, pp22,23): R550 common-block-object is variable name [ ... ] ... Constraint: A variable-name shall not be a name made accessible by use association. Now, due to your multiple including of the same common line, the same name reappears again and again in a common block, even though it's use associated. This is the violation of the standard I was referring to. Actually, after writing this, and double checking the quote in a book which reproduces the Fortran 90 standard, I see that Fortran 90 doesn't seem to have this connstraint. So maybe the other compilers will refuxe it in some kind of strict mode. But I still disblieve you theory that common blocks belogn inside a module. In the above example, the one common block should be in which module? How will this common block be shared with g77, C and C++ compiled code? No, that's not what I'm saying. The thing about common blocks is that they're _not_ in modules. We have to record them to know where in memory a variable will be found -- remember that common storage works differently from other storage. A common variable is replaced to an offset into a common storage, which carries the name of the respective common block. (read on) Say, if you have module m common /s/ x, y private x end module use m common /s/ a, b y = 2. print *,b end This program should print 2.. This is why we need the information about x being in the common block in the main program. (I'm not completely sure if symbols which are in a common may be public, and I will verify this, but you get the point). This is not how Fortran compilers traditionally work. They save no information about the internal structure of the common block- only the name and size. Indeed, and we record the size by recording the objects that are stored in the common block. Common block are layouted way after module files have been written, and this way the frontend needs no knowledge about how memory is layout in the backend (well, it needs some knowledge to get equivalences right, but that's not the point), for instance your common block can look quite different if derived types are packed or not. If you have mismatching definitions of common blocks between source files, you may get a linker warning (global s size mismatch) (older linkers did not complain) and you may see interesting effects on variable values. Most of the time, these are bugs (that is why most programs define common blocks in header files), but I have seen (ugly) code where it is done on purpose. Indeed, but when you put common blocks in a module the compiler can do better. Please note that in module m common /c/ i, j private i end module use m i = 4 end The variable i set in the main program will be a local variable, not the variable in the common block, so we get that right. If we add common /c/ x, k j = 2 print *, k to the main program, the compiler needs to know that j is one storage unit into the common block, and therefore it needs to know more about the common block than just its size. The problem you're seeing is that gfortran is quite strict about the standard, and about where common blocks are allowed. It is not wrong (at least wrt to these things, and the bugs I thought I had found yesterday were actually bugs on my side, so I'm quite confident that we get it right) If Fortran 90 code like yours is something we'd like to support (I'm guessing you'd want that :-) we can reopen the bug, mark it enhancement, and maybe add a comment which only contains the things I said about Fortran 90 above, to make it easier to see why it has been reopenened. P.S. With the two patches (modules/commons and blah_conv_ref_blah
[Bug fortran/15326] ICE with assumed length character strings
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2004-10-10 21:08 --- Subject: Re: ICE with assumed length character strings tobi at gcc dot gnu dot org wrote: If the function D from the testcase is declared external, with no interface, we hit the same assertion as without the patch. Ugh, messed up when editing. This is meant to read: If the function D from the testcase is external, not contained, we hit the same assertion as without the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326
