Re: Address as HImode when Pmode is QImode?

[Markus L]

Hi Adam,

Looks like you were right! My SIZE_TYPE was undefined so it defaulted
to "long unsigned int". Setting it to "unsigned int" solved my
problems.

Thank you very much!
/Markus


2009/8/13 Adam Nemet :
> Markus L  writes:
>> I run into an assert in convert_memory_address not beeing able to
>> convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
>> few frames up the I can dump the tree node and it looks like the
>> address calculations are done in HImode. Why is the address beeing
>> calculated as unsigned long int and not as unsigned int which would be
>> Pmode for my target? Is this expected (and my problem originates from
>> elsewhere) or am I missing something obvious here?
>
> What's your sizetype?  This could be related to:
>
> http://gcc.gnu.org/ml/gcc/2008-05/msg00313.html
>
> Adam
>

Trace crash in gargabe collector to the code at fault?

[okellogg]

Working on the GNAT multi-source compile feature

(see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),

I am running into crashes in ggc_collect() on compiling

the 2nd file in the compile job.



Following the advice given in
http://gcc.gnu.org/ml/gcc/2004-04/msg00901.html ,
I configured GCC with --enable-gcac.

As a result, the crash no longer happens in ggc-page.c
function
lookup_page_table_entry (at the line "return
base[L1][L2];") but
instead happens in validate_free_objects, at the line

 /* Make certain it isn't visible from any root. Notice
that we
 do this check before sweep_pages merges save_in_use_p. */
 gcc_assert (!(pe->in_use_p[word] & (1UL << bit)));

The backtrace using trunk 20090807 is:
#7 0x0852f5bf in fancy_abort (file=0x8c734ca
"../../gcc/gcc/ggc-page.c["00"]", line=1888, 
 function=0x8c7354f "validate_free_objects["00"]") at
../../gcc/gcc/diagnostic.c:730
#8 0x084c5d5b in validate_free_objects () at
../../gcc/gcc/ggc-page.c:1888
#9 0x084c5ec7 in ggc_collect () at
../../gcc/gcc/ggc-page.c:1949
#10 0x088eb317 in cgraph_finalize_function
(decl=0xb6824e00, nested=0 '["00"]') at
../../gcc/gcc/cgraphunit.c:550
#11 0x087403fe in finalize_size_functions () at
../../gcc/gcc/stor-layoutc:366
#12 0x088ec3c5 in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1034
#13 0x08167a73 in gnat_write_global_declarations () at
../../gcc/gcc/ada/gcc-interface/utils.c:4671
#14 0x0874a198 in compile_file () at
../../gcc/gcc/toplev.c:1044
#15 0x0874bfd4 in do_compile () at
../../gcc/gcc/toplev.c:2387
#16 0x0874c0f0 in toplev_main (argc=25, argv=0xbfe6faa4) at
../../gcc/gcc/toplev.c:2445
#17 0x084c460a in main (argc=148423232, argv=0x8c105b0) at
../../gcc/gcc/main.c:35

I am stuck here, i.e. I don't know how to find the code
that is
at fault.
Is there some way to trace a pointer entered in
G.free_object_list
back to its origin in the code?

Thanks,

Oliver






Heute schon ge"freeMail"t?
Jetzt kostenlose E-Mail-Adresse sichern!
http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6831

Re: Trace crash in gargabe collector to the code at fault?

[Andrew Haley]

okell...@freenet.de wrote:
> Working on the GNAT multi-source compile feature
> 
> (see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),
> 
> I am running into crashes in ggc_collect() on compiling
> 
> the 2nd file in the compile job.
> 
> 
> 
> Following the advice given in
> http://gcc.gnu.org/ml/gcc/2004-04/msg00901.html ,
> I configured GCC with --enable-gcac.
> 
> As a result, the crash no longer happens in ggc-page.c
> function
> lookup_page_table_entry (at the line "return
> base[L1][L2];") but
> instead happens in validate_free_objects, at the line
> 
>  /* Make certain it isn't visible from any root. Notice
> that we
>  do this check before sweep_pages merges save_in_use_p. */
>  gcc_assert (!(pe->in_use_p[word] & (1UL << bit)));
> 
> The backtrace using trunk 20090807 is:
> #7 0x0852f5bf in fancy_abort (file=0x8c734ca
> "../../gcc/gcc/ggc-page.c["00"]", line=1888, 
>  function=0x8c7354f "validate_free_objects["00"]") at
> ../../gcc/gcc/diagnostic.c:730
> #8 0x084c5d5b in validate_free_objects () at
> ../../gcc/gcc/ggc-page.c:1888
> #9 0x084c5ec7 in ggc_collect () at
> ../../gcc/gcc/ggc-page.c:1949
> #10 0x088eb317 in cgraph_finalize_function
> (decl=0xb6824e00, nested=0 '["00"]') at
> ../../gcc/gcc/cgraphunit.c:550
> #11 0x087403fe in finalize_size_functions () at
> ../../gcc/gcc/stor-layoutc:366
> #12 0x088ec3c5 in cgraph_finalize_compilation_unit () at
> ../../gcc/gcc/cgraphunit.c:1034
> #13 0x08167a73 in gnat_write_global_declarations () at
> ../../gcc/gcc/ada/gcc-interface/utils.c:4671
> #14 0x0874a198 in compile_file () at
> ../../gcc/gcc/toplev.c:1044
> #15 0x0874bfd4 in do_compile () at
> ../../gcc/gcc/toplev.c:2387
> #16 0x0874c0f0 in toplev_main (argc=25, argv=0xbfe6faa4) at
> ../../gcc/gcc/toplev.c:2445
> #17 0x084c460a in main (argc=148423232, argv=0x8c105b0) at
> ../../gcc/gcc/main.c:35
> 
> I am stuck here, i.e. I don't know how to find the code
> that is
> at fault.
> Is there some way to trace a pointer entered in
> G.free_object_list
> back to its origin in the code?

The usual way to find this is to use a gdb watchpoint.  Find what object is
being freed, put a breakpoing on ggc_alloc_stat at the point the object is
created, and then put a watchpoint on the word that is being corrupted.

Andrew.

Re: Help on loop peeling

[Eric Fisher]

2009/8/13 Sebastian Pop :

> Could you please send the patch you are working on, together with
> a reduced testcase?  This could help to reproduce the error.

Thanks.

I put the patch and a test below. The patch is based on 4.4.0. It's
just a toy, I haven't a nice design for now.

Actually, first_niters shouldn't be calculated in this way.

