[CFARM] maintenance ok
Hi, we lost just one disk during transportation. If you know someone who has a spare X GB SCSI disk available for donation, please contact me. Otherwise I'll just buy one :). So we have 8 bi processor machines online, 7 with ubuntu 5.10 and 1 with NetBSD. I'm creating accounts on request: private email to me with prefered login and authorized_keys in *ATTACHMENT* not inline as email is added plenty of random things. I suggest people use [CFARM] in the subject for discussing compileFarm ideas and plans, if there's too much volume or low interest for the mailing list audience at large we'll create a separate mailing list. Think of updating the wiki with your proposals http://gcc.gnu.org/wiki/CompileFarm More in a few hours after work. Laurent On Tue, 2005-12-13 at 20:23 +0100, Laurent GUERBY wrote: > I'll leaving home for the datacenter, the machines will reboot within > the next two hours. > > I'll setup the account for people who requested them by email tonight. > > Laurent > >
Re: [CFARM] maintenance ok
On 12/14/05, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > Hi, we lost just one disk during transportation. > > If you know someone who has a spare X GB SCSI disk available for > donation, please contact me. Otherwise I'll just buy one :). > > So we have 8 bi processor machines online, 7 with ubuntu 5.10 > and 1 with NetBSD. Do they have accessible webspace or other means of automatically publishing results? If so, we could set aside one machine for continuous testing of whatever is desired. Richard.
Solaris/GCC 3.4.x/4.0.x issue: _GLIBCXX_HAVE_ASINL & others.
Hello, I'm trying to solve small MICO build issue on Solaris/GCC platform. The issue is simple: since GCC 3.4.0 we start to fail compiling code which uses asinl and other functions. The actual issue is that configure (generated by autoconf2.13) detects asinl (and others) function as available, while in fact it is not available on the system (headers/libs), but it is available only in GCC's libstdc++ (as a symbol not as a function defined in header file). So this misdetection of asinl and others then cause MICO build to fail since asinl and others are not defined in header files. I've studied this issue on linux and solaris with GCC 3.4.x and 4.0.1 and found that interestingly _GLIBCXX_HAVE_ASINL is defined when libstdc++ do not provide asinl symbol (function) and it is not defined when it provides it. I have two questions with regarding to this: 1) is this issue GCC's bug to publicly expose asinl/ldexpl/frexpl/fmodl/ceill/floorl/fabsl symbols in its libstdc++? 2) is it reliable to use _GLIBCXX_HAVE_ASINL to detect if asinl is just exposed by libstdc++ and not supported by the target OS? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC mailing list archive search omits results after May 2005
On Tue, Dec 13, 2005 at 11:03:12PM -0500, Hans-Peter Nilsson wrote: >On Tue, 13 Dec 2005, DJ Delorie wrote: >>>Summary of the thread: it's known about and may never be fixed, but >>>alternative searchable archives exist (gmane, nabble, probably others >>>like marc and mail-archive too). >> >>Could we put in a google search box on the archive pages at least, to >>stop confusing people? > >Technically feasible but politically sensitive. Considering that links >on readings.html to sites that provide some software that's >non-free-by-FSF-definition is forbidden, I'd like to know if that'd be >allowed, and I'd want that answer straight from the GNU's mouth (so >please don't start discussing it among just-subscribers-to-this-list >and anyway don't CC me if you do). SC? I asked about this a couple of years ago and, IIRC, the SC said no. cgf
Re: GCC mailing list archive search omits results after May 2005
Hans-Peter Nilsson wrote: > On Tue, 13 Dec 2005, DJ Delorie wrote: > > Could we put in a google search box on the archive pages at least, to > > stop confusing people? > > Technically feasible but politically sensitive. Considering > that links on readings.html to sites that provide some software > that's non-free-by-FSF-definition is forbidden, I'd like to know > if that'd be allowed, and I'd want that answer straight from the > GNU's mouth It would be useful to at least note by the search box that it only searches messages sent prior to May 2005. But note that Gmane (http://gmane.org) is run entirely on Free Software, and doesn't provide any non-Free Software downloads so you could presumably add a search box for that without political worries. (This may also be true for some of the other mail archives, I'm just much more familiar with how Gmane is run because I built the current search facility for it). Anyway, should you want it there's sample HTML to cut-and-paste for a search box on this page: http://search.gmane.org/ Cheers, Olly
Re: GCC mailing list archive search omits results after May 2005
On Dec 14, 2005, at 9:30 AM, Olly Betts wrote: It would be useful to at least note by the search box that it only searches messages sent prior to May 2005. :-( I think we should remove all traces of any search that doesn't work. It doesn't help advanced people, and it doesn't help beginners. It has never been any good, so I don't think it is a real loss.
Re: GCC mailing list archive search omits results after May 2005
mrs wrote: > I think we should remove all traces of any search that doesn't work. > [...] We'll try to set up mnogosearch again on the machine. Please stand by. - FChE
heads up - gcc toplevel bootstrap activated
This is just a heads up that GCC has switched so that the toplevel coordinates the bootstrapping. The main change is that on a native configuration `make' will automatically bootstrap, unless you configure with --disable-bootstrap (and, since the binutils list is receiving this message, if you bootstrap a combined tree, the assembler and linker will also be built three times, each time using the previous one). There should be no behavior change for cross configurations, nor for trees not including GCC. Let me know if I broke something. Paolo
Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}
On Mon, Dec 12, 2005 at 05:26:10PM +0100, Richard Guenther wrote:
>
> Always interesting to compare seemingly duplicates. The variant
> from fold-const.c seems to be more strict with types and sets
> TREE_ADDRESSABLE on the base component, while the gfc variant
> sets it on the passed tree itself. Other than that, the gfc variant
> uses convert () to do typecasting. And the gfc variant has
> parameters swapped compared to the fold-const.c variant which may
> cause confusion if we switch.
>
> Would a patch be accepted to convert the gfc_build_addr_expr to
> build_fold_addr_expr{,_with_type}?
>
Richard,
First, I think this type of decision would come down to
Paul Brook and Steven Bosscher, so you should probably
discuss it with them.
IMHO, I think this type of patch is desirable if it brings
gfortran into line with other parts of GCC for consistency.
The obvious advantage is that others, who don't normally
work on gfortran, can easily read, understand, and potentially
spot problems.
Of course, a patch like this would need not only regression
testing on your platform of choice, but probably several others
including cygwin, aix, MacOs, and hp-ux which tend to uncover
problems.
The only downside I see with this type of patch is that backporting
fixes from trunk to 4.1 will be more difficult. With only a small
group of active gfortran hackers, this may place 4.1 into position
of low maintenance.
--
Steve
Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}
The only downside I see with this type of patch is that backporting fixes from trunk to 4.1 will be more difficult. With only a small group of active gfortran hackers, this may place 4.1 into position of low maintenance. Unless I am mistaken, this patch doesn't touch anything outside the fortran/ front-end, so I think we can consider backporting it to 4.1. $ diff gcc/gcc/fortran gcc-4.1/gcc/fortran|wc -l 743 $ diff gcc/libgfortran gcc-4.1/libgfortran|wc -l 1747 The last number falls down to 484 if we don't count the regenerated files. FX
"Bag of pages" algorithm?
Hi, Could anyone recommend a good reference (paper/book/webpage/...) about the "bag of pages" GC algorithm used in GCC? Also, is there any document about the specifics of GCC implementation (besides GCC Internals document)? Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: "Bag of pages" algorithm?
On Wed, 2005-12-14 at 14:17 -0500, Domagoj D wrote: > Hi, > > Could anyone recommend a good reference (paper/book/webpage/...) > about the "bag of pages" GC algorithm used in GCC? There is none, AFAIK. > Also, is there > any document about the specifics of GCC implementation (besides > GCC Internals document)? Nope.
Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu
On Tue, Dec 13, 2005 at 04:39:56PM -0500, Jakub Jelinek wrote: > PR debug/25023 > * config/i386/i386.c (ix86_force_to_memory): Always use > SImode push for HImode in -m32. > (ix86_free_from_memory): Likewise. > > * gcc.dg/pr25023.c: New test. Ok. r~
Re: "Bag of pages" algorithm?
Hi Daniel, > > Could anyone recommend a good reference (paper/book/webpage/...) > > about the "bag of pages" GC algorithm used in GCC? > There is none, AFAIK. Argh, how am I supposed to figure out the arcane lore of GCC programmers than? :-) > > Also, is there > > any document about the specifics of GCC implementation (besides > > GCC Internals document)? > Nope. I can just hope that someone actually knows a good reference to recommend or is willing to write "GCC GC for beginners" :-) in a page or two... Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}
On Wed, 14 Dec 2005, FX Coudert wrote: > > The only downside I see with this type of patch is that backporting > > fixes from trunk to 4.1 will be more difficult. With only a small > > group of active gfortran hackers, this may place 4.1 into position > > of low maintenance. > > Unless I am mistaken, this patch doesn't touch anything outside the fortran/ > front-end, so I think we can consider backporting it to 4.1. As less intrusive first step I can bring the fortran variants in line with the middle-end ones, especially wrt correctness. We at least should correct these issues. Richard.
Re: "Bag of pages" algorithm?
On Wed, 2005-12-14 at 15:21 -0500, Domagoj D wrote: > Hi Daniel, > > > > Could anyone recommend a good reference (paper/book/webpage/...) > > > about the "bag of pages" GC algorithm used in GCC? > > There is none, AFAIK. > > Argh, how am I supposed to figure out the arcane lore of GCC programmers > than? :-) What exactly are you trying to do? Replace it? > > > > Also, is there > > > any document about the specifics of GCC implementation (besides > > > GCC Internals document)? > > Nope. > > I can just hope that someone actually knows a good reference to recommend > or is willing to write "GCC GC for beginners" :-) in a page or two... I wrote on of the two gc implementations that is there (ggc-zone). There is nothing magic or special about them. They should be fairly easy to understand for anyone who understands the basics of garbage collection. > > Thx. > Domagoj >
unrecognized option '-no-cpp-precomp' on Mac OS X (10.4.3)
I have built gcc-4.1-20051209 successfully and while using it to try to compile Python-2.4.2, I get this error: /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.3.0/bin/gcc -c - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/martinol/build- magnesium/Python-2.4.2/Include -DPy_BUILD_CORE -o Modules/python.o / Users/martinol/build-magnesium/Python-2.4.2/Modules/python.c gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-Wno-long-double" make[1]: *** [Modules/python.o] Error 1 make: *** [python-build] Error 2 Using grep, I see stage1 flags that use this option. However, the on- line documentation did not seem to have this option in it -- at least not in the section dealing with command line options for the CPP. Any ideas where it might have gone? Is it an "internal" option? Paul
Re: unrecognized option '-no-cpp-precomp' on Mac OS X (10.4.3)
On Wed, Dec 14, 2005 at 02:52:26PM -0600, Paul Martinolich wrote: > I have built gcc-4.1-20051209 successfully and while using it to try to > compile Python-2.4.2, I get this error: > > /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.3.0/bin/gcc -c - > fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - > DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/martinol/build- > magnesium/Python-2.4.2/Include -DPy_BUILD_CORE -o Modules/python.o / > Users/martinol/build-magnesium/Python-2.4.2/Modules/python.c > gcc: unrecognized option '-no-cpp-precomp' > cc1: error: unrecognized command line option "-Wno-long-double" > make[1]: *** [Modules/python.o] Error 1 > make: *** [python-build] Error 2 > > > Using grep, I see stage1 flags that use this option. However, the on- > line documentation did not > seem to have this option in it -- at least not in the section dealing > with command line options > for the CPP. > > Any ideas where it might have gone? Is it an "internal" option? It is only supported by Apple's compiler, not part of the FSF GCC. Python is incorrect for using it unconditionally based on the target. -- Daniel Jacobowitz CodeSourcery, LLC
Re: unrecognized option '-no-cpp-precomp' on Mac OS X (10.4.3)
On Dec 14, 2005, at 12:52 PM, Paul Martinolich wrote: I have built gcc-4.1-20051209 successfully and while using it to try to compile Python-2.4.2, I get this error: /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.3.0/bin/gcc - c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/ martinol/build-magnesium/Python-2.4.2/Include -DPy_BUILD_CORE -o Modules/python.o /Users/martinol/build-magnesium/Python-2.4.2/ Modules/python.c gcc: unrecognized option '-no-cpp-precomp' This flag should be removed from the compile, it hasn't been needed in a long while (since gcc-3.1). cc1: error: unrecognized command line option "-Wno-long-double" This project was meant to compile with Apple's gcc, you could try it instead.
unable to build head on Fedora
Hi, My fresh check out on the head build using the gcc shipped with Fedora Core 4 has failed for the past couple of days with this error: /home/joel/gcc-work/head/b-native/./gcc/xgcc -B/home/joel/gcc-work/head/b-native/./gcc/ -B/home/joel/gcc-head-test//i686-pc-linux-gnu/bin/ -B/home/joel/gcc-head-test//i686-pc-linux-gnu/lib/ -isystem /home/joel/gcc-head-test//i686-pc-linux-gnu/include -isystem /home/joel/gcc-head-test//i686-pc-linux-gnu/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg g-alleve.adb -o g-alleve.o g-alleve.adb: In function ‘GNAT.ALTIVEC.LOW_LEVEL_VECTORS.LL_VUC_OPERATIONS.SATURATE.2XNN’: g-alleve.adb:871: error: unrecognizable insn: (insn 113 112 114 4 g-alleve.adb:866 (set (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8]) (reg:HI 0 ax [orig:77 d ] [77])) -1 (nil) (nil)) +=GNAT BUG DETECTED==+ | 4.2.0 20051214 (experimental) (i686-pc-linux-gnu) GCC error: | | in extract_insn, at recog.c:2084 | | Error detected at g-alleve.adb:5035:1| configure command: ./gcc/configure --prefix=/home/joel/gcc-head-test/ --enable-languages=c,c++,ada Is this a known failure? -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
[CFARM] SCSI disk
On Wed, 2005-12-14 at 14:11 +0100, Laurent GUERBY wrote: > Hi, we lost just one disk during transportation. > > If you know someone who has a spare X GB SCSI disk available for > donation, please contact me. Otherwise I'll just buy one :). Sebastian Pop kindly proposed a disk, but unfortunately it wasn't suitable for the rack. The machines are Dell Poweredge 1550 so the disk model should be 1 inch, 80 pin (SCA), SCSI U160 or U320. I'll wait until january :). Laurent
Re: unable to build head on Fedora
On Wed, Dec 14, 2005 at 04:34:17PM -0600, Joel Sherrill <[EMAIL PROTECTED]> wrote: > > My fresh check out on the head build using the gcc shipped with > Fedora Core 4 has failed for the past couple of days with this error: A day and half. > /home/joel/gcc-work/head/b-native/./gcc/xgcc > -B/home/joel/gcc-work/head/b-native/./gcc/ > -B/home/joel/gcc-head-test//i686-pc-linux-gnu/bin/ > -B/home/joel/gcc-head-test//i686-pc-linux-gnu/lib/ -isystem > /home/joel/gcc-head-test//i686-pc-linux-gnu/include -isystem > /home/joel/gcc-head-test//i686-pc-linux-gnu/sys-include -c -g -O2 -fPIC > -W -Wall -gnatpg g-alleve.adb -o g-alleve.o > g-alleve.adb: In function > ?GNAT.ALTIVEC.LOW_LEVEL_VECTORS.LL_VUC_OPERATIONS.SATURATE.2XNN?: > > g-alleve.adb:871: error: unrecognizable insn: > (insn 113 112 114 4 g-alleve.adb:866 (set (mem:HI (pre_dec:SI > (reg/f:SI 7 sp)) [0 S2 A8]) > (reg:HI 0 ax [orig:77 d ] [77])) -1 (nil) > (nil)) > Is this a known failure? Yes, just svn update and retry. Jakub
Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}
Richard, As less intrusive first step I can bring the fortran variants in line with the middle-end ones, especially wrt correctness. We at least should correct these issues. For what it is worth, I applaud your effort - I think that the gfortran middle-end should be made completely consistent with the rest of gcc. The nature of your proposed patch is such that it should apply relatively easily to all and any of the trees; ie. a given function/macro is replaced by its rest-of-gcc equivalent. A nagging worry that I have is that the gcc middle-end is still not very well documented. The majority of the active gfortran developers are not full-timers and already find the gfortran variants fairly hard going at times (speaking first and foremost for myself, of course!) without having to delve deeper into gcc MiddleWorld. That said, I would get on with it if I were you. Cheers Paul T
porting gcc/binutils
Hi, I'm trying to port gcc and binutils to a new target and I hoped to find a brief procedure on that matter on the net, but was unsuccessful. OK, the GCC internals is quite a resourceful document and one can learn a lot by examining the source tree, but It would be very helpful if there would be a brief procedure description (HOWTO). Like what to do first, port gas I guess, and what to do (like create your directory(s), write ISA file(s), machine descriptions, coff/elf generation etc.). I'd be really grateful if someone could help me out. best regards Andrija Radicevic
[CFARM] accounts & use
Note: I'll be offline starting friday and up to monday, so if you want to start hacking on the machines over the week-end please send me your prefered UNIX and public key AS ATTACHMENT (not inline) in the next 12 hours. On Wed, 2005-12-14 at 14:28 +0100, Richard Guenther wrote: > Do they have accessible webspace or other means of automatically > publishing results? If someone has a webserver somewhere and an account on the farm, the following scheme should work from the webserver: #!/bin/sh while true; do ssh [EMAIL PROTECTED] bin/wait_for_some_result scp -C [EMAIL PROTECTED] log/latest_result . Mail and/or copy to webserver ssh [EMAIL PROTECTED] bin/result_processed done > If so, we could set aside one machine for continuous > testing of whatever is desired. We can set most of the machines for continuous testing if we decide to do so :). We have enough to do per day (24h) between 30 and 40 native bootstrap for all languages, takes 4h to boot, 4h to test (on one 1.25GHz Pentium 3), see: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00569.html My estimate is that there are about 8 commit per day on branches (4.0 and 4.1 have identical stats), and about 20 commits per day on trunk. So we could on average test a posteriori every single commit on 2 branches + trunk if we put all the machines on it. But we may want to set aside time to do external project testing, or to set up a priori patch testing. May be we can setup a separate svn repository where trusted people could svn add their patch, have the cluster test patches from this svn repo, check results and publish a certificate of good health to the patch. Open to discussion. Current users of the farm: Ian Lance TaylorGCC François-Xavier Coudert <[EMAIL PROTECTED]> GCC Olly Betts <[EMAIL PROTECTED]> http://www.xapian.org/ C++ library Sebastian Pop <[EMAIL PROTECTED]>GCC Emmanuel Dreyfus <[EMAIL PROTECTED]>NetBSD Mike Stein <[EMAIL PROTECTED]> AVR cross & simulator Roberto Bagnara <[EMAIL PROTECTED]> http://www.cs.unipr.it/ppl/ C++ library Olly and Roberto are working on testing their C++ library with the latest GCC, so they are asking us to set up at least a reference install in cron. This will probably not be through a symlink (otherwise if we change it during someone use that would break things), I suggested the use of a one line text file somewhere so you can do at the beginning of library testing script something like: PATH=$(cat /some/where/LATEST_WORKING_TRUNK):$PATH minimal_check_that_gcc_does_work_otherwise_abort many_interesting_things and /some/where/LATEST_WORKING_TRUNK will be updated with a simple echo each time a builds is considered succesfull. Help wanted: 1/ how to do an NFS setup where machine can see each other but don't freeze / can still boot when other machines are not online. 2/ set up SVK locally on the cluster, with local svn server (and may be more efficient svn client than the one currently installed. I'll start more work on this monday. Laurent
Huge compile time regressions
Hi, Someone caused a >10% compile time regression yesterday for CSiBE, see http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs Gr. Steven
Re: porting gcc/binutils
On Dec 14, 2005, at 3:31 PM, Andrija Radičević wrote: I'm trying to port gcc and binutils to a new target and I hoped to find a brief procedure on that matter on the net, but was unsuccessful. OK, the GCC internals is quite a resourceful document and one can learn a lot by examining the source tree, but It would be very helpful if there would be a brief procedure description (HOWTO). Like what to do first, port gas I guess, and what to do (like create your directory(s), write ISA file(s), machine descriptions, coff/elf generation etc.). I'd be really grateful if someone could help me out. Pick closest architecture to the one you want, copy to to a new directory based upon the name of the new architecture and modify to suit, then build and your done. :-) If you would like to contribute to the documentation, take notes on what you found to be undocumented and/or non-obvious and contribute to the docs. If you get stuck on a specific step, ask here (for gcc only)... (and then add the answer you get to the docs). For binutils help, you'd want a different list.
Re: RELOAD_OTHER bug?
> I see now that this code is in merge_assigned_reloads, so it might
> even be safe there to set the reload type to
> RELOAD_FOR_OTHER_ADDRESS. You'll have to check if the reload type
> from that point onward is only needed to determine the time of the
> reload insn (rather than also the lifetime of the reload register).
It seems like the very next thing it does is generate and emit the
reload insns via emit_reload_insns().
However, I modified my logic to check to see if the other thing we're
merging with is also an address; if it's not, we stick with
RELOAD_OTHER. I fiddled with the logic to look for reloads for the
new RELOAD_FOR_OTHER_ADDRESS too, but I suspect if we find any,
something may go wrong anyway.
Patch so far...
Index: reload1.c
===
--- reload1.c (revision 108504)
+++ reload1.c (working copy)
@@ -1830,6 +1830,8 @@
&& rld[r].regno == -1)
if (! find_reg (chain, i))
{
+ if (dump_file)
+ fprintf(dump_file, "reload failure for reload %d\n", i);
spill_failure (chain->insn, rld[r].class);
failure = 1;
return;
@@ -1898,6 +1900,12 @@
{
error ("unable to find a register to spill in class %qs",
reg_class_names[class]);
+
+ if (dump_file)
+ {
+ fprintf (dump_file, "\nReloads for insn # %d\n", INSN_UID (insn));
+ debug_reload_to_stream (dump_file);
+ }
fatal_insn ("this is the insn:", insn);
}
}
@@ -6051,6 +6059,29 @@
reload_spill_index[r] = -1;
}
+
+/* Returns true if merging reloads i and j should result in a
+ RELOAD_FOR_OTHER_ADDRESS reload, else false for RELOAD_OTHER. */
+static int
+merge_becomes_other_address (int i, int j)
+{
+ int wn1 = rld[i].when_needed;
+ int wn2 = rld[j].when_needed;
+
+ if (wn2 == RELOAD_FOR_OTHER_ADDRESS)
+wn2 = wn1;
+ else if (wn1 != RELOAD_FOR_OTHER_ADDRESS)
+return 0;
+
+ return (wn2 == RELOAD_FOR_INPUT_ADDRESS
+ || wn2 == RELOAD_FOR_INPADDR_ADDRESS
+ || wn2 == RELOAD_FOR_OUTPUT_ADDRESS
+ || wn2 == RELOAD_FOR_OUTADDR_ADDRESS
+ || wn2 == RELOAD_FOR_OPERAND_ADDRESS
+ || wn2 == RELOAD_FOR_OPADDR_ADDR
+ || wn2 == RELOAD_FOR_OTHER_ADDRESS);
+}
+
/* If SMALL_REGISTER_CLASSES is nonzero, we may not have merged two
reloads of the same item for fear that we might not have enough reload
registers. However, normally they will get the same reload register
@@ -6064,6 +6095,7 @@
This will not increase the number of spill registers needed and will
prevent redundant code. */
+extern const char *const reload_when_needed_name[];
static void
merge_assigned_reloads (rtx insn)
{
@@ -6136,23 +6168,28 @@
|| rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
|| rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
{
- rld[i].when_needed = RELOAD_OTHER;
+ if (merge_becomes_other_address (i, j))
+ rld[i].when_needed = RELOAD_FOR_OTHER_ADDRESS;
+ else
+ rld[i].when_needed = RELOAD_OTHER;
rld[j].in = 0;
reload_spill_index[j] = -1;
transfer_replacements (i, j);
}
- /* If this is now RELOAD_OTHER, look for any reloads that load
-parts of this operand and set them to RELOAD_FOR_OTHER_ADDRESS
-if they were for inputs, RELOAD_OTHER for outputs. Note that
-this test is equivalent to looking for reloads for this operand
+ /* If this is now RELOAD_OTHER or RELOAD_FOR_OTHER_ADDRESS,
+look for any reloads that load parts of this operand and
+set them to RELOAD_FOR_OTHER_ADDRESS if they were for
+inputs, RELOAD_OTHER for outputs. Note that this test is
+equivalent to looking for reloads for this operand
number. */
/* We must take special care with RELOAD_FOR_OUTPUT_ADDRESS; it may
share registers with a RELOAD_FOR_INPUT, so we can not change it
to RELOAD_FOR_OTHER_ADDRESS. We should never need to, since we
do not modify RELOAD_FOR_OUTPUT. */
- if (rld[i].when_needed == RELOAD_OTHER)
+ if (rld[i].when_needed == RELOAD_OTHER
+ || rld[i].when_needed == RELOAD_FOR_OTHER_ADDRESS)
for (j = 0; j < n_reloads; j++)
if (rld[j].in != 0
&& rld[j].when_needed != RELOAD_OTHER
options for compiling C using C++ compiler [trying 1 more time]
I'm working on a project where I post-process AST (.tu) output from gcc using the -fdump-translation-unit option. Problem is the C compiler does not generate useful AST data. So I actually run the preprocessed source again thru g++ to get AST data. This works fine unless there are constructs not allowed under C++. Particular problems are bool and other keyword stuff and K&R style function declarations. I'm trying to find the best way to minimize the problem via options or other ways. I already use "-fpermissive" and this eases it a bit. Suggestions? -J _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Huge compile time regressions
On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote: > Hi, > > Someone caused a >10% compile time regression yesterday for CSiBE, see > http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs > > > Gr. > Steven > This is very very bad. Joern, i'd imagine this was your patch.
Problems with ?: operator
hi,
while compiling the following code on gcc v3.3 compiler (on mac os x),
i got the "invalid lvalue asignment" error as expected in the
following code:
main(){
int a = 1;
a < 10 ? a = 5 : a = 7;
return;
}
but i didn't get any error in
15 < 10 ? a = 5 : a = 7;
and
a < 10 ? a : a = 7;
5 < 10 ? a = 5 : a = 7; is giving error
15 < 10 ? a = 5 : a = 7; is not giving any error
why?
i am compiling using the following command:
$ cc -ansi -O0 file.c
all the syntaxes are wrong according to the ansi C grammar given in
"The C Programming Language" by Kernighan & Ritchie. then how come the
other 2 expressions are not giving compilation error.
when compiled on VC++, none of the expressions is giving error.
--
SULABH NANGALIA
Computer Science Engineer
Avisere
Mobile: +91 98300 29360
Need help
Dear all! It posible to receive function with type defined logicaly as '...false, true, true, ""' in 'attribute_spec', to a TARGET_EXPAND_BUILTIN or TARGET_RESOLVE_OVERLOADED_BUILTIN hooks? Criteria function return type and arguments count/type must be ignored for filtering. -- Regards Ivan Petrov
