Re: signed/unsigned comparison warning level
unless x is an integer larger than 1/2 UINT_MAX... then it's still a bad test. it's safer to test if the signed is less than 0 otherwise cast that to unsigned. On Sun, Sep 26, 2010 at 10:06 PM, foxmuldrs...@yahoo.com wrote: > Use the explicit override if you need signed comparison. > > unsigned int x; > int y; > if ((int)x < y) > > -Rick > > -Original message- > > From: J Decker > To: Ian Lance Taylor > Cc: gcc@gcc.gnu.org > Sent: Mon, Sep 27, 2010 05:51:56 GMT+00:00 > Subject: Re: signed/unsigned comparison warning level > >> The standards did not leave this open. They define precisely what is >> supposed to happen. >> > Really? I'll have to drop this whole lobbying effort then. That > makes me sad that they didn't define it to be comparing of the numbers > where there are overlaps in signed and unsigned instead of causing all > negative signed values to be wrong. > >> >>> But if it's not fixed, this warning should definatly be issued at >>> default warning level. This should be more like 'if this comparison >>> can be wrong, it will be wrong'. >> >> There is no problem comparing values of signed type with values of >> unsigned type if the signed values are known to be nonnegative. Of >> course it is sometimes hard to know that; hence the warning. But >> enabling the warning by default does not make sense. >> > > It's exactly the fact that 'of course it is sometimes' that makes > the warning make more sense to be on by default. I don't always know > that I've added an unsigned value to an expression, causing one side > of a comparison to become unsigned, resulting in 100% failure on > negative signed result comparison. > > >> Ian >> >
Re: signed/unsigned comparison warning level
On 27/09/2010 07:51, J Decker wrote:
The standards did not leave this open. They define precisely what is
supposed to happen.
Really? I'll have to drop this whole lobbying effort then. That
makes me sad that they didn't define it to be comparing of the numbers
where there are overlaps in signed and unsigned instead of causing all
negative signed values to be wrong.
Your basic problem here is that you are thinking of mathematically ideal
integers and numbers - C works using an approximation that fits a
balance between "real world" numbers and the arithmetic supported by
typical processors.
For example, the standards say explicitly that unsigned integers wrap
modulo 2^n - that doesn't happen with real-world integers.
The compiler is generating the correct code for source written in C. If
the C language doesn't work the way you think here, then you can enable
the warnings to get a message when there are conflicts - you can then
manually and explicitly write the code you want (maybe casting one or
both operands to "long long int").
But if it's not fixed, this warning should definatly be issued at
default warning level. This should be more like 'if this comparison
can be wrong, it will be wrong'.
There is no problem comparing values of signed type with values of
unsigned type if the signed values are known to be nonnegative. Of
course it is sometimes hard to know that; hence the warning. But
enabling the warning by default does not make sense.
It's exactly the fact that 'of course it is sometimes' that makes
the warning make more sense to be on by default. I don't always know
that I've added an unsigned value to an expression, causing one side
of a comparison to become unsigned, resulting in 100% failure on
negative signed result comparison.
If you don't know what code you are writing, then you should be more
careful in your programming. If your code depends on whether parts of
an expression are signed or unsigned, and it is not entirely clear from
the context, then use explicit casts so that the compiler, the code
author, and other code readers know exactly what is happening.
The compiler cannot spot every possible arithmetic error. What do you
expect the compiler to do with a function like this?
int foo(unsigned int x) {
if ((x + 1) > 0) return 1;
return 0;
}
If "int" worked like real mathematical integers, it would always return
1. If "int" works like it does on most processors, then it will return
0 if i is equal to ((unsigned int) -1).
You have two choices here. You can learn how "int" and "unsigned int"
actually work in C, and program accordingly using casts as necessary and
enabling warnings for safety. Or you can switch to a language which
provides much better checking of this sort of thing, such as Ada.
There are good reasons why the warning is not enabled by default. It is
far from rare in C programs to have mixed use of signed and unsigned
data, and in the vast majority of cases it is done safely. For some
types of programs you want to enable warnings like this and explicitly
add type-casts to remove the warnings, but in most cases the warnings
would be annoying noise that makes it harder to find real errors.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Hello Luke, Luke A. Guest wrote: > I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. Thanks :-) > Any pointers would be gratefully received. I'm fairly sure I know where > to start. A few general points, jic. The first thing will be to adjust your target system.ads to have GCC_ZCX_Support := True, then use the gnatlib-zcx Makefile target, with essentially two effects: adjust your target system.ads further to switch the GCC_ZCX_Support to True as well, and arrange to build/link with the "-gcc" variants of a-exexpr.adb and raise.c. The system.ads changes control the compiler to declare eh regions, produce dwarf eh info etc. The use of -gcc variants is for the runtime library, switching to the libgcc services for exception propagations. raise-gcc.c hosts the Ada personality routine, where a number of changes will be needed I believe. There, please, I'd rather have the ARM specializations abstracted as much as possible, e.g. with new functions and alternate implementations, instead of provided as #ifdefs blocks spread within existing functions. Thanks, Olivier
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote: > Hello Luke, > > Luke A. Guest wrote: > > I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. > > Thanks :-) Well, I'm reading as much as I can regarding this, but finding it hard to work some things out. I've been reading through: http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example code in C++ and Ada, but it doesn't seem to match up in some places, i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains the function. > > Any pointers would be gratefully received. I'm fairly sure I know where > > to start. > > A few general points, jic. > > The first thing will be to adjust your target system.ads to > have GCC_ZCX_Support := True, then use the gnatlib-zcx Makefile > target, with essentially two effects: adjust your target system.ads > further to switch the GCC_ZCX_Support to True as well, and arrange > to build/link with the "-gcc" variants of a-exexpr.adb and raise.c. Yup, aware of this so far. > The system.ads changes control the compiler to declare eh regions, produce > dwarf eh info etc. Yup. > The use of -gcc variants is for the runtime library, switching to the > libgcc services for exception propagations. > > raise-gcc.c hosts the Ada personality routine, where a number of changes > will be needed I believe. Also, I think tracebak.c is where the ARM specific routine(s) will need to go, included from another file tb-armlinux.c? I think this will be required as (if I'm right), different ARM CPU's have differing number of registers, and I think I read in the ARM docs that float regs won't need to be saved if they're not used. I could be wrong about this though. > There, please, I'd rather have the ARM specializations abstracted as > much as possible, e.g. with new functions and alternate implementations, > instead of provided as #ifdefs blocks spread within existing functions. Well, I think that's possible to a point, obviously some things will have to go into ifdef's unfortunately (it's not Ada :D). Hopefully, I can rely on some help from you AdaCore guys? This is my first foray into GCC internals :/ Thanks, Luke.
Re: Bugzilla outage Thursday, September 23, 18:00GMT-21:00GMT
On Sun, Sep 26, 2010 at 4:01 AM, Ian Lance Taylor wrote: > Jonathan Wakely writes: > >> Thank you, Frédéric, despite a few bug reports the upgrade went very >> smoothly and it's great that we have a modern version of Bugzilla now. >> >> Was it a conscious decision for the "Add me to CC list" checkbox to be >> ticked by default? It means that I get added to the CC list whenever >> I comment on a bug, something I do often as a maintainer, but I rarely >> want to be CC'd by default. I follow most bugs via the email archives >> and only CC myself on bugs I am especially interested in (I use >> searching for myself in the CC list as a search for the bugs I care >> most about.) >> >> I'm sure I can get used to unticking the checkbox before I comment, >> I'm just wondering if I'm the only one who preferred the old >> behaviour. > > I kind of like the new default, but it's not a big deal to me. Because you don't touch every bug at least one ;) Richard. > Ian >
Alignment error
Hi, This is regarding to the alignment error generated by GDB when compiled in same GCC with u-boot makefile. I wrote a small code consisting of following statements for the ARM platform int* pInt = (int*)0x10002004; //word-aligned char* pChar = (char* )0x10003005; //non-word-aligned *pInt = 0x34; *pChar = 'A'; The assembly mnemonics for the above two statements are STR and STRB respectively. This I made part of the u-boot and build successfully for the smdk2400 platform. But when I debugged with GDB, *pChar = 'A' throwed an exception. Later, I put the above code snippet into my own main() and compiled at the command prompt without any makefile. This time also STR and STRB respectively were generated. But it worked without any exception in the same gdb. So, the same source code and also the same ASM mnemonic works differently with the code generation commands(i.e., gcc). In this regard, I am searching for the gcc command line argument present in the u-boot makefile which throws exception in GDB for accessing non-word-aligned address that corresponds to char*. Kindly give me useful tips. Regards, Thomas Joseph __ Scanned and protected by Email scanner
Re: Alignment error
Hi Thomas, [Note: You sent this to g...@sourceware.org but the correct address to use is g...@gcc.gnu.org]. int* pInt = (int*)0x10002004; //word-aligned char* pChar = (char* )0x10003005; //non-word-aligned *pInt = 0x34; *pChar = 'A'; The assembly mnemonics for the above two statements are STR and STRB respectively. This I made part of the u-boot and build successfully for the smdk2400 platform. But when I debugged with GDB, *pChar = 'A' throwed an exception. What kind of exception ? There should be no restrictions on byte accesses to memory, unless the memory region itself is restricted to Priviledged access only. So, the same source code and also the same ASM mnemonic works differently with the code generation commands(i.e., gcc). In this regard, I am searching for the gcc command line argument present in the u-boot makefile which throws exception in GDB for accessing non-word-aligned address that corresponds to char*. Kindly give me useful tips. If you add "-v" to the gcc command line that is being generated by your u-boot makefile then gcc will display the command line that it uses to invoke the compiler, assembler and linker. If that does not work then you could try placing a small script in the execution search path ahead of the real gcc that echos its arguments and then calls the real gcc. Cheers Nick
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Luke A. Guest wrote:
> Well, I'm reading as much as I can regarding this, but finding it hard
> to work some things out.
That's a pretty complex and very precise machinery overall.
> I've been reading through:
> http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example
> code in C++ and Ada, but it doesn't seem to match up in some places,
> i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains
> the function.
There's a variety of registration functions and some targets
don't resort to such calls at all, see unwind-dw2-fde-glibc.c.
A quick glance suggests that your arm-linux port might be using the
latter (from t-linux if I'm not mistaken, I'm not at all familiar with
the port though).
[...]
> Yup, aware of this so far.
[...]
> Yup.
> > raise-gcc.c hosts the Ada personality routine, where a number of changes
> > will be needed I believe.
>
> Also, I think tracebak.c
Sure, was just suggesting starters. You will have made good progress
when you get to traceback issues :) It's useful to have a global
idea of course.
Another aspect is the possible need for special processing to get through
signal handlers (the fallback_frame_state buisness on other targets).
The capability to raise from signal handlers is often useful in Ada, and
typically available with the base sjlj runtime.
Not clear to me if this would require anything special not already there
for arm-linux.
> is where the ARM specific routine(s) will need to go, included from
> another file tb-armlinux.c?
> I think this will be required as (if I'm right), different ARM CPU's
> have differing number of registers, and I think I read in the ARM
> docs that float regs won't need to be saved if they're not used. I
> could be wrong about this though.
While I know there are arm-eabi specifics wrt unwinding, I'm really
not familiar with the details so I'm not sure what exactly will be
needed for traceback computations.
Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ?
If not, ISTM we'd more need something like a tb-armeabi variant. To
be confirmed.
> > There, please, I'd rather have the ARM specializations abstracted as
> > much as possible, e.g. with new functions and alternate implementations,
> > instead of provided as #ifdefs blocks spread within existing functions.
>
> Well, I think that's possible to a point, obviously some things will
> have to go into ifdef's unfortunately (it's not Ada :D).
Sure. All I'm saying is that I'd prefer
#if ARM
void foo ()
void bar ()
#else
void foo ()
void bar ()
#endif
void dosomething ()
{
...
foo ()
...
bar ()
...
}
or alternate C files to
void dosomething ()
{
...
#if ARM
foo blob 1
#else
foo blob 2
#endif
...
#if ARM
bar blob 1
#else
bar blob 2
#endif
}
especially when that needs to be repeated in several places.
> Hopefully, I can rely on some help from you AdaCore guys?
Some, sure :) As I said we aren't familiar with the details of the ARM
EH specifics and we're not running arm-linux in-house, so ...
Now if you get something working, we can comment on the integration
scheme for the Ada specific parts.
> This is my first foray into GCC internals :/
Welcome :-D
Out of curiosity, why did you choose that particular topic (ZCX for
Ada on arm-linux) ? Does this just happen to seem of interest for
learning purposes, or is there a more specific need ?
Olivier
Re: eliminating mpc/mpfr and reducing gmp
On 09/27/2010 01:23 AM, Jay K wrote: > > Hi. You know, gmp/mpfr/mpc are a significant > portion of building any frontend/backend. I disagree. Most of the time I don't notice them. > The result is a lot faster to build, if you are just doing a just > a single stage build of a compiler. Sure, but if you're working on the compiler you don't need to rebuild mpfr et al. If you're not, it only happens once. On my box, for mpc: real0m2.624s user0m3.336s sys 0m1.663s and for mpfr: real0m4.484s user0m12.006s sys 0m5.127s Andrew.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On 09/27/2010 10:36 AM, Luke A. Guest wrote: > On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote: >> Hello Luke, >> >> Luke A. Guest wrote: >>> I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. >> >> Thanks :-) > > Well, I'm reading as much as I can regarding this, but finding it hard > to work some things out. I've been reading through: > http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example > code in C++ and Ada, but it doesn't seem to match up in some places, > i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains > the function. > >>> Any pointers would be gratefully received. I'm fairly sure I know where >>> to start. >> >> A few general points, jic. >> >> The first thing will be to adjust your target system.ads to >> have GCC_ZCX_Support := True, then use the gnatlib-zcx Makefile >> target, with essentially two effects: adjust your target system.ads >> further to switch the GCC_ZCX_Support to True as well, and arrange >> to build/link with the "-gcc" variants of a-exexpr.adb and raise.c. > > Yup, aware of this so far. > >> The system.ads changes control the compiler to declare eh regions, produce >> dwarf eh info etc. > > Yup. > >> The use of -gcc variants is for the runtime library, switching to the >> libgcc services for exception propagations. >> >> raise-gcc.c hosts the Ada personality routine, where a number of changes >> will be needed I believe. > > Also, I think tracebak.c is where the ARM specific routine(s) will need > to go, included from another file tb-armlinux.c? I think this will be > required as (if I'm right), different ARM CPU's have differing number of > registers, and I think I read in the ARM docs that float regs won't need > to be saved if they're not used. I could be wrong about this though. > >> There, please, I'd rather have the ARM specializations abstracted as >> much as possible, e.g. with new functions and alternate implementations, >> instead of provided as #ifdefs blocks spread within existing functions. > > Well, I think that's possible to a point, obviously some things will > have to go into ifdef's unfortunately (it's not Ada :D). > > Hopefully, I can rely on some help from you AdaCore guys? This is my > first foray into GCC internals :/ The best clue you're going to get is my work to solve the same problem in libgcj. Most of what you need to know is in libjava/exception.cc. See Revision 128098. Andrew.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
On Mon, 2010-09-27 at 12:33 +0200, Olivier Hainque wrote: > Luke A. Guest wrote: > > Well, I'm reading as much as I can regarding this, but finding it hard > > to work some things out. > > That's a pretty complex and very precise machinery overall. You're not wrong. > > I've been reading through: > > http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example > > code in C++ and Ada, but it doesn't seem to match up in some places, > > i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains > > the function. > > There's a variety of registration functions and some targets > don't resort to such calls at all, see unwind-dw2-fde-glibc.c. > > A quick glance suggests that your arm-linux port might be using the > latter (from t-linux if I'm not mistaken, I'm not at all familiar with > the port though). I can't see any mention of unwind in the the t-linux-eabi file, I'm probably missing something I just don't unerstand here :D > While I know there are arm-eabi specifics wrt unwinding, I'm really > not familiar with the details so I'm not sure what exactly will be > needed for traceback computations. > > Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ? I would expect so, but again, not sure on this yet. > especially when that needs to be repeated in several places. Fair enough. > > Hopefully, I can rely on some help from you AdaCore guys? > > Some, sure :) As I said we aren't familiar with the details of the ARM > EH specifics and we're not running arm-linux in-house, so ... > > Now if you get something working, we can comment on the integration > scheme for the Ada specific parts. Ok. > > This is my first foray into GCC internals :/ > > Welcome :-D > > Out of curiosity, why did you choose that particular topic (ZCX for > Ada on arm-linux) ? Does this just happen to seem of interest for > learning purposes, or is there a more specific need ? In #Ada there are always people coming in and asking if there is an ARM GNAT, which we always say "sort of..." ARM CPU's aren't the fastest on the planet and not having EABI EH to help with this is something that really needs to be done imho. Also, with the ever increasing number of ARM CPU's out there, having Ada on them would useful (if only to a few of us). It makes sense to me that a language which was designed for embedded use, doesn't get much embedded use :/ in the mainstream. Thanks, Luke.
Re: signed/unsigned comparison warning level
On 27 September 2010 05:19, J Decker wrote: > > I don't know why standards left this open, other than there isn't a > single-instruction translation from code to CPU for the comparison; > > But if it's not fixed, this warning should definatly be issued at > default warning level. This should be more like 'if this comparison > can be wrong, it will be wrong'. Please, see http://c-faq.com/expr/preservingrules.html The warnings that you want are Wsign-compare and Wsign-conversion. They are not enabled by default because they produce a lot of false positives: http://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions Cheers, Manuel.
RE: eliminating mpc/mpfr and reducing gmp
Wow that is fast. My fastest machine, and I have several slower: gmp time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 2m2.594s mpfr time sh -c "./configure -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 0m43.756s mpc time sh -c "./configure -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 0m15.495s which is still a significant fraction of building cc1 (I don't have that time sorry) I used to use Cygwin. Things add up much faster there. > mpfr et al. If you're not, it only happens once. Almost anything long but incremental can be justified via incrementality. But there is also, occasionally, mass bouts of trying to get the configure switches just right and starting over repeatedly...at least me being unsure of incrementality in the fact of rerunning configure... Anyway, just putting it out there, probably won't happen, but configure -without-mpc -without-mpfr might be nice and aren't difficult, -without-gmp much better, but I can't yet claim it isn't difficult. Maybe, something like, if gmp is "in tree", after configure, the Makefile could be hacked down to omit mpf, mpq, and lots others, but then the linkage between gcc and gmp gets messy. i.e. as gmp changes. - Jay > Date: Mon, 27 Sep 2010 11:37:04 +0100 > From: a...@redhat.com > To: jay.kr...@cornell.edu > CC: gcc@gcc.gnu.org > Subject: Re: eliminating mpc/mpfr and reducing gmp > > On 09/27/2010 01:23 AM, Jay K wrote: > > > > Hi. You know, gmp/mpfr/mpc are a significant > > portion of building any frontend/backend. > > I disagree. Most of the time I don't notice them. > > > The result is a lot faster to build, if you are just doing a just > > a single stage build of a compiler. > > Sure, but if you're working on the compiler you don't need to rebuild > mpfr et al. If you're not, it only happens once. > > On my box, for mpc: > > real 0m2.624s > user 0m3.336s > sys 0m1.663s > > and for mpfr: > > real 0m4.484s > user 0m12.006s > sys 0m5.127s > > Andrew.
Re: eliminating mpc/mpfr and reducing gmp
On Mon, Sep 27, 2010 at 1:39 PM, Jay K wrote: > > Wow that is fast. > > > My fastest machine, and I have several slower: > > > gmp > time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared > -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" > real 2m2.594s > > mpfr > time sh -c "./configure -disable-shared -enable-static && make && ssh > r...@localhost \"cd `pwd` && make install\"" > real 0m43.756s > > mpc > time sh -c "./configure -disable-shared -enable-static && make && ssh > r...@localhost \"cd `pwd` && make install\"" > real 0m15.495s > > > which is still a significant fraction of building cc1 (I don't have that time > sorry) > > I used to use Cygwin. Things add up much faster there. > > >> mpfr et al. If you're not, it only happens once. > > > Almost anything long but incremental can be justified via incrementality. > But there is also, occasionally, mass bouts of trying to get the configure > switches just right and > starting over repeatedly...at least me being unsure of incrementality in the > fact of rerunning configure... > > > Anyway, just putting it out there, probably won't happen, but configure > -without-mpc -without-mpfr might be nice > and aren't difficult, -without-gmp much better, but I can't yet claim it > isn't difficult. > Maybe, something like, if gmp is "in tree", after configure, the Makefile > could be hacked down > to omit mpf, mpq, and lots others, but then the linkage between gcc and gmp > gets messy. > i.e. as gmp changes. No, we don't want that. It'll exlode the testing matrix and we'd get weird bugreports for missed optimizations. Richard. > > - Jay > > >> Date: Mon, 27 Sep 2010 11:37:04 +0100 >> From: a...@redhat.com >> To: jay.kr...@cornell.edu >> CC: gcc@gcc.gnu.org >> Subject: Re: eliminating mpc/mpfr and reducing gmp >> >> On 09/27/2010 01:23 AM, Jay K wrote: >> > >> > Hi. You know, gmp/mpfr/mpc are a significant >> > portion of building any frontend/backend. >> >> I disagree. Most of the time I don't notice them. >> >> > The result is a lot faster to build, if you are just doing a just >> > a single stage build of a compiler. >> >> Sure, but if you're working on the compiler you don't need to rebuild >> mpfr et al. If you're not, it only happens once. >> >> On my box, for mpc: >> >> real 0m2.624s >> user 0m3.336s >> sys 0m1.663s >> >> and for mpfr: >> >> real 0m4.484s >> user 0m12.006s >> sys 0m5.127s >> >> Andrew. > >
Simple development GCC and G++
A while back I posted a question about adding edit-and-continue abilities. Since then I've begun work on a rapid development compiler (rdc) which has these abilities, but I've had some thoughts I'd like to share, and receive some feedback from the GCC experts: What if a subset of GCC could be used for this? A portion which uses the parser to push properly parsed instructions to a new code generator module which handles the entirety of the edit-and-continue requirements? I would offer to write these. These abilities would be one part of the other part, which would be changes to GDB which allow the changes to be updated against the executable code image in memory. The goal here would not be to have ANY code speed, code size, or anything glorious in the generated code, but would be only a true and wholly accurate representation in execution as dictated by the original source code, with all traditional step-through line-by-line debugging abilities being generated, but with the added new ability to allow compilation of changed source code, merged into the existing executable and image in memory without leaving or restarting the app. The product I've been developing is a simple C/C++ compiler that basically does what I've described. It's in early stages, and it occurred to me that it might be easy or easier for me to add this new edit-and-continue module to both GCC and GDB, and then have the existing GCC community reap the benefits of this added feature, being maintained from here on out -- by me at first, but whoever else would want to do it at some point. Any thoughts? Thank you in advance. - Rick C. Hodgin - Email me for phone contact info if you want to talk to me personally.
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
[resending a reply sent to a private copy]
From: Olivier Hainque
To: "Luke A. Guest"
Subject: Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Date: Mon, 27 Sep 2010 15:18:59 +0200
Luke A. Guest wrote:
> > A quick glance suggests that your arm-linux port might be using the
> > latter (from t-linux if I'm not mistaken, I'm not at all familiar with
> > the port though).
>
> I can't see any mention of unwind in the the t-linux-eabi file, I'm
> probably missing something I just don't unerstand here :D
I was thinking of
config.gcc
arm*-*-linux*) # ARM GNU/Linux with ELF
...
tmake_file="${tmake_file} t-linux arm/t-arm"
^^^
then in config/t-linux
# Use unwind-dw2-fde-glibc
...
> > Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ?
>
> I would expect so, but again, not sure on this yet.
We'll see.
> > Out of curiosity, why did you choose that particular topic (ZCX for
> > Ada on arm-linux) ? Does this just happen to seem of interest for
> > learning purposes, or is there a more specific need ?
>
> In #Ada there are always people coming in and asking if there is an ARM
> GNAT, which we always say "sort of..." ARM CPU's aren't the fastest on
> the planet and not having EABI EH to help with this is something that
> really needs to be done imho.
[...]
I see, thanks.
Cheers,
Olivier
Re: Simple development GCC and G++
On Mon, Sep 27, 2010 at 07:47:48AM -0500, Rick C. Hodgin wrote:
> A while back I posted a question about adding edit-and-continue
> abilities.
Are you sure that is feasible? I mean, in principle, a caching
incremental compiler is probably feasible, but I cannot figure how you
could edit the source code of a running process. What should happen
when your user add new local variables?
> Since then I've begun work on a rapid development compiler
> (rdc) which has these abilities, but I've had some thoughts I'd like to
> share, and receive some feedback from the GCC experts:
>
> What if a subset of GCC could be used for this? A portion which uses
> the parser to push properly parsed instructions to a new code generator
> module which handles the entirety of the edit-and-continue requirements?
> I would offer to write these.
There has been some experimental work on the idea of incremental
compilation, see http://gcc.gnu.org/wiki/IncrementalCompiler & ask Tom
Tromey. I believe he arrived to the conclusion it might not worth the
effort, but I am not sure at all.
You might want to reuse a lot of code from GCC. I would imagine that
the front-end & the back-end could be reused, and that your work might
become some middle-end pass.
If you just want to add some clever middle-end pass, consider perhaps
using MELT (see http://gcc.gnu.org/wiki/MELT for more, or ask me) to
prototype it.
You could use GCC for your goals, which I don't understand well in the
detail. It seems that you want to re-edit & recompile code within a
running process. But what happens if your user adds a new big variable
(e.g. an automatic array) inside a middle stack frame (so changes the
call stack)?
So my guess is that you are aiming an impossible goal. But perhaps I
misunderstood you!
>
> These abilities would be one part of the other part, which would be
> changes to GDB which allow the changes to be updated against the
> executable code image in memory.
>
> The goal here would not be to have ANY code speed, code size, or
> anything glorious in the generated code, but would be only a true and
> wholly accurate representation in execution as dictated by the original
> source code, with all traditional step-through line-by-line debugging
> abilities being generated, but with the added new ability to allow
> compilation of changed source code, merged into the existing executable
> and image in memory without leaving or restarting the app.
>
> The product I've been developing is a simple C/C++ compiler that
> basically does what I've described. It's in early stages,
If your product is based upon GCC, it should be a free GPLv3 licenced
software (since it is derived from GCC GPLv3 source code).
> and it occurred to me that it might be easy or easier for me to add
> this new edit-and-continue module to both GCC and GDB, and then have
> the existing GCC community reap the benefits of this added feature,
> being maintained from here on out -- by me at first, but whoever
> else would want to do it at some point.
I probably misunderstood your goals, because my feeling is that you
would dream of changing the source code of a running C application and
incrementally re-feeding it into the running process, and I don't
understand how you handle the variation of internal call stack frames,
and even what that would mean to your user.
If you really want the user to change code and continue running,
consiser studying old Andrew Appel's "Compiling with Continuations"
book. But that won't work for old C code (unless you radically change
the ABI to something very incompatible).
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 mines, sont seulement les miennes} ***
Re: Simple development GCC and G++
> A while back I posted a question about adding edit-and-continue > abilities. Since then I've begun work on a rapid development compiler > (rdc) which has these abilities, but I've had some thoughts I'd like to > share, and receive some feedback from the GCC experts: > > What if a subset of GCC could be used for this? A portion which uses > the parser to push properly parsed instructions to a new code generator > module which handles the entirety of the edit-and-continue requirements? > I would offer to write these. Most of the interesting bits happen in the linker+debugger. "gcc -ffunction- sections -fdata-sections -fPIC" is likely to be pretty good in terms of compiler output. What you then need is a linker that will relink an image, changing it as little as possible relative to a previous run. Your debugger then needs to be able to replace these images in-place (which may require interaction with the dynamic linker). Be warned that this ends up being extremely complex, even for relatively simple changes. Paul
Re: Simple development GCC and G++
> Most of the interesting bits happen in the linker+debugger... Agreed, which is why the compiler side doesn't matter much in terms of how much it does, just so long as it is correct and compliant. This is the hard part I'm finding, which is why I'm looking to the GCC community which spends a great deal of effort maintaining that compliance. The GCC portion (which generates the input to this process which writes the alternate kind of output which accommodates everything necessary to feed the linker and program database with enough information that it may handle multiple compiles over time, etc.) coupled to this new "managing back-end" would enable the ability, when coupled also to changes in gdb which allow it. > What you then need is a linker that will relink an image, changing it as > little as possible relative to a previous run. Your debugger then needs to > be > able to replace these images in-place (which may require interaction with the > dynamic linker). Exactly. That is exactly it. > Be warned that this ends up being extremely complex, even for relatively > simple changes. If the design was implemented in such a way that each source code line or function was contained in its own logical unit, then it becomes a simple matter of replacement. The linker would determine code generation size to see if it could overlay the existing block that was previously at that location before the code change, and if so then overwrite it, adjusting the instruction pointer to the new instruction location in the process, or if it could not, then it would NOP-out everything that's there and insert a branching instruction to some new location tagged on to the end of the executable, which executes the new, larger amount of code, before branching back then to continue in the program where it would've been originally. If you look at the way Microsoft handles this by tracing through the disassembly view, it is very straight-forward, though I agree with you that it can be very complex. - Rick
Re: Simple development GCC and G++
On Mon, 27 Sep 2010 09:57:24 -0500
> If you haven't used this feature in Microsoft's Visual Studio, you can
> download Microsoft Visual Studio Express for free and see it in action.
[off-topic]
Well, I would imagine that Visual Studio Express runs only on Microsoft
Windows. Unfortunately, I don't have any Windows system (I am a free
software enthusiast, using Linux since 1993, and Unix before that).
And I am not particularily fond of coding in C or C#.
Thanks for your detailed reply.
--
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: Porting ZCX (not SJLJ) for GNAT ARM EABI
On 09/27/2010 03:47 AM, Luke A. Guest wrote: > I can't see any mention of unwind in the the t-linux-eabi file, I'm > probably missing something I just don't unerstand here :D Because it's in config/arm/t-bpabi. Do be clear on whether you're working on arm-linux-eabi, i.e. with the ARM EABI unwind information, or whether you're mistakenly doing something with the old pre-eabi code. r~
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
On Thu, Apr 29, 2010 at 4:07 PM, Steven Bosscher wrote: > 2010/4/30 Jan Hubicka : >> Yep, I read that page (and saw some of implementation too). Just was not >> able >> to follow the precise feature set of LIPO (i.e. if it gets better SPEC >> results >> than LTO+FDO then why) > > OK, that's an interesting question. The first question (if...) is > something you'll have to try yourself, I suppose :-) > > BTW will the CGO presentation about LIPO and sampled FDO be published > somewhere in the open? All the slides from CGO are available here: http://www.cgo.org/cgo2010/talks/ > > Ciao! > Steven > -- Neil Vachharajani Google 650-214-1804
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
On Fri, Apr 30, 2010 at 12:07 PM, Xinliang David Li wrote: > > On Fri, Apr 30, 2010 at 11:12 AM, Jan Hubicka wrote: > >> > > >> > Interesting. My plan for profiling with LTO is to ultimately make it > >> > linktime > >> > transform. This will be more difficult with WHOPR (i.e. instrumenting > >> > need > >> > function bodies that are not available at WPA time), but I believe it is > >> > solvable: just assign uids to the edges and do instrumentation at > >> > ltrans. Then > >> > we will save cgraph profile in some easier way so WHOPR can read it in > >> > and read > >> > rest of stuff in ltrans. This would invovlve shipping the correct > >> > profiles for > >> > given function etc so it will be a bit of implementation challenge. > >> > >> This can be tricky -- to maximize FDO benefit, the > >> profile-use/annotation needs to happen early which means > >> instrumentation also needs to happen early (to avoid cfg mismatches). > > > > I don't see much problem in this particular area. > > > > GCC optimization queue is organized in a way that we first do early > > optimizatoins that all are intended to be simple cleanups without size/speed > > tradeoffs. Then we do IPA and late optimizations that are both driven by > > profile (estimated or read). > > Profile reading happens early because we use same infrastructure for gcov > > and > > profile feedback. This is not giving profile feedback better benefit, > > quite a > > converse since early passes may not be able to update profile precisely and > > we > > also get higher profile overhead. > > > > So I think decoupling gcov and profile feedback and pushing profile feedback > > back in queue is going to be win. > > > > There are two parts of profile-feedback > 1) cfg edge counts annotation. > > For this part, yes, most of the early phases (other than possibly > einline-2) do not need/depend on, and can probably pushed back (in > fact the static/guessed profile pass is later). > > 2) value profile transformations: > > This part may benefit more from doing early -- not only because of > more cleanups, but also due to the requirement for getting more > precise inline summary. > > > > Yes, optimization must match, but with LTO this is not problem and in > > general > > the early optimization should be stable wrt memory layout (nothing else > > changes). This used to be excercised before profiling was updated to tree > > level in 4.x. > > > You mean CFG layout is stable? but ccp, copy_prop, dce, tail recursion > etc all can change cfg. > > > > > I would be very interested in the low overhead support - there is a lot to > > gain > > especially because the profiling resuls are less dependent on setup and can > > be > > better reused. I know part of code was contributed (the support for > > reading not > > 100% valid profiles). Is there any extra info available on this? > > > > For profile smoothing, Neil may point to more information. Sorry for the *very* delayed response, but some email filters went a bit wild. Profile smoothing does a good job of taking imprecise profiles and fixing them up. This doesn't address the stale profile problem with GCC instrumentation based FDO profile collection. There are checks which completely discard profiles if the function line numbers (IIRC) do not match. I have some patches I've been meaning to send upstream which help ease this restriction (i.e., add the ability to retain more of a stale profile), but this opens up many bugs which I've been incrementally squashing throughout the rest of the compiler. > > > Main problem IMO is how to get profile into WHOPR without having function > > bodies. > > I guess we will end up with summarizing the info in WHOR firendly way and > > letting it to stream the other counters to LTRANS that will annotate the > > function > > body once read in from the file. > >> > > I am a little lost here :) > > >> > >> > > >> >> 2) comdat function resolution -- since LIPO uses aux module functions > >> >> for inlining purpose only, it has the freedom to choose which copy to > >> >> use. The current scheme chooses copy in current module with priority > >> >> for better profile data context sensitivity (see below) > >> > > >> > This is interesting. How do you solve the problem when given comdat > >> > function > >> > "loose"? I.e. it is replaced at linktime by other function that may or > >> > may > >> > not be profiled from other unit? > >> > >> Whatever function that is selected will have profile data (assuming it > >> called at runtime) -- but the profile data are merged from different > >> contexts including from calls in different modules. For instance, > >> both a.C and b.C define foo. and b.C:foo is selected at runtime, and > >> a.C:foo is not inlined (after instrumentation) anywhere in a.C, then > >> a.C:foo won't have any profile data, and b.C:foo has merged profile > >> data resulting from calls in both a.C and b.C. > > > > Yes, but this is what I am concerned about.
rx-elf: sched2 dependency question
In this example, why isn't insn 117 scheduled before insn 115 ? What
is the dependency? The only thing they have in common is CC, but both
generate a value which is never used.
;; ==
;; -- basic block 15 from 114 to 118 -- after reload
;; ==
;; dependencies resolved: insn 114
;; tick updated: insn 114 into ready
;; Ready list after queue_to_ready:114:46
;; Ready list after ready_sort:114:46
;; Ready list (t = 0):114:46
;;0--> 114 r12=sxn([r14]):throughput,nothing
;; dependencies resolved: insn 115
;; Ready-->Q: insn 115: queued for 2 cycles.
;; tick updated: insn 115 into queue with cost=2
;; Ready list (t = 0):
;; Q-->Ready: insn 115: moving to ready with 1 stalls
;; Ready list after queue_to_ready:115:47
;; Ready list after ready_sort:115:47
;; Ready list (t = 2):115:47
;;2--> 115 {r12=r3+r12;cc=cmp(r3+r12,0x0);} :throughput
;; dependencies resolved: insn 116
;; Ready-->Q: insn 116: queued for 1 cycles.
;; tick updated: insn 116 into queue with cost=1
;; dependencies resolved: insn 117
;; Ready-->Q: insn 117: queued for 1 cycles.
;; tick updated: insn 117 into queue with cost=1
;; Ready list (t = 2):
;; Q-->Ready: insn 117: moving to ready without stalls
;; Q-->Ready: insn 116: moving to ready without stalls
;; Ready list after queue_to_ready:116:49 117:48
;; Ready list after ready_sort:116:49 117:48
;; Ready list (t = 3):116:49 117:48
;;3--> 117 {r4=r4+0x1;cc=cmp(r4+0x1,0x0);} :throughput
;; Ready list (t = 3):116:49
;; Ready list after queue_to_ready:116:49
;; Ready list after ready_sort:116:49
;; Ready list (t = 4):116:49
;;4--> 116 [r14]=r12 :throughput
;; dependencies resolved: insn 118
;; tick updated: insn 118 into ready
;; Ready list (t = 4):118:50
;; Ready list after queue_to_ready:118:50
;; Ready list after ready_sort:118:50
;; Ready list (t = 5):118:50
;;5--> 118 {r14=r14+0x2;cc=cmp(r14+0x2,0x0);}:throughput
;; Ready list (t = 5):
;; Ready list (final):
;; total time = 5
;; new head = 114
;; new tail = 118
;; Start of basic block ( 14 9) -> 15
;; bb 15 artificial_defs: { }
;; bb 15 artificial_uses: { u-1(0){ }}
;; lr in0 [r0] 1 [r1] 2 [r2] 3 [r3] 4 [r4] 7 [r7] 11 [r11] 14 [r14] 15
[r15]
;; lr use 0 [r0] 3 [r3] 4 [r4] 14 [r14]
;; lr def 4 [r4] 12 [r12] 14 [r14] 16 [cc]
;; live in 0 [r0] 1 [r1] 2 [r2] 3 [r3] 4 [r4] 7 [r7] 11 [r11] 14 [r14] 15
[r15]
;; live gen 4 [r4] 12 [r12] 14 [r14] 16 [cc]
;; live kill
;; Pred edge 14 [100.0%] (fallthru,can_fallthru)
;; Pred edge 9 [25.0%] (can_fallthru)
(code_label 311 102 120 15 1121 "" [1 uses])
(note 120 311 113 15 [bb 15] NOTE_INSN_BASIC_BLOCK)
(note 113 120 114 15 NOTE_INSN_DELETED)
(insn 114 113 115 15 dj.c:256 (set (reg:SI 12 r12 [138])
(sign_extend:SI (mem:HI (reg:SI 14 r14 [orig:24 ivtmp.929 ] [24]) [2 S2
A16]))) 60 {extendhisi2} (nil))
(insn 115 114 117 15 dj.c:256 (parallel [
(set (reg:SI 12 r12 [139])
(plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ] [54])
(reg:SI 12 r12 [138])))
(set (reg:CC_ZSC 16 cc)
(compare:CC_ZSC (plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ]
[54])
(reg:SI 12 r12 [138]))
(const_int 0)))
]) 72 {addsi3} (expr_list:REG_UNUSED (reg:CC_ZSC 16 cc)
(nil)))
(insn 117 115 116 15 dj.c:255 (parallel [
(set (reg/v:SI 4 r4 [orig:31 j ] [31])
(plus:SI (reg/v:SI 4 r4 [orig:31 j ] [31])
(const_int 1)))
(set (reg:CC_ZSC 16 cc)
(compare:CC_ZSC (plus:SI (reg/v:SI 4 r4 [orig:31 j ] [31])
(const_int 1))
(const_int 0)))
]) 72 {addsi3} (expr_list:REG_UNUSED (reg:CC_ZSC 16 cc)
(nil)))
(insn 116 117 118 15 dj.c:256 (set (mem:HI (reg:SI 14 r14 [orig:24 ivtmp.929 ]
[24]) [2 S2 A16])
(reg:HI 12 r12 [139])) 58 {*movhi_internal} (expr_list:REG_DEAD (reg:HI
12 r12 [139])
(nil)))
(insn 118 116 310 15 dj.c:255 (parallel [
(set (reg:SI 14 r14 [orig:24 ivtmp.929 ] [24])
(plus:SI (reg:SI 14 r14 [orig:24 ivtmp.929 ] [24])
(const_int 2)))
(set (reg:CC_ZSC 16 cc)
(compare:CC_ZSC (plus:SI (reg:SI 14 r14 [orig:24 ivtmp.929 ]
[24])
(const_int
Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64
On Mon, Sep 27, 2010 at 11:04:10AM -0700, Neil Vachharajani wrote: > On Thu, Apr 29, 2...@4:07 PM, Steven Bosscher wrote: > > 2010/4/30 Jan Hubicka : > >> Yep, I read that page (and saw some of implementation too). Just was not > >> able > >> to follow the precise feature set of LIPO (i.e. if it gets better SPEC > >> results > >> than LTO+FDO then why) > > > > OK, that's an interesting question. The first question (if...) is > > something you'll have to try yourself, I suppose :-) > > > > BTW will the CGO presentation about LIPO and sampled FDO be published > > somewhere in the open? > > All the slides from CGO are available here: > http://www.cgo.org/cgo2010/talks/ > > > > > Ciao! > > Steven > > > FYI, my recent Polyhedron 2008 benchmark runs for llvm-gcc-4.2 2.8rc2 on x86_64-apple-darwin10 indicates that there are some significant performance regressions between 2.7 and 2.8. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034780.html > > > -- > Neil Vachharajani > Google > 650-214-1804
Re: rx-elf: sched2 dependency question
DJ Delorie writes: > In this example, why isn't insn 117 scheduled before insn 115 ? What > is the dependency? The only thing they have in common is CC, but both > generate a value which is never used. I don't see anything in sched-deps.c which prevents using a register for scheduling dependencies even if there is a REG_UNUSED note. Perhaps this is a bug. Or perhaps I'm missing something. In the debugger you should be able to use sd_debug_lists to dump all the dependency information for the insns. Ian
Re: rx-elf: sched2 dependency question
On 09/27/2010 01:30 PM, DJ Delorie wrote:
> (insn 115 114 117 15 dj.c:256 (parallel [
> (set (reg:SI 12 r12 [139])
> (plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ] [54])
> (reg:SI 12 r12 [138])))
> (set (reg:CC_ZSC 16 cc)
> (compare:CC_ZSC (plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ]
> [54])
> (reg:SI 12 r12 [138]))
> (const_int 0)))
> ]) 72 {addsi3} (expr_list:REG_UNUSED (reg:CC_ZSC 16 cc)
> (nil)))
I think it's probably a mistake to have the default ADD
instruction SET the flags, rather than CLOBBER them.
That said, I suppose it wouldn't hurt to modify sched-deps
to treat a SET+REG_UNUSED as a CLOBBER.
r~
Re: rx-elf: sched2 dependency question
> I think it's probably a mistake to have the default ADD > instruction SET the flags, rather than CLOBBER them. How else would we optimize away compares?
Re: rx-elf: sched2 dependency question
On 09/27/2010 03:37 PM, DJ Delorie wrote: >> I think it's probably a mistake to have the default ADD >> instruction SET the flags, rather than CLOBBER them. > > How else would we optimize away compares? By having a separate ADD that looks like your current one. Combine will put them together for you. Compare i386 (define_insn "*add_1" [(set (match_operand:SWI48 0 "nonimmediate_operand" "=r,rm,r,r") (plus:SWI48 (match_operand:SWI48 1 "nonimmediate_operand" "%0,0,r,r") (match_operand:SWI48 2 "" ",r,0,l"))) (clobber (reg:CC FLAGS_REG))] "ix86_binary_operator_ok (PLUS, mode, operands)" ... (define_insn "*add_2" [(set (reg FLAGS_REG) (compare (plus:SWI (match_operand:SWI 1 "nonimmediate_operand" "%0,0") (match_operand:SWI 2 "" ",")) (const_int 0))) (set (match_operand:SWI 0 "nonimmediate_operand" "=,m") (plus:SWI (match_dup 1) (match_dup 2)))] "ix86_match_ccmode (insn, CCGOCmode) && ix86_binary_operator_ok (PLUS, mode, operands)" ... r~
Re: rx-elf: sched2 dependency question
Would we have to do that for *all* the math/logic ops, or just add?
Re: rx-elf: sched2 dependency question
On 09/27/2010 04:21 PM, DJ Delorie wrote: > Would we have to do that for *all* the math/logic ops, or just add? All of them of course. r~
Re: rx-elf: sched2 dependency question
> That said, I suppose it wouldn't hurt to modify sched-deps
> to treat a SET+REG_UNUSED as a CLOBBER.
Early in sched_analyze_reg, check for ref==USE and a REG_UNUSED note,
and change ref to CLOBBER? I tried it, it didn't seem to help...
Index: sched-deps.c
===
--- sched-deps.c(revision 164652)
+++ sched-deps.c(working copy)
@@ -2116,12 +2116,16 @@ sched_analyze_reg (struct deps_desc *dep
if (!reload_completed && sel_sched_p ()
&& (regno >= max_reg_num () - 1 || regno >= deps->max_reg))
extend_deps_reg_info (deps, regno);
maybe_extend_reg_info_p ();
+ if (ref == SET
+ && find_regno_note (insn, REG_UNUSED, regno))
+ref = CLOBBER;
+
/* A hard reg in a wide mode may really be multiple registers.
If so, mark all of them just like the first. */
if (regno < FIRST_PSEUDO_REGISTER)
{
int i = hard_regno_nregs[regno][mode];
if (ref == SET)
Re: eliminating mpc/mpfr and reducing gmp
On 27/09/2010 12:39, Jay K wrote: > gmp > time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared > -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" > real2m2.594s > > mpfr > time sh -c "./configure -disable-shared -enable-static && make && ssh > r...@localhost \"cd `pwd` && make install\"" > real0m43.756s > > mpc > time sh -c "./configure -disable-shared -enable-static && make && ssh > r...@localhost \"cd `pwd` && make install\"" > real0m15.495s > which is still a significant fraction of building cc1 (I don't have that > time sorry) Huh, am I doing something seriously wrong? It takes me four hours to boostrap GCC at with all languages enabled at -j8 on an AMD2x64; I'm not too concerned about 3 minutes per pass! cheers, DaveK
64-bit pei vs dwarf2
The 64-bit PEI format has a SECREL32 relocation type. It does not, however, have a SECREL64 relocation type. Which means that for > #define DWARF_REF_SIZE \ > (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE) we don't really have something to use for for dwarf2. I could fake it with .secrel32 ref .long 0 but it seems better simply to force the use of dwarf3 for this target. Suggestions about how to go about this within the tangled mess of option processing? r~
RE: eliminating mpc/mpfr and reducing gmp
I only do one language, no driver, one stage, no libraries (none of libgcc, libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably fine, and aren't used by this frontend anyway), the bootstrap compiler is always pretty decent, thus one stage (or I'll "cheat" and do one full regular bootstrap+install of a recent release on the occasional oddball host). It takes under 10 minutes on year old MacBook. (sorry, I didn't measure). I guess it is very unusual, but it is also actually very useful. Everyone else probably depends on good incrementality when actively changing stuff, or pays a higher price overall when occasionally building the entire thing clean and not changing stuff, so this is minor. We understand each other, fair enough. - Jay > Date: Tue, 28 Sep 2010 01:51:31 +0100 > From: dave.korn.cyg...@gmail.com > To: jay.kr...@cornell.edu > CC: a...@redhat.com; gcc@gcc.gnu.org > Subject: Re: eliminating mpc/mpfr and reducing gmp > > On 27/09/2010 12:39, Jay K wrote: > > > gmp > > time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared > > -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" > > real 2m2.594s > > > > mpfr > > time sh -c "./configure -disable-shared -enable-static && make && ssh > > r...@localhost \"cd `pwd` && make install\"" > > real 0m43.756s > > > > mpc > > time sh -c "./configure -disable-shared -enable-static && make && ssh > > r...@localhost \"cd `pwd` && make install\"" > > real 0m15.495s > > > > which is still a significant fraction of building cc1 (I don't have that > > time sorry) > > > Huh, am I doing something seriously wrong? It takes me four hours to > boostrap GCC at with all languages enabled at -j8 on an AMD2x64; I'm not too > concerned about 3 minutes per pass! > > cheers, > DaveK >
Re: 64-bit pei vs dwarf2
On 28/09/2010 01:29, Richard Henderson wrote: > The 64-bit PEI format has a SECREL32 relocation type. It > does not, however, have a SECREL64 relocation type. Which > means that for > >> #define DWARF_REF_SIZE \ >> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE) > > we don't really have something to use for for dwarf2. > > I could fake it with > > .secrel32 ref > .long 0 > > but it seems better simply to force the use of dwarf3 > for this target. Suggestions about how to go about this > within the tangled mess of option processing? Override PREFERRED_DEBUGGING_TYPE in mingw-w64.h? cheers, DaveK
Re: eliminating mpc/mpfr and reducing gmp
On 28/09/2010 02:01, Jay K wrote: > I only do one language, no driver, one stage, no libraries (none of libgcc, > libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably > fine, and aren't used by this frontend anyway), the bootstrap compiler is > always pretty decent, thus one stage (or I'll "cheat" and do one full > regular bootstrap+install of a recent release on the occasional oddball > host). > > > It takes under 10 minutes on year old MacBook. (sorry, I didn't measure). Well, the other thing is: why not just build them once and install them to your $prefix? There's no need to build them in-tree every time if you have sufficiently up-to-date versions installed. cheers, DaveK
RE: eliminating mpc/mpfr and reducing gmp
> Well, the other thing is: why not just build them once and install them to > your $prefix? There's no need to build them in-tree every time if you have > sufficiently up-to-date versions installed. > > cheers, > DaveK I have a CVS tree, used by others, that builds a frontend. "Others" are a few people and a few automated build machines (using Hudson), with various operating systems (Linux, Solaris, Darwin, FreeBSD, etc.). The requirements on these machines isn't of course zero -- they exist, they are up and running -- but is kept low where possible. So the decision was made, not exactly by me, but I went along, to add gmp+mpfr to the tree, and later mpc. It's pretty simple, reliable, works. What I was often doing was deleting gmp/mpfr in my local CVS tree, leaving configure to find them in /usr/local. And then sometimes I'd accidentally restore them with cvs upd -dAP. I toyed with the idea of having it always check /usr/local first but didn't do that. What if user has an insufficient version there? I'd have to test for that and fallback to in-tree. Since we are using Hudson we could probably add nice automation, to build gmp/mpfr/mpc "somewhere", neither /usr/local, nor "in gcc", maybe install to $HOME/hudson, and point the frontend build at them. But the Hudson stuff...is not well known to me, I'd kind of rather leave it alone. And I'd have to e.g. deal with the gmp inline problem, just another small detail... I'm satisfied so far with the pruning. I can see it isn't for everyone. We'll see, maybe I'll grow to dislike it as well. - Jay
Re: 64-bit pei vs dwarf2
2010/9/28 Richard Henderson :
> The 64-bit PEI format has a SECREL32 relocation type. It
> does not, however, have a SECREL64 relocation type. Which
> means that for
>
>> #define DWARF_REF_SIZE \
>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>
> we don't really have something to use for for dwarf2.
>
> I could fake it with
>
> .secrel32 ref
> .long 0
>
> but it seems better simply to force the use of dwarf3
> for this target. Suggestions about how to go about this
> within the tangled mess of option processing?
>
>
> r~
>
Well, dwarf-3 is ok, if it helps to solve the issue. On the other hand
to fake it by secrel32 ref ; .long 0 looks not wrong to me. As PE+
is limited in image size to 2GB there should be any issue about it. A
section relative offset can't get bigger then 2^31 bits.
We could introduce here a .seclrel64 relocation, but wouldn't be
covered by standard.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: 64-bit pei vs dwarf2
2010/9/28 Kai Tietz :
> 2010/9/28 Richard Henderson :
>> The 64-bit PEI format has a SECREL32 relocation type. It
>> does not, however, have a SECREL64 relocation type. Which
>> means that for
>>
>>> #define DWARF_REF_SIZE \
>>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>>
>> we don't really have something to use for for dwarf2.
>>
>> I could fake it with
>>
>> .secrel32 ref
>> .long 0
>>
>> but it seems better simply to force the use of dwarf3
>> for this target. Suggestions about how to go about this
>> within the tangled mess of option processing?
>>
>>
>> r~
>>
>
> Well, dwarf-3 is ok, if it helps to solve the issue. On the other hand
> to fake it by secrel32 ref ; .long 0 looks not wrong to me. As PE+
> is limited in image size to 2GB there should be any issue about it. A
> section relative offset can't get bigger then 2^31 bits.
> We could introduce here a .seclrel64 relocation, but wouldn't be
> covered by standard.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
The fix would be then in cygming.h ASM_OUTPUT_DWARF_OFFSET to emit for
64-bit, if SIZE == 8, an additional .long 0 after the .secrel32.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