--- gcc-4.4.0/gcc/tree-ssa-loop-manip.c 2009-02-20 23:20:38.0 +0800
+++ new-gcc-4.4.0/gcc/tree-ssa-loop-manip.c 2009-08-14 11:28:44.0 
+0800
@@ -1089,3 +1089,41 @@ tree_unroll_loop (struct loop *loop, uns
   tree_transform_and_unroll_loop (loop, factor, exit, desc,
  NULL, NULL);
 }
+
+/* Peel off the first or last few iterations of the loop. */
+
+struct loop *
+tree_peel_loop (struct loop *loop, unsigned num,
+edge e, struct tree_niter_desc *desc)
+{
+  struct loop *new_loop, *first_loop, *second_loop;
+  tree first_niters;
+  edge exit_e = single_exit (loop);
+
+  if (!slpeel_can_duplicate_loop_p (loop, e))
+return NULL;
+
+  new_loop = slpeel_tree_duplicate_loop_to_edge_cfg (loop, e);
+
+  if (e == exit_e)
+{
+  /* NEW_LOOP was placed after LOOP.  */
+  first_loop = loop;
+  second_loop = new_loop;
+}
+  else
+{
+  /* NEW_LOOP was placed before LOOP.  */
+  first_loop = new_loop;
+  second_loop = loop;
+}
+
+  slpeel_update_phis_for_duplicate_loop (loop, new_loop, e == exit_e);
+  rename_variables_in_loop (new_loop);
+
+  first_niters = build_int_cst (integer_type_node, num);
+
+  slpeel_make_loop_iterate_ntimes (first_loop, first_niters);
+
+  return new_loop;
+}
--- gcc-4.4.0/gcc/tree-ssa-loop-prefetch.c  2009-03-05 01:50:20.0 
+0800
+++ new-gcc-4.4.0/gcc/tree-ssa-loop-prefetch.c  2009-08-14
11:25:53.0 +0800
@@ -1459,7 +1459,7 @@ loop_prefetch_arrays (struct loop *loop)
   unsigned ahead, ninsns, time, unroll_factor;
   HOST_WIDE_INT est_niter;
   struct tree_niter_desc desc;
-  bool unrolled = false, no_other_refs;
+  bool unrolled_or_peeled = false, no_other_refs;

   if (optimize_loop_nest_for_size_p (loop))
 {
@@ -1511,13 +1511,20 @@ loop_prefetch_arrays (struct loop *loop)
   if (!schedule_prefetches (refs, unroll_factor, ahead))
 goto fail;

-  /* Step 5: unroll the loop.  TODO -- peeling of first and last few
+  /* step 5: peel off the last few iterations. */
+  if (ahead > 0)
+{
+  if (tree_peel_loop (loop, ahead, single_exit (loop), &desc) != NULL)
+unrolled_or_peeled = true;
+}
+
+  /* Step 6: unroll the loop.  TODO -- peeling of first and last few
  iterations so that we do not issue superfluous prefetches.  */
   if (unroll_factor != 1)
 {
   tree_unroll_loop (loop, unroll_factor,
single_dom_exit (loop), &desc);
-  unrolled = true;
+  unrolled_or_peeled = true;
 }

   /* Step 6: issue the prefetches.  */
@@ -1525,7 +1532,7 @@ loop_prefetch_arrays (struct loop *loop)

 fail:
   release_mem_refs (refs);
-  return unrolled;
+  return unrolled_or_peeled;
 }

 /* Issue prefetch instructions for array references in loops.  */
--- gcc-4.4.0/gcc/tree-vectorizer.c 2009-03-18 23:29:28.0 +0800
+++ new-gcc-4.4.0/gcc/tree-vectorizer.c 2009-08-14 11:26:29.0 +0800
@@ -253,7 +253,7 @@ rename_variables_in_loop (struct loop *l
AFTER is true if NEW_LOOP executes after ORIG_LOOP, and false if it
executes before it.  */

-static void
+void
 slpeel_update_phis_for_duplicate_loop (struct loop *orig_loop,
   struct loop *new_loop, bool after)
 {

--

#include 

extern int length;
extern unsigned short calc_crc (unsigned short data, unsigned short crc);

unsigned short
test (void)
{
  int i;
  unsigned short crc = 0;
  char *image;

  image = (char *)malloc (length);

  for (i = 0; i < length; i++)
{
  crc = calc_crc (image[i], crc);
}
  return crc;
}



But, for this test case, it's an another error.

Program received signal SIGSEGV, Segmentation fault.
0x0840a46d in gimple_bb (g=0x0) at ../../gcc-4.4.0/gcc/gimple.h:1070
1070  return g->gsbase.bb;
(gdb) bt
#0  0x0840a46d in gimple_bb (g=0x0) at ../../gcc-4.4.0/gcc/gimple.h:1070
#1  0x0840b446 in find_uses_to_rename_use (bb=0xb7c5e3c0,
use=0xb7c5a000, use_blocks=0x89befd8, need_phis=0x89b2778)
at ../../gcc-4.4.0/gcc/tree-ssa-loop-manip.c:246
#2  0x0840b60d in find_uses_to_rename_bb (bb=0xb7c5e3c0,
use_blocks=0x89befd8, need_phis=0x89b2778)
at ../../gcc-4.4.0/gcc/tree-ssa-loop-manip.c:297
#3  0x0840b7c1 in find_uses_to_rename (changed_bbs=0x0,
use_blocks=0x89befd8, need_phis=0x89b2778)
at ../../gcc-4.4.0/gcc/tree-ssa-loop-manip.c:327
#4  0x0840b879 in rewrite_into_loop_closed_ssa (changed_bbs=0x0,
update_flag=2048)
at ../../gcc-4.4.0/gcc/tree-ssa-loop-manip.c:387
#5  0x084983f8 in execute_vrp () at ../../gcc-4.4.0/gcc/tree-vrp.c:7249
#6  0x0828d69c in execute_one_pas

(int *const) function parameter

[Marc Mason]

Hello,

The following code is rejected by one compiler, while it is accepted by gcc
without any warning. Several people in comp.lang.c seem to think that it is a
bug in the first compiler which should ***not*** reject the program.

Message-ID: 
http://groups.google.com/group/comp.lang.c/browse_frm/thread/2858a1c9ccdcd741

I'd like to ask what you think.

typedef int fun_t(int *p);

int foo1(  int *  p) { return *p; }
int foo2(const int *  p) { return *p; }
int foo3(  int *const p) { return *p; }
int foo4(const int *const p) { return *p; }

