RE: Understanding IRA
Hi again, Vladimir,
I am pleased to report some performance improvements after altering
ira-costs.c. A key benchmark for us has improved by 5%.
Specifically, in record_reg_classes(), after the alt_cost has been
calculated and it will be applied to pp->mem_cost and pp->cost[k], I
check whether this particular operand wanted one of our BOTTOM_REGS
(r0-r15) and I further increase the pp->mem_cost by an arbitrary
amount and also increase pp->cost[k] by an arbitrary amount if k
does not represent the BOTTOM_REGS class. My aim here is to nudge
IRA in the right direction for operands that just want BOTTOM_REGS.
After experimenting with different values for my "arbitrary
amounts", I discovered some that successfully made IRA more likely
to give BOTTOM_REGS to those instructions/operands that want
BOTTOM_REGS, since any other regs and memory ended up with high
enough costs for IRA to try and avoid using them.
I have included a snippet from my version of record_reg_classes()
below:
op_cost_add = alt_cost * frequency;
/* Finally, update the costs with the information we've
calculated about this alternative. */
for (i = 0; i < n_ops; i++)
if (REG_P (ops[i]) && REGNO (ops[i]) >= FIRST_PSEUDO_REGISTER)
{
struct costs *pp = op_costs[i], *qq = this_op_costs[i];
int scale = 1 + (recog_data.operand_type[i] == OP_INOUT);
/* If this operand really wanted a BOTTOM_REG, add an extra
cost onto memory to nudge IRA away from putting it in
memory */
if (allocno_pref &&
allocno_pref[ALLOCNO_NUM(ira_curr_regno_allocno_map
[REGNO (ops[i])])]
== BOTTOM_REGS)
{
pp->mem_cost = MIN (pp->mem_cost,
(qq->mem_cost + op_cost_add +
(flag_ira_preferred_register_cost_memory * frequency))
* scale);
}
else
{
pp->mem_cost = MIN (pp->mem_cost,
(qq->mem_cost + op_cost_add)
* scale);
}
for (k = 0; k < cost_classes_num; k++)
{
/* If this operand really wanted a BOTTOM_REG, add an
extra cost onto any register class that isn't
BOTTOM_REGS to nudge IRA away from putting it in a
hard register of that class */
if (allocno_pref &&
allocno_pref[ALLOCNO_NUM(ira_curr_regno_allocno_map
[REGNO (ops[i])])]
== BOTTOM_REGS)
{
switch(cost_classes[k])
{
case BOTTOM_REGS:
op_cost_add = alt_cost * frequency;
break;
case TOP_CREGS:
case C_REGS:
op_cost_add = (alt_cost +
flag_ira_preferred_register_cost_register)
* frequency;
break;
default:
op_cost_add = alt_cost * frequency;
break;
}
}
pp->cost[k] = MIN (pp->cost[k],
(qq->cost[k] + op_cost_add)
* scale);
}
}
So far, I have found the best value for
flag_ira_preferred_register_cost_memory to be 20 and the best value
for flag_ira_preferred_register_cost_register to be 6. I appreciate
that these numbers do not really correlate with the other cost units
but they were the ones that made the impact.
In terms of coloring algorithms, we are still seeing better
performance with the priority algorithm on our benchmarks, but the
cost adjustments above improved both priority algorithm and the CB
algorithm, with ira-region=mixed and ira-region=one.
If you have any thoughts you'd like to share then I'd definitely be
interested, but this post is mainly because you said in a previous
email that you wanted to hear my suggestions :)
Best regards,
Ian
>Ian Bolton wrote:
>> I hope you could also make some suggestions as to how I might
>> help IRA work well with our instructions that can only use a
>> subset of the register bank.
>>
>I forgot to write: thanks, it would be interesting for me to see
>your suggestions :)
Re: Lattice Mico32 port
On Wed, Oct 21, 2009 at 7:49 AM, Jon Beniston wrote: >> The port is ok to check in. > > Great - so can I apply it, or does someone else need to? Until you have write access to the repository, someone else needs to commit the patch for you. The GCC community generally likes to see a few examples of patches (correctness, coding standards) and knowledge about version control repositories before giving write access. Thanks, David
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160567p26160567.html Sent from the gcc - Dev mailing list archive at Nabble.com.
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160568p26160568.html Sent from the gcc - Dev mailing list archive at Nabble.com.
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160571p26160571.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Understanding IRA
On 11/03/09 09:29, Ian Bolton wrote: Hi again, Vladimir, I am pleased to report some performance improvements after altering ira-costs.c. A key benchmark for us has improved by 5%. Specifically, in record_reg_classes(), after the alt_cost has been calculated and it will be applied to pp->mem_cost and pp->cost[k], I check whether this particular operand wanted one of our BOTTOM_REGS (r0-r15) and I further increase the pp->mem_cost by an arbitrary amount and also increase pp->cost[k] by an arbitrary amount if k does not represent the BOTTOM_REGS class. My aim here is to nudge IRA in the right direction for operands that just want BOTTOM_REGS. After experimenting with different values for my "arbitrary amounts", I discovered some that successfully made IRA more likely to give BOTTOM_REGS to those instructions/operands that want BOTTOM_REGS, since any other regs and memory ended up with high enough costs for IRA to try and avoid using them. I have included a snippet from my version of record_reg_classes() below: What I don't understand at this point is why the current mechanisms in IRA aren't showing a lower cost for using BOTTOM_REGS (or a higher cost for TOP_REGS). i.e. I don't think any of this should be necessary as IRA should already be doing something similar. This may be a case where your backend hasn't indicated that TOP_REGS has a higher cost than BOTTOM_REGS in particular situations. jeff
Re: help on - instruction scheduling passes in gcc
ddmetro writes: > 1. We are expecting that pass_sched and pass_sched2, each will enter > schedule_insns() function once per pass. However, we found that it is > entering schedule_insns() function per function(in the program) per pass. > (If there are two functions in the input program, pass_sched will enter > schedule_insns() twice and pass_sched2 will also enter schedule_insns() > twice.)We are not able to track this flow in the code. Kindly help us as to > what are we missing out? I got six copies of your message. One is sufficient. The optimization passes are all run for each function. If you have two functions, pass_sched and pass_sched2 will each be run twice. > 2. We are trying to visualize the code into regions and then into basic > blocks i.e., what all insns form a basic block and what basic blocks form a > region. >Also we are trying to figure out - the before and after scenarios - when > an insn moves from one basic block to another. >However we are not able to map this information looking at any of the rtl > dump files. >Kindly help us as to what should be our approach? Look for the basic block notes or use -fdump-rtl-all-blocks. > 3. We are trying to figure out the difference and need of 2 passes, both > calling the same function(schedule_insns()). However, we are unable to find > any difference in the two calls to schedule_insns() in two schedule > passes(pass_sched and pass_sched2). Kindly help us as to what are we missing > out? The difference is that pass_sched is called before register allocation and pass_sched2 is called after. Ian
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160585p26160585.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
KOSAKI Motohiro wrote: Hello, I'm not sure how to handle this, while compiling firefox-3.6b1.source I get this with the default compiling options, as well as custom: [ 532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0 [ 532.942330] Pid: 16002, comm: cc1plus Tainted: P 2.6.32-rc5-00083-g04ea458 #2 [ 532.942333] Call Trace: [ 532.942342] [] T.417+0x7c/0x245 [ 532.942347] [] __out_of_memory+0x142/0x159 [ 532.942352] [] out_of_memory+0x6e/0x9d [ 532.942357] [] __alloc_pages_nodemask+0x47e/0x5cc [ 532.942363] [] handle_mm_fault+0x25d/0x68e [ 532.942369] [] do_page_fault+0x2bb/0x2d3 [ 532.942373] [] page_fault+0x25/0x30 [ 532.942376] Mem-Info: [ 532.942378] DMA per-cpu: [ 532.942380] CPU0: hi:0, btch: 1 usd: 0 [ 532.942383] CPU1: hi:0, btch: 1 usd: 0 [ 532.942385] DMA32 per-cpu: [ 532.942388] CPU0: hi: 186, btch: 31 usd: 94 [ 532.942391] CPU1: hi: 186, btch: 31 usd: 23 [ 532.942393] Normal per-cpu: [ 532.942395] CPU0: hi: 186, btch: 31 usd: 150 [ 532.942398] CPU1: hi: 186, btch: 31 usd: 155 [ 532.942404] active_anon:707575 inactive_anon:264673 isolated_anon:0 [ 532.942406] active_file:58 inactive_file:33 isolated_file:0 file cache (active_file + inactive_file) was very little. It indicate anyone waste too much memory. I doubt you use buggy compiler. hmm... then this is something with firefox then.. In that case I'll continue to build my system with this compiler. Although a bit concerned building everything for the system with a compiler that shows some memory issue,but if you say its not the compiler, then I'll carry on with what I'm doing. (and use an older compiler for firefox). Justin P. Mattock
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160581p26160581.html Sent from the gcc - Dev mailing list archive at Nabble.com.
help on - instruction scheduling passes in gcc
Hi All, Our project is to optimize instruction scheduling in gcc by detecting structural hazards. We are trying to understand the two instruction scheduling passes(pass_sched and pass_sched2) and have the following doubts regarding the same. We are currently looking at schedule_insns() method and not selective scheduler. 1. We are expecting that pass_sched and pass_sched2, each will enter schedule_insns() function once per pass. However, we found that it is entering schedule_insns() function per function(in the program) per pass. (If there are two functions in the input program, pass_sched will enter schedule_insns() twice and pass_sched2 will also enter schedule_insns() twice.)We are not able to track this flow in the code. Kindly help us as to what are we missing out? 2. We are trying to visualize the code into regions and then into basic blocks i.e., what all insns form a basic block and what basic blocks form a region. Also we are trying to figure out - the before and after scenarios - when an insn moves from one basic block to another. However we are not able to map this information looking at any of the rtl dump files. Kindly help us as to what should be our approach? 3. We are trying to figure out the difference and need of 2 passes, both calling the same function(schedule_insns()). However, we are unable to find any difference in the two calls to schedule_insns() in two schedule passes(pass_sched and pass_sched2). Kindly help us as to what are we missing out? Target language for which optimization is being done: C Target machine architecture: i686 GCC version: 4.4.1 Kindly help us with our issues. Thanking You, Dhiraj Padnani -- View this message in context: http://old.nabble.com/help-on---instruction-scheduling-passes-in-gcc-tp26160582p26160582.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Preserving the argument spills for GDB
I will try to add more details about my issue. Another way of putting this is : For my architecture there is: - A certain number of input registers which allow calls without going on the stack - There is not automatically a frame pointer on the stack either What is needed, from the GCC side, to provide GDB with enough information to preserve the arguments that are passed and allow to see a backtrace and walk the stack. Do we need to change the ABI and store certain indispensable things on the stack for GDB ? I see very little documentation about this or questions, so I don't know exactly where to look to. Note: in O0 levels, the compiler does actually store the arguments on the stack and has a frame pointer, this gives GDB the possibility to do show the arguments passed to a function at a break point but not the backtrace. In O3, however, I don't even get the arguments correct. Thanks for any input, Jc On Tue, Nov 3, 2009 at 2:01 PM, Jean Christophe Beyler wrote: > Dear all, > > I've been working on handling the Debugging information for the use of > GDB on my port. Though I definitely know that, when compiling in -O3, > some information is lost and the debugger can't always have all the > information, I'd like to at least keep the values of the arguments > when doing a backtrace. Since my architecture uses register passing > for arguments, relatively quickly this is lost since it is not stored > on the stack. > > Therefore, I would like to, when doing a backtrace, have the argument > information. I asked a few clarifications on the GDB mailing list and, > it seems, that I need to copy the arguments on the stack (like what is > done by default when using -O0). However, when compiling in -O3, the > compiler of course removes these stores on the stack and relies solely > (and justly so) on the input registers. > > I've reread the GCC internals and have been looking at anything > regarding the stack but can't seem to figure this one out. How exactly > do I explain to the compiler that I want to keep those spills to the > stack for debugging purposes ? > > Thanks for your help, > Jc >
Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
On Tue, Nov 3, 2009 at 3:23 PM, Roland McGrath wrote:
> --with is wrong for this. It's not about the ambient system built against.
> It's a feature selection for how you build binutils, which means --enable.
>
Here is the updated patch.
--
H.J.
2009-11-03 Roland McGrath
H.J. Lu
* configure.ac (--enable-gold): Accept --enable-gold=both to
add gold to configdirs without removing ld.
* configure: Regenerated.
gold/
2009-11-03 H.J. Lu
* Makefile.am (install-exec-local): Install as @installed_lin...@.
Install as ld if "@linker@" == "ld.gold" and @installed_linker@
!= "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--enable-linker.
* configure: Regenerated.
ld/
2009-11-03 H.J. Lu
* Makefile.am (transform): Install as @installed_lin...@.
(install-exec-local): Depend on install-binPROGRAMS. Install
as @installed_lin...@. Install as ld if "@linker@" == "ld.bfd"
and @installed_linker@ != "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--enable-linker.
* configure: Regenerated.
diff --git a/configure b/configure
index 1ece75c..e353f63 100755
--- a/configure
+++ b/configure
@@ -1482,7 +1482,7 @@ Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
- --enable-gold use gold instead of ld
+ --enable-gold[=ARG] build gold [ARG={yes,both}]
--enable-libada build libada directory
--enable-libssp build libssp directory
--enable-build-with-cxx build with C++ compiler instead of C compiler
@@ -3076,7 +3076,8 @@ else
ENABLE_GOLD=no
fi
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in
+yes|both)
# Check for ELF target.
is_elf=no
case "${target}" in
@@ -3096,11 +3097,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+if test "${ENABLE_GOLD}" = both; then
+ configdirs="$configdirs gold"
+ else
+ configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+ fi
;;
esac
fi
-fi
+ ENABLE_GOLD=yes
+ ;;
+esac
# Configure extra directories which are host specific
diff --git a/configure.ac b/configure.ac
index 407ab59..b349633 100644
--- a/configure.ac
+++ b/configure.ac
@@ -311,10 +311,11 @@ esac
# Handle --enable-gold.
AC_ARG_ENABLE(gold,
-[ --enable-gold use gold instead of ld],
+[ --enable-gold[[=ARG]] build gold [[ARG={yes,both}]]],
ENABLE_GOLD=$enableval,
ENABLE_GOLD=no)
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in
+yes|both)
# Check for ELF target.
is_elf=no
case "${target}" in
@@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+if test "${ENABLE_GOLD}" = both; then
+ configdirs="$configdirs gold"
+ else
+ configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+ fi
;;
esac
fi
-fi
+ ENABLE_GOLD=yes
+ ;;
+esac
# Configure extra directories which are host specific
diff --git a/gold/Makefile.am b/gold/Makefile.am
index 8d8b617..85b103b 100644
--- a/gold/Makefile.am
+++ b/gold/Makefile.am
@@ -163,12 +163,20 @@ check: libgold.a
install-exec-local: ld-new$(EXEEXT)
$(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
- n=`echo ld | sed '$(transform)'`; \
+ n=`echo @installed_linker@ | sed '$(transform)'`; \
$(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(bindir)/$${n}$(EXEEXT); \
- if test "$(bindir)" != "$(tooldir)/bin"; then \
- rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
- ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT)
$(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
+ if test "@linker@" = "ld.gold"; then \
+ if test "@installed_linker@" != "ld"; then \
+ ld=`echo ld | sed '$(transform)'`; \
+ rm -f $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
+ ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT)
$(DESTDIR)$(bindir)/$${ld}$(EXEEXT) >/dev/null 2>/dev/null \
+ || $(INSTALL_PROGRAM) ld-new$(EXEEXT)
$(DESTDIR)$(bindir)/$${ld}
Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
--with is wrong for this. It's not about the ambient system built against. It's a feature selection for how you build binutils, which means --enable.
Re: How to debug lto1 ICE?
On Tue, Nov 3, 2009 at 1:12 PM, Rafael Espindola wrote: > That is correct. This is to avoid command lines that are too large. We > currently delete those files during the plugin cleanup. I will send a > patch disabling cleanup if -debug is given. -save-temps will also keep the files around which is what I use to be able to debug lto1. Thanks, Andrew Pinski
Re: How to debug lto1 ICE?
> But with the above details, how can I figure out how to run gdb, ie what > arguments to give to gdb --args? This is an area that needs some improvement :-( What I do is pass -Wl,-debug to gcc. That will make collect2 print the call to ld. Add a -plugin-opt=-debug to it and it should print the call to lto-wrapper. > I suppose the offending process is probably > /usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet > -dumpbase interp.pic.o -mtune=generic -auxbase-strip /tmp/ccKdeyrC.lto.o -O2 > -version @/tmp/ccJMSLwC -o /tmp/ccODq2S4.s > > But I am not sure to understand correctly, in particular the @/tmp/ccJMSLwC > argument puzzles me. Apparently, some program arguments are collected in > some temporary files That is correct. This is to avoid command lines that are too large. We currently delete those files during the plugin cleanup. I will send a patch disabling cleanup if -debug is given. > So how do I run lto1 under GDB, knowing the faulty gcc invocation? Given the lto-wrapper line above, add -debug to it and it will print the lto1 invocation. > Regards. > Cheers, -- Rafael Ávila de Espíndola
Preserving the argument spills for GDB
Dear all, I've been working on handling the Debugging information for the use of GDB on my port. Though I definitely know that, when compiling in -O3, some information is lost and the debugger can't always have all the information, I'd like to at least keep the values of the arguments when doing a backtrace. Since my architecture uses register passing for arguments, relatively quickly this is lost since it is not stored on the stack. Therefore, I would like to, when doing a backtrace, have the argument information. I asked a few clarifications on the GDB mailing list and, it seems, that I need to copy the arguments on the stack (like what is done by default when using -O0). However, when compiling in -O3, the compiler of course removes these stores on the stack and relies solely (and justly so) on the input registers. I've reread the GCC internals and have been looking at anything regarding the stack but can't seem to figure this one out. How exactly do I explain to the compiler that I want to keep those spills to the stack for debugging purposes ? Thanks for your help, Jc
gcc-4.4-20091103 is now available
Snapshot gcc-4.4-20091103 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091103/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 153873 You'll find: gcc-4.4-20091103.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091103.tar.bz2 C front end and core compiler gcc-ada-4.4-20091103.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091103.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091103.tar.bz2 C++ front end and runtime gcc-java-4.4-20091103.tar.bz2 Java front end and runtime gcc-objc-4.4-20091103.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091103.tar.bz2The GCC testsuite Diffs from 4.4-20091027 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
> Hello, > I'm not sure how to handle this, > while compiling firefox-3.6b1.source > I get this with the default compiling options, > as well as custom: > > > [ 532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, > oom_adj=0 > [ 532.942330] Pid: 16002, comm: cc1plus Tainted: P > 2.6.32-rc5-00083-g04ea458 #2 > [ 532.942333] Call Trace: > [ 532.942342] [] T.417+0x7c/0x245 > [ 532.942347] [] __out_of_memory+0x142/0x159 > [ 532.942352] [] out_of_memory+0x6e/0x9d > [ 532.942357] [] __alloc_pages_nodemask+0x47e/0x5cc > [ 532.942363] [] handle_mm_fault+0x25d/0x68e > [ 532.942369] [] do_page_fault+0x2bb/0x2d3 > [ 532.942373] [] page_fault+0x25/0x30 > [ 532.942376] Mem-Info: > [ 532.942378] DMA per-cpu: > [ 532.942380] CPU0: hi:0, btch: 1 usd: 0 > [ 532.942383] CPU1: hi:0, btch: 1 usd: 0 > [ 532.942385] DMA32 per-cpu: > [ 532.942388] CPU0: hi: 186, btch: 31 usd: 94 > [ 532.942391] CPU1: hi: 186, btch: 31 usd: 23 > [ 532.942393] Normal per-cpu: > [ 532.942395] CPU0: hi: 186, btch: 31 usd: 150 > [ 532.942398] CPU1: hi: 186, btch: 31 usd: 155 > [ 532.942404] active_anon:707575 inactive_anon:264673 isolated_anon:0 > [ 532.942406] active_file:58 inactive_file:33 isolated_file:0 file cache (active_file + inactive_file) was very little. It indicate anyone waste too much memory. I doubt you use buggy compiler. > [ 532.942407] unevictable:0 dirty:0 writeback:0 unstable:0 buffer:71 > [ 532.942408] free:6998 slab_reclaimable:2697 slab_unreclaimable:16267 > [ 532.942409] mapped:136 shmem:64 pagetables:2761 bounce:0 > [ 532.942418] DMA free:15944kB min:28kB low:32kB high:40kB > active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB > unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15360kB > mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB > slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB > pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB > pages_scanned:0 all_unreclaimable? yes > [ 532.942425] lowmem_reserve[]: 0 2976 3986 3986 > [ 532.942436] DMA32 free:10020kB min:6020kB low:7524kB high:9028kB > active_anon:2360492kB inactive_anon:590196kB active_file:84kB > inactive_file:68kB unevictable:0kB isolated(anon):0kB > isolated(file):0kB present:3047792kB mlocked:0kB dirty:0kB > writeback:0kB mapped:136kB shmem:80kB slab_reclaimable:0kB > slab_unreclaimable:88kB kernel_stack:0kB pagetables:6100kB > unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:448 > all_unreclaimable? yes > [ 532.942443] lowmem_reserve[]: 0 0 1010 1010 > [ 532.942454] Normal free:2028kB min:2040kB low:2548kB high:3060kB > active_anon:469808kB inactive_anon:468496kB active_file:148kB > inactive_file:64kB unevictable:0kB isolated(anon):0kB > isolated(file):0kB present:1034240kB mlocked:0kB dirty:0kB > writeback:0kB mapped:408kB shmem:176kB slab_reclaimable:10788kB > slab_unreclaimable:64972kB kernel_stack:800kB pagetables:4944kB > unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:413 > all_unreclaimable? yes > [ 532.942461] lowmem_reserve[]: 0 0 0 0 > [ 532.942465] DMA: 2*4kB 2*8kB 3*16kB 2*32kB 3*64kB 2*128kB 2*256kB > 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15944kB > [ 532.942478] DMA32: 7*4kB 7*8kB 5*16kB 4*32kB 2*64kB 1*128kB 1*256kB > 4*512kB 3*1024kB 0*2048kB 1*4096kB = 10020kB > [ 532.942490] Normal: 507*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2028kB > [ 532.942501] 7974 total pagecache pages > [ 532.942503] 7778 pages in swap cache > [ 532.942506] Swap cache stats: add 112290, delete 104512, find 3595/4051 > [ 532.942508] Free swap = 0kB > [ 532.942510] Total swap = 431632kB > [ 532.957941] 1048576 pages RAM > [ 532.957943] 40518 pages reserved > [ 532.957945] 312 pages shared > [ 532.957947] 1000176 pages non-shared > [ 532.957951] Out of memory: kill process 16001 (c++) score 543727 or a child > [ 532.957955] Killed process 16002 (cc1plus) > > I just compiled the latest gcc snapshot a few days > ago.
How to debug lto1 ICE?
Hello All I just encountered a ICE from LTO. I hope I gave enough details in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932 BTW, I am quite scared of the official policy of only preprocessed files in bugzilla. I feel it does not match well LTO issues. I tried to make a bug report as precise as possible. Since it is a SIGSEGV ICE, I would have been happy to investigate it myself (even if today I don't know anything about LTO). However, I have no idea of how and what to start under the debugger. Running the faulty gcc with gcc -v gives me % gcc-trunk -v -flto -O2 -shared -o libcamlrun_shared.so interp.pic.o misc.pic.o stacks.pic.o fix_code.pic.o startup.pic.o freelist.pic.o major_gc.pic.o minor_gc.pic.o memory.pic.o alloc.pic.o roots.pic.o globroots.pic.o fail.pic.o signals.pic.o signals_byt.pic.o printexc.pic.o backtrace.pic.o compare.pic.o ints.pic.o floats.pic.o str.pic.o array.pic.o io.pic.o extern.pic.o intern.pic.o hash.pic.o sys.pic.o meta.pic.o parsing.pic.o gc_ctrl.pic.o terminfo.pic.o md5.pic.o obj.pic.o lexing.pic.o callback.pic.o debugger.pic.o weak.pic.o compact.pic.o finalise.pic.o custom.pic.o dynlink.pic.o unix.pic.o main.pic.o -lm -ldl -lcurses -lpthread Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk --with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib --enable-languages=c,c++ --enable-lto --enable-plugins --enable-maintainer-mode : (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk --with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib --enable-languages=c,c++ --enable-lto --enable-plugins --enable-maintainer-mode : (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk --with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib --enable-lto --enable-plugins --enable-maintainer-mode --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk --with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib --enable-lto --enable-plugins --enable-maintainer-mode --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure --program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk --with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ --disable-multilib --enable-lto --enable-plugins --enable-maintainer-mode --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 4.5.0 20091103 (experimental) (GCC) COMPILER_PATH=/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-flto' '-O2' '-shared' '-o' 'libcamlrun_shared.so' '-mtune=generic' /usr/local/libexec/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 -flto --eh-frame-hdr -m elf_x86_64 -shared -o libcamlrun_shared.so /usr/lib/../lib64/crti.o /usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbeginS.o -L/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0 -L/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. interp.pic.o misc.pic.o stacks.pic.o fix_code.pic.o startup.pic.o freelist.pic.o major_gc.pic.o minor_gc.pic.o memory.pic.o alloc.pic.o roots.pic.o globroots.pic.o fail.pic.o signals.pic.o signals_byt.pic.o printexc.pic.o backtrace.pic.o compare.pic.o ints.pic.o floats.pic.o str.pic.o array.pic.o io.pic.o extern.pic.o intern.pic.o hash.pic.o sys.pic.o meta.pic.o parsing.pic.o gc_ctrl.pic.o terminfo.pic.o md5.pic.o obj.pic.o lexing.pic.o callback.pic.o debugger.pic.o weak.pic.o compact.pic.o finalise.pic.o custom.pic.o dynlink.pic.o unix.pic.
Re: Preserving the argument spills for GDB
Jean Christophe Beyler writes: > I've been working on handling the Debugging information for the use of > GDB on my port. Though I definitely know that, when compiling in -O3, > some information is lost and the debugger can't always have all the > information, I'd like to at least keep the values of the arguments > when doing a backtrace. Since my architecture uses register passing > for arguments, relatively quickly this is lost since it is not stored > on the stack. > > Therefore, I would like to, when doing a backtrace, have the argument > information. I asked a few clarifications on the GDB mailing list and, > it seems, that I need to copy the arguments on the stack (like what is > done by default when using -O0). However, when compiling in -O3, the > compiler of course removes these stores on the stack and relies solely > (and justly so) on the input registers. > > I've reread the GCC internals and have been looking at anything > regarding the stack but can't seem to figure this one out. How exactly > do I explain to the compiler that I want to keep those spills to the > stack for debugging purposes ? 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. Not to miss the obvious, note that this will hurt optimization. However, if you need to have the argument values available for all backtraces, then I'm not sure what else to recommend. In general gcc will discard argument values that are not needed. Ian
Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
On Mon, Nov 2, 2009 at 3:06 PM, H.J. Lu wrote:
> Hi,
>
> This patch adds --enable-gold=both --with-linker=[bfd|gold] so that we
> can build both ld and gold. This patch will
>
> 1. Install ld as ld.bfd
> 2. Install gold as ld.gold
> 3. Install one of them as ld, selected by --with-linker.
>
> If needed, gcc install invoke gold as ld.gold and ld as ld.bfd. Any
> comments?
>
Here is the updated patch. It installs ld.bfd/ld.gold only if both
linkers are enabled.
H.J.
---
2009-11-03 Roland McGrath
H.J. Lu
* configure.ac (--enable-gold): Accept --enable-gold=both to
add gold to configdirs without removing ld.
* configure: Regenerated.
gold/
2009-11-03 H.J. Lu
* Makefile.am (install-exec-local): Install as @installed_lin...@.
Install as ld if "@linker@" == "ld.gold" and @installed_linker@
!= "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--with-linker.
* configure: Regenerated.
ld/
2009-11-03 H.J. Lu
* Makefile.am (transform): Install as @installed_lin...@.
(install-exec-local): Depend on install-binPROGRAMS. Install
as @installed_lin...@. Install as ld if "@linker@" == "ld.bfd"
and @installed_linker@ != "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--with-linker.
* configure: Regenerated.
2009-11-03 Roland McGrath
H.J. Lu
* configure.ac (--enable-gold): Accept --enable-gold=both to
add gold to configdirs without removing ld.
* configure: Regenerated.
gold/
2009-11-03 H.J. Lu
* Makefile.am (install-exec-local): Install as @installed_lin...@.
Install as ld if "@linker@" == "ld.gold" and @installed_linker@
!= "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--with-linker.
* configure: Regenerated.
ld/
2009-11-03 H.J. Lu
* Makefile.am (transform): Install as @installed_lin...@.
(install-exec-local): Depend on install-binPROGRAMS. Install
as @installed_lin...@. Install as ld if "@linker@" == "ld.bfd"
and @installed_linker@ != "ld".
* Makefile.in: Regenerated.
* configure.ac (installed_linker): New substituted variable. Set
by --enable-gold.
(linker): New substituted variable. Set by --enable-gold and
--with-linker.
* configure: Regenerated.
diff --git a/configure b/configure
index 1ece75c..e353f63 100755
--- a/configure
+++ b/configure
@@ -1482,7 +1482,7 @@ Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
- --enable-gold use gold instead of ld
+ --enable-gold[=ARG] build gold [ARG={yes,both}]
--enable-libada build libada directory
--enable-libssp build libssp directory
--enable-build-with-cxx build with C++ compiler instead of C compiler
@@ -3076,7 +3076,8 @@ else
ENABLE_GOLD=no
fi
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in
+yes|both)
# Check for ELF target.
is_elf=no
case "${target}" in
@@ -3096,11 +3097,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+if test "${ENABLE_GOLD}" = both; then
+ configdirs="$configdirs gold"
+ else
+ configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+ fi
;;
esac
fi
-fi
+ ENABLE_GOLD=yes
+ ;;
+esac
# Configure extra directories which are host specific
diff --git a/configure.ac b/configure.ac
index 407ab59..b349633 100644
--- a/configure.ac
+++ b/configure.ac
@@ -311,10 +311,11 @@ esac
# Handle --enable-gold.
AC_ARG_ENABLE(gold,
-[ --enable-gold use gold instead of ld],
+[ --enable-gold[[=ARG]] build gold [[ARG={yes,both}]]],
ENABLE_GOLD=$enableval,
ENABLE_GOLD=no)
-if test "${ENABLE_GOLD}" = "yes"; then
+case "${ENABLE_GOLD}" in
+yes|both)
# Check for ELF target.
is_elf=no
case "${target}" in
@@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
# Check for target supported by gold.
case "${target}" in
i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-configdirs="`echo "
Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]
I can't really tell how that's different from the patch I posted. It looks fine to me. Thanks, Roland
Re: i370 port
C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
../include
varasm.c
(insn 117 429 118 7 (parallel [
(set (reg:SI 64)
(compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21
virtual-stack-vars)
(const_int 456 [0x1c8])) [232 value+0 S196
A64])
(mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
(const_int 8 [0x8])) [0 A8])))
(use (const_int 196 [0xc4]))
]) -1 (nil)
(nil))
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in
instantiate_virtual_regs_lossage,
at function.c:3767
OK, so what goes on here is that GCC attempts to replace the "virtual"
register 21 (virtual-stack-vars) with some real register, that is
frame pointer + STARTING_FRAME_OFFSET. It seems for the i370 port,
this should resolve to
register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size
Overall, the middle-end would therefore replace "reg 21 + 456" with
"reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
+ current_function_outgoing_args_size.
It will then re-process the insn pattern constraints to verify that the
resulting insn is still valid. At this stage, it appears we're running
into the above error. I'm not quite sure why this would be case, this
will require some further debugging why the insn was not recognized ...
This mystery is finally solved.
The previous workaround I had in place failed when I tried to do an
unoptimized compile of varasm.c. I found this out when I tried speeding
up the experimental configure/make process. However, since it was
occurring with unoptimized compiles, I thought it would be easier to
track down, and indeed, I found out that the memcmp was only
failing for values 128 and above. 127 was working fine. That made me
suspect a signed char vs unsigned char problem.
And it's the "QI" below that was causing the grief ...
*** 699,711
{
op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
}
!
! /* one circumstance has been found where this short comparison
! causes an internal error. Could be related to the fact that
! both displacements were non-zero, which is unusual. So check
! for that */
! if (((iv1 == 0) || (iv2 == 0)) &&
! GET_CODE (operands[3]) == CONST_INT && INTVAL (operands[3]) < 256)
{
emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
gen_rtx_SET (VOIDmode, operands[0],
--- 697,705
{
op2 = gen_rtx_MEM (BLKmode, copy_to_mode_reg (SImode, op2));
}
!
! if (GET_CODE (operands[3]) == CONST_INT
! && (unsigned)INTVAL (operands[3]) < 256)
{
emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2,
gen_rtx_SET (VOIDmode, operands[0],
***
*** 747,753
[(set (match_operand:SI 0 "register_operand" "=d")
(compare:SI (match_operand:BLK 1 "s_operand" "m")
(match_operand:BLK 2 "s_operand" "m")))
!(use (match_operand:QI 3 "immediate_operand" "I"))]
"((unsigned) INTVAL (operands[3]) < 256)"
"*
{
--- 741,747
[(set (match_operand:SI 0 "register_operand" "=d")
(compare:SI (match_operand:BLK 1 "s_operand" "m")
(match_operand:BLK 2 "s_operand" "m")))
!(use (match_operand:SI 3 "immediate_operand" "I"))]
"((unsigned) INTVAL (operands[3]) < 256)"
"*
{
The QI must be a signed char, and thus rejecting any value greater than 127.
As you can see, I changed it to SI, which, with the constraints and tests
in place, should be fine.
Just to be sure, I did a before and after comparison of the generated
assembler for all of GCC (3.4.6) and it all checked out fine. :-)
BFN. Paul.
Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock wrote: > Hello, > I'm not sure how to handle this, > while compiling firefox-3.6b1.source > I get this with the default compiling options, > as well as custom: > > ... > > active_anon:2360492kB inactive_anon:590196kB active_file:84kB 2.8GB of anonymous memory > [ 532.942508] Free swap = 0kB > [ 532.942510] Total swap = 431632kB 430MB of swap, all used up. That's a genuine OOM. Something (presumably cc1plus) has consumed wy too much memory, quite possibly leaked it. It would help if the oom-killer were to print some information about the oom-killed process's memory footprint.
Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
Andrew Morton wrote: On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock wrote: Hello, I'm not sure how to handle this, while compiling firefox-3.6b1.source I get this with the default compiling options, as well as custom: ... active_anon:2360492kB inactive_anon:590196kB active_file:84kB 2.8GB of anonymous memory figured it would be good enough (I think I have 4gig's total) [ 532.942508] Free swap = 0kB [ 532.942510] Total swap = 431632kB 430MB of swap, all used up. yep, narrow down to the smallest amount. That's a genuine OOM. Something (presumably cc1plus) has consumed wy too much memory, quite possibly leaked it. It would help if the oom-killer were to print some information about the oom-killed process's memory footprint. I still have everything setup(if you need me to add a debug patch let me know) as for compiling: libc compiled fine, kernel fine, and every package on the clfs list up to boot up the fresh system. (was figuring out how to compiling/install firefox before I threw the old system away). stable gcc(4.4*) on the macbook(same os/kernel) compiled fine firefox, xulrunner, and in the process thunderbird... Justin P. Mattock
