Re: [RFC] timers, pointers to functions and type safety

[Kyle Moffett]

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 callback and data  
and checks if func(data) would be valid.


This is where a very limited form of C++ templates would do nicely;  
you could define something like the following:


template 
static inline void setup_timer(struct timer_list *timer,
void (*function)(T *), T *data)
{
timer->function = (void (*)(void *))function;
timer->data = (void *)data;
init_timer(timer);
}

Any attempts to call it with mismatched "function" and "data"  
arguments would display an "Unable to find matching template" error  
from the compiler.


Unfortunately you can't get simple templated functions without  
opening the whole barrel of monkeys involved with C++ support;  
including an explosion of reserved words, a 400% or more increase in  
compilation time, a decrease in the efficiency of parts of the  
generated code, etc.



Maybe it's time for Linux to fork GCC and morph C99 into a language  
whose design more fundamentally supports the kinds of type-checking  
and static verification that we keep adding to the kernel, including  
some of the things that sparse, lockdep, kmemleak, etc. do.



Cheers,
Kyle Moffett

Re: [RFC] timers, pointers to functions and type safety

[Arnd Bergmann]

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
> current kernel targets and existing gcc versions).  Namely, we could
> * introduce SETUP_TIMER variant with cast to void (*)(unsigned long)
> * switch to its use, converting callback instances to take pointers
> at the same time.  That would be done in reasonably sized groups.
> * once it's over, flip ->function to void (*)(void *), ->data to
> void * and update SETUP_TIMER accordingly; deal with remaining few instances
> of ->function.

Another alternative might be to define an intermediate version of
timer_list that avoids adding new macros, like

struct timer_list {
struct list_head entry;
­   unsigned long expires;

­   void (*function)(union { unsigned long l; void *p; }
 __attribute__((transparent_union)));
­   union {
unsigned long data __deprecated;
void *obj;
};

­   struct tvec_t_base_s *base;
};

Unfortunately, this relies more on gcc specific behavior than we
may want, and it makes it possible to abuse in new ways, like defining
a function to take an unsigned long argument, but passing the data
as void *obj.

Arnd <><

Re: About changing the tree structure in pragmas

[Ferad Zyulkyarov]

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:

int test_fn_call()
{
   printf("in test_fn_call\n");
   return 0;
}

int main(void)
{
   #pragma test_pragma
   printf("Hello World\n");
   return 0;
}

We want when "#pragma test_pragma" is met to build a call to the
"test_fn_call" function.

The expected output is:
in test_fn_call
Hello World

Problem solution:
Below is the code that handles the execution of the "#pragma test_pragma"

static void handle_pragma_test(cpp_reader *ARG_UNUSED(dummy))
{
   tree fn_decl;
   tree fn_call;
   tree fn_id;

   fn_id = get_identifier("test_fn_call");
   fn_decl = lookup_name(fn_id);

   fn_call = build_function_call_expr(fn_decl, NULL_TREE);
   add_stmt(fn_call);
} /* End of void handle_pragma_test */


--
Ferad Zyulkyarov
Barcelona Supercomputing Center



On 11/30/06, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:

Hi,

I am trying to implement a pragma that will change the tree structure
of the program. Although I looked at some basic tutorials about
implementing front-ends for gcc and looked at the implementation of
the currently available pragmas I am not well recognized with the
gcc's interface for manipulating the program's tree structure.

I will appreciate your advices on implementing the following scenario:

code example:

1: printf("Outside pragma 1");
2: #pragma test_pragma
3: {
4: /* the pragma is supposed to put 'printf("test_pragma");' just here
before all statements that follow */
5: printf("Inside pragma 1");
6: }
7: printf("Outside pragma 2");

Expected output:
Outside pragma 1
test_pragma
Inside pragma 1
Outside pragma 2

I suppose that probably there is a way to do this like:
tree* function_call = build(FUNCTION_CALL, "printf", param_list);

Also, I would be very thankful for any resources about the API for
manipulating the program's tree structure.

Thanks,
Ferad Zyulkyarov

Re: [RFC] timers, pointers to functions and type safety

[Al Viro]

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 safety more
> for error checking than optimization, being that the kernel still
> defaults to -fno-strict-aliasing.

Indeed.