void zozo(void)
{
  fun_t *fp;
  fp = foo1;
  fp = foo2; /* GCC WARNS */
  fp = foo3;
  fp = foo4; /* GCC WARNS */
}

(I run gcc 4.3.2 under cygwin.)

$ gcc -std=c89 -pedantic -Wall -Wextra -O2 -c mu2.c
mu2.c: In function 'zozo':
mu2.c:12: warning: assignment from incompatible pointer type
mu2.c:14: warning: assignment from incompatible pointer type

$ cc -c mu2.c
E "mu2.c",L12/C8(#416): foo2
|Type `int(const int * p)' ("mu2.c",L4/C5) can't be converted to type
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
E "mu2.c",L13/C8(#416): foo3
|Type `int(int *const p)' ("mu2.c",L5/C5) can't be converted to type 
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
E "mu2.c",L14/C8(#416): foo4
|Type `int(const int *const p)' ("mu2.c",L6/C5) can't be converted to type
`fun_t(*)'.
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).
3 user errors   No warnings

The relevant line is line 13 i.e. fp = foo3;
(cc's warnings are cosmetically different if I write fp = &foo3;)

E "mu2.c",L13/C8(#416):
|Type `int(*)(int *const p)' can't be converted to type `fun_t(*)'.
|(See also type `int(int *const p)' ("mu2.c",L5/C5)).
|(See also type `fun_t' (= `int(int * p)') ("mu2.c",L1/C13)).

In short, cc refuses to convert
an "int (*)(int *const)" pointer to an "int (*)(int *)" pointer.

Would you say this is a bug in cc?

-- 
Regards.

Re: (int *const) function parameter

[Joseph S. Myers]

On Fri, 14 Aug 2009, Marc Mason wrote:

> Hello,
> 
> The following code is rejected by one compiler, while it is accepted by gcc
> without any warning. Several people in comp.lang.c seem to think that it is a
> bug in the first compiler which should ***not*** reject the program.
> 
> Message-ID: 
> http://groups.google.com/group/comp.lang.c/browse_frm/thread/2858a1c9ccdcd741
> 
> I'd like to ask what you think.

Bugs in other compilers are offtopic for this list.  The relevant wording 
from 6.7.5.3#15 has already been quoted in that discussion.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Help on loop peeling

[Sebastian Pop]

Hi,

> Seems that use info is not updated.
>

You should put a TODO_update_ssa in the flags of prefetching pass.
With the attached patch I don't see an error.

Also, why don't you use trunk for your developments?

Sebastian
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index 1d2e69a..1320b5a 100644
--- a/gcc/tree-flow.h
+++ b/gcc/tree-flow.h
@@ -782,6 +782,7 @@ bool gimple_duplicate_loop_to_header_edge (struct loop *, edge,
 	 edge, VEC (edge, heap) **,
 	 int);
 struct loop *slpeel_tree_duplicate_loop_to_edge_cfg (struct loop *, edge);
+void slpeel_update_phis_for_duplicate_loop (struct loop *, struct loop *, bool);
 void rename_variables_in_loop (struct loop *);
 void rename_variables_in_bb (basic_block bb);
 struct loop *tree_ssa_loop_version (struct loop *, tree,
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index e43c0bc..2f536df 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -1104,6 +1104,44 @@ tree_unroll_loop (struct loop *loop, unsigned factor,
   NULL, NULL);
 }
 
+/* Peel off the first or last few iterations of the loop. */
+
+struct loop *
+tree_peel_loop (struct loop *loop, unsigned num,
+edge e, struct tree_niter_desc *desc)
+{
+  struct loop *new_loop, *first_loop, *second_loop;
+  tree first_niters;
+  edge exit_e = single_exit (loop);
+
+  if (!slpeel_can_duplicate_loop_p (loop, e))
+return NULL;
+
+  new_loop = slpeel_tree_duplicate_loop_to_edge_cfg (loop, e);
+
+  if (e == exit_e)
+{
+  /* NEW_LOOP was placed after LOOP.  */
+  first_loop = loop;
+  second_loop = new_loop;
+}
+  else
+{
+  /* NEW_LOOP was placed before LOOP.  */
+  first_loop = new_loop;
+  second_loop = loop;
+}
+
+  slpeel_update_phis_for_duplicate_loop (loop, new_loop, e == exit_e);
+  rename_variables_in_loop (new_loop);
+
+  first_niters = build_int_cst (integer_type_node, num);
+
+  slpeel_make_loop_iterate_ntimes (first_loop, first_niters);
+
+  return new_loop;
+}
+
 /* Rewrite the phi node at position PSI in function of the main
induction variable MAIN_IV and insert the generated code at GSI.  */
 
diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index b479707..36f2402 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -1548,7 +1548,7 @@ loop_prefetch_arrays (struct loop *loop)
   unsigned ahead, ninsns, time, unroll_factor;
   HOST_WIDE_INT est_niter;
   struct tree_niter_desc desc;
-  bool unrolled = false, no_other_refs;
+  bool unrolled_or_peeled = false, no_other_refs;
   unsigned prefetch_count;
   unsigned mem_ref_count;
 
@@ -1599,13 +1599,20 @@ loop_prefetch_arrays (struct loop *loop)
   if (!schedule_prefetches (refs, unroll_factor, ahead))
 goto fail;
 
-  /* Step 5: unroll the loop.  TODO -- peeling of first and last few
+  /* step 5: peel off the last few iterations. */
+  if (ahead > 0)
+{
+  if (tree_peel_loop (loop, ahead, single_exit (loop), &desc) != NULL)
+unrolled_or_peeled = true;
+}
+
+  /* Step 6: unroll the loop.  TODO -- peeling of first and last few
  iterations so that we do not issue superfluous prefetches.  */
   if (unroll_factor != 1)
 {
   tree_unroll_loop (loop, unroll_factor,
 			single_dom_exit (loop), &desc);
-  unrolled = true;
+  unrolled_or_peeled = true;
 }
 
   /* Step 6: issue the prefetches.  */
@@ -1613,7 +1620,7 @@ loop_prefetch_arrays (struct loop *loop)
 
 fail:
   release_mem_refs (refs);
-  return unrolled;
+  return unrolled_or_peeled;
 }
 
 /* Issue prefetch instructions for array references in loops.  */
diff --git a/gcc/tree-ssa-loop.c b/gcc/tree-ssa-loop.c
index 8f7047f..6adbb7b 100644
--- a/gcc/tree-ssa-loop.c
+++ b/gcc/tree-ssa-loop.c
@@ -626,7 +626,8 @@ struct gimple_opt_pass pass_loop_prefetch =
   0,	/* properties_provided */
   0,	/* properties_destroyed */
   0,	/* todo_flags_start */
-  TODO_dump_func | TODO_verify_loops	/* todo_flags_finish */
+  TODO_dump_func | TODO_verify_loops
+  | TODO_update_ssa			/* todo_flags_finish */
  }
 };
 
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index c0b15cd..c1d7564 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -121,7 +121,7 @@ rename_variables_in_loop (struct loop *loop)
AFTER is true if NEW_LOOP executes after ORIG_LOOP, and false if it
executes before it.  */
 
