[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-03-03 21:49 --- Subject: Re: COMPLEX function returns incompatible with g77 On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote: BTW I will also propose a patch to make -fno-second-underscore the default, once this is fixed. I'm confused...shouldn't it be one or the other? i.e. either make -ff2c -fsecond-underscore the default, compatible with g77, *or* make -fno-f2c -fno-second-underscore the default, incompatible with g77 but free of f2c cruft. I would vote for the former, simply because compatibility with g77 by default has huge practical advantages for library distributors that seem (to me) to outweigh the aesthetic benefits of removing f2c cruft. (Making -fno-second-underscore the default does have the non-aesthetic practical advantage of better compatibility with non-GNU compilers, but the GNU project has traditionally placed a higher priority on compatibility with free software than with non-free software.) Steven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-03-04 04:44 --- Subject: Re: COMPLEX function returns incompatible with g77 On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote: I agree with you that -ff2c should imply -fsecond-underscore. I don't agree that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that -fno-f2c should be the default. Just to be clear, what exactly do you feel are the concrete practical advantages to -ff2c? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-03-04 04:46 --- Subject: Re: COMPLEX function returns incompatible with g77 Just to be clear, what exactly do you feel are the concrete practical advantages to -ff2c? (Sorry, I mean -fno-f2c. The practical advantages to backwards compatibility are obvious.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:28 --- Subject: Re: COMPLEX function returns incompatible with g77 I confirm that it works when you compile arg1.f with -fno-f2c: g77 -fno-f2c -c arg1.f gfortran arg1tst.f arg1.o -o arg1tst ./arg1tst ( 4.00, 6.00) However, this doesn't really alter the basic question of why you are changing the default calling conventions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:44 --- Subject: Re: COMPLEX function returns incompatible with g77 On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote: Well chaning to be more target's C like (because that is what gfortran uses now) ABI. If you're breaking backwards ABI compatibility anyway, which does not seem like a decision to take lightly, clean up everything at once. e.g. you want to get rid of f2c cruft, why not make -fno-second-underscore the default as well? (Despite the gcc manual's claims, no non-GNU compilers that I know of append 2 underscores to external names with underscores, at least any more. Almost all of them, e.g. SGI, Intel ifc, Portland, Tru64, ..., append a single underscore in all cases. IBM xlf and HP/UX append no underscores at all.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From stevenj at fftw dot org 2005-02-23 20:46 --- Subject: Re: COMPLEX function returns incompatible with g77 On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote: And gfortran is totally new front-end, written from scratch. Obviously. That doesn't mean that the rest of the world ceases to exist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From stevenj at fftw dot org 2005-02-23 23:17 --- Subject: Re: cannot mix C and Fortran I/O On Wed, 23 Feb 2005, Thomas dot Koenig at online dot de wrote: Add fflush(stdout); at the end of cio.c, and things work as expected. This is a workaround, but it would be nice to be able to mix C and Fortran code with I/O more seamlessly. Is putting an fflush into a few strategic places in libgfortran that expensive that it overwhelms the benefit of seamless integration with stdio? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug pending/19514] bogus warning about complex integer types from typedef
--- Additional Comments From stevenj at fftw dot org 2005-01-18 22:56 --- Subject: Re: bogus warning about complex integer types from typedef On Tue, 18 Jan 2005, joseph at codesourcery dot com wrote: typedef double R; typedef R _Complex C; This is not valid code; you can't use _Complex together with a typedef, only together with float, double or long double in one of the forms listed in C99. My copy of the C99 draft standard states (sec. 6.7.7): A typedef declaration does not introduce a new type, only a synonym for the type so specified. According to this, R complex should be a synonym for double complex, and therefore should be valid code. What justification do you have for claiming otherwise? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
[Bug pending/19514] bogus warning about complex integer types from typedef
--- Additional Comments From stevenj at fftw dot org 2005-01-18 23:15 --- Subject: Re: bogus warning about complex integer types from typedef Okay, I guess I see what you mean. double in double _Complex is arguably not a type, but rather a type-specifier as defined in 6.7.2, and the each list of type-specifiers shall be one of the following sets, a prescribed list of combinations that does not include typedefs. What an annoyance; one has to define R via the preprocessor, then, in order to use consistent floating-point precisions everywhere in a program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19514