> >Again, that's not a portable C, even leaving aside the use of typeof.
> >Casts between the incompatible function types are undefined behaviour;
> >rationale is that we might have different calling conventions for those.
> >However, here we are at much safer ground; calling conventions are not
> >likely to change if you replace a pointer to object with void *.
^^
> Is this true of the ports you guys support  even if the object is a
> function pointer or a function?
> (Though the first case may be insane.  I can't think of a *good*
> reason you'd pass a pointer to a function pointer to a timer
> callback,).

Pointer to pointer to function should be OK - it's a pointer to normal
object type and I would be very surprised if it differed from void *,
modulo very creative reading of 6.3.2.3(1).  I certainly wouldn't expect
it to differ from e.g. pointer to pointer to struct, even on targets
far odder than anything we might hope to port to.

Pointer to function might be worse, but that's excluded by the above -
it's not a pointer to object type.

In any case, we don't do either anywhere and if the need ever arises
we can simply put that pointer into whatever structure our timer_list
is embedded into and pass the address of that structure (which is what
we do in a lot of cases anyway).

IOW, it's worth checking in SETUP_TIMER, but it's not going to be a
realistic PITA in any instance.

> >IOW, "gcc would ICE if it ever inlined it" kind of arguments (i.e. what
> >had triggered gcc refusing to do direct call via such cast) doesn't apply
> >here.  Question to gcc folks: can we expect no problems with the approach
> >above, provided that calling conventions are the same for passing void *
> >and pointers to objects?  No versions (including current 4.3 snapshots)
> >create any problems here...
> 
> Personally, as someone who works on the pointer and alias analysis,
> I'm much more worried about your casting of void (*)(void) to void
> (*)(unsigned long) breaking in the future than I am about the above.

That one will be gone; it's pure laziness and IMO ~10 instances mostly in
weird ancient cdrom drivers are not worth worrying about, especially since
getting rid of such crap is a matter of minutes.

> I can't really see the above code breaking any more than what you have
> now, and it should in fact, break a lot less.  However, the removal of
> the argument cast (IE void (*) (void) to void (*) unsigned long) maybe
> break eventually.  As we get into intermodule analysis and figure out
> the conservative set of called functions for a random function
> pointer,  the typical thing to do is to type filter the set so only
> those address taken functions with "compatible"  signatures (for some
> very loose definition of compatible) are said to be callable by a
> given function pointer.  I can't imagine the definition of compatible
> would include address taken functions with less arguments than the
> function pointer you are calling through.  In this specific case, as
> you point out, it's pretty unlikely we'll ever be able to come up with
> a set without something telling us.  But I figured i'd mention it in
> case this type of casting is prevalent elsewhere.

Umm...  That type of casting worries me too, and not for timer-related
reasons.  We do it a lot in one place: fs/bad_inode.c.  A bunch of methods
with different arguments,
static int return_EIO(void)
{
return -EIO;
}
and (void *)return_EIO used to initialize them.  There's a couple of
other places where minor turds like that are done, but that one is
the most massive.  That's bloody annoying when doing any global call
graph analysis (sparse-based in my case, but I wouldn't expect gcc
folks being any happier with it)...

And no, it certainly isn't good C for many reasons (any target where
callee removes arguments from stack before returning control to caller
and that one's toast, for starters).
 
> IOW, unless someone else can see a good reason, I see no reason for
> you guys not to switch.

Re: [RFC] timers, pointers to functions and type safety

[Al Viro]

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 * or pointer to object type
> > * a macro SETUP_TIMER(timer, func, data) sets callback and data  
> >and checks if func(data) would be valid.
> 
> This is where a very limited form of C++ templates would do nicely;  
> you could define something like the following:
> 
> template 
> static inline void setup_timer(struct timer_list *timer,
>   void (*function)(T *), T *data)
> {
>   timer->function = (void (*)(void *))function;
>   timer->data = (void *)data;
>   init_timer(timer);
> }
> 
> Any attempts to call it with mismatched "function" and "data"  
> arguments would display an "Unable to find matching template" error  
> from the compiler.
> 
> Unfortunately you can't get simple templated functions without  
> opening the whole barrel of monkeys involved with C++ support;  

Fortunately, you can get all checks done by gcc without involving C++ (or
related flamewars).  See original post for a way to do it in a macro
and for fsck sake, leave gcc@gcc.gnu.org out of it.

Folks, please trim the Cc.  My apologies for cross-posting in the first place,
should've double-posted instead and manually forwarded relevant followups...