-static void
+void
 slpeel_update_phis_for_duplicate_loop (struct loop *orig_loop,
    struct loop *new_loop, bool after)
 {

Re: Build report for GCC 4.4.1/i386-unknown-freebsd7.2/binutils-2.19.1

[Loren James Rittle]

In article <20090811.n7cmlsw1041...@latour.labs.mot.com>, I wrote:

> GCC 4.4.1 was successfully built, checked and installed on
> i386-unknown-freebsd7.2.  Note: Default configure options were
> used except GNU binutils 2.19.1.20090812 rather than system's
> binutils 2.15 and the testsuite was run with -pthread.

> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01308.html

> Finally, AFAIK, all required tools were provided by the base system or
> recent versions installed from the system's ports collection.  Neither
> ppl or cloog-ppl was installed for this report (or the GCC 4.4.1 using
> binutils-2.16.1 report that I recently sent).

First, additional notes on the above cited results: After studying the
testsuite logs closely, I see that boehm-gc/gctest fails (for reasons,
as yet, unknown) and three new gcc.target/i386/avx-vmovntps-256-1.c
FAILS appear when GNU binutils 2.19.1.20090812 is used rather than GNU
binutils-2.16.1.

This result was after installing ppl but not cloog:

http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01366.html

This result was after removing all installed copies of binutils
(except that located in /usr/bin) and then staging gas, ld, binutils,
bfd, opcodes, and gprof directories from binutils-2.19.1 (and that was
easier than I recalled; kudos to those that made it so):

http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01398.html

In this case, the testsuite was run without -pthread.  The mudflap
results did not improve as much as I expected.

This result was after installing both ppl and cloog [*] (and having
none of mpfr, gmp, ppl, or cloog source staged in the gcc-4.4.1 source
tree yet having binutils-2.19.1 staged as outlined aboved):

http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01428.html

[*] Installed from the FreeBSD ports system with system compiler gcc-4.2.1:
/usr/ports/math/libgmp4 [4.3.1]
/usr/ports/math/mpfr [2.4.1]
/usr/ports/devel/ppl [0.10.2]

Installed by hand since not yet present in the FreeBSD ports system:
cloog-ppl-0.15.7.tar.gz [from http://gcc.gnu.org/]

This non-result was having mpfr, gmp, ppl, and cloog source staged (as
semi-documented at http://gcc.gnu.org/install/prerequisites.html for
at least mpfr and gmp) in the gcc-4.4.1 source tree:

[...]
Configuring stage 1 in ./gmp
[...]
Configuring stage 1 in ./mpfr
[...]
checking for gmp.h... no
configure: error: gmp.h can't be found, or is unusable.

What happens is that gmp stage 1 is correctly configured and built in
order but then mpfr stage 1 is not configured to find the gmp stage 1
just built (the gmp.h header file is not found).  Did I expect too
much if I thought this would auto-magically work like it does when one
stages the binutils sources?

Either way, I think these statements in install/prerequisites.html may
be incorrect or overly vague for gcc-4.4.1: (1) "Alternatively, if a
GMP source distribution is found in a subdirectory of your GCC sources
named gmp, it will be built together with GCC." (2) "Alternatively, if
a MPFR source distribution is found in a subdirectory of your GCC
sources named mpfr, it will be built together with GCC."  At least, if
you try to do (1) and (2) at the same time.

Finally, in case you wonder, I am testing many subtle variations since
it has been a long time since I updated the default configuration for
FreeBSD and/or the *-*-freebsd* section of install.texi .

Regards,
Loren

Re: Trace crash in gargabe collector to the code at fault?

[Tom Tromey]

> "Andrew" == Andrew Haley  writes:

>> I am running into crashes in ggc_collect() on compiling

Andrew> The usual way to find this is to use a gdb watchpoint.  Find
Andrew> what object is being freed, put a breakpoing on ggc_alloc_stat
Andrew> at the point the object is created, and then put a watchpoint on
Andrew> the word that is being corrupted.

I've also had decent results by configuring with valgrind support.

Tom

Re: Implementing C++1x and C1x atomics

[Lawrence Crowl]

On 8/13/09, Joseph S. Myers  wrote:
> On Thu, 13 Aug 2009, Lawrence Crowl wrote:
> > > Now a processor D for this architecture comes out.  All code
> > > for A, B and C will work on D, but D also has 8-byte atomic
> > > operations.  GCC 4.7, with -march=D, generates code that
> > > uses these operations inline.  If code built with GCC 4.7
> > > -march=D, and code built with GCC 4.6 or without -march=D,
> > > are used together with the glibc 2.12 shared library, both
> > > implementations of the atomic operations are now used and
> > > things don't work.
> >
> > Here is where the heavy platform nature of the atomics comes in.
> > The installed shared glibc 2.12 on the system with a D processor
> > must have been built with -march=D.  If so, then all operations
> > share the same implementation, and everything works.
>
> The practicalities of GNU/Linux distribution deployment mean that
> you don't want to have many different versions of libc built for
> different processors and that you don't want to require users
> of code optimized for a new processor to have a correspondingly
> new or newly built libc.  This is why STT_GNU_IFUNC is useful;
> in theory you can build libc for every processor variant, in
> practice it's better to have one or very few binaries of it and
> have those dynamically use optimized versions of the few functions
> for which CPU optimization make a major difference.

I was thinking of STT_GNU_IFUNC as an optimization on producing
multiple binaries.

> > > glibc 2.13 changes the out-of-line implementation to test
> > > at runtime whether it is running on D, and use the new
> > > instruction instead of the lock-based implementation if so
> > > (probably using STT_GNU_IFUNC so this test is only run the
> > > first time the symbol is resolved).  That new glibc will now
> > > work with objects built with either 4.6 or 4.7.
> >
> > Well, okay, but there would be less exposure to problems if
> > -march=D implied that the library was compiled with -march=D
> > (or better).
>
> It doesn't.  It doesn't imply then processor D had even been
> invented when the C library was built.  You can reasonably build
> a program with a new compiler, against an old libc, that uses its
> own dynamic choice of code for different CPUs, will run on a range
> of distributions and will use code good for the particular CPU
> it is run on; it simply needs to avoid inlining these particular
> operations, while exploiting all other new features of D.

The atomics need a consistency of implementation, which makes them
particularly imporant to have in the system.

> > > But on GNU/Linux - unlike BSDs, say - it is expected that the
> > > compiler, libc and kernel versions can be updated more or less
> > > independently, and that it should be possible to use a newer
> > > compiler to build code that will run with an older C library.
> > > So the case of GCC 4.7 with glibc 2.12 needs to work.  This
> > > means that code built with GCC 4.7 against the 
> > > header provided with glibc 2.12 must not use the 8-byte atomic
> > > instruction that GCC 4.7 knows how to use, because glibc 2.12
> > > will not use it in the out-of-line implementation at runtime.
> >
> > I am suggesting that certain highly processor-dependent routines
> > should be updated with the processor.  That is, I don't think
> > the taxonomy is quite right.
>
> I am saying it is desirable not to have to update those with
> the processor; at most, to have to update the kernel for
> a new processor and keep the same userspace distribution.
> Users routinely run distributions predating their hardware
> (copying an installing from one system to another, or keeping the
> same distribution deployed across multiple systems); they should
> be able to exploit the features of the new hardware in their own
> binaries as far as possible (meaning -march=D should work fine,
> just not inline these operations) while doing so.

So, if -march=D should not imply inlining of the atomic operations,
we need another option that does.  That other option in turn
must require the dynamic library use compatible implementations.
(I'd really like to see errors caught by the loader.)

> > > Are you proposing to avoid this issue by saying that the
> > > platform ABI for GNU/Linux on an X processor is that the
> > > 8-byte operations must never be inlined, and so making GCC
> > > not use the inline operations with -march=D (for GNU/Linux -
> > > it might be different for another OS)?
> >
> > No, I am proposing that an object compiled with -march=D should
> > fail to load on a system that doesn't have both a >=D processor
> > and a >=D library.
>
> Whereas I say -march=D should not cause the operations to be
> inlined unless the library (whose headers are used at compile time)
> is D-aware.  Which means the library communicates to the compiler
> whether it is D-aware.  The simplest way of doing this is through
> macro definitions such as those I suggested, but it could also
> use pragmas to

Call stack mechanisms

[Joshua Moore-Oliva]

I am doing research on multi-threaded call stack mechanisms, and in addition 
to academic papers, I am surveying what mechanisms existing languages use.

Does the gcc backend use a mechanism other than the standard C-pthread 
style "one stack is allocated on thread creation for each thread, and if that 
space is exhausted it is considered an error"? If so, could you detail your 
call stack mechanism?

Does this change between frontends, or is it standardized on the gcc backend?

Thanks for your time, Joshua Moore-Oliva

Re: Implementing C++1x and C1x atomics

[Joseph S. Myers]

On Fri, 14 Aug 2009, Lawrence Crowl wrote:

> So, if -march=D should not imply inlining of the atomic operations,
> we need another option that does.  That other option in turn
> must require the dynamic library use compatible implementations.
> (I'd really like to see errors caught by the loader.)

The loader doesn't catch you using a processor extension that adds new 
call-preserved registers when setjmp/longjmp haven't been updated to 
handle those registers (one existing case that I think unavoidably does 
require a new libc to use a feature of a new architecture).  Fortunately, 
most people producing ABIs for such processor extensions realise it's best 
to make the new registers call-clobbered so that setjmp/longjmp and 
unwinding don't need to handle them.

> > /* in stdc-predef.h (or stdatomic.h if you don't like stdc-predef.h) */
> > #ifdef __arch_D__
> > #pragma GCC atomic_8byte_ok_to_inline
> > #endif
> 
> I must say the header approach really worries me.  The problem is
> that the library that you compile under may not be the library that
> you execute under.  I shudder to think what shipping preprocessor
> output from one system to another will do.

It is required when using glibc that:

(A) Code compiled against headers from libc version X must be run with 
libc version X or later.

(B) Code compiled against headers from libc version X must be linked into 
an executable or shared library against a binary of libc version X 
(exactly).  .o and .a files are not necessarily compatible from one 
version to the next, since compiling against headers from version X means 
the object needs the versions of functions that are provided by libc 
version X, but the symbol references are only bound to particular symbol 
versions at the point at which you link with libc.so.  (It's been a long 
time since there was major breakage of this sort affecting lots of static 
libraries - I think maybe the 2.2-to-2.3 transition - but the principle 
remains that symbol versioning does not assure compatibility for .o and .a 
files, only for executables and shared libraries.)

As long as you follow (A) and each libc version knows about all the atomic 
instruction cases the previous one know about, having libc declare to the 
compiler when it's safe to inline atomic operations (with the default in 
the absence of such a declaration from libc being only to inline 
operations if they are present on all subarchitectures and there is no 
lock-based libc implementation with which to be incompatible) should work 
fine.

-- 
Joseph S. Myers
jos...@codesourcery.com

Need some Unix and /bin/sh expertise for GCC testsuite

[Laurent GUERBY]

Hi,

Even after the last patch I can still see random ACATS failures on a
stock debian etch x86_64 machine (gcc13). I've added many traces to the
ACATS script and I can see now a common pattern and it's not related
to Ada multi threading or wrong code generation.

First the ACATS script itself is relatively straightforward: loop
over the test, copy some files, call gnatmake and then run the
compiled test and check the output.

The issue comes for a surprising - to me - /bin/sh behaviour,
if an /bin/sh expert could help me figure out the following:

=> gcc/testsuite/ada/acats/run_all.sh
<<
#!/bin/sh
# Run ACATS with the GNU Ada compiler
...
target_gnatmake () {
  echo gnatmake --GCC=\"$GCC\" $gnatflags $gccflags $* -largs $EXTERNAL_OBJECTS 
--GCC=\"$GCC\"
  gnatmake --GCC="$GCC" $gnatflags $gccflags $* -largs $EXTERNAL_OBJECTS 
--GCC="$GCC"
}
...
while ...
  ...
  target_gnatmake $extraflags -I$dir/support $main >> $dir/acats.log 2>&1
  if [ $? -ne 0 ]; then
 display "FAIL: $i"
 failed="${failed}${i} "
 clean_dir
 continue
  fi

  echo "RUN $binmain" >> $dir/acats.log
  cd $dir/run

  ZSTAMP=none
  if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
 sync
 ZSTAMP=$(date '+%Y%m%dT%H%M%S')
 ls -l $dir/tests/$chapter/$i/ > 
/home/guerby/tmp/acats/postsync-${i}-${ZSTAMP} 2>&1
 ps fauxw > /home/guerby/tmp/acats/psfauxw1-${i}-${ZSTAMP} 2>&1
  fi

  target_run $dir/tests/$chapter/$i/$binmain > 
$dir/tests/$chapter/$i/${i}.log 2>&1
  ...
>>

Now the common fail pattern is as follows:

1/ target_gnatmake succeeds, that is we don't pass in the first "if".

2/ However even is gnatmake has succeeded we enter the second "if"
because there's no executable in the dir as shown by "ls -l" output:

=> postsync-c48005b-20090813T202815
<<
total 44
-rw-r--r-- 1 guerby guerby 10345 2009-08-13 20:28 b~c48005b.adb
-rw-r--r-- 1 guerby guerby 12375 2009-08-13 20:28 b~c48005b.ads
-rw-r--r-- 1 guerby guerby  2786 2009-08-13 20:28 c48005b.adb
-rw-r--r-- 1 guerby guerby   784 2009-08-13 20:28 c48005b.ali
-rw-r--r-- 1 guerby guerby12 2009-08-13 20:28 c48005b.lst
-rw-r--r-- 1 guerby guerby  3208 2009-08-13 20:28 c48005b.o
>>

3/ Here is the point I find surprising: the "ps fauxww" run in the
second "if" show that even if the script is fully sequential
at least one gnatmake subprocess (collect-ld) is still marked as running 
*in parallel* with the ps command in the subsequent "if" of the script!

=> psfauxw1-c48005b-20090813T202815
<<
...
guerby7715  1.3  0.0  12176  1936 ?SN   20:20   0:06   \_ /bin/sh 
/home/guerby/trunk/gcc/testsuite/ada/acats/run_all.sh
guerby7794  0.0  0.0  10796  2476 ?SN   20:28   0:00   \_ 
gnatmake --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ -gnatws 
-O2 -I/home/guerby/build/gcc/testsuite/ada/acats/support c48005b.adb -largs 
--GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/
guerby7803  0.0  0.0   4048  1228 ?SN   20:28   0:00   |   \_ 
/home/guerby/build/gcc/gnatlink c48005b.ali --GCC=/home/guerby/build/gcc/xgcc 
-B/home/guerby/build/gcc/
guerby7809  0.0  0.0   2880   584 ?SN   20:28   0:00   |   
\_ /home/guerby/build/gcc/xgcc b~c48005b.o ... -o c48005b ...
guerby7810  0.0  0.0   2756   444 ?SN   20:28   0:00   |
   \_ /home/guerby/build/gcc/collect2 --eh-frame-hdr -m elf_x86_64 
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c48005b ...
guerby7811  0.0  0.0  11548  1500 ?RN   20:28   0:00   |
   \_ /bin/sh /home/guerby/build/gcc/collect-ld --eh-frame-hdr -m 
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c48005b 
guerby7808  0.0  0.0  14328  1156 ?RN   20:28   0:00   \_ ps 
fauxw
...
>>

4/ we run the executable but since it's not there we get:

=> c48005b.log
<<
/home/guerby/trunk/gcc/testsuite/ada/acats/run_all.sh: line 16: 
/home/guerby/build/gcc/testsuite/ada/acats/tests/c4/c48005b/c48005b: Permission 
denied
>>

5/ After the run an empty file appears in another "ls -l" 
(not shown in the script above):

-rw-r--r-- 1 guerby guerby 0 2009-08-13 20:28 c48005b

6/ Waiting for one more second ("sleep 1" not shown above) the 
full file appears at last in "ls -l":

-rwxr-xr-x 1 guerby guerby 1164960 2009-08-13 20:28 c48005b

Any idea of why /bin/sh is running stuff in parallel instead
of sequential? 

Could some code in 
gnatmake/gnatlink/xgcc/collect2/collect-ld cause it?

gue...@gcc13:~$ /bin/sh --version
GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu)

Thanks in advance,

Laurent

Re: Implementing C++1x and C1x atomics

[Lawrence Crowl]

On 8/14/09, Joseph S. Myers  wrote:
> On Fri, 14 Aug 2009, Lawrence Crowl wrote:
> > So, if -march=D should not imply inlining of the atomic
> > operations, we need another option that does.  That other
> > option in turn must require the dynamic library use compatible
> > implementations.  (I'd really like to see errors caught by
> > the loader.)
>
> The loader doesn't catch you using a processor extension that
> adds new call-preserved registers when setjmp/longjmp haven't
> been updated to handle those registers (one existing case that
> I think unavoidably does require a new libc to use a feature of
> a new architecture).  Fortunately, most people producing ABIs
> for such processor extensions realise it's best to make the new
> registers call-clobbered so that setjmp/longjmp and unwinding
> don't need to handle them.
>
> > > /* in stdc-predef.h (or stdatomic.h if you don't like stdc-predef.h) */
> > > #ifdef __arch_D__
> > > #pragma GCC atomic_8byte_ok_to_inline
> > > #endif
> >
> > I must say the header approach really worries me.  The problem is
> > that the library that you compile under may not be the library
> > that you execute under.  I shudder to think what shipping
> > preprocessor output from one system to another will do.
>
> It is required when using glibc that:
>
> (A) Code compiled against headers from libc version X must be
> run with libc version X or later.
>
> (B) Code compiled against headers from libc version X must be
> linked into an executable or shared library against a binary of
> libc version X (exactly).  .o and .a files are not necessarily
> compatible from one version to the next, since compiling against
> headers from version X means the object needs the versions of
> functions that are provided by libc version X, but the symbol
> references are only bound to particular symbol versions at the
> point at which you link with libc.so.  (It's been a long time
> since there was major breakage of this sort affecting lots of
> static libraries - I think maybe the 2.2-to-2.3 transition -
> but the principle remains that symbol versioning does not assure
> compatibility for .o and .a files, only for executables and
> shared libraries.)
>
> As long as you follow (A) and each libc version knows about
> all the atomic instruction cases the previous one know about,
> having libc declare to the compiler when it's safe to inline
> atomic operations (with the default in the absence of such a
> declaration from libc being only to inline operations if they are
> present on all subarchitectures and there is no lock-based libc
> implementation with which to be incompatible) should work fine.

So, suppose I compile my program A, using libc version X, on
a processor of type D, which permits me to inline the atomic
operations.  Then suppose that I execute A on a processor of type E,
which has libc version X, but which supports fewer atomic operations
and thus requires a locking implementation.  I have met all the
versioning requirements.  What happens?

-- 
Lawrence Crowl

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Dave Korn]

Laurent GUERBY wrote:

> 3/ Here is the point I find surprising: the "ps fauxww" run in the
> second "if" show that even if the script is fully sequential
> at least one gnatmake subprocess (collect-ld) is still marked as running 
> *in parallel* with the ps command in the subsequent "if" of the script!

> Any idea of why /bin/sh is running stuff in parallel instead
> of sequential? 
> 
> Could some code in 
> gnatmake/gnatlink/xgcc/collect2/collect-ld cause it?

  I notice gnatmake.adb has a reference to GNAT.OS_Lib.Non_Blocking_Spawn in
it coincidence?

cheers,
  DaveK

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Laurent GUERBY]

