Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote: From: "David Edelsohn" AIX Shell is KSH. The problem is shell append += and libtool not running with the same shell used by configure. Hm, the mpc configure script actually has a check for shell +=, and on my solaris box it correctly detects that it doesn't work. checking whether the shell understands "+="... no Presumably on solaris then += isn't used. I wonder what does configure say here for AIX and why does it attempt to use it? As David said, the problem is using the same shell in configure and libtool. I think I fixed this upstream (just as a consequence of cleanups). Paolo
Re: is LTO aimed for large programs?
On 11/09/2009 12:03 AM, Basile STARYNKEVITCH wrote: > is gcc-trunk -flto -O2 aimed for medium sized programs (something like > bash), or for bigger ones (something like the linux kernel, the Xorg > server, the Qt or GTK graphical toolkit libraries, or bootstrapping GCC > itself. My understanding is that LTO aims at both, but that one needs to use -fwhopr for really large systems as the otherwise e.g. the memory usage may exceed the available memory. I don't know whether one can really estimated how much memory compilation needs. It is surely not a simple function on the number of code lines. I tried -flto successfully for our 100 kLoC Fortran code and there lto1 needs <1/2 GB of RAM (370 MB if I recall correctly). (Thanks to especially Richard; initially more than 4 GB were needed and lto1 crashed thus). Toon also used LTO [1] for their HIRLAM weather forecasting program, which has according to [2] 1.2 MLoC in Fortran and O(10 kLoC) in C. If I recall correctly, bootstrapping GCC also works in principle, except for problems when comparing stage2 with stage3. > Perhaps the question is when not to use -flto and use -fwhopr instead? My rule of thumb is: Try -flto first, if it does not work (running out of memory), try -fwhopr. I think the advantage of -flto is also that it is better tested, while -fwhopr has known issues. Tobias [1] http://gcc.gnu.org/ml/gcc/2009-10/msg00122.html [2] http://moene.org/~toon/GCCSummit-2006.pdf
Re: is LTO aimed for large programs?
On Mon, Nov 9, 2009 at 10:44 AM, Tobias Burnus wrote: > On 11/09/2009 12:03 AM, Basile STARYNKEVITCH wrote: >> is gcc-trunk -flto -O2 aimed for medium sized programs (something like >> bash), or for bigger ones (something like the linux kernel, the Xorg >> server, the Qt or GTK graphical toolkit libraries, or bootstrapping GCC >> itself. > > My understanding is that LTO aims at both, but that one needs to use > -fwhopr for really large systems as the otherwise e.g. the memory usage > may exceed the available memory. I don't know whether one can really > estimated how much memory compilation needs. It is surely not a simple > function on the number of code lines. > > I tried -flto successfully for our 100 kLoC Fortran code and there lto1 > needs <1/2 GB of RAM (370 MB if I recall correctly). (Thanks to > especially Richard; initially more than 4 GB were needed and lto1 > crashed thus). Toon also used LTO [1] for their HIRLAM weather > forecasting program, which has according to [2] 1.2 MLoC in Fortran and > O(10 kLoC) in C. > > If I recall correctly, bootstrapping GCC also works in principle, except > for problems when comparing stage2 with stage3. > > >> Perhaps the question is when not to use -flto and use -fwhopr instead? > > My rule of thumb is: Try -flto first, if it does not work (running out > of memory), try -fwhopr. I think the advantage of -flto is also that it > is better tested, while -fwhopr has known issues. Indeed for 4.5 I wouldn't recommend on using -fwhopr at all. The compile-time penalty is dependent on the complexity of the IPA passes we run - and I have no idea if they are currently worse than linear in the number of cgraph nodes or edges. The main issue with LTO is memory usage as you have to keep the whole program in memory. Another issue is that with excessive inlining (which we avoid by default, but of course you can tweak params) you can more easily hit non-linear time- and memory complexity in function local passes. Richard.
Re: How to run gcc test suite in pure mingw32 environment?
徐持恒 wrote: > These days, I’m trying to build gcc-4.4.2 + binutils-2.20 + gmp + mpfr in > Msys+MinGW and Cygwin environment. > > The builds on both environments are OK, but I cannot run "make check", or > "make check-gcc". > > Finally, I found, that, to run test, you must first install guile, autogen, > tck/tk, expect, dejagnu. > This "self-hosted" idea is quite the same as trying to produce cars in garages or even on roads because they will be used there... I myself would be more interested to get these tests for MinGW-hosted tools to work on Linux because that is the "preferred build platform for MinGW-hosted tools" for me. Some years ago I produced more than 100 binutils+GCC+GDB/Insight toolchains for all kind of targets to be run on the MinGW runtime host. Just for a fun... The tests regarding to "does it work" happening on Windoze/MinGW via compiling apps there and then possibly running them on the built-in simulator in GDB or using the standalone "$target-run" simulator on the console. When all the $target systems for the MinGW-hosted binutils, GCCs and GDB/Insights are non-Windoze targets, the question is about how well these tools would work on Windoze and are the results from them identical with their equivalents on the primary Linux host. What maybe could be usable, would be some kind of "gdbserver" to run on Windoze and run the MinGW-hosted toolchain tests "natively" there. What has been the "problem" is that those very limited tests on the Windoze/MinGW host have this far showed the toolchains to work quite identically with their earlier equivalents on the Linux host, for instance a toolchain for "arm-elf" on MinGW-host working nicely on Windoze too. So really no need to wonder how to get "make check" to work with the Canadian-cross built toolchains... > Is't it necessary to port newlib to pure MinGW environment ? I tried to understand what this clause means but didn't "grok" it... Could you elaborate what the point is? "Pure MinGW" means "running apps using the native Windoze DLLs" meanwhile Cygwin (and MSYS?) try to provide a "Unix layer" for the apps like binutils, GCC and GDB. For instance the tcl/tk/itcl DLLs are for Win32 API in the MinGW-hosted Insights... > If we have test environment on Windows platform, we can greatly improve the > development process in this platform ,and ensure the quality of gcc and > companion tools on Windows. I noticed that there are also a MinGW-w64 > project, if we have that test environment, we can impove it, even accelerate > it. > When producing those 100+ toolchains for MinGW, my conclusion was : "In the same time when one developer builds 100 toolchains for MinGW host on a productive build platform, there must be 100 developers to get just one toolchain (for MinGW target) being built on the native Windoze build platform :( Just name your $target(s) and I will report how many minutes it takes to build gcc-4.4.2 + binutils-2.20 (and the gmp + mpfr for MinGW host) for it and for MinGW $host on Linux $build host Producing Insight 6.8 for MinGW host and for a couple of targets like 'mips-elf' seemed to work nicely on July 2009 but some targets might still be problems with the MinGW $host. For instance making a remote debugger for 'sparc-solaris2.11' or some embedded Linux target to run on MinGW host
Re: How to run gcc test suite in pure mingw32 environment?
2009/11/9 Kai Ruottu :
> I myself would be more interested to get these tests for MinGW-hosted
> tools to work on Linux because that is
> the "preferred build platform for MinGW-hosted tools" for me. Some years
> ago I produced more than 100
> binutils+GCC+GDB/Insight toolchains for all kind of targets to be run on
> the MinGW runtime host. Just for a
> fun... The tests regarding to "does it work" happening on Windoze/MinGW
> via compiling apps there and then
> possibly running them on the built-in simulator in GDB or using the
> standalone "$target-run" simulator on the
> console.
The testruns we do for 32-bit and 64-bit of mingw-w64 are done on a
linux host by cross-compilation and are executed on a remote Windows
host. ssh and rexec can be used here. NightStrike can give here more
details.
> What has been the "problem" is that those very limited tests on the
> Windoze/MinGW host have this far
> showed the toolchains to work quite identically with their earlier
> equivalents on the Linux host, for instance
> a toolchain for "arm-elf" on MinGW-host working nicely on Windoze too.
> So really no need to wonder how
> to get "make check" to work with the Canadian-cross built toolchains...
Indeed, to make a cross-compiler (especially on cygwin and linux)
makes absolutely sense. In fact it is at the moment (as the expect
tool isn't ported for native Windows hosts) the only way to do
regression tests.
>> Is't it necessary to port newlib to pure MinGW environment ?
This makes no sense. Possibly your initial idea here isn't
understandable, so could you give us more details about this?
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: is LTO aimed for large programs?
On Sun, Nov 8, 2009 at 18:03, Basile STARYNKEVITCH wrote: > Perhaps the question is when not to use -flto and use -fwhopr instead? I don't think anyone has systematically tried to determine these limits. The original design tried to address a specific instance of a program with about 400 million callgraph nodes. At the time, -flto was running out of virtual addressing space to hold it (the gcc binary was 32 bits), but it could be processed with -fwhopr. The current implementation of -fwhopr is incomplete, however. It needs fixes to the pass manager to properly apply all IPA passes (and associated bug fixes). I would not use it in 4.5. Richi has made numerous fixes to symbol/type handling, so -flto is now more memory efficient than it was when I last tried it on a large application. Diego.
Re: is LTO aimed for large programs?
On Mon, Nov 9, 2009 at 1:35 PM, Diego Novillo wrote: > On Sun, Nov 8, 2009 at 18:03, Basile STARYNKEVITCH > wrote: > >> Perhaps the question is when not to use -flto and use -fwhopr instead? > > I don't think anyone has systematically tried to determine these > limits. The original design tried to address a specific instance of a > program with about 400 million callgraph nodes. At the time, -flto > was running out of virtual addressing space to hold it (the gcc binary > was 32 bits), but it could be processed with -fwhopr. Hm, as WPA needs the whole cgraph in memory and a single cgraph node (not counting any edges or decls) is 256 bytes large that would require 97GB ram alone for cgraph nodes. So I don't believe you ;) Even with 400 thousand cgraph nodes you'd run out of virtual memory on 32bits unless the cgraph node size on 32bit is less than 10 bytes which it is of course not ... (btw, a function decl is also 240 bytes). I think we can scale to a million cgraph nodes on a 64bit host with lots of memory (remember we need to pull in all decls and types during WPA phase). Richard.
Re: How to write shift and add pattern?
2009/11/6 Richard Henderson :
> On 11/06/2009 05:29 AM, Mohamed Shafi wrote:
>>
>> The target that i am working on has 1& 2 bit shift-add patterns.
>> GCC is not generating shift-add patterns when the shift count is 1. It
>> is currently generating add operations. What should be done to
>> generate shift-add pattern instead of add-add pattern?
>
> I'm not sure. You may have to resort to matching
>
> (set (match_operand 0 "register_operand" "")
> (plus (plus (match_operand 1 "register_operand" "")
> (match_dup 1))
> (match_operand 2 "register_operand" ""
>
> But you should debug make_compound_operation first to
> figure out what's going on for your port, because it's
> working for x86_64:
>
> long foo(long a, long b) { return a*2 + b; }
>
> leaq (%rsi,%rdi,2), %rax # 8 *lea_2_rex64
> ret # 26 return_internal
>
>
> r~
>
I have fixed this. The culprit was the cost factor. I added the
case in targetm.rtx_costs and now it works properly. But i am having
issues with the reload.
Regards,
Shafi
Re: is LTO aimed for large programs?
On Mon, Nov 9, 2009 at 07:47, Richard Guenther wrote: > So I don't believe you ;) Even with 400 thousand cgraph nodes > you'd run out of virtual memory on 32bits unless the cgraph > node size on 32bit is less than 10 bytes which it is of course not ... You are right. I was thinking 400k, not 400m. Sorry about that. Diego.
Re: How to write shift and add pattern?
2009/11/6 Ian Lance Taylor : > Mohamed Shafi writes: > >> It is generating with data registers. Here is the pattern that i have >> written: >> >> >> (define_insn "*saddl" >> [(set (match_operand:SI 0 "register_operand" "=r,d") >> (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "r,d") >> (match_operand:SI 2 "const24_operand" "J,J")) >> (match_operand:SI 3 "register_operand" "0,0")))] >> >> How can i do this. Will the constraint modifiers '?' or '!' help? >> How can make GCC generate shift and add sequence when the shift count is 1? > > Does 'd' represent a data register? I assume that 'r' is a general > register, as it always is. What is the constraint character for an > address register? You don't seem to have an alternative here for > address registers, so I'm not surprised that the compiler isn't > picking it. No doubt I misunderstand something. > Ok the constrain for address register is 'a'. Thats typo in the pattern that i given here. The proper pattern is (define_insn "*saddl" [(set (match_operand:SI 0 "register_operand" "=a,d") (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "a,d") (match_operand:SI 2 "const24_operand" "J,J")) (match_operand:SI 3 "register_operand" "0,0")))] So how can i choose the address registers over data registers if that is more profitable? Regards, Shafi
RE: Understanding IRA
Dave Hudson wrote: > On Thu, 2009-11-05 at 18:05 +, Ian Bolton wrote: > > I think I may have made a breakthrough! > > > > As mentioned above, IRA is correctly increasing the cost for TOP_REGS > > when an allocno in region 1 is being used in one of our special > > instructions that needs BOTTOM_REGS. We can also see that IRA is > > passing that allocno cost up to the associated allocno in region 0 > and > > altering the total_cost for that allocno. > > > > However, it does not appear as though IRA is doing anything with the > > total_costs, apart from using it to determine the preferred class for > > the allocno. When the main logic of the algorithms comes into play, > > we only look at allocno_costs, which do not take into account the > > future usage of that register in the allocno in region 1. > > > > I believe that if the decisions were made based on total_costs then I > > would get a better allocation with existing IRA. Before I experiment > > with this, I was wondering what the motivation is for only looking > > at allocno_costs? > > > > BTW, I did look into using the ! and * constraints, but I don't think > > they could help. Our architecture is like Motorola 68k in that we > have > > some instructions that can use all the registers and some that can > > only use the subset (BOTTOM_REGS). The latter type can only specify > > "b" for their constraint, since they can only go in BOTTOM_REGS. The > > former type might benefit from "b,!t", so we are more likely to get > > things in BOTTOM_REGS for when they are later needed there, but the > > flip-side is that we might also fill up BOTTOM_REGS when actually > there > > was no subsequent need for the value to be in BOTTOM_REGS. I may > have > > misunderstood how all this works, but it looks like constraints will > > not help here and, in fact, the total_costs calculations that I > > mention above are precisely the way IRA passes information about > > register requirements upwards. > > I've been working on gcc for an ISA (Ubicom32) that seems to have some > similarities to the problem you're seeing (we have some regs that can > be > used for many things but not all) and was seeing a ton a pointless > moves > introduced by reload. > > I've ended up trying quite a few different strategies including > defining > different cover classes and the strategy we're now using is to leave > the > cover classes the same way you have them but found that the most > critical thing was to ensure that REGNO_REG_CLASS was returning a > minimal class correctly. Once I had this right then IRA started to do > the right thing most of the time (-Os still isn't great but -O2 usually > looks very good now). We still see some problems but they're usually a > result of reload messing things up or suboptimal handling of > auto-incrementing in MEMs. Thanks for the info, Dave. Given that C_REGS = r0-r31, BOTTOM_REGS = r0-r15, TOP_CREGS = r16-r31, when you say "minimal class", does that mean that I should change my macro from this: /* Map a register number to a register class. */ #define REGNO_REG_CLASS(REGNO) \ (BOTTOM_C_REG_P (REGNO) ? BOTTOM_REGS : \ (REGNO) == LINK_POINTER_REGNUM ? LINK_REGS : \ C_REG_P (REGNO) ? C_REGS : \ D_REG_P (REGNO) ? D_REGS : \ CSR_REG_P (REGNO) ? CSR_REGS : \ (unsigned)(REGNO) < FIRST_PSEUDO_REGISTER ? INTERNAL_REGS : ALL_REGS) to this (see C_REG_P line for change): /* Map a register number to a register class. */ #define REGNO_REG_CLASS(REGNO) \ (BOTTOM_C_REG_P (REGNO) ? BOTTOM_REGS : \ (REGNO) == LINK_POINTER_REGNUM ? LINK_REGS : \ C_REG_P (REGNO) ? TOP_CREGS :\ D_REG_P (REGNO) ? D_REGS : \ CSR_REG_P (REGNO) ? CSR_REGS : \ (unsigned)(REGNO) < FIRST_PSEUDO_REGISTER ? INTERNAL_REGS : ALL_REGS) I made the change and nothing noticeable happened, but maybe once I fix whatever else needs fixing then the second version of the macro will be better?
Re: How to support 40bit GP register
2009/10/22 Richard Henderson : > On 10/21/2009 07:25 AM, Mohamed Shafi wrote: >> >> For accessing a->b GCC generates the following code: >> >> move.l (sp-16), d3 >> lsrr.l #<16, d3 >> move.l (sp-12),d2 >> asll #<16,d2 >> or d3,d2 >> cmpeq.w #<2,d2 >> jf _L2 >> >> Because data registers are 40 bit for 'asll' operation the shift count >> should be 16+8 or there should be sign extension from 32bit to 40 bits >> after the 'or' operation. The target has instruction to sign extend >> from 32bit to 40 bit. >> >> Similarly there are other operation that requires sign/zero extension. >> So is there any way to tell GCC that the data registers are 40bit and >> there by expect it to generate sign/zero extension accordingly ? > > Define a machine mode for your 40-bit type in cpu-modes.def. Depending on > how your 40-bit type is stored in memory, you'll use either > > INT_MODE (RI, 5) // load-store uses exactly 5 bytes > FRACTIONAL_INT_MODE (RI, 40, 8) // load-store uses 8 bytes > > Where I've arbitrarily chosen "RImode" as a mnemonic for Register Integral > Mode. Now you define arithmetic operations, as needed, on > RImode. You define the "extendsiri" pattern to be that sign-extend from > 32-to-40-bit instruction. You define your comparison patterns on RImode, > and not on SImode, since your comparison instruction works on the entire 40 > bits. > > You'll wind up with a selection of patterns in your machine description that > have a sign-extension pattern built in, depending on the exact behaviour of > your ISA. There are plenty of examples on x86_64, mips64, and Alpha (to > name a few) that have similar properties with SI and DImodes. Examine the > -fdump-rtl-combine-details dump for exemplars of the canonical forms that > the combiner creates when it tries to merge sign-extension instructions into > preceeding patterns. > Ok i have comparison patterns written in RImode. When you say that i will wind up with a selection of patterns do you mean to say that i should have patterns for operations that operate on full 40bits in RImode and disable the corresponding SImode patterns? Or is it that i have to write nameless patterns in RImode for arithmetic operations and look at the dumps to see how the combiner will merge the patterns so that it can match the comparison operations? Regards, Shafi
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
Hi Joern,
> After checking in the patch to provide unique pass names for all passes,
> I created
>
> svn://gcc.gnu.org/svn/gcc/branches/ici-20091108-branch
>
> and merged in the patches from:
>
> http://gcc-ici.svn.sourceforge.net/svnroot/gcc-ici/branches/patch-gcc-4.4.0-ici-2.0
>
> Could you please check that this contains the functionality that we want to
> integrate in the first step.
Thanks a lot, Joern!
I downloaded it and will be gradually checking it.
In the mean time, Yuanjie, Liang and Yuri - could you check this version ASAP
and check that the functionality provided during GSOC'09 developments/pass
reordering
work is correct in this version!.. The reason is that since there will be some
small
changes, our plugins will have to slightly change as well (see register_pass
change)...
By the way, we should keep the track of such changes on the GCC Wiki for ICI ...
> FWIW I know that the code does not conform to the GNU coding standard yet.
>
> I've changed register_pass to register_pass_name to resolve the name clash.
> I'm not sure if it should be called register_pass_by_name or something else,
> opinions welcome.
I think register_pass_by_name will be better to show what it does now ;) ...
> Both the gcc 4.5 code and the ICI patches have the concept of events, but
> the implementations are so different that the functionality is pretty much
> orthogonal.
>
> 4.5 has a real C-style interface with an enum to identify the event and
> a single pointer for the data. I.e. low overhead, but rigid typing,
> and the different parts of the program presumably find their data by virtue
> of using the same header files.
> Multiple plugins can register a callback for any event, and all will get
> called. However, since the set of events is hard-coded by an enum
> declaration, you can't have two plugins communicating using events that
> the gcc binary doesn't know about.
>
> The ICI events feel much more like TCL variables and procedure calls.
> Events are identified by strings, and parameters are effectively global
> variables found in a hash table. This is very flexible and can allow
> a good deal of ABI stability, but costs a lot of processor cycles as
> before an event call the parameters are looked up to be entered in the hash
> table, and afterwards they are looked up to be removed, even if no callback
> is registered for the event.
> Also, when a plugin registers a callback for an ICI event, it overrides any
> previous callback registered by another (or even the same) plugin.
That's very true. Our current idea is that for prototyping of ideas, it is
often fine to slow down the compiler slightly but as soon as development
matures and there are some interesting results, the developers will try
to persuade the GCC community to add the event permanently...
> I think we could have the ICI event flexibility/stability with lower
> overhead if the event sender requests an event identifier number (which
> can be allocated after the numbers of the gcc 4.5 static event enum values)
> for an event name at or before the first event with that name, and then
> sends this identifier number with one or more pointers, which might point
> to internal gcc data structures, and a pointer to a function to look up
> the address of a named parameter. The event sender site source code can
> then provide information to build the lookup functions at build time,
> e.g. using gperf.
>
> I.e.:
> /* Call an event with number ID, which is either a value of enum plugin_event,
> or a number allocated for a named event. If the event named parameters,
> the first parameter after id should be as if declared
> void * (*lookup_func) (const char *, va_list) .
> LOOKUP_FUNC can be passed the name of a parameter as its first argument,
> and a va_list as its second argument, which will be the list of parameters
> after LOOKUP_FUNC, to find the named parameter. */
> void
> call_plugin_event (int id, ...)
> {
>struct callback_info *callback;
>va_list ap;
>
>gcc_assert (id < event_id_max);
>callback = plugin_callbacks[id];
>va_start (ap, id);
>for (callback = plugin_callbacks[id]; callback; callback = callback->next)
> (*callback->func) ((void *) ap, callback->user_data);
>va_end (ap);
> }
I have been discussing that with Zbigniew some months ago and I think it can be
reasonable
to add such functionality on top of current ICI. ICI users will still prototype
their ideas
using events referenced by name, however if it works fine and before potential
lengthy approval
to get such an event, they can speed up their plugins using this extended
functionality...
The good thing is that their plugins will still be compatible if we will decide
to keep associated
names with the hardwired event number ...
Cheers,
Grigori
Re: 答复: How to run gcc test suite in pure mingw32 environment?
徐持恒 wrote: > Thank you, I'll give it a try. > > But can you tell me why there are no testresult of MinGW or Cygwin on > gcc-testresults mailinglist ? That's not correct. I haven't done it for a few weeks because I've been busy on other stuff, but Christian J. is still posting them regularly for Cygwin: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00451.html http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00337.html http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00137.html http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02827.html The last one I sent is at: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02682.html cheers, DaveK
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
> After checking in the patch to provide unique pass names for all passes, > I created > > svn://gcc.gnu.org/svn/gcc/branches/ici-20091108-branch > > and merged in the patches from: > > http://gcc-ici.svn.sourceforge.net/svnroot/gcc-ici/branches/patch-gcc-4.4.0-ici-2.0 By the way, not to forget - we should compile/test GCC with ICI with the following libraries (orthogonal to ICI but we need them for our experiments): * gmp & mpfr (for fortran) * ppl & cloog (for GRAPHITE) i.e. I configure GCC with the following flags: configure --enable-languages=c,c++,fortran --with-mpfr=$BUILD_DIR --with-gmp=$BUILD_DIR --with-ppl=$BUILD_DIR --with-cloog=$BUILD_DIR I used it for the GCC 4.4.0 - maybe some GRAPHITE related flags changed ... The idea is to have the same setup that we used for our local developments ... Also, we have been using ICI with C and Fortran a lot, but never checked C++ - it will be important to check it too ... Cheers, Grigori
Re: i370 port
Still making great progress. The process is being simplified. I have a question. I need to remap long names to short, and I wish to use #defines to do this as it is portable. So I have a whole lot of: #define align_functions ZZZ_1 #define align_functions_log ZZZ_2 etc and I have put them all into an mshort.h for convenience. Now all code needs to be exposed to this. ie libiberty and gcc. To fit in with the new style of building, I basically want to update ansidecl.h to do a: #ifdef PUREISO #include "mshort.h" #endif Does that seem reasonable? Actually I also need to #include "unixio.h" to include various types that must be present, st_ino or whatever too. I may have other miscellaneous defines as well. I'm still in the process of unwinding all the hacks I put in years ago. :-) Thanks. Paul.
Re: Preserving the argument spills for GDB
Yes I understand. I'm trying to give multiple options to the users in order to either have this enabled or not actually. I'm running into one issue. In order for this to work, it would be better if I could keep the top of the frame and the stack pointer in two separate registers. This way, whatever happens, I know where to find the top of the frame. I have set HARD_FRAME_POINTER_REGNUM and I have, after I store the hard_frame_pointer on the stack and update the stack pointer generated : /* Update HARD_FRAME_POINTER_REGNUM */ insn = emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx); RTX_FRAME_RELATED_P (insn) = 1; At the end of the function, I load back the hard_frame_pointer and set back the stack pointer. However, in O3, the compiler sometimes decides that my instruction is useless. For debugging purposes this is not good since I put the stack pointer and the return address in fixed places relative to this frame pointer and not the stack pointer (since the stack can move around depending on variable arguments, it's better to use that register). How can I force the prologue to keep this instruction. It is useless only in the case that there is no function call or no alloca. But I have a case where there is a function call and it is still removed. Any ideas ? Thank you very much for your input, Jc On Wed, Nov 4, 2009 at 11:45 AM, Ian Lance Taylor wrote: > Jean Christophe Beyler writes: > >>> You can force your writes to the stack to not be removed by making >>> them use UNSPEC_VOLATILE. You would write special define_insns for >>> this. >> >> Is there an architecture port that has done this already ? > > No, because, when given the choice, gcc prefers faster execution over > more reliable debugging at high optimization levels. > > Ian >
Re: How to write shift and add pattern?
Mohamed Shafi writes: >Ok the constrain for address register is 'a'. Thats typo in the > pattern that i given here. The proper pattern is > > (define_insn "*saddl" >[(set (match_operand:SI 0 "register_operand" "=a,d") >(plus:SI (mult:SI (match_operand:SI 1 "register_operand" "a,d") > (match_operand:SI 2 "const24_operand" "J,J")) > (match_operand:SI 3 "register_operand" "0,0")))] > > So how can i choose the address registers over data registers if that > is more profitable? If it is cheaper to move two values from data registers to address registers than it is to use two data registers for this instruction, then you should omit the d,d,J alternative. If it is cheaper to move one value from a data register to an address register than it is to use two data registers for this instruction, then you should use !, as in "=a,!d". Otherwise you should use ?, as in "=a,?d". You can additional ?'s for additional tuning if appropriate. Ian
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
Eric Botcazou writes: > > I was looking through the gcc-4.5 primary and secondary platform list > > to ensure we have coverage for MPC testing. It occurs to me that some > > of the OS versions are outdated. > > > > I've included the list from the page > > http://gcc.gnu.org/gcc-4.5/criteria.html > > > > Should we update: > > > > 1. solaris2.10 -> 2.11 > > Why move to a not-yet-released version? Indeed: while I regularly test on Solaris 11/SPARC at the moment, it's still so much of a moving target that this doesn't make any sense. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Preserving the argument spills for GDB
Jean Christophe Beyler writes: > How can I force the prologue to keep this instruction. It is useless > only in the case that there is no function call or no alloca. But I > have a case where there is a function call and it is still removed. Make the hard frame pointer register a fixed register, or add it to EPILOGUE_USES. Ian
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
> Eric Botcazou writes: > >> > I was looking through the gcc-4.5 primary and secondary platform list >> > to ensure we have coverage for MPC testing. It occurs to me that some >> > of the OS versions are outdated. >> > >> > I've included the list from the page >> > http://gcc.gnu.org/gcc-4.5/criteria.html >> > >> > Should we update: >> > >> > 1. solaris2.10 -> 2.11 >> >> Why move to a not-yet-released version? > > Indeed: while I regularly test on Solaris 11/SPARC at the moment, it's > still so much of a moving target that this doesn't make any sense. The issue may be one of "de facto" vs "defined as being" released. There is no such thing as a released Solaris revision that responds to uname with SunOS5.11 yet. When Sun/Oracle actually releases something AND you can buy a support contract for it then you have a valid platform in commercial use. Having said that .. I see roughly 30% of all my traffic from SunOS5.11 users on either Solaris Nevada or OpenSolaris beta releases. The question should be ... do we in the community end user world see SunOS5.11 as being a de facto release? I would say yes. Solaris 10 is the enterprise class commercial grade Solaris release and it is staying put for a long long long time yet. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: i370 port
"Paul Edwards" writes: > Now all code needs to be exposed to this. ie libiberty and > gcc. To fit in with the new style of building, I basically want > to update ansidecl.h to do a: > > #ifdef PUREISO > #include "mshort.h" > #endif > > Does that seem reasonable? The ISO C99 standard requires that an identifier have 31 significant initial characters, so PUREISO does not seem like the right name here. Based on your suggested #define's, your system seems even more restrictive than ISO C99 requires. I vaguely recall that ISO C90 requires 6 significant initial characters, so something like PURE_ISO_C90 might be right here. I can see that ansidecl.h is a tempting place to put this, but I don't think it is correct. ansidecl.h is used by many different programs, including the GNU binutils and gdb. Changes that are specific to gcc should be in gcc, probably in gcc/system.h. Changes specific to libiberty should be in libiberty, probably in include/libiberty.h. Ian
Re: How to support 40bit GP register
On 11/09/2009 06:13 AM, Mohamed Shafi wrote: Ok i have comparison patterns written in RImode. When you say that i will wind up with a selection of patterns do you mean to say that i should have patterns for operations that operate on full 40bits in RImode and disable the corresponding SImode patterns? Or is it that i have to write nameless patterns in RImode for arithmetic operations and look at the dumps to see how the combiner will merge the patterns so that it can match the comparison operations? The later. r~
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
Dennis Clarke writes: > > Eric Botcazou writes: > > > >> > I was looking through the gcc-4.5 primary and secondary platform list > >> > to ensure we have coverage for MPC testing. It occurs to me that some > >> > of the OS versions are outdated. > >> > > >> > I've included the list from the page > >> > http://gcc.gnu.org/gcc-4.5/criteria.html > >> > > >> > Should we update: > >> > > >> > 1. solaris2.10 -> 2.11 > >> > >> Why move to a not-yet-released version? > > > > Indeed: while I regularly test on Solaris 11/SPARC at the moment, it's > > still so much of a moving target that this doesn't make any sense. > > The issue may be one of "de facto" vs "defined as being" released. > > There is no such thing as a released Solaris revision that responds to > uname with SunOS5.11 yet. When Sun/Oracle actually releases something AND > you can buy a support contract for it then you have a valid platform in > commercial use. You can get support for the OpenSolaris distribution if you like, yet this is still very much work in progress, not a stable platform we can rely on. > Having said that .. I see roughly 30% of all my traffic from SunOS5.11 > users on either Solaris Nevada or OpenSolaris beta releases. > > The question should be ... do we in the community end user world see > SunOS5.11 as being a de facto release? I would say yes. Certainly not, even if it is widely used (primarily on laptops, I suppose). > Solaris 10 is the enterprise class commercial grade Solaris release and it > is staying put for a long long long time yet. Indeed, and even if we chose sparc-sun-solaris2.10 as the primary platform doesn't mean that *-*-solaris2.11 doesn't work, quite the contrary: I regularly test both and try to keep them working. Rainer - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
>> you can buy a support contract for it then you have a valid platform in >> commercial use. > > You can get support for the OpenSolaris distribution if you like I just went and looked ... you are correct, they have three levels in fact. It looks like $1080 for premium, $720 is standard business hours $324 is patches and updates with email tech support I think. So that makes it a real commercial platform in my mind. > is still very much work in progress, not a stable platform we can rely on. However, Solaris 10 was also a moving platoform in its first few releases but no one would debate it as a commercial grade release or not. I think Opensolaris must be looked at as viable and commercial grade. I am not at all biased in this regardless of the fact that I have been involved one way or another in the OpenSolaris project since day one. I'm very much an outside guy that just loves to experiment and perhaps even attempt to help where I can. >> Having said that .. I see roughly 30% of all my traffic from SunOS5.11 >> users on either Solaris Nevada or OpenSolaris beta releases. >> >> The question should be ... do we in the community end user world see >> SunOS5.11 as being a de facto release? I would say yes. > > Certainly not, even if it is widely used (primarily on laptops, I > suppose). Well, would Fedora Core on PowerPC or Ubuntu or Debian ( any release ) be considered a platform or does that just fall under a wide umbrella of "Linux" ? Some of those are barely used at all anymore. Consider running Linux on a DEC Alpha. Who does that anymore? Is this a popularity measurement or is this based on something more tangible and quantitative like "commercially supported"? >> Solaris 10 is the enterprise class commercial grade Solaris release and >> it is staying put for a long long long time yet. > > Indeed, and even if we chose sparc-sun-solaris2.10 as the primary platform > doesn't mean that *-*-solaris2.11 doesn't work, quite the contrary: I > regularly test both and try to keep them working. I test everything on *-*-solaris2.8 which by way of the ABI golden rule instantly qualifies as tested on anything up to SunOS2.10. It does not imply SunOS2.11 however. -- Dennis
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
On Mon, Nov 9, 2009 at 5:50 PM, Dennis Clarke wrote: > >>> you can buy a support contract for it then you have a valid platform in >>> commercial use. >> >> You can get support for the OpenSolaris distribution if you like > > I just went and looked ... you are correct, they have three levels in > fact. It looks like $1080 for premium, $720 is standard business hours > $324 is patches and updates with email tech support I think. > > So that makes it a real commercial platform in my mind. > >> is still very much work in progress, not a stable platform we can rely on. > > However, Solaris 10 was also a moving platoform in its first few releases > but no one would debate it as a commercial grade release or not. I think > Opensolaris must be looked at as viable and commercial grade. I am not at > all biased in this regardless of the fact that I have been involved one > way or another in the OpenSolaris project since day one. I'm very much an > outside guy that just loves to experiment and perhaps even attempt to help > where I can. > >>> Having said that .. I see roughly 30% of all my traffic from SunOS5.11 >>> users on either Solaris Nevada or OpenSolaris beta releases. >>> >>> The question should be ... do we in the community end user world see >>> SunOS5.11 as being a de facto release? I would say yes. >> >> Certainly not, even if it is widely used (primarily on laptops, I >> suppose). > > Well, would Fedora Core on PowerPC or Ubuntu or Debian ( any release ) be > considered a platform or does that just fall under a wide umbrella of > "Linux" ? Some of those are barely used at all anymore. Consider running > Linux on a DEC Alpha. Who does that anymore? Is this a popularity > measurement or is this based on something more tangible and quantitative > like "commercially supported"? > >>> Solaris 10 is the enterprise class commercial grade Solaris release and >>> it is staying put for a long long long time yet. >> >> Indeed, and even if we chose sparc-sun-solaris2.10 as the primary platform >> doesn't mean that *-*-solaris2.11 doesn't work, quite the contrary: I >> regularly test both and try to keep them working. > > I test everything on *-*-solaris2.8 which by way of the ABI golden rule > instantly qualifies as tested on anything up to SunOS2.10. It does not > imply SunOS2.11 however. If config.gcc handles both triples the same (*-*-solaris2.10 and *-*-solaris2.11) then we can consider both at the same level. Just as we don't make a distinction for glibc or kernel releases for the *-*-linux targets. That some targets specify certain versions is because in the past they handled each OS version slightly different during GCC build and some even in use (for example fixincludes have to be adjusted, etc.). Richard.
How to avoid a tree node being garbage collected after C frontend?
Hello, I need to pass a tree node (section name from processing pragmas) from C frontend to main GCC body (used in TARGET_INSERT_ATTRIBUTES). I store the node in a global pointer array delcared in target.c. But the tree node is garbage collected in the end of c-parser pass, and causes an ICE later on. I am not familiar with GC part at all. How to prevent this from hanppening? I checked other targets. It seems v850 almost uses the same approach to implement section name pragma. Not sure if it has the same problem. Also the issue is very sensitive to certain condition. For example, with -save-temps option the bug disappear. Thanks, Bingfeng Mei
Re: Preserving the argument spills for GDB
I actually already did put it as a fixed register using the FIXED_REGISTER macro. However, I have not yet tested the EPILOGUE_USES because it said that : "The stack and frame pointer are already assumed to be used as needed". My current port defines a different FRAME_POINTER_REGNUM from the HARD_FRAME_POINTER_REGNUM. I have this because before register allocation it is not possible to know the offset as it is said in the Internals. Basically, my code looks like this: move stack pointer down conditional trap on stack pointer store on stack the return address store on stack the frame pointer HARD_FRAME_POINTER_REGNUM (it's the old one so that we know where it started) mov HARD_FRAME_POINTER_REGNUM, stack_pointer ... Function code ... restore return address restore HARD_FRAME_POINTER_REGNUM mov stack_pointer, HARD_FRAME_POINTER_REGNUM This seemed like the simplest solution but it seems to be that, because I restore it in the epilogue, it considers the move as being useless since it doesn't realize it is needed by subsequent function calls in the function code. Thanks for any input, Jc On Mon, Nov 9, 2009 at 10:40 AM, Ian Lance Taylor wrote: > Jean Christophe Beyler writes: > >> How can I force the prologue to keep this instruction. It is useless >> only in the case that there is no function call or no alloca. But I >> have a case where there is a function call and it is still removed. > > Make the hard frame pointer register a fixed register, or add it to > EPILOGUE_USES. > > Ian >
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
Quoting Joern Rennecke :
I think we could have the ICI event flexibility/stability with lower
overhead if the event sender requests an event identifier number (which
can be allocated after the numbers of the gcc 4.5 static event enum values)
for an event name at or before the first event with that name, and then
sends this identifier number with one or more pointers, which might point
to internal gcc data structures, and a pointer to a function to look up
the address of a named parameter. The event sender site source code can
then provide information to build the lookup functions at build time,
e.g. using gperf.
I thought a bit more about this, and decided that using gperf-generated hash
tables is probably overkill.
It is useful to have provisions for the event generator and the event
callback being somewhat out of step, but do we really have to cater
for multiple sources of the same event providing their parameters in
a different way?
If there is only one way to find a parameter with a particular name for
a particular event (for a given combination of compiler binary and plugins),
that this can be defined with an accessor function, which would
generally be defined in the same module which raises the event.
Actually, if we passed around the dso which raises the event, we could
dynamically look up the accessor function to allow co-existence of different
accessor functions for the same event::parameter tuple, but I don't think
there is a need for that.
Here is an example of how I think we can reduce the overhead while keeping
a good amount of flexibility; in loop-unroll.c we currently have:
/* Code for loop-unrolling ICI decision enabling. */
register_event_parameter ("loop->num", &(loop->num));
register_event_parameter ("loop->ninsns", &(loop->ninsns));
register_event_parameter ("loop->av_ninsns", &(loop->av_ninsns));
register_event_parameter ("loop->lpt_decision.times",
&(loop->lpt_decision.times));
register_event_parameter ("loop->lpt_decision.decision",
&(loop->lpt_decision.decision));
register_event_parameter ("loop->lpt_decision.unroll_runtime",
loop->lpt_decision.decision == LPT_UNROLL_RUNTIME ?
(void *) 1 : (void *) 0);
register_event_parameter ("loop->lpt_decision.unroll_constant",
loop->lpt_decision.decision == LPT_UNROLL_CONSTANT ?
(void *) 1 : (void *) 0);
call_plugin_event("unroll_feature_change");
unregister_event_parameter ("loop->num");
unregister_event_parameter ("loop->ninsns");
unregister_event_parameter ("loop->av_ninsns");
unregister_event_parameter ("loop->lpt_decision.times");
unregister_event_parameter ("loop->lpt_decision.decision");
Instead we could have:
invoke_plugin_va_callbacks (PLUGIN_UNROLL_FEATURE_CHANGE, loop);
and then accessor functions:
int
plugin_unroll_feature_change_param_loop_num (va_list va)
{
struct loop *loop = va_arg (va, struct loop *);
return loop->num;
}
unsigned
plugin_unroll_feature_change_param_loop_ninsns (va_list va)
{
struct loop *loop = va_arg (va, struct loop *);
return loop->ninsns;
}
unsigned
plugin_unroll_feature_change_param_loop_av_ninsns (va_list va)
{
struct loop *loop = va_arg (va, struct loop *);
return loop->av_ninsns;
}
...
bool
plugin_unroll_feature_change_param_loop_lpt_decision_unroll_runtime
(va_list va)
{
struct loop *loop = va_arg (va, struct loop *);
return loop->lpt_decision.decision == LPT_UNROLL_RUNTIME;
}
...
There is still another practical issue: as I change the ICI infrastructure
to fit better with the existing gcc 4.5 plugin infrastructure,
the ICI plugins must be adapted to keep working.
As we are trying to have something working in a short time frame, I think
I should pick one plugin and modify it in lock-step with the infrastructure
to demonstrate how it is supposed to work.
Do you think the adapt.c plugin is suitable for that purpose?
Re: How to avoid a tree node being garbage collected after C frontend?
"Bingfeng Mei" writes: > I need to pass a tree node (section name from processing pragmas) > from C frontend to main GCC body (used in TARGET_INSERT_ATTRIBUTES). > I store the node in a global pointer array delcared in target.c. > But the tree node is garbage collected in the end of c-parser > pass, and causes an ICE later on. I am not familiar with GC part > at all. How to prevent this from hanppening? Mark the global variable with GTY(()). See many many existing examples. Ian
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
Hi Joern,
> > I think we could have the ICI event flexibility/stability with lower
> > overhead if the event sender requests an event identifier number (which
> > can be allocated after the numbers of the gcc 4.5 static event enum values)
> > for an event name at or before the first event with that name, and then
> > sends this identifier number with one or more pointers, which might point
> > to internal gcc data structures, and a pointer to a function to look up
> > the address of a named parameter. The event sender site source code can
> > then provide information to build the lookup functions at build time,
> > e.g. using gperf.
>
> I thought a bit more about this, and decided that using gperf-generated hash
> tables is probably overkill.
>
> It is useful to have provisions for the event generator and the event
> callback being somewhat out of step, but do we really have to cater
> for multiple sources of the same event providing their parameters in
> a different way?
> If there is only one way to find a parameter with a particular name for
> a particular event (for a given combination of compiler binary and plugins),
> that this can be defined with an accessor function, which would
> generally be defined in the same module which raises the event.
> Actually, if we passed around the dso which raises the event, we could
> dynamically look up the accessor function to allow co-existence of different
> accessor functions for the same event::parameter tuple, but I don't think
> there is a need for that.
>
> Here is an example of how I think we can reduce the overhead while keeping
> a good amount of flexibility; in loop-unroll.c we currently have:
> /* Code for loop-unrolling ICI decision enabling. */
> register_event_parameter ("loop->num", &(loop->num));
> register_event_parameter ("loop->ninsns", &(loop->ninsns));
> register_event_parameter ("loop->av_ninsns", &(loop->av_ninsns));
>
> register_event_parameter ("loop->lpt_decision.times",
> &(loop->lpt_decision.times));
> register_event_parameter ("loop->lpt_decision.decision",
> &(loop->lpt_decision.decision));
> register_event_parameter ("loop->lpt_decision.unroll_runtime",
>loop->lpt_decision.decision == LPT_UNROLL_RUNTIME ?
> (void *) 1 : (void *) 0);
> register_event_parameter ("loop->lpt_decision.unroll_constant",
>loop->lpt_decision.decision == LPT_UNROLL_CONSTANT ?
> (void *) 1 : (void *) 0);
>
> call_plugin_event("unroll_feature_change");
>
> unregister_event_parameter ("loop->num");
> unregister_event_parameter ("loop->ninsns");
>
> unregister_event_parameter ("loop->av_ninsns");
> unregister_event_parameter ("loop->lpt_decision.times");
> unregister_event_parameter ("loop->lpt_decision.decision");
>
> Instead we could have:
>
> invoke_plugin_va_callbacks (PLUGIN_UNROLL_FEATURE_CHANGE, loop);
> and then accessor functions:
> int
> plugin_unroll_feature_change_param_loop_num (va_list va)
> {
>struct loop *loop = va_arg (va, struct loop *);
>return loop->num;
> }
>
> unsigned
> plugin_unroll_feature_change_param_loop_ninsns (va_list va)
> {
>struct loop *loop = va_arg (va, struct loop *);
>return loop->ninsns;
> }
>
> unsigned
> plugin_unroll_feature_change_param_loop_av_ninsns (va_list va)
> {
>struct loop *loop = va_arg (va, struct loop *);
>return loop->av_ninsns;
> }
> ...
> bool
> plugin_unroll_feature_change_param_loop_lpt_decision_unroll_runtime
> (va_list va)
> {
>struct loop *loop = va_arg (va, struct loop *);
>return loop->lpt_decision.decision == LPT_UNROLL_RUNTIME;
> }
> ...
I am a bit confused about your above example - you suggest to add
this functionality on top of current ICI or substitute it?
If you want to substitute it, I personally disagree. We spent a very long time
with many colleagues and real ICI users discussing how to simplify the usage of
events for people who are not programming professionals,
so I really prefer to keep the current structure as it is ...
However, if it is the way to speedup slow prototype plugins and addition to ICI,
it may be fine but I need to think about it more.
In both cases, I think it is not critical for now and should be the second step
after current ICI is synced with the mainline. However, suggestions from others
are very welcome ;) !..
> There is still another practical issue: as I change the ICI infrastructure
> to fit better with the existing gcc 4.5 plugin infrastructure,
> the ICI plugins must be adapted to keep working.
> As we are trying to have something working in a short time frame, I think
> I should pick one plugin and modify it in lock-step with the infrastructure
> to demonstrate how it is supposed to work.
>
> Do you think the adapt.c plugin is suitable for that purpose?
Yes, adapt.c is the latest plugin that we use for our experiments ...
Cheers,
Grigo
Re: i370 port
Now all code needs to be exposed to this. ie libiberty and gcc. To fit in with the new style of building, I basically want to update ansidecl.h to do a: #ifdef PUREISO #include "mshort.h" #endif Does that seem reasonable? The ISO C99 standard requires that an identifier have 31 significant initial characters, so PUREISO does not seem like the right name here. Ok. I was under the impression that C99 was rarely fully implemented, and far from universal, thus pretty irrelevant. Based on your suggested #define's, your system seems even more restrictive than ISO C99 requires. I vaguely recall that ISO C90 requires 6 significant initial characters, so something like Yep, externals need to be unique in the first 6 characters, and with case ignored. My system requires 8, and ignores case. PURE_ISO_C90 might be right here. Ok. I can see that ansidecl.h is a tempting place to put this, but I don't think it is correct. ansidecl.h is used by many different programs, including the GNU binutils and gdb. Ok, but it's a non-default option, so would have no effect on those. Changes that are specific to gcc should be in gcc, probably in gcc/system.h. Changes specific to libiberty should be in libiberty, probably in include/libiberty.h. I can give it a go, but I'm not sure they kick in early enough. I even had to move the ansidecl in cplus-dem.c up to get it to take effect soon enough. But in principle, separating the remaps for libiberty and gcc into two different files sounds like the correct thing to be doing, so I'll see if I can get that to work. Needs a bit more infrastructure to be written though. :-) BFN. Paul.
pure64 patch for 4.5.0
hello, wanting to know if there's a pure64 patch for 4.5.0 right now I've plugged in a pure64 patch for 4.4.1 on 4.5.0. will this be good or is there more to that needs to be added. http://patches.cross-lfs.org/dev/gcc-4.4.1-pure64-1.patch Justin P. Mattock
答复: How to run gcc test suite in pure mingw32 environment?
I know very well the spirit of MinGW, it want to provide a native Win32
development evrionment.
The issue is : many of the host tools have not been ported or very hard to
be ported to pure MinGW/Win32 environment, for example, bash. This is why
Msys exist. Msys essensially a fork of Cygwin 1.3. In MinGW's download
page, there are two kinds of packages to download, MinGW pacakges and Msys
packages. The MinGW packages are packages ported to pure MinGW/Win32
environment, not linked to non standard DLLs, like, cygwin1.dll or
msys-1.0.dll. The Msys packages are packages developed in a outdated
developent toolchain(gcc-2.9), and linked to msys-1.0.dll. The Msys packages
are not native MinGW/Win32 packages, just like Cygwin packages.
The existence of Msys proves that : in MinGW, you must provide a
additional/optional newlib style library, the headers,libs, to make a bundle
of tools to be build easily : bash, make, coreutils, bzip2,diffutils, file,
findutils, gawk, grep, gzip, less, m4, patch, sed, tar, texinfo, perl, etc.
The testruns for 32-bit and 64-bit of mingw-w64 are done on a linux host by
cross-compilation and are executed on a remote Windows host, again confirm
this points : MinGW lack the the native ported MinGW/Win32 tools.
I know that a lot of basic tools like, make,dmake, perl, tck/tk have been
ported to pure MinGW/Win32 evnrironment. Autoconf, automake, libtool, depend
on perl, but I don't know whether not pure MinGW/Win32 perl works.
I also notice that there a GnuWin32 project, but no prove exists that we
can use that as gcc development environment.
It seems that all GNU development tools have been ported to Cygwin, with the
latest version. But in Msys, many tools are missing or outdated. In some
meaning , Cygwin seems more successful than MinGW+Msys.
It would be very nice when Cygwin can masquerade as MinGW. I have tried to
relpace the uname.exe in Cygwin's bin directory(c:/cygwin/bin), with the one
in MinGW is bin directory(c:/msys/1.0/bin). Then in Cygwin bash when run
"config.guess", it print "i686-pc-mingw32". For lack of time, I have not
done further test.
cheers.
Chiheng Xu
Wuhan,China
-邮件原件-
发件人: Kai Tietz [mailto:ktiet...@googlemail.com]
发送时间: 2009年11月9日 19:04
收件人: Kai Ruottu
抄送: 徐持恒; gcc@gcc.gnu.org
主题: Re: How to run gcc test suite in pure mingw32 environment?
2009/11/9 Kai Ruottu :
> I myself would be more interested to get these tests for MinGW-hosted
> tools to work on Linux because that is
> the "preferred build platform for MinGW-hosted tools" for me. Some years
> ago I produced more than 100
> binutils+GCC+GDB/Insight toolchains for all kind of targets to be run on
> the MinGW runtime host. Just for a
> fun... The tests regarding to "does it work" happening on Windoze/MinGW
> via compiling apps there and then
> possibly running them on the built-in simulator in GDB or using the
> standalone "$target-run" simulator on the
> console.
The testruns we do for 32-bit and 64-bit of mingw-w64 are done on a
linux host by cross-compilation and are executed on a remote Windows
host. ssh and rexec can be used here. NightStrike can give here more
details.
> What has been the "problem" is that those very limited tests on the
> Windoze/MinGW host have this far
> showed the toolchains to work quite identically with their earlier
> equivalents on the Linux host, for instance
> a toolchain for "arm-elf" on MinGW-host working nicely on Windoze too.
> So really no need to wonder how
> to get "make check" to work with the Canadian-cross built toolchains...
Indeed, to make a cross-compiler (especially on cygwin and linux)
makes absolutely sense. In fact it is at the moment (as the expect
tool isn't ported for native Windows hosts) the only way to do
regression tests.
>> Is't it necessary to port newlib to pure MinGW environment ?
This makes no sense. Possibly your initial idea here isn't
understandable, so could you give us more details about this?
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
Dave Korn wrote:
Justin Mattock wrote:
==1830== Command: c++ -o jsxml.o -c -DOSTYPE="Linux2.6" -DOSARCH=Linux
Ah, you're running it on the "c++" utility and it's reporting the stats for
that, but how it works is that "c++" (and "gcc", "g++", et al) is just a
driver, that parses the command line arguments and shells out to the actual
compiler ("cc1plus"), assembler and linker to get them to do all the work.
If you add "-v --save-temps" to the c++ invocation, it'll show you the
separate command lines it executes for the subprograms; the first invocation
will be of cc1plus, using the -E flag to generate the preprocessed source into
a .ii file, it's the second invocation you want, the one which uses the
"-fpreprocessed" flag and names the .ii file as input, which is the one that
actually then compiles the pre-processed source into assembly. For fuller
explanation, see the GCC wiki:
http://gcc.gnu.org/wiki/DebuggingGCC
cheers,
DaveK
I didn't think at the time, but when compiling
4.5.*(snapshot) I added the pure64 patch to
gcc, everything seemed to go fine, but maybe
there needs to be more to it.
would this might cause an issue(memory leak or something)
like what I was receiving even though there's a symlink
to lib64?
BTW: I just cleared the deck and started fresh,
compiled gcc+pure64 patch(snapshot) into a single directory,
and then looked at ldd /usr/bin/gcc*
I see it pointing to /lib64(looking on my other system with
4.4.1 it points to /lib)
Justin P. Mattock
RE: [plugins-ici-cloning-instrumentation] new GCC plugin developements
Quoting Grigori Fursin : > I am a bit confused about your above example - you suggest to add this functionality on top of current ICI or substitute it? The idea was to replace it. The current event implementation has two issues: - It is very different from the existing GCC 4.5 events which makes it confusing to have it side-by-side. I think if we can make the ICI code more of a natural extension of the current event code, it would be more likely to be acceptable. - The parameter registering / unregistering and the event call itself introduce a number of hashing operations which are performed irrespective of the presence of a plugin. This makes these events intrusive if placed in places with a high execution frequency. If you want to substitute it, I personally disagree. We spent a very long time with many colleagues and real ICI users discussing how to simplify the usage of events for people who are not programming professionals, so I really prefer to keep the current structure as it is ... Were these discussions done face-to-face or on a news group/mailing list? If the latter, could you point me where I can read up on the discussion so that I better understand the issues involved. Would these people who are not programming professionals both insert event raising points as well as write event handling code? If we would use C++, some things would get easier, i.e. we could have an event class with subclasses for the separate event types, and then have the parameter accessors be member functions. This would remove the need to repeatedly type the event name when accessing the parameters. However, it would require to build GCC with C++, so I'd say this significantly reduces the chances of having ICI integrated into the gcc mainline and having release GCC binaries shipped with the functionality enabled. If plugin-side run time is not important, we can have register_plugin_event as a wrapper for register_callback and use user_data to squirrel away the event name and the actual callback function; then we can have a wrapper callback function which sets a thread-local variable (can be non-exported global inside the plugin as long as no threads are used) to the plugin name, and make get_event_parameter use a dynamic function name lookup by stringing together the event name with the parameter name. This way, we could look the ICI interface on the plugin side pretty much what it looks now, except that we should probably restrict the event and parameter names to identifier characters, lest we need name mangling to translate them to function names. I had a look at the adapt branch to gauge if the there is really a point for having the varargs stuff, i.e. events with parameters that are not readily available in a single struct. The unroll_parameter_handler / graphite_parameter_handler events are somewhat odd because they have a varying set of parameters. So they really have a list of parameters. We could do this with somehing like: invoke_plugin_va_callbacks (PLUGIN_UNROLL_PARAMETER_HANDLER, "_loop.id", EP_INT, loop->num, "_loop.can_duplicate_loop_p", EP_UNSIGNED_CHAR, ici_can_duplicate_loop_p); And then have the plugin pick through the va_list. Or, if preferred, have a helper function - possibly invoked implicitly by the ICI infrastructure - go through the va_list and build the hash table of arguments from it so that the current parameter query interface can be used. In fact, we could use such a mechanism in general, so if we go back to passing pointers to parameters instead of parameters, you'd have backward compatibility on the plugin side. OTOH, does using pointers to parameters really make this interface easy to use - it seems you had to use this to avoid type compatibility issues, which are sidestepped by using a va_list. If we pass parameter values instead, you could have a query function that tells you if a parameter is set. Possibly also with a pointer argument to assign the value if the parameter is set. tests if a parameter exists - if you like However, if it is the way to speedup slow prototype plugins and addition to ICI, it may be fine but I need to think about it more. Having a single call to invoke an event by number (even if it is a varargs call) is certainly much faster than having all these register_parameter / unregister_parameter calls, particularly in the case that no plugin has registered a callback for the event. In both cases, I think it is not critical for now and should be the second step after current ICI is synced with the mainline. However, suggestions from others are very welcome ;) !.. I thought you were hoping to push some ICI infrastructure into mainline in time for 4.5 . In order to do that - Time is of the essence. - We should reduce the impact that ICI has on the rest
Re: pure64 patch for 4.5.0
"Justin P. Mattock" writes: > wanting to know if there's a pure64 patch for 4.5.0 > right now I've plugged in a pure64 patch for 4.4.1 > on 4.5.0. > will this be good or is there more to that needs to be added. > http://patches.cross-lfs.org/dev/gcc-4.4.1-pure64-1.patch You might do better to ask the people who wrote that patch. The patch does look generally plausible to me but I didn't really look at it in detail. Ian
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On Mon, 9 Nov 2009, Paolo Bonzini wrote: > On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote: > > From: "David Edelsohn" > > > >> AIX Shell is KSH. > >> > >> The problem is shell append += and libtool not running with the same > >> shell used by configure. > > > > Hm, the mpc configure script actually has a check for shell +=, and on > > my solaris box it correctly detects that it doesn't work. > > > > checking whether the shell understands "+="... no > > > > Presumably on solaris then += isn't used. I wonder what does configure > > say here for AIX and why does it attempt to use it? > > As David said, the problem is using the same shell in configure and > libtool. I think I fixed this upstream (just as a consequence of cleanups). > Paolo So IIUC, David is setting SHELL=/path/to/bash first, then running configure, then getting an error. This happens because configure tests that bash understands +=, but libtool is run with (presumably) /bin/sh and doesn't understand += right? If so, then if one doesn't set SHELL (or CONFIG_SHELL?) on AIX, everything should work fine building MPC, right? --Kaveh
Re: pure64 patch for 4.5.0
Ian Lance Taylor wrote: "Justin P. Mattock" writes: wanting to know if there's a pure64 patch for 4.5.0 right now I've plugged in a pure64 patch for 4.4.1 on 4.5.0. will this be good or is there more to that needs to be added. http://patches.cross-lfs.org/dev/gcc-4.4.1-pure64-1.patch You might do better to ask the people who wrote that patch. The patch does look generally plausible to me but I didn't really look at it in detail. Ian Cool thanks. I can try that and see. in any case it's probably better to stick with a stable version. (I just can't help it having an itch to try things out). Justin P. Mattock
