Re: Clustering switch cases
On Fri, Aug 27, 2010 at 4:03 PM, Richard Guenther wrote: > > In fact we might want to move switch optimization up to the tree level > (just because it's way easier to deal with there). Thus, lower switch > to a mixture of binary tree & jump-tables (possibly using perfect > hashing). > Doing the optimisation at the tree-level was exactly my initial idea. By splitting the switches at the tree-level, before expand_case, would then allow for expand_case to transform it either to a jump table or binary tree depending on the situation. I will be looking at the patch Rahul posted and will try to see if I can improve on it. -- PMatos
Re: Delivery Status Notification (Failure)
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to the list. FX Le 28 août 2010 à 11:58, Mail Delivery Subsystem a écrit : > Delivery to the following recipient failed permanently: > > bur...@net-b.de > > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the recipient > domain. We recommend contacting the other email provider for further > information about the cause of this error. The error that the other server > returned was: 550 550-Message rejected because mail-ww0-f45.google.com > [74.125.82.45] is > 550-blacklisted at safe.dnsbl.sorbs.net see Currently Sending Spam See: > 550 http://www.sorbs.net/lookup.shtml?74.125.82.45 (state 14). > > - Original message - > > Received: by 10.227.136.69 with SMTP id q5mr1807220wbt.202.1282989502477; >Sat, 28 Aug 2010 02:58:22 -0700 (PDT) > Return-Path: > Received: from [192.168.1.8] (85-170-0-58.rev.numericable.fr [85.170.0.58]) >by mx.google.com with ESMTPS id w29sm3068376weq.42.2010.08.28.02.58.19 >(version=TLSv1/SSLv3 cipher=RC4-MD5); >Sat, 28 Aug 2010 02:58:21 -0700 (PDT) > Subject: Re: __float128 FE patch > References: <4c78c849.8040...@net-b.de> > From: FX > Content-Type: text/plain; charset=utf-8 > In-Reply-To: <4c78c849.8040...@net-b.de> > Date: Sat, 28 Aug 2010 11:34:58 +0200 > Message-Id: <3f3fe742-30aa-4550-a157-4256906c3...@gmail.com> > To: Tobias Burnus > Content-Transfer-Encoding: quoted-printable > Mime-Version: 1.0 (iPod Mail 8A400) > X-Mailer: iPod Mail (8A400) > > Will do tomorrow. For now I have reverted this line of the patch > > FX > > Le 28 août 2010 à 10:26, Tobias Burnus a écrit : > >> Hi FX, >> >> First question: Will you look at Andrew's patch - or should I do it? I fear >> we are going to duplicate work. >> >> Some observerations: >> >> a) Andrew's patch also needs: >> add: >> #undef LANG_HOOKS_REGISTER_BUILTIN_TYPE >> after: >> #undef LANG_HOOKS_GET_ARRAY_DESCR_INFO >> in f95-lang.c >> >> b) gfc_register_builtin_type >> - TREE_TYPE (complex_float128_type_node) = scalar_type; >> + TREE_TYPE (complex_float128_type_node) = type; >> >> c) trans-types.c still mentions -fsoft-float. >> >> d) It then compiles but segfault in float128_1.f90: >> >> ==27126== Invalid read of size 8 >> ==27126==at 0x5CEE82: build_call_expr_loc_array (builtins.c:10731) >> ==27126==by 0x5CF3DA: build_call_expr_loc (builtins.c:10764) >> ==27126==by 0x58EA74: gfc_conv_intrinsic_function >> (trans-intrinsic.c:1098) >> ==27126==by 0x582882: gfc_conv_function_expr (trans-expr.c:3872) >> ==27126==by 0x57C359: gfc_trans_assignment_1 (trans-expr.c:5592) >> ==27126==by 0x583089: gfc_trans_assignment (trans-expr.c:5766) >> ==27126==by 0x55A495: trans_code (trans.c:1098) >> ==27126==by 0x576211: gfc_generate_function_code (trans-decl.c:4641) >> ==27126==by 0x51EF07: gfc_parse_file (parse.c:4229) >> ==27126==by 0x5559F7: gfc_be_parse_file (f95-lang.c:243) >> ==27126==by 0x849528: toplev_main (toplev.c:971) >> ==27126==by 0x5FF7B7C: (below main) (in /lib64/libc-2.11.2.so) >> >> Tobias
Re: Delivery Status Notification (Failure)
FX wrote: Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to the list. I have not seen any emails since 9:53 (CEST) at fortran@ - neither directly nor via gcc.gnu.org/ml/fortran. Le 28 août 2010 à 11:58, Mail Delivery Subsystem a écrit : Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Message rejected because mail-ww0-f45.google.com [74.125.82.45] is 550-blacklisted at safe.dnsbl.sorbs.net see Currently Sending Spam See: 550 http://www.sorbs.net/lookup.shtml?74.125.82.45 (state 14). That's a stupid anti-spam measure of my provider. I think I am going to change the provider / mail service. Not even delisting seems to be possible without paying $50 (not to the provider but to the SORBS service) - and my provider refuses to disable the service. It even blocked me once (the dynamic IP was blocked) - because someone else was sending spam 2 years ago ... reconnecting (new IP) worked in that case - as did delisting (after several hours). Will do tomorrow. For now I have reverted this line of the patch Le 28 août 2010 à 10:26, Tobias Burnus a écrit : First question: Will you look at Andrew's patch - or should I do it? I fear we are going to duplicate work. OK. Thus, I either work on it today or leave it to you. Tobias PS: You could use my university address (cf. CC list), which hopefully works.
Problems with upstream versions of gmp, mpfr, and mpc [Was: Bug in Build System of gcc-4.5.1? Cannot Find libmpc.so.2]
[ Redirect to gcc. This is a dev issue. ] On 08/27/2010 10:39 PM, Tom Browder wrote: >> On Fri, Aug 27, 2010 at 09:17, Andrew Haley wrote: >>> However, just running download_prerequisites is, IMVHO, the only sane way >>> to do it. > > That's the solution I used, and I got a good build--thanks for the tip, > Andrew. > > I think what we have here is a gcc dependence on specific versions of > gmp, mpfr, and mpc--more than is indicated in the installation > instructions. I have used later versions of all of them and they > cause interdependency problems of all sorts with later rerequisites. I'm very sceptical about "or any later version" instructions when building the gcc prerequisites. In practice this can never be certain to work, because the upstream maintainers of these tools can change them in ways that break gcc. Somehow, we need to keep an eye on these issues so that if a new version of a library changes in a way that breaks the gcc build we notice. But I don't think we have any mechanism to do that at present. Andrew.
Re: Optimization Switches
On Friday 27 August 2010 06:07 AM, Paul Brook wrote: Hi, I wish to selectively enable specific optimizations to observe its effect on the source. My project requires me to do this analysis. It seemed, the -f* flags would enable me to do that. But it turns out that individual optimizations can't be enabled like that, and all the optimizations at a specific level gets enabled when I use a -Ox switch. This faq at http://gcc.gnu.org/wiki/FAQ#optimization-options, says this too. So here are my two questions : a) Is there any way to observe the effect of a particular optimization, without the obvious option of using a lot of -fno switches. b) And do the -f* switches serve any purpose, if I can't enable individual optimizations using them. I suspect that in practice that this isn't a particularly interesting question. Optimizations often interact with each other in complex ways, with the end result being significantly different to the naive sum of their parts. Paul This is precisely what I want, segregating the effect of every single optimization. :) -- Sharjeel
Re: Optimization Switches
On Thursday 26 August 2010 11:02 PM, Jonathan Wakely wrote: On 26 August 2010 12:56, wrote: a) Is there any way to observe the effect of a particular optimization, without the obvious option of using a lot of -fno switches. b) And do the -f* switches serve any purpose, if I can't enable individual optimizations using them. You need an optimisation option, -Ox, to enable optimisations, but you don't have to use -O2 to get optimisations that are normally enabled by -O2, e.g. -O1 -fstrict-aliasing will enable strict aliasing. So to answer the first question, use -O1, turn off the O1 optimisations you don't want, and selectively enable the ones you do want. Thanks a lot.
Re: Problems with upstream versions of gmp, mpfr, and mpc [Was: Bug in Build System of gcc-4.5.1? Cannot Find libmpc.so.2]
> I'm very sceptical about "or any later version" instructions when > building the gcc prerequisites. In practice this can never be certain > to work, because the upstream maintainers of these tools can change > them in ways that break gcc. Indeed, on the SPARC we seem to have problems (miscompilations: fortran/45277, target/45363, c/45407) with any newer versions of GMP/MPFR/MPC. So I'm going to add a blurb to the platform-specific instructions about that. > Somehow, we need to keep an eye on these issues so that if a new > version of a library changes in a way that breaks the gcc build we > notice. But I don't think we have any mechanism to do that at > present. Yes, I think we should have recommended versions for the 3rd party libraries. -- Eric Botcazou
Re: Guidance needed: hi-level steps to track an object until its destruction
On Thu, 2010-08-26 at 18:16 -0700, Jeff Saremi wrote:
> I'm hoping someone here could take the time to outline what I need to do (i'm
> not looking for code but if you point me to some i'd appreciate it).
>
> I'd like to track an object from the it's created until it's destroyed (in
> C++). And then see if a certain method of it is called or not. To keep it
> short we can limit this to one function at the beginning of which an object
> gets created and at the end of it the object goes out of scope.
> And i'm guessing this can be done via one a pass at the right time. I guess
> before gimplification or being converted to RTL and such.
I am not sure that is easily feasible. I would believe it is impossible.
Within the compiler (or inside a GCC plugin, or inside a GCC extension
coded in MELT), you probably are able change/inspect C++ classes & every
other declaration any compiler is tracking. You are also able to find
every occurrence of variables containing a pointer to such classes.
However, you are apparently willing to track a single *instance* of such
a class, and this instance is in the execution of the compiled program
[not inside the compiler]. This means that you are able to deal with all
the aliasing & pointer equivalence issues (a task known to be
impossible). How can the compiler surely know that pointer p in [a
particular instruction of] method YourClass::foo() is never (or
sometimes, or always) pointing to the same instance -in the running
process of the compiled program- as pointer q in method yourclass::bar()
Or perhaps my English is so weak that I misunderstood you. If that is
the case, apologies.
Or maybe you want to instrument your compiler so that for every code
emitted for method yourclass::gee() you add a first block which checks
that the this reciever is not a given pointer.
In other words & C++ parlance, you could (this is doable, but not
trivial) hack the compiler so that at the start of every method (i.e.
member function in C++) the equivalent of the following C++ code has
been magically added
extern "C" YourClass* hunted_yourclass_pointer;
extern "C" void some_error_routine(void);
if (this == hunted_yourclass_pointer)
some_error_routine();
But I am not sure you want to do that.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Guidance needed: hi-level steps to track an object until its destruction
Basile,
you fully understood what I was asking. And I think I understood that I may
have to rethink what I wanted to do since the effort is seemingly out-weighing
the benefits.
thanks again.
jeff
--- On Sat, 8/28/10, Basile Starynkevitch wrote:
> From: Basile Starynkevitch
> Subject: Re: Guidance needed: hi-level steps to track an object until its
> destruction
> To: "Jeff Saremi"
> Cc: gcc@gcc.gnu.org
> Received: Saturday, August 28, 2010, 1:05 PM
> On Thu, 2010-08-26 at 18:16 -0700,
> Jeff Saremi wrote:
> > I'm hoping someone here could take the time to outline
> what I need to do (i'm not looking for code but if you point
> me to some i'd appreciate it).
> >
> > I'd like to track an object from the it's created
> until it's destroyed (in C++). And then see if a certain
> method of it is called or not. To keep it short we can limit
> this to one function at the beginning of which an object
> gets created and at the end of it the object goes out of
> scope.
> > And i'm guessing this can be done via one a pass at
> the right time. I guess before gimplification or being
> converted to RTL and such.
>
>
> I am not sure that is easily feasible. I would believe it
> is impossible.
>
> Within the compiler (or inside a GCC plugin, or inside a
> GCC extension
> coded in MELT), you probably are able change/inspect C++
> classes & every
> other declaration any compiler is tracking. You are also
> able to find
> every occurrence of variables containing a pointer to such
> classes.
>
> However, you are apparently willing to track a single
> *instance* of such
> a class, and this instance is in the execution of the
> compiled program
> [not inside the compiler]. This means that you are able to
> deal with all
> the aliasing & pointer equivalence issues (a task known
> to be
> impossible). How can the compiler surely know that pointer
> p in [a
> particular instruction of] method YourClass::foo() is never
> (or
> sometimes, or always) pointing to the same instance -in the
> running
> process of the compiled program- as pointer q in method
> yourclass::bar()
>
> Or perhaps my English is so weak that I misunderstood you.
> If that is
> the case, apologies.
>
> Or maybe you want to instrument your compiler so that for
> every code
> emitted for method yourclass::gee() you add a first block
> which checks
> that the this reciever is not a given pointer.
>
> In other words & C++ parlance, you could (this is
> doable, but not
> trivial) hack the compiler so that at the start of every
> method (i.e.
> member function in C++) the equivalent of the following C++
> code has
> been magically added
>
> extern "C" YourClass* hunted_yourclass_pointer;
> extern "C" void some_error_routine(void);
>
> if (this == hunted_yourclass_pointer)
> some_error_routine();
>
> But I am not sure you want to do that.
>
> Cheers.
> --
> Basile STARYNKEVITCH
> http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile:
> +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes}
> ***
>
>
Re: Problems with upstream versions of gmp, mpfr, and mpc [Was: Bug in Build System of gcc-4.5.1? Cannot Find libmpc.so.2]
On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou wrote: >> I'm very sceptical about "or any later version" instructions when >> building the gcc prerequisites. In practice this can never be certain >> to work, because the upstream maintainers of these tools can change >> them in ways that break gcc. > > Indeed, on the SPARC we seem to have problems (miscompilations: fortran/45277, > target/45363, c/45407) with any newer versions of GMP/MPFR/MPC. So I'm going > to add a blurb to the platform-specific instructions about that. Wouldn't it be worthwhile to push fixes upstream? Granted, doing so for GMP is a Herculean task, but it's important to make sure that dependencies stay working, even past the minimum requirement version.
Re: Problems with upstream versions of gmp, mpfr, and mpc [Was: Bug in Build System of gcc-4.5.1? Cannot Find libmpc.so.2]
On Sat, Aug 28, 2010 at 12:43, NightStrike wrote: > On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou wrote: >>> I'm very sceptical about "or any later version" instructions when >>> building the gcc prerequisites. In practice this can never be certain >>> to work, because the upstream maintainers of these tools can change >>> them in ways that break gcc. I have had pretty good luck now by using the contributed script "http://gcc.gnu.org/svn/gcc/trunk/contrib/download_prerequisites"; suggested to me by Andrew Haley. That, IMHO, should be on the gcc build instructions page with a link to the script and instructions to run it in the unpacked gcc sources directory. That should minimize build problems for released versions. Regards, -Tom Thomas. M. Browder, Jr. Niceville, FL USA
gcc-4.6-20100828 is now available
Snapshot gcc-4.6-20100828 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100828/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 163620 You'll find: gcc-4.6-20100828.tar.bz2 Complete GCC (includes all of below) MD5=fa83aadbb877673d696fd655c437e231 SHA1=c228b4194884515d5c8b09e3e8668960fda83a4d gcc-core-4.6-20100828.tar.bz2C front end and core compiler MD5=013b0051e2dd0e89662f0b672308c2df SHA1=afd79bc98dd41b6e14f0686dcd3969d8736fe4a9 gcc-ada-4.6-20100828.tar.bz2 Ada front end and runtime MD5=592e406a562a023a11161d9490a5365d SHA1=44f5dba5d45f21c5615774c5ac8d0d4849cad33e gcc-fortran-4.6-20100828.tar.bz2 Fortran front end and runtime MD5=71946663294c951e25ba0459cc87c002 SHA1=1a8cbcd1b9eac8f642ce0a61fb23f0865bcb0c6b gcc-g++-4.6-20100828.tar.bz2 C++ front end and runtime MD5=496696ea38ba36867d9ee3eb61ae8057 SHA1=7119c6a33e5bf2acf595a9e28875409a590c95f9 gcc-java-4.6-20100828.tar.bz2Java front end and runtime MD5=f1b3c6e714abc8f3eeaf1082421ff5af SHA1=a9e3154f7c8f53d21ccc837b01ce307050a6cadc gcc-objc-4.6-20100828.tar.bz2Objective-C front end and runtime MD5=dc2ec165c2298a9dedcaa61efe157bf2 SHA1=11a8d660d21e314a840b3a23d22fc7ef9d54f6ed gcc-testsuite-4.6-20100828.tar.bz2 The GCC testsuite MD5=a63365d553f871b02fdc6fa6b396f837 SHA1=a77b8065ababb717d439a7036aaa35cfbd12d383 Diffs from 4.6-20100821 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
For testing: full __float128 patch
Before I submit it officially for review, I want this patch to get some exposure while I clean up a few remaining dusty corners. To test the patch on x86_64-linux, proceed as follows: -- Get libquad from http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 , then ./configure --prefix=/foo && make && make install -- Build GCC with the extra configure argument: --with-quad=/foo (to be given to the toplevel configure command, like --with-gmp, nothing fancy) Things to test in particular: -- I've tested this on linux and Mac OS; although it's pretty much OS-insensitive, does it work on things like FreeBSD and Windows? -- check carefully I/O support; in particular, the "output formatting" (i.e. writing out the values) involves a wrapper of my own around the gdtoa code, which was a bit painful to write, so bugs might have crawled in there Things that do not yet work, or may change: -- this is only for platform that support __float128 (targets without TFmode would break); I'm working on an updated front-end patch as proposed by Andrew and Tobias -- I realized that the exponentiation builtins are not properly handled by the front-end (all exponentiations involving __float128 or its complex counterpart give wrong code); I'll work on a fix -- Array intrinsics *do not work at all*. This is a limitation of the array descriptor structure, which I cannot overcome by myself. The current patch only changes these files (in_pack_generic.c, in_unpack_generic.c, pack_generic.c, spread_generic.c, unpack_generic.c, cshift0.c) to make them compile, but they will yield wrong results. -- the integration of libquad depends on how the discussion with the SC turns out; the current scheme is not nice at all in case of multilibs, see below Please note: in case of a multilib build, unless you have a system which supports fat libraries (MacOS), only the variant that corresponds to the libquad you've built will have support enabled. Typically, on a x86_64 system where you've built libquad with the default 64-bit compiler, you'll only have libquad support in the -m64 variant of libgfortran, and not the -m32 variant. All comment are of course welcome. I think the two preliminary commits allowed to keep the size of this final patch to a reasonable value under 1kLOC (less than 600 without regenerated files). FX full_testing.diff Description: Binary data
Re: For testing: full __float128 patch
On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote: > Before I submit it officially for review, I want this patch to get some > exposure while I clean up a few remaining dusty corners. To test the patch on > x86_64-linux, proceed as follows: > > -- Get libquad from http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 > , then ./configure --prefix=/foo && make && make install > -- Build GCC with the extra configure argument: --with-quad=/foo (to be > given to the toplevel configure command, like --with-gmp, nothing fancy) > > Things to test in particular: > > -- I've tested this on linux and Mac OS; although it's pretty much > OS-insensitive, does it work on things like FreeBSD and Windows? > -- check carefully I/O support; in particular, the "output formatting" > (i.e. writing out the values) involves a wrapper of my own around the gdtoa > code, which was a bit painful to write, so bugs might have crawled in there > > On i386-*-freebsd, ./configure --prefix=$HOME/work gmake ... -O2 -MT libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c -o libgfortran_io.lo libgfortran_io.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c libgfortran_io.c -fPIC -DPIC -o .libs/libgfortran_io.o In file included from libgfortran_io.c:1: quad.h:8: error: unable to emulate 'TC' quad.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'acosq' quad.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'acoshq' quad.h:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'asinq' quad.h:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'asinhq' quad.h:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atanq' quad.h:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atanhq' quad.h:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atan2q' quad.h:19: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cbrtq' quad.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ceilq' quad.h:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'copysignq' quad.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'coshq' quad.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cosq' quad.h:24: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'erfq' quad.h:25: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'erfcq' quad.h:26: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'expq' quad.h:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'expm1q' quad.h:28: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'fabsq' quad.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'floorq' quad.h:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'fmodq' quad.h:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'frexpq' quad.h:33: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'hypotq' quad.h:34: warning: parameter names (without types) in function declaration quad.h:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'j0q' quad.h:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'j1q' quad.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'jnq' quad.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ldexpq' quad.h:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'lgammaq' quad.h:41: warning: parameter names (without types) in function declaration quad.h:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'logq' quad.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'log10q' quad.h:44: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'log1pq' quad.h:45: warning: parameter names (without types) in function declaration quad.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'modfq' quad.h:47: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nanq' quad.h:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nextafterq' quad.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'powq' quad.h:50: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'remainderq' quad.h:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rintq' quad.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'roundq' quad.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'scalblnq' quad.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'scalbnq' quad.h:56: error: expected ')' before '*' token quad.h:57: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sinhq' quad.h:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sinq' quad.h:59:
Re: For testing: full __float128 patch
On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote: > On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote: > > Before I submit it officially for review, I want this patch to get some > > exposure while I clean up a few remaining dusty corners. To test the patch > > on x86_64-linux, proceed as follows: > > > > -- Get libquad from > > http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 , then ./configure > > --prefix=/foo && make && make install > > -- Build GCC with the extra configure argument: --with-quad=/foo (to be > > given to the toplevel configure command, like --with-gmp, nothing fancy) > > > > Things to test in particular: > > > > -- I've tested this on linux and Mac OS; although it's pretty much > > OS-insensitive, does it work on things like FreeBSD and Windows? > > -- check carefully I/O support; in particular, the "output formatting" > > (i.e. writing out the values) involves a wrapper of my own around the gdtoa > > code, which was a bit painful to write, so bugs might have crawled in there > > > > > > On i386-*-freebsd, > > ./configure --prefix=$HOME/work > gmake > ... > > -O2 -MT libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c -o > libgfortran_io.lo libgfortran_io.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT libgfortran_io.lo > -MD -MP -MF .deps/libgfortran_io.Tpo -c libgfortran_io.c -fPIC -DPIC -o > .libs/libgfortran_io.o > In file included from libgfortran_io.c:1: > quad.h:8: error: unable to emulate 'TC' gcc, here, is the FreeBSD system compiler. gcc (GCC) 4.2.1 20070719 [FreeBSD] If I set my path to include ~/work/bin (where the 4.6.0 gcc lives) as the first directory to search, libquad builds fine. So, what is the minimum required gcc version needs to build libquad? -- Steve
Re: For testing: full __float128 patch
On Sat, Aug 28, 2010 at 05:56:57PM -0700, Steve Kargl wrote: > On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote: > > On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote: > > > Before I submit it officially for review, I want this patch to get some > > > exposure while I clean up a few remaining dusty corners. To test the > > > patch on x86_64-linux, proceed as follows: > > > > > > -- Get libquad from > > > http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 , then ./configure > > > --prefix=/foo && make && make install > > > -- Build GCC with the extra configure argument: --with-quad=/foo (to be > > > given to the toplevel configure command, like --with-gmp, nothing fancy) > > > > > > Things to test in particular: > > > > > > -- I've tested this on linux and Mac OS; although it's pretty much > > > OS-insensitive, does it work on things like FreeBSD and Windows? > > > -- check carefully I/O support; in particular, the "output formatting" > > > (i.e. writing out the values) involves a wrapper of my own around the > > > gdtoa code, which was a bit painful to write, so bugs might have crawled > > > in there > > > > > > > > > > On i386-*-freebsd, > > > > ./configure --prefix=$HOME/work > > gmake > > ... > > > > -O2 -MT libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c -o > > libgfortran_io.lo libgfortran_io.c > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT > > libgfortran_io.lo -MD -MP -MF .deps/libgfortran_io.Tpo -c libgfortran_io.c > > -fPIC -DPIC -o .libs/libgfortran_io.o > > In file included from libgfortran_io.c:1: > > quad.h:8: error: unable to emulate 'TC' > > gcc, here, is the FreeBSD system compiler. > gcc (GCC) 4.2.1 20070719 [FreeBSD] > > If I set my path to include ~/work/bin (where the 4.6.0 gcc lives) > as the first directory to search, libquad builds fine. So, what > is the minimum required gcc version needs to build libquad? > laptop:kargl[246] setenv | grep LD LD_LIBRARY_PATH=/usr/home/kargl/work/lib LD_RUN_PATH=/usr/home/kargl/work/lib laptop:kargl[246] gmake check-gfortran ... 100s of FAILs ^C >From testsuite/gfortran/gfortran.log FAIL: gfortran.dg/PR19754_2.f90 -O0 (test for excess errors) Excess errors: /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `scalbnq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__getf2' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__eqtf2' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__addtf3' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `ldexpq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `acosq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `cabsq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `csqrtq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__floatsitf' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__trunctfxf2' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `clogq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `atan2q' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `lroundq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `expq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `sinq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `libgfortran_dto q' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__divtf3' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `frexpq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `__letf2' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `sqrtq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `cosq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `nanq' /usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/./libgfortran/.libs/libgfortran.so: undefined reference to `roundq' /usr/home