On Fri, 2009-08-14 at 22:19 +0100, Dave Korn wrote:
> Laurent GUERBY wrote:
> 
> > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > second "if" show that even if the script is fully sequential
> > at least one gnatmake subprocess (collect-ld) is still marked as running 
> > *in parallel* with the ps command in the subsequent "if" of the script!
> 
> > Any idea of why /bin/sh is running stuff in parallel instead
> > of sequential? 
> > 
> > Could some code in 
> > gnatmake/gnatlink/xgcc/collect2/collect-ld cause it?
> 
>   I notice gnatmake.adb has a reference to GNAT.OS_Lib.Non_Blocking_Spawn in
> it coincidence?

gnatmake uses Non_Blocking_Spawn to call the compiler (gnatmake supports
"-j N" like make), but for the gnatlink call (we see in the "ps fauxww")
it uses in gcc/ada/make.adb:

   procedure Link
...
  GNAT.OS_Lib.Spawn (Gnatlink_Path.all, Link_Args, Success);
   end Link;

which ends up calling gcc/ada/s-os_lib.adb

  Spawn_Internal (Program_Name, Args, Result, Junk, Blocking =>
True);
...
 function Portable_Spawn (Args : Address) return Integer;
 pragma Import (C, Portable_Spawn, "__gnat_portable_spawn");

