Continuous run-time adaptation and optimization of statically compiled programs
Hi all, Also wanted to announce that we are currently developing run-time adaptation techniques for GCC for statically compiled programs with varying context and behavior. Our technique relies on function/loop versioning and static low-overhead monitoring and adaptation routines. We extend our previous work on adaption techniques for regular numerical codes with stable phases (presented at HiPEAC 2005) to codes with any (irregular) behavior by using time-slot run-time performance monitoring and statistical selection of appropriate versions. We use it for continuous program optimizations, speeding up iterative optimizations and for auto-tuning of libraries. We also use this technique for program run-time adaptation on heterogeneous computing systems. Here is the development website: http://unidapt.sourceforge.net This adaptation technique is used in HiPEAC, MilePost and SARC projects. Any comments and suggestions are welcome! Cheers, Grigori = Grigori Fursin, PhD Research Fellow, INRIA Futurs, France http://fursin.net/research_desc.html
Re: GCC 4.2.0 Status Report (2007-03-04)
On 06 Mar 2007 21:48:14 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 06/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: | > Manuel López-Ibáñez wrote: | > > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: | > >> After reviewing all of the traffic[1] that stemmed from my previous | > >> status report, I've decided that, indeed, it makes sense to steam ahead | > >> with GCC 4.2.0 based on current GCC 4.2.0 release branch. | > >> | > > | > > I ask special permission to apply this patch: | > > | > > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html | > > | > > to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a | > > few weeks already. | > | > This patch is OK for 4.2.0, on the grounds that the -Walways-true option | > has not yet appeared in any FSF release, and we don't want to release | > the option with semantics different than what are eventually intended. | > | > Thanks, | > | | As far as I know, it was introduced in GCC 4.2 revision 108489. | | Also: | | $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch | grep -n | -e "Walways.true" | 63424: * gcc.dg/20031012-1.c: Add -Walways-true option. | 63978: * doc/invoke.texi (Warning Options): Document -Walways-true being | 64532: * common.opt (Walways-true): New option. | | while | | $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch | grep -n | -e "Walways.true" | | shows nothing. I strongly encourage the removal brefore 4.2 gets out. I am bootstrapping and regression testing the backport of the patch and I will commit it and post it here as soon as it finishes. Should we mention Waddress in the GCC 4.2 release notes? Neither Wliteral-string-comparison nor Walways-true were mention. That is, should I prepare a patch? Cheers, Manuel.
libg2c.a missing in 4.1.1
Hi, Noticed libg2c.a is missing in /lib in 4.1.1 hierarchy , whats the equivalent of libg2c.a in gcc 4.1.1 , any pointers . Satya
Re: GCC 4.2.0 Status Report (2007-03-04)
On Wed, 7 Mar 2007, Manuel López-Ibáñez wrote: | Should we mention Waddress in the GCC 4.2 release notes? Proper documentation is sufficient I believe. -- Gaby
Apple's Objective-C 2.0 extensions
Hi all Two questions about Apple's Objective-C 2.0 work: 1) Does anyone know when the syntax extensions will be available & working in the gcc compiler? 2) Will their garbage collection & accelerated message dispatch mechanisms also be supported? Thx & please feel free to CC me Michael _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/ _/_/_/ Hopkins Research Ltd _/_/ _/_/ _/_/_/_/ _/_/_/ http://www.hopkins-research.com/ _/_/ _/ _/ _/_/ _/ _/ 'touch the future' _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Re: Adding a new gcc dir
Is it time to offer "second-strap" level of compilation? Ie allow C99 to bootstrap the creation of a basic GCC compiler, then allow a second compile using the basic GCC compiler to get the full compiler. Nick > ---Original Message--- > From: Paul Brook <[EMAIL PROTECTED]> > Subject: Re: Adding a new gcc dir > Sent: 06 Mar '07 16:32 > > > Which means using C90, which means no mixed declarations and code, no > > C++ comments, etc. Is there any way to compile at least, my files with > > c99 constructs? > > Or all gcc code should be built like this?? > > This is a feature. gcc can be bootstrapped using an arbitrary c90 compiler. > The warning options you mentioned help to enforce this. > > Paul >
RE: Adding a new gcc dir
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > bootstrap the creation of a basic GCC compiler, then allow a second compile > using the basic GCC compiler to get the full compiler. > > Nick Effectively that's what bootstrapping already does, so IIUIC, as long as no C99 creeps into the core C language compiler, it /should/ work to use C99 (and indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/ subdirectory or other places where the files only relate to other languages. cheers, DaveK -- Can't think of a witty .sigline today
Re: Adding a new gcc dir
On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > bootstrap the creation of a basic GCC compiler, then allow a second compile > using the basic GCC compiler to get the full compiler. > > Nick Effectively that's what bootstrapping already does, so IIUIC, as long as no C99 creeps into the core C language compiler, it /should/ work to use C99 (and indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/ subdirectory or other places where the files only relate to other languages. But if I add in my pass // args, or mixed code and variable declarations for example, I get warnings, so it is not that clean. Maybe only by removing pedantic, are you able to do that. Right? Cheers, Paulo Matos cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Adding a new gcc dir
On 3/7/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote: > On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > > > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > > bootstrap the creation of a basic GCC compiler, then allow a second compile > > using the basic GCC compiler to get the full compiler. > > > > Nick > > Effectively that's what bootstrapping already does, so IIUIC, as long as no > C99 creeps into the core C language compiler, it /should/ work to use C99 (and > indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/ > subdirectory or other places where the files only relate to other languages. > But if I add in my pass // args, or mixed code and variable declarations for example, I get warnings, so it is not that clean. Maybe only by removing pedantic, are you able to do that. Moreover, for some reason when using malloc, a lot of poisonous malloc warning come up which are solved by using xmalloc instead, which is another thing I cannot figure out. What is better in xmalloc than malloc? Right? Cheers, Paulo Matos > cheers, > DaveK > -- > Can't think of a witty .sigline today > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RE: Adding a new gcc dir
On 07 March 2007 15:05, Paulo J. Matos wrote: > On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: >> >>> Is it time to offer "second-strap" level of compilation? Ie allow C99 to >>> bootstrap the creation of a basic GCC compiler, then allow a second >>> compile using the basic GCC compiler to get the full compiler. >>> >>> Nick >> >> Effectively that's what bootstrapping already does, so IIUIC, as long as >> no C99 creeps into the core C language compiler, it /should/ work to use >> C99 (and indeed GCC language extensions, attributes etc. etc.) in e.g. the >> cp/ subdirectory or other places where the files only relate to other >> languages. >> > > But if I add in my pass // args, or mixed code and variable > declarations for example, I get warnings, so it is not that clean. > Maybe only by removing pedantic, are you able to do that. > > Right? Yeah, absolutely. Although it does /work/ to use these features, I think we don't yet want to use any of them in the official sources, so the flags set in the gcc makefile are chosen in order to draw attention to any such features that anyone might accidentally use without realising. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 15:07, Paulo J. Matos wrote: > Moreover, for some reason when using malloc, a lot of poisonous malloc > warning come up which are solved by using xmalloc instead, which is > another thing I cannot figure out. What is better in xmalloc than > malloc? Take a look, the source for it is in libiberty. I think the only substantial difference is that if it runs out of memory it exits instead of returning a NULL pointer, meaning the rest of the code doesn't have to remember to check every single malloc return. cheers, DaveK -- Can't think of a witty .sigline today
Re: Accessing function code from CFG
On 3/2/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 03/02/07 10:12: > In an IPA pass, for each CFG node, I have a tree decl member from > which I can access the return type, name of the function, argument > names and its types, but I can't seem to find a way to get the > function code. I would guess it would be a basic block list but I > don't know where I can get it. You need to get at the function structure from the cgraph node with DECL_STRUCT_FUNCTION (cgraph_node->decl). Then you can use one of the CFG accessors like basic_block_info_for_function(). For functions to which DECL_STRUCT_FUNCTION (cgraph_node->decl) != 0, I'm always getting VARRAY_ACTIVE_SIZE(basic_block_info_for_function(DECL_STRUCT_FUNCTION (cgraph_node->decl))) == 0. Is this normal? It seems there are no basic blocks set for the functions. Probably my pass is being run before the bbs are created? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Adding a new gcc dir
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > bootstrap the creation of a basic GCC compiler, then allow a second compile > using the basic GCC compiler to get the full compiler. Maybe, but I consider rejecting mixed code/declarations to be a feature :-) C++ comments are handy for quick debugging hacks, but I'm not sure they add any real value to production code. Paul
Re: Accessing function code from CFG
Paulo J. Matos wrote on 03/07/07 10:36: > Is this normal? It seems there are no basic blocks set for the > functions. Probably my pass is being run before the bbs are created? Looks like it. Set a breakpoint in build_tree_cfg and your function. If gdb stops in your function first, you found the problem.
Re: Adding a new gcc dir
On 3/7/07, Paul Brook <[EMAIL PROTECTED]> wrote:
On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
> Is it time to offer "second-strap" level of compilation? Ie allow C99 to
> bootstrap the creation of a basic GCC compiler, then allow a second compile
> using the basic GCC compiler to get the full compiler.
Maybe, but I consider rejecting mixed code/declarations to be a feature :-)
Well, I'm curious to hear more about that... Why do you think that...
int i;
...
...
for(i = 0; i < n; i++) ..
is better than
for(int i = 0; i < ..) ... ???
I find the second much more compact and readable than the first.
C++ comments are handy for quick debugging hacks, but I'm not sure they add
any real value to production code.
Their value lies (at least for me) in things line
if (foo) // now I'll do...
{
}
and for example
struct foo {
int myint ; // this int is ...
double mydouble ; // this double is...
};
in a one line comments, using /* */ is just horrid! :)
Paul
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: Accessing function code from CFG
On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 03/07/07 10:36: > Is this normal? It seems there are no basic blocks set for the > functions. Probably my pass is being run before the bbs are created? Looks like it. Set a breakpoint in build_tree_cfg and your function. If gdb stops in your function first, you found the problem. Now, this is wierd, probably I'm just doing it wrong, gdb is not finding any build_tree_cfg or my pass pass_gsvt, but it find, for example xmalloc. $ gdb gcc-bin/bin/gcc GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) break build_tree_cfg Function "build_tree_cfg" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break pass_gsvt Function "pass_gsvt" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) break xmalloc Breakpoint 1 at 0x415f30: file ../../gsvt/libiberty/xmalloc.c, line 145. Same results if I use objdump -t gcc | grep finds xmalloc but no build_tree_cfg or pass_gsvt. What am I missing? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Accessing function code from CFG
Paulo J. Matos wrote on 03/07/07 11:43: > What am I missing? You are debugging the wrong binary. I'd suggest you browse through http://gcc.gnu.org/wiki/DebuggingGCC You need to debug one of cc1/cc1plus/jc1
Re: Accessing function code from CFG
On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote on 03/07/07 11:43: > What am I missing? You are debugging the wrong binary. I'd suggest you browse through http://gcc.gnu.org/wiki/DebuggingGCC You need to debug one of cc1/cc1plus/jc1 Thank you. It seems I've not found my error then. build_tree_cfg is called 4 times before my pass. I guess it's one for each function I have in my source file. So, how come no bbs are created? Is there any other way to test where the problem lies? -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Accessing function code from CFG
On 3/7/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/7/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Paulo J. Matos wrote on 03/07/07 11:43:
>
> > What am I missing?
>
> You are debugging the wrong binary. I'd suggest you browse through
> http://gcc.gnu.org/wiki/DebuggingGCC
>
> You need to debug one of cc1/cc1plus/jc1
>
Thank you. It seems I've not found my error then. build_tree_cfg is
called 4 times before my pass. I guess it's one for each function I
have in my source file.
So, how come no bbs are created? Is there any other way to test where
the problem lies?
As a side note, if I instead try to access BBs through FOR_EACH_BB_FN
I get the basic blocks I wanted. :)
struct function *fdecl = DECL_STRUCT_FUNCTION(node->decl);
basic_block bb;
FOR_EACH_BB_FN(bb, fdecl) {
printf("For each bb!\n");
}
This will print "For each bb!" a couple of times for each function.
Seems to be working this way around! :) heh!
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Re: GCC 4.2.0 Status Report (2007-03-04)
On Wed, Mar 07, 2007 at 04:13:08AM -0600, Gabriel Dos Reis wrote: > On Wed, 7 Mar 2007, Manuel López-Ibáñez wrote: > > | Should we mention Waddress in the GCC 4.2 release notes? > > Proper documentation is sufficient I believe. Or the release notes could just say something like: * New warning options: -Wfoo, -Wbar (see the GCC manual for details)
Re: Apple's Objective-C 2.0 extensions
Hi Michael, Two questions about Apple's Objective-C 2.0 work: 1) Does anyone know when the syntax extensions will be available & working in the gcc compiler? 2) Will their garbage collection & accelerated message dispatch mechanisms also be supported? Fairborz is working on them, I imagine that it won't be until they're done in Leopard, but I'll let him give more information. -eric
RE: Adding a new gcc dir
On 07 March 2007 16:16, Paulo J. Matos wrote:
> On 3/7/07, Paul Brook <[EMAIL PROTECTED]> wrote:
>> On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
>>> Is it time to offer "second-strap" level of compilation? Ie allow C99 to
>>> bootstrap the creation of a basic GCC compiler, then allow a second
>>> compile using the basic GCC compiler to get the full compiler.
>>
>> Maybe, but I consider rejecting mixed code/declarations to be a feature :-)
>
> Well, I'm curious to hear more about that... Why do you think that...
> int i;
> ...
> ...
> for(i = 0; i < n; i++) ..
>
> is better than
> for(int i = 0; i < ..) ... ???
As explained: because it makes it impossible for users running old systems
with pre-C99 compilers to build gcc and thereby excludes them from the world
of free software, which is the opposite of what we're trying to achieve.
> Their value lies (at least for me) in things line
> if (foo) // now I'll do...
> {
>
> }
>
> and for example
> struct foo {
> int myint ; // this int is ...
> double mydouble ; // this double is...
> };
The benefit of saving three keypresses is outweighed (for the FSF's goals)
by the disadvantage of excluding a whole category of potential
users/contributors.
> in a one line comments, using /* */ is just horrid! :)
That's a purely religious opinion!
You might find it interesting to browse the gnu coding standards
(http://www.gnu.org/prep/standards/) and the additional standards specific to
gcc (http://gcc.gnu.org/codingconventions.html), since much of what we have
discussed is explained there along with the rationale that justifies the
decisions.
Things won't stay like this forever, and at some point we'll undoubtedly
decide that it's no longer necessary to stay backwardly compatible all that
far back, and start using C99 features (and beyond that, we may at sometime
start using C++ in the compiler core). It's a purely practical matter of
ensuring gcc is accessible to the greatest possible number of people.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Adding a new gcc dir
On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote: As explained: because it makes it impossible for users running old systems with pre-C99 compilers to build gcc and thereby excludes them from the world of free software, which is the opposite of what we're trying to achieve. Well, I surely understand that and I find it nice. Still, I was questioning Paul why he said: "I consider rejecting mixed code/declarations to be a feature" because it seems that if he could use mixed code/declarations, he wouldn't. I just asked why? Now, as I said, I understand gcc restriction and in my gcc code I surely adhere to it. The benefit of saving three keypresses is outweighed (for the FSF's goals) by the disadvantage of excluding a whole category of potential users/contributors. I surely don't know FSF's goals but again I understand gcc code not containing //, but my question was more directed to Paul view. :) > in a one line comments, using /* */ is just horrid! :) That's a purely religious opinion! Yes, it is. I'm religiously simplistic, best-language agnostic and god atheist! You might find it interesting to browse the gnu coding standards (http://www.gnu.org/prep/standards/) and the additional standards specific to gcc (http://gcc.gnu.org/codingconventions.html), since much of what we have discussed is explained there along with the rationale that justifies the decisions. I'll look into it . Things won't stay like this forever, and at some point we'll undoubtedly decide that it's no longer necessary to stay backwardly compatible all that far back, and start using C99 features (and beyond that, we may at sometime start using C++ in the compiler core). It's a purely practical matter of ensuring gcc is accessible to the greatest possible number of people. cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RE: Adding a new gcc dir
On 07 March 2007 17:44, Paulo J. Matos wrote: > Well, I surely understand that and I find it nice. Still, I was > questioning Paul why he said: "I consider rejecting mixed > code/declarations to be a feature" > I surely don't know FSF's goals but again I understand gcc code not > containing //, but my question was more directed to Paul view. :) Ah, well I'd best let him speak for himself! cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.2.0 Status Report (2007-03-04)
On Sun, 2007-03-04 at 20:45 -0800, Mark Mitchell wrote: > However, I do think that it's important to eliminate some of the 139 > open P2 and P1 regressions [2], especially those P1 regressions which > did not appear in GCC 4.1.x. There are a handful I've been involved with which are labeled as 4.0/4.1/4.2/4.3 regressions which I don't see ever being fixed in 4.0 through 4.2. There is perhaps some hope for 4.3, but 4.4 is the more likely case. They require new development work that I think is unlikely to ever be backported to these releases for just these testcases. The PRs are - 21596 I made a simple attempt at this one, but the simple approach isn't going to work. - 23200 fixed in 4.3 by the new version of TER. Unlikely to port the entire TER rewrite back to 4.2 at this stage (it could be done tho :-). - 27986 This is in fact a variation of the issue in 21596, except this one crosses basic blocks. It will require all new work to get this case. - 27877 Mark Shinwell applied a patch for this to 4.3. I pinged him about applying it to 4.2. If I haven't heard from him by thursday, I will apply it friday. I would say you can mark the first 3 as 'will not fix', or whatever you do to indicate they aren't going to be resolved in 4.2. When I actually have a fix for them (or RTL optimizers fix them), we can look at what it takes to port them back, but for this release I'd claim they are a no-go. Andrew
Re: Apple's Objective-C 2.0 extensions
On Mar 7, 2007, at 9:13 AM, Eric Christopher wrote: Hi Michael, Two questions about Apple's Objective-C 2.0 work: 1) Does anyone know when the syntax extensions will be available & working in the gcc compiler? It is work in progress. For current status, you can check out Apple's 4.0 branch. We will push this to FSF mainline when features are frozen and adapted by Apple's internal developers. Note that features rely heavily on Leopard frameworks. So, you may not get very far using the new features on Tiger, etc. 2) Will their garbage collection & accelerated message dispatch mechanisms also be supported? Yes. In Leopard. If you want more information on the features, please ask and after management approval, I can forward them to you. - Fariborz Fairborz is working on them, I imagine that it won't be until they're done in Leopard, but I'll let him give more information. -eric
Re: Apple's Objective-C 2.0 extensions
On Mar 7, 2007, at 4:44 AM, Michael Hopkins wrote: 1) Does anyone know when the syntax extensions will be available & working in the gcc compiler? I'd like to contribute all the Objective-C front end features in time for 4.3, unfortunately, I've not started doing that work. I'm hoping we'll have some time to do that in the next couple of months. Do you want to run them on darwin9 or some other OS? If another OS, there is runtime support needed for the various features new in Objective-C 2.0 that are required for full functionality. If you'd like to get your hands dirty and help out with the libobjc runtime, let me know. 2) Will their garbage collection & accelerated message dispatch mechanisms also be supported? Does -fobjc-gc work for you now? It's been on mainline for a while now. As for accelerated message dispatch, I'm not exactly certain which feature you're referring to. The feature I think you're referring (call 0xnnn, instead of call __objc_msgSend, where 0xnnn is a fixed address for the platform) to is 95% in mainline now, but there is an ever so small slice that prevents it from working as I recall. If you wanted to finish wiring it up, I could provide pointers.
Detemining the size of int_fast8_t etc. in the frontend
Hi, gfortran provides via ISO C Bindings access to the C types int, float etc. It also provides access to int_fast8_t, int_fast16_t, etc. of stdint.h. Using "#include " with e.g. sizeof(int_fast8_t) does not work with cross compilations. (It actually fails already for -m32 on x86-64.) On the other hand, "struct gcc_target" does not seem to provide this information. What is the proper way to obtain this information? Tobias
Re: [RFC]possible improvements to --with-sysroot
On 3/6/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: > I have used "strace -f" to check where linker looked for -lqt-mt. From > what I have observed, it seems that ld didn't use > $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. I found a clue which may lead to a neat solution to this problem. And this has something to do with gcc, so I still posted it here. First of all, $SYSROOT/etc/ld.so.conf solution maybe an overkill, so I think we can ignore it for now. The finding is if ld is invoked with --sysroot option and if the dir specified by -L has a leading "=", for example: --sysroot=/usr/mipsel-unknown-linux-gnu -L=/usr/qt/3/lib -L/usr/lib -lqt-mt Then when ld will looking for libqt-mt.so in /usr/mipsel-unknown-linux-gnu/usr/qt/3/lib, instead of /usr/qt/3/lib. Thus problem solved. So I think if there is a way to detect whether gcc is doing cross compile. If so, when cross compiling is detected, collect2 search for -L option in COLLECT_GCC_OPTIONS, and insert a "=" between -L and the actual path. I think this way is better than the $SYSROOT/etc/ld.so.conf way. -- Zhang Le, Robert Linux Engineer/Trainer http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
Re: Detemining the size of int_fast8_t etc. in the frontend
On Mar 7, 2007, at 11:21 AM, Tobias Burnus wrote: Using "#include " with e.g. sizeof(int_fast8_t) does not work with cross compilations. Sounds like a bug? When I try it on my compiler, it works just fine natively and with cross compilations. I'd file a bug report. If it is an OS bug, it can be fixed by fixincludes. What is the proper way to obtain this information? Autoconf with sizeof(int_fast16_t,) and sizeof(int_fast8_t) strikes me as one possibility.
Re: Detemining the size of int_fast8_t etc. in the frontend
On Wed, Mar 07, 2007 at 12:05:32PM -0800, Mike Stump wrote: > On Mar 7, 2007, at 11:21 AM, Tobias Burnus wrote: > >Using "#include " with e.g. sizeof(int_fast8_t) does not > >work with cross compilations. > > Sounds like a bug? When I try it on my compiler, it works just fine > natively and with cross compilations. I'd file a bug report. If it > is an OS bug, it can be fixed by fixincludes. He's talking about finding the target's int_fast8_t in the frontend. That's another issue entirely. -- Daniel Jacobowitz CodeSourcery
Re: Detemining the size of int_fast8_t etc. in the frontend
On Wednesday 07 March 2007 19:21, Tobias Burnus wrote: > gfortran provides via ISO C Bindings access to the C types int, float > etc. It also provides access to int_fast8_t, int_fast16_t, etc. of > stdint.h. > > Using "#include " with e.g. sizeof(int_fast8_t) does not work > with cross compilations. (It actually fails already for -m32 on x86-64.) > On the other hand, "struct gcc_target" does not seem to provide this > information. > > What is the proper way to obtain this information? I suspect the answer is that there currently isn't one. gcc uses the stdint.h provided by the target C library. This may not be available when building the compiler. Paul
Re: Apple's Objective-C 2.0 extensions
On Mar 7, 2007, at 11:16 AM, Mike Stump wrote: Does -fobjc-gc work for you now? It's been on mainline for a while now. As for accelerated message dispatch, I'm not exactly certain which feature you're Option may be recognized. But it entirely depends on Leopard runtime for support. - Fariborz
Re: Detemining the size of int_fast8_t etc. in the frontend
On Wed, 7 Mar 2007, Tobias Burnus wrote: > Hi, > > gfortran provides via ISO C Bindings access to the C types int, float > etc. It also provides access to int_fast8_t, int_fast16_t, etc. of stdint.h. > > Using "#include " with e.g. sizeof(int_fast8_t) does not work > with cross compilations. (It actually fails already for -m32 on x86-64.) > On the other hand, "struct gcc_target" does not seem to provide this > information. > > What is the proper way to obtain this information? See bug 448. You'll need to define lots of target macros to match existing and files. Defaults for those macros will be tricky (for example, glibc and newlib use different choices of types) and testcases will be needed to make sure the types are the same as in existing system headers. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Detemining the size of int_fast8_t etc. in the frontend
Hi Tobias, What is the proper way to obtain this information? I fear the answer to this question is "there's no way". We already discussed that a few months ago, at the thread starting here: http:// gcc.gnu.org/ml/gcc/2006-10/msg00346.html From private discussion, with Paul Brook & Joseph Myers IIRC, the conclusion is that GCC can't do that right now, but it could if target-specific files provided the information. Maybe there's a PR open for that, otherwise you can open it, and we can try to get people implement the framework for this... Christopher's original ISO_C_BINDING patch used autoconf to guess it, and I remove that (before creating the fortran-experiments branch). Currently, there's no other option than to return -2 for the corresponding ISO_C_BINDING constants. FX smime.p7s Description: S/MIME cryptographic signature
gcc-4.2-20070307 is now available
Snapshot gcc-4.2-20070307 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070307/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 122675 You'll find: gcc-4.2-20070307.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070307.tar.bz2 C front end and core compiler gcc-ada-4.2-20070307.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070307.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070307.tar.bz2 C++ front end and runtime gcc-java-4.2-20070307.tar.bz2 Java front end and runtime gcc-objc-4.2-20070307.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070307.tar.bz2The GCC testsuite Diffs from 4.2-20070228 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