Re: [RFC] timers, pointers to functions and type safety

[Thomas Gleixner]

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 to the callback. Most of the timers are
embedded into data structures anyway and for the rest we can easily
build one.

> "A fscking huge patch flipping everything at once" is obviously not an
> answer; too much PITA merging and impossible to review.

There are ~ 500 files affected and this is in the range of cleanups we
did recently at the end of the merge window already. I'd volunteer to
hack this up and keep the patch up to date until the final merge. I have
done that before and I'm not scared about it. The patches are a couple
of lines per file and I do not agree that this is impossible to review. 

tglx

Re: Announce: MPFR 2.2.1 is released

[Kaveh R. GHAZI]

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
> 662bc38c75c9857ebbbc34e3280053cd  mpfr-2.2.1.tar.gz
> 93a2bf9dc66f81caa57c7649a6da8e46  mpfr-2.2.1.zip
>

Hi Vincent, thanks for making this release.  Since this version of mpfr
fixes important bugs encountered by GCC, I've updated the gcc
documentation and error messages to refer to version 2.2.1.

I have NOT (yet) updated gcc's configure to force the issue.  I'll wait a
little while to let people upgrade.


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



Patch below installed as obvious after testing on sparc-sun-solaris2.10.

--Kaveh

2006-12-02  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

* configure.in: Update MPFR version in error message.

* configure: Regenerate.

gcc:
* doc/install.texi: Update recommended MPFR version.  Remove
obsolete reference to cumulative patch.

gcc/testsuite:
* gcc.dg/torture/builtin-sin-mpfr-1.c: Update MPFR comment.

diff -rup orig/egcc-SVN20061201/configure.in egcc-SVN20061201/configure.in
--- orig/egcc-SVN20061201/configure.in  2006-11-26 20:01:56.0 -0500
+++ egcc-SVN20061201/configure.in   2006-12-02 11:12:45.998319820 -0500
@@ -1130,7 +1130,7 @@ fi
 CFLAGS="$saved_CFLAGS"

 if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
-  AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.2+.
+  AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.2.1+.
 Try the --with-gmp and/or --with-mpfr options to specify their locations.
 Copies of these libraries' source code can be found at their respective
 hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
diff -rup orig/egcc-SVN20061201/gcc/doc/install.texi 
egcc-SVN20061201/gcc/doc/install.texi
--- orig/egcc-SVN20061201/gcc/doc/install.texi  2006-11-26 20:01:26.0 
-0500
+++ egcc-SVN20061201/gcc/doc/install.texi   2006-12-02 11:07:36.801797569 
-0500
@@ -297,16 +297,14 @@ library search path, you will have to co
 @option{--with-gmp} configure option.  See also
 @option{--with-gmp-lib} and @option{--with-gmp-include}.

[EMAIL PROTECTED] MPFR Library version 2.2 (or later)
[EMAIL PROTECTED] MPFR Library version 2.2.1 (or later)

 Necessary to build GCC.  It can be downloaded from
[EMAIL PROTECTED]://www.mpfr.org/}.  If you're using version 2.2.0, You
-should also apply revision 16 (or later) of the cumulative patch from
[EMAIL PROTECTED]://www.mpfr.org/mpfr-current/}.  The version of MPFR that is
-bundled with GMP 4.1.x contains numerous bugs.  Although GCC will
-appear to function with the buggy versions of MPFR, there are a few
-bugs that will not be fixed when using this version.  It is strongly
-recommended to upgrade to the recommended version of MPFR.
[EMAIL PROTECTED]://www.mpfr.org/}.  The version of MPFR that is bundled with
+GMP 4.1.x contains numerous bugs.  Although GCC may appear to function
+with the buggy versions of MPFR, there are a few bugs that will not be
+fixed when using this version.  It is strongly recommended to upgrade
+to the recommended version of MPFR.

 The @option{--with-mpfr} configure option should be used if your MPFR
 Library is not installed in your default library search path.  See
diff -rup 
orig/egcc-SVN20061201/gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c 
egcc-SVN20061201/gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c
--- orig/egcc-SVN20061201/gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c 
2006-10-23 20:01:14.0 -0400
+++ egcc-SVN20061201/gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c  
2006-12-02 11:09:23.086012787 -0500
@@ -1,7 +1,6 @@
 /* Version 2.2.0 of MPFR had bugs in sin rounding.  This test checks
to see if that buggy version was installed.  The problem is fixed
-   in the MPFR cumulative patch http://www.mpfr.org/mpfr-current and
-   presumably later MPFR versions.
+   in version 2.2.1 and presumably later MPFR versions.

Origin: Kaveh R. Ghazi 10/23/2006.  */