which ends up calling in gcc/ada/adaint.c:

int
__gnat_portable_spawn (char *args[])
...
  pid = fork ();
  if (pid < 0)
return -1;

  if (pid == 0)
{
  /* The child. */
  if (execv (args[0], MAYBE_TO_PTR32 (args)) != 0)
_exit (1);
}

  /* The parent.  */
  finished = waitpid (pid, &status, 0);

  if (finished != pid || WIFEXITED (status) == 0)
return -1;

  return WEXITSTATUS (status);
}

Thanks for your help :).

Laurent

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Ralf Wildenhues]

Hello,

* Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> => gcc/testsuite/ada/acats/run_all.sh

> 3/ Here is the point I find surprising: the "ps fauxww" run in the
> second "if" show that even if the script is fully sequential
> at least one gnatmake subprocess (collect-ld) is still marked as running 
> *in parallel* with the ps command in the subsequent "if" of the script!

One thing I see in that script is there is a line
  rm -rf $dir/tests.$$ &

that will be run "in parallel" due to the stray "&".  However, I also
don't see at least parts of the rest of the script that you quote, so
maybe I'm looking at the wrong version (looking at trunk) or you have
added debug statements, so maybe yours has more such stray asynchronous
lists.

Hope that helps.

Cheers,
Ralf

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Laurent GUERBY]

