On 2006-12-02 11:41:48 -0800, Bruce Korb wrote:
> Anyway, the whole deal about gmp-config is that mpfr should be doing
> the equivalent of --with-gmp=`gmp-config --libdir` so that you
> *don't* have the /usr/local headers and the /usr binary.
Assuming a gmp-config program is provided, the user can
On 2006-12-02 10:16:31 -0800, Bruce Korb wrote:
> Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
> go pull and build that only to find:
>
> checking if gmp.h version and libgmp version are the same...
> (4.2.1/4.1.4) no
Note that this test was really buggy in MPFR 2.2.0. I f
On Sat, 2 Dec 2006, Kaveh R. GHAZI wrote:
> Gerald, would you please copy the mpfr-2-2.1 tarball to the gcc
> infrastructure directory and delete 2.2.0 and the cumulative patch from
> there? Thanks. http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2
Sure -- done it is.
Gerald
PS: I will most p
Brendon Costa wrote:
> Hi all,
>
> I understand that all template functions in GCC should have vague
> linkage and thus may be exported into numerous translation units where
> they are used. I have been attempting to use a few different macros on
> both an instanciated template functions FUNCTION_
On Fri, Dec 01, 2006 at 07:57:51PM -0800, Andrew Pinski wrote:
> On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
> > The thing is, absolute majority of callbacks really want a pointer to
> > some object. There is a handful of cases where we really want a genuine
> > number - not a pointer cast t
On Fri, Dec 01, 2006 at 07:57:51PM -0800, Andrew Pinski wrote:
> On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
> > There's a bunch of related issues, some kernel, some gcc,
> > thus the Cc from hell on that one.
>
> I don't really see how this is a GCC question, rather I see this
> as a C
Hi Kaveh,
Kaveh R. GHAZI wrote:
>
> It's not clear from your message whether this is a problem limited to
> mpfr-2.2.1, or 2.2.0 had this also. In any case, I think the mpfr
> configure process is right to stop you from shooting yourself by using a
> mismatched gmp header and library.
Here-to-fore
On Sat, 2 Dec 2006, Bruce Korb wrote:
> Hi Kaveh,
>
> Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
> go pull and build that only to find:
>
> checking if gmp.h version and libgmp version are the same...
> (4.2.1/4.1.4) no
>
> which is a problem because I cannot have /usr/lo
Hi Kaveh,
Requiring this is a bit of a nuisance. mpfr requires gmp so I had to
go pull and build that only to find:
checking if gmp.h version and libgmp version are the same...
(4.2.1/4.1.4) no
which is a problem because I cannot have /usr/local/lib found before
/usr/lib for
some things, yet for
Snapshot gcc-4.3-20061202 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Wed, 29 Nov 2006, Vincent Lefevre wrote:
> MPFR 2.2.1 is now available for download from the MPFR web site:
>
> http://www.mpfr.org/mpfr-2.2.1/
>
> Thanks very much to those who tested the release candidates.
>
> The MD5's:
> 40bf06f8081461d8db7d6f4ad5b9f6bd mpfr-2.2.1.tar.bz2
> 662bc38c75c9
I managed to create function call within the gcc's abstract syntax
tree (AST) as a side effect of executing a pragma. I post a simple
example how it is done, in case someone else sticks on this simple
point like me :)
Example problem scenario:
Suppose that we have the following "C" source file:
On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
> Now, there's another question: how do we get there? Or, at least, from
> current void (*)(unsigned long) to void (*)(void *)...
I think the real solution should be
void (*function)(struct timer_list *timer);
and hand the timer itself
On Sat, Dec 02, 2006 at 04:23:32AM -0500, Kyle Moffett wrote:
> On Dec 01, 2006, at 12:21:49, Al Viro wrote:
> >And that's where it gets interesting. It would be very nice to get to
> >the following situation:
> > * callbacks are void (*)(void *)
> > * data is void *
> > * instances can take void
On Sat, Dec 02, 2006 at 01:29:32AM -0500, Daniel Berlin wrote:
> >While that is safe (modulo the portability constraint that affects much
> >more code than just timers), it ends up very inconvenient and leads to
> >lousy type safety.
>
> Understandable. I assume you are trying to get more type s
On Friday 01 December 2006 18:21, Al Viro wrote:
> There is a tempting
> possibility to do that gradually, with all intermediates still in working
> state, provided that on all platforms currently supported by the kernel
> unsigned long and void * are indeed passed the same way (again, only for
>
On Dec 01, 2006, at 12:21:49, Al Viro wrote:
And that's where it gets interesting. It would be very nice to get to
the following situation:
* callbacks are void (*)(void *)
* data is void *
* instances can take void * or pointer to object type
* a macro SETUP_TIMER(timer, func, data) sets ca
17 matches
Mail list logo
