Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
IMO, anybody who uses -mrtd (with or without decorations) is asking for trouble. Unless you are planning to use a gfortran dll in a VisualBasic app, I can see little reason to change from the default "C" calling convention. That precise reason is, as far as I understand, important for some people. Fortran code is used for internal routines, built into shared libraries that are later plugged into commercial apps. How hard do you think it would be to implement a -mrtd-naming option (or another name) to go with -mrtd and add name decorations? FX
Building gcc trunk on Darwin / Intel?
Hi All, I'm new to this and searched Google and the mailing lists a bit before posting this. I'm not subscribed to this list, so I'd appreciate it if whoever answered CCed me directly. I tried building gcc trunk on Darwin / Intel: imac20:/datal/gcc_build mohanembar$ uname -a Darwin imac20.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 (OS X 10.4.8) ...with this build compiler: imac20:/datal/gcc_build mohanembar$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ...which is what came with Xcode 2.4.1 (I believe). I configure like this: /datal/gcc/gcc/configure --build=i686-apple-darwin8 --target=i686-apple-darwin8 \ --disable-static --enable-shared --disable-multilib --disable-checking --disable-gconf-peer \ --disable-plugin --prefix=/datal/gcc/i686-apple-darwin \ --enable-languages=c,java,objc --with-gmp=/opt/local --with-mpfr=/opt/local ...where gmp and mpfr were obtained and installed via DarwinPorts. I haven't built any special version of odcctools since I assumed that they would be up-to-date enough with this Xcode. When I do a make, I get: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o build/errors.o ../build-i686-apple-darwin8/libiberty/libiberty.a build/gengtype /datal/gcc/gcc/gcc/config/i386/darwin.h:244: unterminated comment or string; unexpected EOF make[3]: *** [s-gtype] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 Any clues? Thanks in advance. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/
Re: Building gcc trunk on Darwin / Intel?
On Mar 10, 2007, at 6:43 AM, Mohan Embar wrote: I tried building gcc trunk on Darwin / Intel: /datal/gcc/gcc/gcc/config/i386/darwin.h:244: unterminated comment or string; unexpected EOF You should be able to update and build now... Let us know if not.
Quick FUNCTION_MODE doco query
--
http://gcc.gnu.org/onlinedocs/gccint/Misc.html#Misc
- Macro: FUNCTION_MODE
An alias for the machine mode used for memory references to functions
being called, in call RTL expressions. On most machines this should be QImode.
--
Was this description perhaps written in pre-RISC days? Is it not correct to
use SImode on a RISC machine where all instructions are always 4-aligned? (A
quick grep suggests that of current backends, 7 use Pmode, 3 HImode, 17 QImode
and 8 SImode). It looks to me like it should be a mode that has the same
alignment as the smallest addressable instruction, no? Would the below be a
more accurate description?
@defmac FUNCTION_MODE
An alias for the machine mode used for memory references to functions
being called, in @code{call} RTL expressions. On most CISC machines,
where an instruction can begin at any byte address, this should be
@code{QImode}; on RISC machines, where all instructions are word-sized
and aligned, this should be a mode with the same size and alignment as
the machine instruction words - @code{SImode} for 32-bit processors, or
perhaps @code{HImode} for such machines as the ARM cpu in Thumb mode,
which uses 16-bit instructions.
@end defmac
If so I'll send a patch+changelog to the patches list.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Quick FUNCTION_MODE doco query
> @defmac FUNCTION_MODE
> An alias for the machine mode used for memory references to functions
> being called, in @code{call} RTL expressions. On most CISC machines,
> where an instruction can begin at any byte address, this should be
> @code{QImode}; on RISC machines, where all instructions are word-sized
> and aligned, this should be a mode with the same size and alignment as
> the machine instruction words - @code{SImode} for 32-bit processors, or
> perhaps @code{HImode} for such machines as the ARM cpu in Thumb mode,
> which uses 16-bit instructions.
> @end defmac
I think the last sentence just adds more confusion than value. Maybe:
[...]. On most RISC machines, where all instructions have fixed sized and
alignment, this should be a mode with the same size and alignment as the
machine instruction words - Typically @code{SImode} or @code{HImode}.
Paul
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Danny Smith writes: >Unless you are planning to use a gfortran dll in a VisualBasic app, I >can see little reason to change from the default "C" calling convention FX Coudert writes: >That precise reason is, as far as I understand, important for some >people. Fortran code is used for internal routines, built into shared >libraries that are later plugged into commercial apps. Well, perhaps things are different in Fortran, but the big problem with using -mrtd in C/C++ is that it changes the default calling convention for all functions, not just those that are ment to be exported. While most of MinGW's of headers declare the calling convention of functions explictily, not all of them do. >How hard do you think it would be to implement a -mrtd-naming option >(or another name) to go with -mrtd and add name decorations It wouldn't be too hard, but I don't think it would be a good idea to implement. It would mislead people into thinking the option might be useful, and -mrtd fools enough people as it is. Adding name decorations won't make it more useful. From the examples I've seen, VisualBasic 6 has no problem DLL functions expored without "@n" suffixes. Any library that needs to be able to be called from VisualBasic 6 or some other "stdcall only" environment should explictly declare it's exported functions with the stdcall calling convention. Ross Ridge
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Ross Ridge wrote: > Danny Smith writes: >> Unless you are planning to use a gfortran dll in a VisualBasic app, I >> can see little reason to change from the default "C" calling convention > > FX Coudert writes: >> That precise reason is, as far as I understand, important for some >> people. Fortran code is used for internal routines, built into shared >> libraries that are later plugged into commercial apps. > > > Well, perhaps things are different in Fortran, but the big problem > with using -mrtd in C/C++ is that it changes the default calling > convention for all functions, not just those that are ment to be > exported. While most of MinGW's of headers declare the calling > convention of functions explictily, not all of them do. I think the problem is even bigger in Fortran as the language defines a lot of intrinsic functions, which are implemented in a library (libgfortran). > >How hard do you think it would be to implement a -mrtd-naming option > >(or another name) to go with -mrtd and add name decorations > > Any library that needs to be able to be called from VisualBasic 6 or some > other "stdcall only" environment should explictly declare it's exported > functions with the stdcall calling convention. Thus, if I understood you correctly, you recommend that we add, e.g., pragma support to gfortran with a pragma which adds the __attribute__((stdcall)) to the tree? Tobias
AC_LIBTOOL_WIN32_DLL for libgfortran
Hi all, I've been trying to use tweak the libgfortran build machinery to get it generate a libgfortran.dll on windows systems, but I have no luck. I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is indicated in the autobook and other online resources. but configure (on a cross-compiler from i686-linux to i386-pc-mingw32) still says: checking if libtool supports shared libraries... yes checking if package supports dlls... no checking whether to build shared libraries... no Is there another thing needed to get this support? I admit I'm a bit lost in the gigantic GCC build system, but I thought the target libraries were actually rather... standalone, autoconf-ly speaking. I bet I was wrong. Thanks for any help or hint, FX
Re: AC_LIBTOOL_WIN32_DLL for libgfortran
FX Coudert wrote: > I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before > AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is > indicated in the autobook and other online resources. but configure > (on a cross-compiler from i686-linux to i386-pc-mingw32) still says: Did you put it in the toplevel configure.in or in libgfortran/configure.ac? I suspect it needs to be in the former, because the latter probably shares the same config.cache and thus it won't be checked a second time when running configure for libgfortran. In any case, I think efforts would be better spent helping get a modern libtool into the tree, since the one there now is ancient and I wouldn't be surprised if the mingw/cygwin-specific parts have bitrotted from years of neglect. For example, this AC_LIBTOOL_WIN32_DLL macro was removed/deprecated from libtool three years ago. Brian
RE: Is "FTZ/DAZ for SSE via fast math" available for x86 arch other than Linux?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Zuxy Meng > Sent: Wednesday, 7 March 2007 12:36 a.m. > > I've uploaded a proposed patch for this bug > (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=diff). > Putting > crtfastmath.o in the endfile section of specs causes undefined reference to > memset, so I moved it to the startfile section. Anyone to review this? Quite > trivial anyway. Hello Zuxy, crtfasmath.o is an endfile for a reason. _set_fast_math is run from the .ctors section. It needs to be run before other constructors that might use fastmath, so is made an end ctor (ctors are run from right to left). The reference to memset does not occur on trunk with optimization. It can be avoided with 4.2.0 by adding -minline-all-stringops to rule for (T)crtfastmath.o Danny -- Zuxy
Re: AC_LIBTOOL_WIN32_DLL for libgfortran
In any case, I think efforts would be better spent helping get a modern libtool into the tree, since the one there now is ancient and I wouldn't be surprised if the mingw/cygwin-specific parts have bitrotted from years of neglect. There is effort to get that done, as you can see in the recent (few days ago) thread starting here: http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html Please feel free to step into this other discussion and help/give advice about how achieve this goal. For example, this AC_LIBTOOL_WIN32_DLL macro was removed/deprecated from libtool three years ago. What should be used with a recent libtool? And where is it documented? FX