On Fri, 2009-08-14 at 23:25 +0200, Ralf Wildenhues wrote:
> Hello,
> 
> * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > => gcc/testsuite/ada/acats/run_all.sh
> 
> > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > second "if" show that even if the script is fully sequential
> > at least one gnatmake subprocess (collect-ld) is still marked as running 
> > *in parallel* with the ps command in the subsequent "if" of the script!
> 
> One thing I see in that script is there is a line
>   rm -rf $dir/tests.$$ &
> 
> that will be run "in parallel" due to the stray "&".  

This one is part of initialization done once well before the loop over
the tests, so I don't think it can interfere in any way (and my
"ps fauxww" log doesn't show it around).

> However, I also
> don't see at least parts of the rest of the script that you quote, so
> maybe I'm looking at the wrong version (looking at trunk) or you have
> added debug statements, so maybe yours has more such stray asynchronous
> lists.

Yes my quote is from my heavily instrumented run_all.sh. 

The svn clean run_all.sh will exhibit the random fail with the very same
error message in gcc/testsuite/ada/acats/acats.log so the
instrumentation doesn't change the failure mode.

Thanks for your help,

Laurent

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Andreas Schwab]

Laurent GUERBY  writes:

> Any idea of why /bin/sh is running stuff in parallel instead
> of sequential? 

Have you tried set -x?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Laurent GUERBY]

On Fri, 2009-08-14 at 23:36 +0200, Andreas Schwab wrote:
> Laurent GUERBY  writes:
> 
> > Any idea of why /bin/sh is running stuff in parallel instead
> > of sequential? 
> 
> Have you tried set -x?

IIRC I tried at first but it didn't gave me useful information,
everything looked "normal", then I switched to more invasive
logging including three "ps fauxww" and "ls -l".

On the statistical side over the past three monthes there were 17
occurrences of this issue:

-rw-r--r-- 1 guerby guerby  29623 2009-05-21 18:05 
psfauxw1-c48004d-20090521T180512
-rw-r--r-- 1 guerby guerby  36904 2009-05-21 22:57 
psfauxw1-d4a002b-20090521T225738
-rw-r--r-- 1 guerby guerby  31810 2009-05-23 21:45 
psfauxw1-d4a002b-20090523T214538
-rw-r--r-- 1 guerby guerby  29774 2009-05-29 05:15 
psfauxw1-d4a002b-20090529T051533
-rw-r--r-- 1 guerby guerby  30467 2009-07-02 17:06 
psfauxw1-cxaa005-20090702T170643
-rw-r--r-- 1 guerby guerby  64559 2009-07-03 08:15 
psfauxw1-cxaa017-20090703T081509
-rw-r--r-- 1 guerby guerby  30227 2009-07-03 13:13 
psfauxw1-d4a002a-20090703T131307
-rw-r--r-- 1 guerby guerby  30280 2009-07-03 22:43 
psfauxw1-cb3003a-20090703T224359
-rw-r--r-- 1 guerby guerby  29442 2009-07-12 03:57 
psfauxw1-cb1001a-20090712T035707
-rw-r--r-- 1 guerby guerby  30361 2009-07-23 03:33 
psfauxw1-cb20a02-20090723T033340
-rw-r--r-- 1 guerby guerby  30361 2009-07-23 03:42 
psfauxw1-cz1103a-20090723T034235
-rw-r--r-- 1 guerby guerby  30443 2009-07-27 01:02 
psfauxw1-c48004d-20090727T010248
-rw-r--r-- 1 guerby guerby  30112 2009-07-30 02:03 
psfauxw1-cz1102a-20090730T020304
-rw-r--r-- 1 guerby guerby  34507 2009-08-02 04:34 
psfauxw1-cd1009o-20090802T043428
-rw-r--r-- 1 guerby guerby  37807 2009-08-08 11:08 
psfauxw1-d4a002a-20090808T110858
-rw-r--r-- 1 guerby guerby  38340 2009-08-09 16:52 
psfauxw1-c48004d-20090809T165214
-rw-r--r-- 1 guerby guerby  38319 2009-08-13 20:28 
psfauxw1-c48005b-20090813T202815