gcc-4.3-20061202 is now available

[gccadmin]

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 revision 119451

You'll find:

gcc-4.3-20061202.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20061202.tar.bz2 C front end and core compiler

gcc-ada-4.3-20061202.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20061202.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20061202.tar.bz2  C++ front end and runtime

gcc-java-4.3-20061202.tar.bz2 Java front end and runtime

gcc-objc-4.3-20061202.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20061202.tar.bz2The GCC testsuite

Diffs from 4.3-20061125 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.

Re: Announce: MPFR 2.2.1 is released

[Bruce Korb]

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 mpfr I have to find gmp in /usr/local/lib first.
The normal
way for this to work is for mpfr to use gmp-config to find out where to
find headers
and libraries. This was not done. I don't have an easy route from here
to there.

Now, what? :( Thanks - Bruce


Kaveh R. GHAZI wrote:
> 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
>> 662bc38c75c9857ebbbc34e3280053cd mpfr-2.2.1.tar.gz
>> 93a2bf9dc66f81caa57c7649a6da8e46 mpfr-2.2.1.zip
>>
>
> Hi Vincent, thanks for making this release. Since this version of mpfr
> fixes important bugs encountered by GCC, I've updated the gcc
> documentation and error messages to refer to version 2.2.1.
>
> I have NOT (yet) updated gcc's configure to force the issue. I'll wait a
> little while to let people upgrade.

Re: Announce: MPFR 2.2.1 is released

[Kaveh R. GHAZI]

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/local/lib found before
> /usr/lib for some things, yet for mpfr I have to find gmp in
> /usr/local/lib first. The normal way for this to work is for mpfr to use
> gmp-config to find out where to find headers and libraries. This was not
> done. I don't have an easy route from here to there.
>
> Now, what? :( Thanks - Bruce

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.

I'm not sure why you can't put /usr/local/lib first, but I totally
sympathize! :-)  I've had access to boxes where what got put into
/usr/local by previous users was really old garbage and I didn't want to
suck it into my builds.

The way I solved it was to put my stuff in another directory (e.g.
/usr/local/foo) then I could safely put that directory ahead of /usr and
not worry about wierd side-effects from unrelated things.  Try installing
gmp (and mpfr) in their own dir and use --with-gmp=PATH when configuring
gcc.  Let me know if that works for you.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Announce: MPFR 2.2.1 is released

[Bruce Korb]

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, I've been happy with whatever was installed with my
distribution.
Now, that doesn't work.
>
> I'm not sure why you can't put /usr/local/lib first, but I totally
> sympathize! :-) I've had access to boxes where what got put into
> /usr/local by previous users was really old garbage and I didn't want to
> suck it into my builds.
(details: the primary library version was the same, but some libs in
/usr/local/lib were preserved over a re-install and they referenced
libimf which was now gone.) Anyway, it was an ugly nuisance.
I've now "rm -f"-ed all those broken .so-s.
> The way I solved it was to put my stuff in another directory (e.g.
> /usr/local/foo) then I could safely put that directory ahead of /usr and
> not worry about wierd side-effects from unrelated things. Try installing
> gmp (and mpfr) in their own dir and use --with-gmp=PATH when configuring
> gcc. Let me know if that works for you.
export LD_LIBRARY_PATH=/usr/local/lib seems to workThanks. Maybe now
that the
libimf referencing libs are gone, I can go back and re-order the library
search again.
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. (a suggestion and a hint to Vincent.) Except I just
noticed
gmp-config doesn't exist. Or mpfr-config. *sigh*. Never mind, I guess.

All this is for an inclhack.def patch:

fix = {
hackname = glibc_calloc;
files = bits/string2.h;
select = ' calloc \(1, 1\)';
c-fix = format;
c-fix-arg = ' calloc ((size_t)1, (size_t)1)';
test-text = <<- _EOTest_
char * pz = (char *) calloc (1, 1);
_EOTest_;
};


Thank you - Bruce

Re: [RFC] timers, pointers to functions and type safety

