Re: comparing DejaGNU results
On Thu, 2006-06-01 at 03:43, Mike Stump wrote:
> Mine was designed to do two things, figure out if the results are
> interesting and not send email, if they are not, and to show
> engineers the `interesting' detailed results in priority order. It's
> meant to be run daily, and on good days, it produces no output. On
> normal days, output is 20-30 lines at most. It tries to balance the
> complaints with the occasional atta boy, to help with moral.
The only problem I have with Mike's script is that it doesn't handle
runs with multiple multi-lib variants nicely. Attached is a local hack
that I have to address this, but you'll need to re-seed your reference
files if you apply it.
With the change the output generated is not something like
Tests that now work, but didn't before:
arm-sim/-mthumb: g++.old-deja/g++.oliva/template9.C (test for errors, line 10)
arm-sim: g++.old-deja/g++.oliva/template9.C (test for errors, line 10)
New tests that FAIL:
arm-sim/-mthumb: g++.dg/init/const3.C (test for excess errors)
arm-sim/-mthumb: g++.dg/opt/temp2.C (test for excess errors)
arm-sim/-mthumb: g++.dg/other/unused1.C scan-assembler stringz?\t"class2"
arm-sim/-mthumb: g++.dg/other/unused1.C scan-assembler stringz?\t"printer"
arm-sim/-mthumb: g++.dg/template/fntry1.C (test for excess errors)
arm-sim: g++.dg/other/unused1.C scan-assembler stringz?\t"class2"
arm-sim: g++.dg/other/unused1.C scan-assembler stringz?\t"printer"
--- /home/rearnsha/gnusrc/gcc/trunk/contrib/compare_tests 2005-11-12
16:36:57.0 +
+++ compare_gcc_tests 2006-01-24 18:49:05.0 +
@@ -22,8 +22,8 @@
exit 2
fi
-sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$1" >$tmp1
-sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$2" >$tmp2
+sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$1" | awk '/^Running target / {target
= $3} {sub(/: /, "&"target": " ); print $0;}' >$tmp1
+sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$2" | awk '/^Running target / {target
= $3} {sub(/: /, "&"target": " ); print $0;}' >$tmp2
before=$tmp1
now=$tmp2
Re: IA-64 speculation patches have bad impact on ARM
Vladimir Makarov wrote: ... I am agree with this. Two months ago Maxim submitted patches which affects only ia64 except one thing affecting all targets - the patch which builds more scheduling regions and as consequence permits more aggressive interblock scheduling. Insn scheduling before the register allocation even without Maxim's patches is not safe when hard registers are used in RTL. It is a known bug (e.g. for x86_64) and it is in bugzilla. Jim Wilson wrote several possible solutions for this, no one is easy to implement except for switching off insn scheduling before RA (what is done for x86_64). But we can restore the state (probably safe for most programs) what was before Maxim's patch. So Maxim could you do this (of course you can save max-sched-extend-regions-iters value for ia64 because it is probably safe for targets with many registers). Vlad Considering that bug, I agree that by default there should be no additional regions. The patch will be posted in a few minutes. -- Maxim
hppa libiberty configure failure: Link tests are not allowed after GCC_NO_EXECUTABLES.
I get the following failure while building gcc 4.2 on hppa: checking for pid_t... no checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libiberty] Error 1 make[3]: Leaving directory `/build/buildd/gcc-snapshot-20060530/build-hppa64' make[2]: *** [all] Error 2 -- Martin Michlmayr http://www.cyrius.com/
Re: hppa libiberty configure failure: Link tests are not allowed after GCC_NO_EXECUTABLES.
Martin Michlmayr writes: > I get the following failure while building gcc 4.2 on hppa: > > checking for pid_t... no > checking for library containing strerror... configure: error: Link tests are > not allowed after GCC_NO_EXECUTABLES. > make[3]: *** [configure-target-libiberty] Error 1 > make[3]: Leaving directory > `/build/buildd/gcc-snapshot-20060530/build-hppa64' > make[2]: *** [all] Error 2 you try to build some target library for hppa64-linux, which won't work. most likely some --disable-gomp is missing when configuring the cross compiler. Matthias
Re: IA-64 speculation patches have bad impact on ARM
Daniel Jacobowitz wrote:
...
Not even a single comment - shame on you both! :-) If this is the
solution we choose, can we make sure that there's at least a comment
explaining what's going on?
Totally agree. That was an *example patch*. Here is a bit updated, but
still an example of how we can arrange instructions on ARM or some other
platform with not much execution units.
--
Maxim
--- config/arm/arm.c (/gcc-local/trunk/gcc) (revision 19935)
+++ config/arm/arm.c (/gcc-local/arm-bug/gcc) (revision 19935)
@@ -52,6 +52,7 @@
#include "target-def.h"
#include "debug.h"
#include "langhooks.h"
+#include "sched-int.h"
/* Forward definitions of types. */
typedef struct minipool_nodeMnode;
@@ -118,6 +119,9 @@ static void thumb_output_function_prolog
static int arm_comp_type_attributes (tree, tree);
static void arm_set_default_type_attributes (tree);
static int arm_adjust_cost (rtx, rtx, rtx, int);
+static void arm_reorder (rtx *, int);
+static int arm_reorder1 (FILE *, int, rtx *, int *, int);
+static int arm_reorder2 (FILE *, int, rtx *, int *, int);
static int count_insns_for_constant (HOST_WIDE_INT, int);
static int arm_get_strip_length (int);
static bool arm_function_ok_for_sibcall (tree, tree);
@@ -245,6 +249,12 @@ static bool arm_tls_symbol_p (rtx x);
#undef TARGET_SCHED_ADJUST_COST
#define TARGET_SCHED_ADJUST_COST arm_adjust_cost
+#undef TARGET_SCHED_REORDER
+#define TARGET_SCHED_REORDER arm_reorder1
+
+#undef TARGET_SCHED_REORDER2
+#define TARGET_SCHED_REORDER2 arm_reorder2
+
#undef TARGET_ENCODE_SECTION_INFO
#ifdef ARM_PE
#define TARGET_ENCODE_SECTION_INFO arm_pe_encode_section_info
@@ -5229,6 +5239,68 @@ arm_adjust_cost (rtx insn, rtx link, rtx
return cost;
}
+/* Reorder insns in the ready list, so that instructions from the target block
+ will be scheduled ahead of instructions from the source blocks. */
+static void
+arm_reorder (rtx *ready, int n_ready)
+{
+ if (n_ready > 1)
+{
+ /* Find out what target block is.
+
+ !!! It is better to use TARGET_BB itself from the
+ haifa-sched.c: schedule_block (), but it is unavailable due to its
+ local scope. */
+ basic_block target_bb = BLOCK_FOR_INSN (current_sched_info->prev_head);
+
+ if (/* If insn, that will be scheduled next don't belong to
+ TARGET_BB.
+
+ !!! Actually, we want here another condition:
+ 'if (IS_SPECULATIVE_INSN (ready[n_ready - 1]))', but it is
+ unavailable due to local scope in sched-rgn.c . */
+ BLOCK_FOR_INSN (ready[n_ready - 1]) != target_bb)
+/* Search the ready list for the most prioritized insn from the
+ TARGET_BB, and, if found, move it to the head of the list. */
+{
+ int i;
+
+ for (i = n_ready - 1; i >= 0; i--)
+{
+ rtx insn = ready[i];
+
+ if (BLOCK_FOR_INSN (insn) != target_bb)
+continue;
+
+ memcpy (ready + i, ready + i + 1,
+ (n_ready - i - 1) * sizeof (*ready));
+ ready[n_ready - 1] = insn;
+ break;
+}
+}
+}
+}
+
+/* Override default sorting algorithm to reduce number of interblock
+ motions. */
+static int
+arm_reorder1 (FILE *dump ATTRIBUTE_UNUSED, int sched_verbose ATTRIBUTE_UNUSED,
+ rtx *ready, int *pn_ready, int clock_var ATTRIBUTE_UNUSED)
+{
+ arm_reorder (ready, *pn_ready);
+ return 1;
+}
+
+/* Override default sorting algorithm to reduce number of interblock
+ motions. */
+static int
+arm_reorder2 (FILE *dump ATTRIBUTE_UNUSED, int sched_verbose ATTRIBUTE_UNUSED,
+ rtx *ready, int *pn_ready, int clock_var ATTRIBUTE_UNUSED)
+{
+ arm_reorder (ready, *pn_ready);
+ return 0;
+}
+
static int fp_consts_inited = 0;
/* Only zero is valid for VFP. Other values are also valid for FPA. */
Re: Modifying ARM code generator for elimination of 8bit writes - need help
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote: > > (define_insn "*arm_movqi_insn" > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,Q") > > (match_operand:QI 1 "general_operand" "rI,K,m,+r"))] > > "TARGET_ARM > >&& ( register_operand (operands[0], QImode) > > > >|| register_operand (operands[1], QImode))" > > > > "@ > >mov%?\\t%0, %1 > >mvn%?\\t%0, #%B1 > >ldr%?b\\t%0, %1 > >swp%?b\\t%1, %1, [%M0]" > > [(set_attr "type" "*,*,load1,store1") > >(set_attr "predicable" "yes")] > > ) > > Changing "m" to "Q", narrowing the address modes > Changing "r" to "+r", (register is globbered) > and of course making the swpb call.. I think you will need to remove the '+' as already suggested and add (clobber (match_scratch:QI "=X,X,X,1")) to tell GCC that the register allocated to operand 1 is clobbered by the instruction for this particular alternative. You will also have to modify any code which expands this pattern accordingly. -- Rask Ingemann Lambertsen
Re: comparing DejaGNU results
On Jun 1, 2006, at 1:45 AM, Richard Earnshaw wrote:
The only problem I have with Mike's script is that it doesn't handle
runs with multiple multi-lib variants nicely.
Yeah, in the past, we drove the multilib pass from above as in
general we had to select different hardware for testing. I like the
idea.
Attached is a local hack that I have to address this
Let's see if anyone can spot any non-portabilities in it. I think it
is safe. If safe, I'd say let's add this, as it helps.
I do have a slight additional change:
--- cmp_logs.~2~2006-06-01 09:41:12.0 -0700
+++ cmp_logs2006-06-01 10:05:56.0 -0700
@@ -25,2 +25,2 @@
-sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$1" | awk '/^Running
target / {target = $3} {sub(/: /, "&"target": " ); print $0;}' >$tmp1
-sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$2" | awk '/^Running
target / {target = $3} {sub(/: /, "&"target": " ); print $0;}' >$tmp2
+sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$1" | awk '/^Running
target / {target = $3} { if (target != "unix") { sub(/: /,
"&"target": " ); }; print $0; }' >$tmp1
+sed 's/^XFAIL/FAIL/; s/^XPASS/PASS/' < "$2" | awk '/^Running
target / {target = $3} { if (target != "unix") { sub(/: /,
"&"target": " ); }; print $0; }' >$tmp2
This preserves the simplicity in the non-multilib case and keeps
future results comparable with older results.
Assembler clarification
I can't explain myself what is going on within this lines in the .debug_frame section. Context: AMD64 linux64 system. (Ubuntu) Within the debug_frame section I find the following assembly instructions: .byte0x4 .long.LCFI0-.LFB2 The distance between labels LCFI0 and LFB2 is exactly one byte. I would expect then, that the assembler generates 0x04 (byte 1) 0x01 (byte 2) i.e. TWO bytesw, one with 4 and the other with 1. but I find that the output is 0x41, i.e. the 4 in the highest NIBBLE of a byte and the 1 in the lower nibble. Why? Is this documented somehow? Is there a compressing pass in the debug_frame section thanks
4.1.1 build failures due to old makeinfo
Hi, My attempts to build 4.1.1 on Solaris 8 and HP-UX 11 fail in fastjar because it seems that the logic to deal with an out-of-date makeinfo is borked. We get WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. But this isn't just a warning; the build terminates. Also, fastjar.info and fastjar.1 are newer than fastjar.texi, and GNU Make version 3.79 was used, so the message is incorrect. I built a new-enough version of texinfo/makeinfo for both platforms and am trying again.
Intermixing powerpc-eabi and powerpc-linux C code
Hi! Does anyone happen to know if it is possible to link (and run) C code compiled with a powerpc-eabi targeted gcc with C code compiled with a powerpc-linux targeted gcc? The resulting program would be run on a PowerPC Linux system (ELDK 4.0). In this case, main() would be compiled by powerpc-linux-gcc while a test driver and all code to be tested would be compiled by powerpc-eabi-gcc. Everything would be linked using powerpc-linux-gcc. The call from Linux-land to eabi-land would not need to pass arguments nor return anything and nothing would need to be shared between the two pieces of code. None of the powerpc-eabi code will depend on any libraries or other external code, it will all be completely self-contained. Thanks! Ron McCall
Re: Expansion of __builtin_frame_address
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but allow targets to define another macro
that will cause the default code to use the soft frame pointer rather than
the hard frame pointer, and hence allow FP elimination. (If such a macro
were set by a particular target, am I right in thinking that it would be
safe to use the soft frame pointer even in the count >= 1 cases?)
I tend to think that option (iii) might be best, although perhaps it
is overkill and option (i) would do. But I'm not entirely sure;
still being a gcc novice I have to admit to not being quite thoroughly
clear on this myself at this stage. So any advice or comments would be
appreciated!
I agree that option (iii) is best, as it provides the ability to
optimize on platforms where that is feasible, and still provides a
working default elsewhere. I will review and approve a suitable patch
to implement (iii), assuming that there are no objections from Jim or
others.
This having been discussed some more, and my understanding improved,
I now believe that option (i) is in fact the correct thing to do. The
attach patch implements this, which basically amounts to the same logic
that is currently in the compiler save for the removal of the special
case when count == 0.
OK for mainline?
Mark
--
2006-06-01 Mark Shinwell <[EMAIL PROTECTED]>
* gcc/builtins.c (expand_builtin_return_addr): Always use
hard_frame_pointer_rtx and prevent frame pointer elimination
if INITIAL_FRAME_ADDRESS_RTX isn't set.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 114277)
+++ gcc/builtins.c (working copy)
@@ -496,20 +496,14 @@ expand_builtin_return_addr (enum built_i
#else
rtx tem;
- /* For a zero count, we don't care what frame address we return, so frame
- pointer elimination is OK, and using the soft frame pointer is OK.
- For a non-zero count, we require a stable offset from the current frame
- pointer to the previous one, so we must use the hard frame pointer, and
- we must disable frame pointer elimination. */
- if (count == 0)
-tem = frame_pointer_rtx;
- else
-{
- tem = hard_frame_pointer_rtx;
+ /* We require a stable offset from the current frame pointer to the
+ previous one, so we must use the hard frame pointer, and we must
+ disable frame pointer elimination. */
- /* Tell reload not to eliminate the frame pointer. */
- current_function_accesses_prior_frames = 1;
-}
+ tem = hard_frame_pointer_rtx;
+
+ /* Tell reload not to eliminate the frame pointer. */
+ current_function_accesses_prior_frames = 1;
#endif
/* Some machines need special handling before we can access
Re: mingw32 subtle build failure
On Thu, Jun 01, 2006 at 11:58:31AM +0530, Ranjit Mathew wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Christopher Faylor wrote: >> On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote: >>> And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS? >>> (grep is soo sloow on my win32 machine) >> >> For the record, I don't do Msys. Please don't cc me about msys problems. > >I think he CC-ed you on the message because you seem to be >the one who added the conditional code using USE_MINGW_MSYS >to libiberty/pex-win32.c: > > http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00557.html Fair enough. The USE_MINGW_MSYS conditional is for people who want to make an Msys aware version of the pex* functions. I included it because when I volunteered to work on these function, I thought that it was a requirement, so I reluctantly added features to deal with Msys. Then I was told that it wasn't necessary. So, rather than nuke my changes, I added a conditional. It's likely to have bit-rotted by now. Again, I request that you all not cc me on this thread any further. cgf
Difference between 'FOR_EACH_BB' and 'for (i=0; i
My understanding is that: both are used to traverse BBs and the only
(potential )difference is the order of the traversal. 'FOR_EACH_BB'
traverses BBs throught the linked list order; 'for (i=0; ii++){bb=BASIC_BLOCK(i);}' traverses accoring to the BB's index (because
BASIC_BLOCK(i)->index ==i)
(Please correct me if my understanding is wrong:) )
So, is there any particular reason to pick up on over the other? For
example, function 'compute_defs_uses_and_gen()' in bt-load.c uses the latter
one to traverse basic blocks, but most other routines use the first one to
traverse BBs.
Thanks,
_
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: Intermixing powerpc-eabi and powerpc-linux C code
> The call from Linux-land to eabi-land would not need > to pass arguments nor return anything and nothing > would need to be shared between the two pieces of > code. So basically you can replace the whole thing with sleep(1); and noone would be any the wiser. Paul
Re: Difference between 'FOR_EACH_BB' and 'for (i=0; i
sean yang wrote on 06/01/06 14:44: > 'for (i=0; i the > BB's index (because BASIC_BLOCK(i)->index ==i) > The first form may take you to a NULL basic block. See expunge_block.
Re: Difference between 'FOR_EACH_BB' and 'for (i=0; i
On 6/1/06, sean yang <[EMAIL PROTECTED]> wrote:
My understanding is that: both are used to traverse BBs and the only
(potential )difference is the order of the traversal. 'FOR_EACH_BB'
traverses BBs throught the linked list order; 'for (i=0; iindex ==i)
(Please correct me if my understanding is wrong:) )
So, is there any particular reason to pick up on over the other?
At least two reasons:
1) BASIC_BLOCK(i) may be NULL.
2) FOR_{EACH,ALL}_BB is preferred.
Gr.
Steven
Re: Intermixing powerpc-eabi and powerpc-linux C code
I guess I should have also mentioned that the resultant program will be run under gdb, with a script setting breakpoints, running, examining variables, etc. --- Paul Brook <[EMAIL PROTECTED]> wrote: > > The call from Linux-land to eabi-land would not > need > > to pass arguments nor return anything and nothing > > would need to be shared between the two pieces of > > code. > > So basically you can replace the whole thing with > sleep(1); and noone would be > any the wiser. > > Paul >
Re: Difference between 'FOR_EACH_BB' and 'for (i=0; i
Thanks. after reading expunge_block(), i am curious whether " 'for (i=0;
i'compute_defs_uses_and_gen()' uses it, it should work; from the other hand,
from the code of expunge_block, BASIC_BLOCK[n_basic_blocks-1] may not be the
last element in the BASIC_BLOCK array.
For example,
BASIC_BLOCK is like this, [b0, NULL, b1, NULL, b3 ]; aparently,
n_basic_blocks ==3.
Shouldn't those code with 'for (i=0; iMaybe it did not cause a problem because all these code get executed before
any basic_block cleanup.
Thanks,
Sean
-
expunge_block (basic_block b)
{
unlink_block (b);
BASIC_BLOCK (b->index) = NULL;
n_basic_blocks--;
/* We should be able to ggc_free here, but we are not.
The dead SSA_NAMES are left pointing to dead statements that are
pointing
to dead basic blocks making garbage collector to die.
We should be able to release all dead SSA_NAMES and at the same
time we should
clear out BB pointer of dead statements consistently. */
}
---
From: Diego Novillo <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: Difference between 'FOR_EACH_BB' and 'for (i=0;
i
Date: Thu, 01 Jun 2006 14:51:54 -0400
sean yang wrote on 06/01/06 14:44:
> 'for (i=0; iaccoring to the
> BB's index (because BASIC_BLOCK(i)->index ==i)
>
The first form may take you to a NULL basic block. See expunge_block.
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
Re: comparing DejaGNU results
> Please do. I'd welcome it (and scripts to generate html, to track > known issues, to trim log files, to drive things and do on)... I > think having a few different styles would be good, then people can > try them all out and see which ones they like and why. Anyway, for > me, it isn't yet better: : > I tried all the results and couldn't find any that your script could > analyze, except libgomp, but only because libgomp doesn't run on my > system, so there are no results in it? Is it just me? I hand edited > my results to be the first 30 or so from the Objective C++ testsuite, > and then I got it to analyze and not dump out. > > When I tried gcc, I had a chance to notice the timings, your version: > > real8m44.413s > user2m0.714s > sys 7m54.847s > > mine: > > real0m1.994s > user0m1.756s > sys 0m0.556s As I said I had only used it on Linux, I assume you're using Darwin. I tried it there and had to fix the following. You got the first two but not the last so my script was way non-functional. sed uses -E instead of -r (as you noted) sort uses -m but not --merge (as you noted) sed doesn't honour \t or \s > :-) Maybe you only run the script on toy results? Or, do you just > drink lots of coffee? Now, I know mine is well more than 10-100x > slower than it could be, but waiting 2 seconds isn't a hardship for > me. Waiting 8 minutes strikes me as just a little slow. I said it was slow :-)> On NetBSD your approach is at least 50x faster. Strangely, on FC3 the two have similar elapsed times: time ./compare_tests gcc-sim-20050503.sum gcc-sim-20060528.sum >compare2.lst real4m0.729s user4m5.880s sys 0m0.231s time ./dg-cmp-results.sh -v "" gcc-sim-20050503.sum gcc-sim-20060528.sum >dg-cmp2.lst real4m25.941s user1m29.850s sys 3m8.021s > The output of yours doesn't seem to be targeted for human eyes, the > verbosity (at the least verbose setting) is about 121x more than mine > for two random sets I had lying around, and that is with it cutting > the output off really early due to the above problem. I predict that > in normal day to day use, it is well better than 120,000x larger. > What use do you get out of it? It obviously wasn't working properly for you due to linux - netbsd differences. wc -l *2.lst 66 compare2.lst 63 dg-cmp2.lst Results from mine should have looked like: dg-cmp-results.sh: Verbosity is 1, Variant is "" Older log file: gcc-sim-20050503.sum Test Run By jim on Mon May 2 12:29:08 2005 Target is xscale-unknown-elf Host is i686-pc-linux-gnu Newer log file: gcc-sim-20060528.sum Test Run By jim on Mon May 29 12:55:01 2006 Target is xscale-unknown-elf Host is i686-pc-linux-gnu PASS->FAIL: gcc.c-torture/execute/920428-2.c compilation, -O1 PASS->FAIL: gcc.c-torture/execute/920428-2.c compilation, -O2 PASS->FAIL: gcc.c-torture/execute/920428-2.c compilation, -O3 -fomit-frame-pointer PASS->FAIL: gcc.c-torture/execute/920428-2.c compilation, -O3 -g PASS->FAIL: gcc.c-torture/execute/920428-2.c compilation, -Os PASS->UNRESOLVED: gcc.c-torture/execute/920428-2.c execution, -O1 PASS->UNRESOLVED: gcc.c-torture/execute/920428-2.c execution, -O2 : PASS->UNRESOLVED: gcc.c-torture/execute/nestfunc-6.c execution, -Os FAIL->PASS: gcc.dg/20030324-1.c execution test FAIL->PASS: gcc.dg/debug/dwarf2/dwarf-die7.c scan-assembler 1.*DW_AT_inline FAIL->PASS: gcc.dg/range-test-1.c execution test > Mine was designed to do two things, figure out if the results are > interesting and not send email, if they are not, and to show > engineers the `interesting' detailed results in priority order. It's > meant to be run daily, and on good days, it produces no output. On > normal days, output is 20-30 lines at most. It tries to balance the > complaints with the occasional atta boy, to help with moral. Mine is used at the end of full build & test runs so a few minutes didn't bother me. A look at output like that above tells me what I need. Your approach is faster, esp. on Darwin / NetBSD. The only advantages I see to mine is handling variants (Richard's patch fixes that), verbosity control, and detail -- compare_tests only looks at X?(PASS|X?FAIL). Jim. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Re: comparing DejaGNU results
Whoops... I forgot to attach my fixes, for anyone that's interested. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario --- dg-cmp-results.sh 2006/05/31 19:22:14 1.18 +++ dg-cmp-results.sh 2006/06/01 17:53:21 @@ -31,6 +31,16 @@ if test $# -ne 3 -o ! -f "$2" -o ! -f "$ exit 1 fi +# Command differences for various platforms. +case `uname -s` in +Darwin|NetBSD) +E=-E # sed +;; +*) +E=-r # sed +;; +esac + # sections are identified by separator lines beginning with '\t\t==='. # section 0 identifies run date, target, and host. # section 1 and subsequent contain test data for a target variant. @@ -62,15 +72,15 @@ unset temp # Copy out the old file's section 0. echo "Older log file: $OFILE" -sed -r -e '/^\t+===/,$d' $OFILE +sed $E -e '/^[[:space:]]+===/,$d' $OFILE # Copy out the new file's section 0. echo "Newer log file: $NFILE" -sed -r -e '/^\t+===/,$d' $NFILE +sed $E -e '/^[[:space:]]+===/,$d' $NFILE # Create a temporary file from the old file's interesting section. -sed -r -e "1,/$header/d" \ - -e '/^\t+===/,$d' \ +sed $E -e "1,/$header/d" \ + -e '/^[[:space:]]+===/,$d' \ -e '/^[A-Z]+:/!d' \ -e 's/\r$//' \ -e 's/^/O:/' \ @@ -79,8 +89,8 @@ sed -r -e "1,/$header/d" \ >/tmp/o$$-$OBASE # Create a temporary file from the new file's interesting section. -sed -r -e "1,/$header/d" \ - -e '/^\t+===/,$d' \ +sed $E -e "1,/$header/d" \ + -e '/^[[:space:]]+===/,$d' \ -e '/^[A-Z]+:/!d' \ -e 's/\r$//' \ -e 's/^/N:/' \ @@ -94,9 +104,9 @@ sed -r -e "1,/$header/d" \ # If so, we assume that the order is the same in both files. IFS=: firstread=Y -sort --merge -s -t : -k 3b /tmp/o$$-$OBASE /tmp/n$$-$NBASE | +sort -m -s -t : -k 3b /tmp/o$$-$OBASE /tmp/n$$-$NBASE | while read -r lineon linestatus linename; do -linename=`echo "$linename" |sed -r -e 's/^ *(.*) *$/\1/'` +linename=`echo "$linename" |sed $E -e 's/^ *(.*) *$/\1/'` if test $verbose -ge 4; then case "$linestatus" in @@ -231,15 +241,15 @@ while read -r lineon linestatus linename else ##echo "$lines" |read -r prevon prevstatus prevname line=`echo "$lines" |head -n 1` - prevon=`echo "$line" |sed -r -e 's/\s*(.):([A-Z]+):(.*)$/\1/'` - prevstatus=`echo "$line" |sed -r -e 's/\s*(.):([A-Z]+):(.*)$/\2/'` - prevname=`echo "$line" |sed -r -e 's/\s*(.):([A-Z]+):(.*)$/\3/'` + prevon=`echo "$line" |sed $E -e 's/ *(.):([A-Z]+):(.*)$/\1/'` + prevstatus=`echo "$line" |sed $E -e 's/ *(.):([A-Z]+):(.*)$/\2/'` + prevname=`echo "$line" |sed $E -e 's/ *(.):([A-Z]+):(.*)$/\3/'` if test $verbose -ge 4; then echo " debug: pulled a line from the stack" fi #lines=`echo "$lines" |tail -n $numlines` - lines=`echo "$lines" |sed -e 1d` + lines=`echo "$lines" |sed $E -e 1d` fi ;; *)
Re: Difference between 'FOR_EACH_BB' and 'for (i=0; i
sean yang wrote on 06/01/06 15:28: > Thanks. after reading expunge_block(), i am curious whether " 'for (i=0; > i That was my point: it doesn't, unless you can guarantee that the CFG has been compacted.
Re: comparing DejaGNU results
> Your approach is faster, esp. on Darwin / NetBSD. > The only advantages I see to mine is handling variants (Richard's patch > fixes that), verbosity control, and detail -- compare_tests only looks > at X?(PASS|FAIL). Hmm.. another small point, FWIW. Both the results files I used contained the following ssequence of results: PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) compare_tests reported the following: Tests that now fail, but worked before: gcc.c-torture/compile/930210-1.c (test for excess errors) gcc.c-torture/compile/930210-1.c (test for excess errors) gcc.c-torture/compile/930210-1.c (test for excess errors) : Tests that now work, but didn't before: gcc.c-torture/compile/930210-1.c (test for excess errors) gcc.c-torture/compile/930210-1.c (test for excess errors) gcc.c-torture/compile/930210-1.c (test for excess errors) dg-cmp-results didn't report anything (at that verbosity) because nothing had changed. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Re: comparing DejaGNU results
On Thu, 1 Jun 2006, James Lemke wrote: > Both the results files I used contained the following ssequence of > results: > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) This probably means you are using too old a version of DejaGnu; make sure you are using at least 1.4.4, the minimum supported version. There are still problems with duplicate test assertion names (e.g. bug 20771), but there shouldn't be in c-torture if you use current DejaGnu. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: comparing DejaGNU results
> > Both the results files I used contained the following ssequence of > > results: > > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > > PASS: gcc.c-torture/compile/930210-1.c (test for excess errors) > > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > > FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors) > > This probably means you are using too old a version of DejaGnu; make sure > you are using at least 1.4.4, the minimum supported version. There are > still problems with duplicate test assertion names (e.g. bug 20771), but > there shouldn't be in c-torture if you use current DejaGnu. Thanks. Regardless, dg-cmp-results handles that situation, albeit slowly ; - )> -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Re: [wwwdocs] releases.html v/s develop.html
On Sun, 14 May 2006, Ranjit Mathew wrote: > Dave Yost points out that a cursory look at the main table > in: > > http://gcc.gnu.org/releases.html > > (which is linked-to from the main page) gives the impression > that 3.4.6 has been our last release. It is very easy to > miss the fine-print-like statement above the table that > refers the reader to develop.html for the 4.x series and > beyond. > > I agree with him and propose that we either retire releases.html > or include information about the 4.x series in that table too. In the eyes of at least some, especially the dates for the old releases in releases.html are of historical interest, so I'd be quite hesitant to remove these. I'm not sure I agree that it is easy to miss the statement on releases past 4.0.0 on that page, but empircal evidence seems to prove me wrong. As for background, one of the reasons to stop doing this table for 4.0.0 and beyond is to reduce the work of our release managers and avoid potential for inconsistency. Neither of this is really that strong a point (perhaps a minute of work, and little risk of inconsitency when done as part of the release process). Mind to send/commit a patch to complete releases.html with 4.x releases and add a step to releasing.html? (Basically you just need to revert revision 1.26 of that file.) > Note that releases.html claims 3.4.6 is the latest in the > 3.4 series but the main page says 3.4.5 is the last one (but > then the very next line contradicts this line!). This we got addressed finally. (Sorry for the late response, I am finally removing all backlog.) > in fact, why don't we just remove the "Previous release series" > bit for the 3.4 series? It looks a bit odd to have two "Previous > release series" on that page. The 3.4 series is extremely popular among users and operating system distributors and has been active until very recently, so I think we should keep it for some further time. When we are going to release 4.2.0, it's time to go, though. (At that point in time, I predict the 4.1 series to become a more than worthwhile successor as far as usage and quality go.) Gerald
Re: [wwwdocs] releases.html v/s develop.html
On Thu, Jun 01, 2006 at 11:43:09PM +0200, Gerald Pfeifer wrote: > In the eyes of at least some, especially the dates for the old > releases in releases.html are of historical interest, so I'd be > quite hesitant to remove these. > > I'm not sure I agree that it is easy to miss the statement on > releases past 4.0.0 on that page, but empircal evidence seems > to prove me wrong. Let's just add the info to the table. Here is a proposed patch. Note that I resorted by date and added an explanation. I think that the attempt to sort by release number became increasingly untenable after 3.4, because we now have heavy overlapping. Better to just state it and explain it. Index: releases.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v retrieving revision 1.67 diff -u -r1.67 releases.html --- releases.html 10 Mar 2006 12:42:46 - 1.67 +++ releases.html 1 Jun 2006 22:20:40 - @@ -26,21 +26,31 @@ GCC Timeline +The table is sorted by date; starting with version 3.3.4, the GCC +project provides bug releases for older release branches for those users +who require a very high degree of stability. + Please refer to our development plan -for releases past 4.0.0 and future releases. +for future releases, and an alternative view of the release history. ReleaseRelease date +GCC 4.1.1 May 24, 2006 +GCC 4.0.3 March 10, 2006 GCC 3.4.6 March 06, 2006 +GCC 4.1.0 February 28, 2006 GCC 3.4.5 November 30, 2005 +GCC 4.0.2 September 28, 2005 +GCC 4.0.1 July 7, 2005 GCC 3.4.4 May 18, 2005 +GCC 3.3.6 May 3, 2005 +GCC 4.0.0 April 20, 2005 GCC 3.4.3 November 4, 2004 +GCC 3.3.5 September 30, 2004 GCC 3.4.2 September 6, 2004 GCC 3.4.1 July 1, 2004 -GCC 3.4.0 April 18, 2004 -GCC 3.3.6 May 3, 2005 -GCC 3.3.5 September 30, 2004 GCC 3.3.4 May 31, 2004 +GCC 3.4.0 April 18, 2004 GCC 3.3.3 February 14, 2004 GCC 3.3.2 October 17, 2003 GCC 3.3.1 August 8, 2003
gcc-4.0-20060601 is now available
Snapshot gcc-4.0-20060601 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060601/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 114318 You'll find: gcc-4.0-20060601.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060601.tar.bz2 C front end and core compiler gcc-ada-4.0-20060601.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060601.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060601.tar.bz2 C++ front end and runtime gcc-java-4.0-20060601.tar.bz2 Java front end and runtime gcc-objc-4.0-20060601.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060601.tar.bz2The GCC testsuite Diffs from 4.0-20060525 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: Intermixing powerpc-eabi and powerpc-linux C code
On Jun 1, 2006, at 11:32 AM, Ron McCall wrote: Does anyone happen to know if it is possible to link (and run) C code compiled with a powerpc-eabi targeted gcc with C code compiled with a powerpc-linux targeted gcc? This is a linker question, we don't do linkers here. In particular, the relocs have to be compatible, if you want to do reloc processing. You can use ld and resolve all the relocs and just slam in the bytes, but then, you're not using gcc to link per se. Why not just try it out and see?
Re: Expansion of __builtin_frame_address
Mark Shinwell wrote: Option (i), which is in all but name the "solution 5" approach [1] proposed last year, means that the "count == 0" case is elevated to the same level of importance as the "count > 0" cases, in line with the use in backtrace (). The problem with this is that on platforms where the soft and hard FPs coincide there is going to be a slight performance degradation, as identified previously, whenever these builtins are used. I don't have a problem with the proposed patch that implements this. I didn't choose this option earlier because I didn't have a testcase that required it. You have now supplied one (glibc backtrace), so I think it is now reasonable to go forward with this. The workaround for the performance problem is for backend maintainers to add an appropriate definition for the INITIAL_FRAME_ADDRESS_RTX macro. Perhaps forcing the issue will provide some incentive to people to fix their backends. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: c++ regression in trunk
Geoff, When building xplor with -shared-libgcc -whyload, I don't see any explicit symbols being loaded from libgcc_s. However from libxplorCmd.dylib, which has code called from xplor, I see... /usr/lib/libgcc_s.1.dylib(unwind-dw2_s.o) loaded to resolve symbol: __Unwind_Resume /usr/lib/libgcc_s.1.dylib(darwin-fallback_s.o) loaded to resolve private symbol: __Unwind_fallback_frame_state_for /usr/lib/libgcc_s.1.dylib(dylib1.o) loaded to resolve private symbol: dyld_stub_binding_helper /usr/lib/libgcc_s.1.dylib(link editor) loaded to resolve private symbol: __mh_dylib_header /usr/lib/libgcc_s.1.dylib(darwin-fpsave_s.o) loaded to resolve private symbol: restFP /usr/lib/libgcc_s.1.dylib(unwind-dw2-fde-darwin_s.o) loaded to resolve symbol: __Unwind_Find_FDE Finally from libintVar.dylib, which has code called from libxplorCmd.dylib, I see... /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.2.0/../../../libgcc_s.10.4.dylib(single module) loaded to resolve symbol: __Unwind_Resume Let me know if you need anything else to pin this problem down. Jack
Re: Segment registers support for i386
Remy Saissy wrote: I've looked for a target specific callback to modify but I've found nothing, even in the gcc internals info pages. Do you mean I would have to modify some code outside of the i386 directory ? Or maybe to add such a callback if it doesn't exist ;) You'ld have to modify code in the main GCC directory, probably a lot of code. Since it's target dependent, you'ld need to implement it using a hook or hooks. In which file does the tree to RTL conversion code is located ? There are several files that do this jobs. See the internals documentation. Does it mean that an RTL expression which use reg: force gcc to use a particular pseudo register ? Pseudo registers aren't real registers. They either get changed to real hard registers, or memory references to stack slots. See the internals documentation for more details. Ross Ridge Ok, Thanks a lot for your help, I'm going to see what I can do and if I don't give up now ;) Have a great day. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
Libiberty
I haven't found anything in the docs that I see that explains the libiberty library. Can this be compiled without having to compile a whole new compiler? I am running 3.4.6 and what to cross compile for a pdp-11. I just want to compile the extra support and that's all. Bill
Re: Libiberty
> I haven't found anything in the docs that I see that explains > the libiberty library. You didn't find the libiberty documentation? It's separate from the gcc documentation, but available on the gcc docs web page. > Can this be compiled without having to compile a whole new compiler? Er, yes, since that's what we do each time we build it for the build and host machines. Only the target libiberty is built with the just-built compiler. > I am running 3.4.6 and what to cross compile for a pdp-11. I just > want to compile the extra support and that's all. Extra support for what purpose? Are you trying to use libiberty with your own application?
Re: Libiberty
- Original Message - From: "DJ Delorie" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 01, 2006 10:31 PM Subject: Re: Libiberty > > Please don't reply to me personally, use the mailing list. Sorry I just pressed reply. You personal address must have been there. Bill
Re: Modifying ARM code generator for elimination of 8bit writes - need help
Rask, On Thursday 01 June 2006 16:13, Rask Ingemann Lambertsen wrote: > I think you will need to remove the '+' as already suggested and add > (clobber (match_scratch:QI "=X,X,X,1")) to tell GCC that the register > allocated to operand 1 is clobbered by the instruction for this > particular alternative. Using (define_insn "*arm_movqi_insn" [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m") (match_operand:QI 1 "general_operand" "rI,K,m,r")) (clobber (match_scratch:QI 2 "=X,X,X,1"))] "TARGET_ARM && ( register_operand (operands[0], QImode) || register_operand (operands[1], QImode))" "@ mov%?\\t%0, %1 mvn%?\\t%0, #%B1 ldr%?b\\t%0, %1 str%?b\\t%1, %0" [(set_attr "type" "*,*,load1,store1") (set_attr "predicable" "yes")] ) (_only_ adding the clobber statement), I get > /data1/home/wolfgang/Projekte/DSO/devkitpro/buildscripts/newlib-1.14. >0/newlib/li bc/argz/argz_create_sep.c: In function 'argz_create_sep': > /data1/home/wolfgang/Projekte/DSO/devkitpro/buildscripts/newlib-1.14. >0/newlib/li bc/argz/argz_create_sep.c:60: error: unrecognizable insn: > (insn 192 21 24 0 > /data1/home/wolfgang/Projekte/DSO/devkitpro/buildscripts/newli > b-1.14.0/newlib/libc/argz/argz_create_sep.c:29 (set (reg:QI 1 r1) > (reg:QI 4 r4)) -1 (nil) > (nil)) > /data1/home/wolfgang/Projekte/DSO/devkitpro/buildscripts/newlib-1.14. >0/newlib/li bc/argz/argz_create_sep.c:60: internal compiler error: in > extract_insn, at recog .c:2020 What do you mean with > You will also have to modify any code which > expands this pattern accordingly. I will use this weekend to digg deeper into the documentation... thank you for your help so far... Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