Since the machine runs on average 5 bootstrap+check a day and that ACATS
has 2315 tests, it's a rate of failure of ~ 17 per one million individual test 
run.
But it's at least one spurious FAIL in about 4% of bootstrap+check.

Laurent

Re: Implementing C++1x and C1x atomics

[Joseph S. Myers]

On Fri, 14 Aug 2009, Lawrence Crowl wrote:

> So, suppose I compile my program A, using libc version X, on
> a processor of type D, which permits me to inline the atomic
> operations.  Then suppose that I execute A on a processor of type E,
> which has libc version X, but which supports fewer atomic operations
> and thus requires a locking implementation.  I have met all the
> versioning requirements.  What happens?

(I will suppose that by "compile ... on a processor of type D" you mean 
compile with the compiler told to target D (explicitly with -march=D, or 
implicitly with -march=native, or with a compiler configured 
--with-arch=D), since the processor of the target is in general 
independent of that of the host.)

You get SIGILL when the atomic instruction that is present on D but not E 
is executed.  That a program built for one processor (D) but executed on 
another (E), whose features are not a superset of those of D, will get 
SIGILL, or execute incorrectly if E does something else on encountering 
that instruction, is not in any way specific to atomic instructions; it 
applies to every architecture with more than one supported variant.  Ways 
for the kernel or dynamic linker to detect such incompatibilities may be 
useful, but would apply to this issue in general, not specifically to 
atomic operations.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Dave Korn]

Laurent GUERBY wrote:

> gnatmake uses Non_Blocking_Spawn to call the compiler (gnatmake supports
> "-j N" like make), but for the gnatlink call (we see in the "ps fauxww")
> it uses in gcc/ada/make.adb:
> 
>procedure Link
> ...
>   GNAT.OS_Lib.Spawn (Gnatlink_Path.all, Link_Args, Success);
>end Link;
> 
> which ends up calling gcc/ada/s-os_lib.adb
> 
>   Spawn_Internal (Program_Name, Args, Result, Junk, Blocking =>
> True);
> ...
>  function Portable_Spawn (Args : Address) return Integer;
>  pragma Import (C, Portable_Spawn, "__gnat_portable_spawn");
> 
> which ends up calling in gcc/ada/adaint.c:
> 
> int
> __gnat_portable_spawn (char *args[])
> ...
>   pid = fork ();
>   if (pid < 0)
> return -1;
> 
>   if (pid == 0)
> {
>   /* The child. */
>   if (execv (args[0], MAYBE_TO_PTR32 (args)) != 0)
>   _exit (1);
> }
> 
>   /* The parent.  */
>   finished = waitpid (pid, &status, 0);
> 
>   if (finished != pid || WIFEXITED (status) == 0)
> return -1;
> 
>   return WEXITSTATUS (status);
> }

  Hmpf.  That seems to rule out that theory.  Gnatlink is still spawning the
gcc driver to link, rather than the linker itself; maybe the driver's doing
something wrong?  Is collect-ld a shell script or an executable on your host?

cheers,
  DaveK

Re: About feasibility of implementing an instruction

[Mohamed Shafi]

2009/7/3 Ian Lance Taylor :
> Mohamed Shafi  writes:
>
>> I just want to know about the feasibility of implementing an
>> instruction for a port in gcc 4.4
>> The target has 40 bit register where the normal load/store/move
>> instructions will be able to access the 32 bits of the register. In
>> order to move data into the rest of the register [b32 to b39] the data
>> has to be stored into a 32bit memory location. The data should be
>> stored in such a way that if it is stored for 0-7 in memory the data
>> can be moved to b32-b39 of a even register and if the data in the
>> memory is stored in 16-23 of the memory word then it can be moved to
>> b32-b39 of a odd register. Hope i make myself clear.
>>
>> Will it be possible to implement this in the gcc back-end so that the
>> particular instruction is supported?
>
> In general, the gcc backend can do anything, so, yes, this can be
> supported.  It sounds like this is not a general purpose register, so I
> would probably do it using a builtin function.  If you need to treat it
> as a general purpose register (i.e., the register is managed by the
> register allocator) then you will need a secondary reload to handle
> this.
>

This is a general purpose register. All the 40 bits are used only for
fixed-point data types. When the register is used for fixed-point data
type all the operations except initialization, are done through
built-in functions. For initialization the immediate value should move
through a memory ..i.e there is no immediate load when the data is
40bit. So i am planning to control this using LEGITIMATE_CONSTANT
macro. But then i have a question. If all the operations are through
intrinsics will there be a need for spilling for the variables used in
the built-in functions? If so then depending on the register that get
spilled is even or odd [b32 to b39] of the register gets stored in the
memory to [b0 to b7] or [b16 tr b23] respectively. Will i be able to
keep track of the spilling so that i can reload into the proper
register?

Hope i am clear.

Regards
Shafi

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Ralf Wildenhues]

> > * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > > => gcc/testsuite/ada/acats/run_all.sh
> > 
> > > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > > second "if" show that even if the script is fully sequential
> > > at least one gnatmake subprocess (collect-ld) is still marked as running 
> > > *in parallel* with the ps command in the subsequent "if" of the script!

Sounds like http://thread.gmane.org/gmane.comp.shells.bash.bugs/11990
and the NEWS for bash-3.2 contains this entry:

l.  Several fixes to the code that manages the list of terminated jobs and
their exit statuses, and the list of active and recently-terminated jobs
to avoid pid aliasing/wraparound and allocation errors.

I'd try out a newer bash version.

Cheers,
Ralf