[Joe Buck]

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 question which means this should have gone to either
> [EMAIL PROTECTED] or the C news group.

In this case, I think the issue is important enough to ask the gcc
people directly.  Let's face it, some people are "more equal than
others"; it is very important for the gcc folks to help the Linux
kernel folks get it right; they are not just some random programmers.

Now, I do hope that detailed discussions of what to do about the
issue aren't crossposted to gcc from here forward.

> Then create an union which contains the two different types of call
> back.
> You know:
> union a
> {
>   void (*callbackwithulong) (unsigned long);
>   void (*callbackwithptr) (void*);
> };

This is a good suggestion.

> I don't see why there is a mystery about this?

But I wish you hadn't added this.  Unfortunately, while compiler
developers know the standards documents backwards and forwards
(or at least aspire to that), most code is developed by throwing
it at the compiler and seeing what works.  It's only been recently
that compilers (not just gcc) have been taking more advantage of
the aliasing rules to generate better code, and we're going to
need to help users deal with the problems this causes, not just
insult them.

Re: [RFC] timers, pointers to functions and type safety

[Olivier Galibert]

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 to unsigned long, not an index in array, etc.
> > They certainly can be dealt with.  Nearly a thousand of other instances
> > definitely want pointers.
> 
> Then create an union which contains the two different types of call
> back.
> You know:
> union a
> {
>   void (*callbackwithulong) (unsigned long);
>   void (*callbackwithptr) (void*);
> };
> 
> And then you just use the correct in the correct place.

And you do that how?  The timer code has no way of knowing which of
the two should be used.  Adding a flag, including the associated
storage, to choose between two code paths identical at the assembly
level is not really a good solution.

  OG.

Re: Determining if a function has vague linkage

[Brendon Costa]

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_DECL node and a normal
> functions FUNCTION_DECL node to see what the results are. I have tried:
> 
> DECL_WEAK(fndecl)
> DECL_ONE_ONLY(fndecl)
> DECL_COMDAT(fndecl)
> DECL_DEFER_OUTPUT(fndecl)
> DECL_REPO_AVAILABLE_P(fndecl)
> IDENTIFIER_REPO_CHOSEN(DECL_ASSEMBLER_NAME(fndecl))
> 
> and ALL of these macros are returning false for both the FUNCTION_DECL
> nodes. Is there any macro i can use to determine if a FUNCTION_DECL node
> has vague linkage? Or do i need to just assume that it is the sace for a
> template function?

I forgot to mention that i also looked at the DECL_LINKONCE_P() macro as
mentioned in the GCC internals documentation. However it has not yet
been implemented. This macro could help me i think.

I dont know enough about GCC to write this macro myself. Is there anyone
willing to implement this? I am willing to help in some way, I just dont
know where to start.

Thanks,
Brendon.

Re: Announce: MPFR 2.2.1 is released

[Gerald Pfeifer]

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 probably be without Internet access for at least two
weeks starting on Monday; if we'd like to see such an update during
the period I recommend to ask [EMAIL PROTECTED], for example.

Re: Announce: MPFR 2.2.1 is released

[Vincent Lefevre]

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 fixed it in
MPFR 2.2.1, but this is still a warning, since I'm not sure that
it will work with any compiler on Earth.

> which is a problem because I cannot have /usr/local/lib found before
> /usr/lib for some things, yet for mpfr I have to find gmp in
> /usr/local/lib first. The normal way for this to work is for mpfr to
> use gmp-config to find out where to find headers and libraries.

GMP doesn't provide a gmp-config (in its official archive). But if
you want to use /usr/lib before /usr/local/lib for some libraries,
and /usr/local/lib before /usr/lib for GMP, I don't know how to tell
the compiler/linker to do that (in a portable way). So, a gmp-config
would probably be useless.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Announce: MPFR 2.2.1 is released

[Vincent Lefevre]

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 do that (or
the package/port system if you prefer). Otherwise, if several GMP
versions are installed, how would MPFR know which gmp-config to take?
Using the default $PATH would be a non-standard behavior, IMHO. For
instance, I sometimes install particular GMP versions in particular
directories, that don't have a corresponding directory in $PATH.

Also, --with-xxx= options are buggy by design, since as soon
as two such options are used, one of the directories will have the
precedence over the other one, for *any* library, and this makes
these options very confusing. Fortunately, MPFR has only one.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)