BUG in libstdc++-v3/config/os/generic/error_constants.h

[Dongsheng Song]

 snip libstdc++-v3/config/os/generic/error_constants.h

  not_supported =   ENOTSUP,
 snip libstdc++-v3/config/os/generic/error_constants.h


OpenBSD 4.2 not defined ENOTSUP, only EOPNOTSUPP !

 snip /usr/include/sys/errno.h 
#define EOPNOTSUPP  45  /* Operation not supported */
 snip /usr/include/sys/errno.h 

This affect gcc 4.3/trunk only. Maybe we should add a new file
libstdc++-v3/config/os/bsd/openbsd/error_constants.h like mingw32 ?

Dongsheng

Re: symbol lookup error: cc1: undefined symbol: mpfr_remquo

[Kaveh R. GHAZI]

On Mon, 21 Jan 2008, Kaveh R. GHAZI wrote:

> > Exactly this issue. I am not sure how this can happen. My configure
> > options are above. I am using the Compile Farm.
>
> This happens because you linked GCC with a shared MPFR library in
> /opt/cfarm/mpfr-2.3.0/lib, but because there is no -rpath set you get the
> system mpfr-2.2.0 from /usr/lib at runtime.

FYI, Laurent moved the shared mpfr libs into a subdir on all the machines,
so you can use the /opt/cfarm/mpfr-2.3.0 directory for configuring GCC on
the compile farm.


> > It works if I use --with-mpfr=/home/ghazi/gcc-testing/lib/422-230/ instead.
> > Thanks,
> > Manuel.
>
> Yeah :-), that works because I configured my private copy of GMP/MPFR on
> the compile farm with --disable-shared so there is no chance of runtime
> mixup.

I've deleted my private copy of gmp-4.2.2/mpfr-2.3.0 from most of the
boxes there.  Now that mpfr-2.3.1 has been released, I've installed
private copies for testing purposes.  (This one relies on the system gmp).
You're welcome to try that or simply use the /opt 2.3.0 copy.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Question about Register Class Allocation

[Ian Lance Taylor]

"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:

> I saw that regclass() function determines which class of register
> the registers in the current units should be assigned to. The question I
> have is: Will this decision change in any other parts of the compiler?
> or is this this the final place where they fix the register class? So,
> if I add my own priority-based register-class assigner, can I just
> replace this function and add my own?

regclass sets preferences.  Those preferences will not change later.
The register allocator will honor those preferences if possible.
However, it is not required to honor them.  It is only required to
honor the constraints in the MD file.

Ian

Question about Register Class Allocation

[Balaji V. Iyer]

Hello Everyone,
I am currently working with Gcc 4.0.2 and I have a question
regarding the register allocation.
 
I saw that regclass() function determines which class of register
the registers in the current units should be assigned to. The question I
have is: Will this decision change in any other parts of the compiler?
or is this this the final place where they fix the register class? So,
if I add my own priority-based register-class assigner, can I just
replace this function and add my own?
 
Any help is very very much appreciated. Please feel free to contact me
if you need any additional clarification.
 
Thanks,
 
Balaji V. Iyer.
 
-- 
 
Balaji V. Iyer
PhD Student, 
Center for Efficient, Scalable and Reliable Computing,
Department of Electrical and Computer Engineering,
North Carolina State University.

Re: GCC 4.3 target deprecation proposals

[Kai Henningsen]

On Wed, Jan 23, 2008 at 07:28:23PM -0500, DJ Delorie wrote:
> 
> > You can't cross-test, with DejaGnu running elsewhere?
> 
> I've tried.  The problem is communication between the DOS system (or
> emulator) and the host system.  DOS isn't kind to networking,
> semaphores, or anything else that hints at multiprocessing.

Under Linux with DOSEMU, it should be fairly simple.

Create a named pipe.

On the DOS side, use a shell script to read one line from the pipe.

On the Linux side, prepare a DOS shell script or batch for the DOS side
to execute. (Remember the carriage returns where appropriate.) Then,
echo a crlf into the named pipe.

The read on the DOS side will now finish. Go execute the job. Then echo
your return code into a file, read another line from the named pipe, and
loop.

On the Linux side, echo another crlf into the named pipe; this waits for
the DOS side. Then read the return code from the file.


You might (with a sufficiently modern bash on the Linux side) write your
script with something like
#! /bin/bash
printf "%q " "$0" "$@" > script
echo -e '\r' > thepipe
echo Waiting for return code
echo -e '\r' > thepipe
read rc < rc
exit $rc
and link this to every command name you want to be able to execute.

On the DOS side,
:
while true
do
echo Waiting for command
read dummy < thepipe
sh script
echo $? > rc
read dummy < thepipe
done

Disclaimer: I haven't really done more than a quick test of named pipe
reading. I'm sure there are some subtilities here.

Re: c++0x concepts in gcc call

[Doug Gregor]

On Mon, Jan 28, 2008 at 5:38 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Sun, 27 Jan 2008, Doug Gregor wrote:
>  > I was planning to kill the cxx0x-branch outright, because it has
>  > nothing that isn't available on mainline (except a not-nearly-complete
>  > delegating constructors implementation), and will not be used. If this
>  > would be better handled by moving the entry to "Inactive Development
>  > Branches", I'll certainly do that.
>
>  Yes, for historical reasons it would be nice to have that branch
>  documented there, with a note that/when it was merged into mainline
>  as for some of the other examples there.

Okay, done.

>  Gerald
>
>  PS: Nice patch of yours that fixes seven PRs at once. :-)

Now it's nine PRs :)

  - Doug

Index: svn.html
N===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.73
diff -u -r1.73 svn.html
--- svn.html28 Jan 2008 15:19:04 -  1.73
+++ svn.html29 Jan 2008 17:37:47 -
@@ -779,7 +779,12 @@
 [EMAIL PROTECTED]>
   

-
+  cxx0x-branch
+  This branch was for developed of C++0x features, and all
+  features developed on this branch have been merged to
+  mainline. Future C++0x features will be developed against mainline
+  or, in the case of concepts, on
+  the cxx0x-concepts-branch.
 

 

Re: GCC 4.3 target deprecation proposals

[Ryan Mansfield]

Joseph S. Myers wrote:

Following my proposal for target architecture deprecations in 4.3
, I now propose the
following list of individual targets to deprecate, based on the same
methodology previously described.  The patch to remove c4x and
deprecate the previously discussed target architectures crx, iq2000,
mt, stormy16 will be submitted shortly; the patch for the remaining
deprecations (only touching config.gcc and the release notes) will be
submitted later after any discussion.



* i[34567]86-*-nto-qnx*


Please do not deprecated this target. We intend to update this target 
and post test results in the very near future.


Regards,

Ryan Mansfield

Re: Memory leaks in compiler

[Richard Guenther]

On Jan 29, 2008 2:14 PM, Ira Rosen <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:
>
> > > When a loop is vectorized, some statements are removed from the basic
> > > blocks, but the vectorizer information attached to these BBs is never
> > > freed.
> >
> > Sebastian, thanks for bringing this to our attention. I'll look into
> this.
> > I hope that removing stmts from a BB can be easily localized.
> > -- Victor
> >
>
> The attached patch, mainly written by Victor, fixes memory leaks in the
> vectorizer, that were found with the help of valgrind and by examining the
> code.
>
> Bootstrapped with vectorization enabled and tested on vectorizer testsuite
> on ppc-linux. I still have to perform full regtesting.
>
> Is it O.K. for 4.3? Or will it wait for 4.4?

Please wait for 4.4.

Thanks,
Richard.

Re: Memory leaks in compiler

[Ira Rosen]

(I am resending this, since some of the addresses got corrupted. My
apologies.)

Hi,

[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:

> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
> Sebastian, thanks for bringing this to our attention. I'll look into
this.
> I hope that removing stmts from a BB can be easily localized.
> -- Victor
>

The attached patch, mainly written by Victor, fixes memory leaks in the
vectorizer, that were found with the help of valgrind and by examining the
code.

Bootstrapped with vectorization enabled and tested on vectorizer testsuite
on ppc-linux. I still have to perform full regtesting.

Is it O.K. for 4.3? Or will it wait for 4.4?

Thanks,.
Victor and Ira

ChangeLog:

  * tree-vectorizer.c (free_stmt_vec_info): New function.
  (destroy_loop_vec_info): Move code to free_stmt_vec_info().
  Call free_stmt_vec_info(). Free LOOP_VINFO_STRIDED_STORES..
  * tree-vectorizer.h (free_stmt_vec_info): Declare.
  * tree-vect-transform.c (vectorizable_conversion): Free
  vec_oprnds0 if it was allocated.
  (vect_permute_store_chain): Remove unused VECs.
  (vectorizable_store): Free VECs that are allocated in the..
  function.
  (vect_transform_strided_load, vectorizable_load): Likewise.
  (vect_remove_stores): Simplify the code.
  (vect_transform_loop): Move code to vect_remove_stores().
  Call vect_remove_stores() and free_stmt_vec_info().


(See attached file: memleaks.txt)

Index: tree-vectorizer.c
===
--- tree-vectorizer.c   (revision 131899)
+++ tree-vectorizer.c   (working copy)
@@ -1558,6 +1558,22 @@ new_stmt_vec_info (tree stmt, loop_vec_i
 }
 
 
+/* Free stmt vectorization related info.  */
+
+void
+free_stmt_vec_info (tree stmt)
+{
+  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+
+  if (!stmt_info)
+return;
+
+  VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
+  free (stmt_info);
+  set_stmt_info (stmt_ann (stmt), NULL);
+}
+
+
 /* Function bb_in_loop_p
 
Used as predicate for dfs order traversal of the loop bbs.  */
@@ -1714,21 +1730,13 @@ destroy_loop_vec_info (loop_vec_info loo
 {
   basic_block bb = bbs[j];
   tree phi;
-  stmt_vec_info stmt_info;
 
   for (phi = phi_nodes (bb); phi; phi = PHI_CHAIN (phi))
-{
-  stmt_ann_t ann = stmt_ann (phi);
-
-  stmt_info = vinfo_for_stmt (phi);
-  free (stmt_info);
-  set_stmt_info (ann, NULL);
-}
+free_stmt_vec_info (phi);
 
   for (si = bsi_start (bb); !bsi_end_p (si); )
{
  tree stmt = bsi_stmt (si);
- stmt_ann_t ann = stmt_ann (stmt);
  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
 
  if (stmt_info)
@@ -1746,9 +1754,7 @@ destroy_loop_vec_info (loop_vec_info loo
}

  /* Free stmt_vec_info.  */
- VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
- free (stmt_info);
- set_stmt_info (ann, NULL);
+ free_stmt_vec_info (stmt);
 
  /* Remove dead "pattern stmts".  */
  if (remove_stmt_p)
@@ -1767,6 +1773,7 @@ destroy_loop_vec_info (loop_vec_info loo
   for (j = 0; VEC_iterate (slp_instance, slp_instances, j, instance); j++)
 vect_free_slp_tree (SLP_INSTANCE_TREE (instance));
   VEC_free (slp_instance, heap, LOOP_VINFO_SLP_INSTANCES (loop_vinfo));
+  VEC_free (tree, heap, LOOP_VINFO_STRIDED_STORES (loop_vinfo));
 
   free (loop_vinfo);
   loop->aux = NULL;
Index: tree-vectorizer.h
===
--- tree-vectorizer.h   (revision 131899)
+++ tree-vectorizer.h   (working copy)
@@ -667,6 +667,7 @@ extern bool supportable_narrowing_operat
 extern loop_vec_info new_loop_vec_info (struct loop *loop);
 extern void destroy_loop_vec_info (loop_vec_info, bool);
 extern stmt_vec_info new_stmt_vec_info (tree stmt, loop_vec_info);
+extern void free_stmt_vec_info (tree stmt);
 
 
 /** In tree-vect-analyze.c  **/
Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 131899)
+++ tree-vect-transform.c   (working copy)
@@ -3638,6 +3638,9 @@ vectorizable_conversion (tree stmt, bloc
   *vec_stmt = STMT_VINFO_VEC_STMT (stmt_info);
 }
 
+  if (vec_oprnds0)
+VEC_free (tree, heap, vec_oprnds0); 
+
   return true;
 }
 
@@ -4589,11 +4592,8 @@ vect_permute_store_chain (VEC(tree,heap)
   tree scalar_dest, tmp;
   int i;
   unsigned int j;
-  VEC(tree,heap) *first, *second;
   
   scalar_dest = GIMPLE_STMT_OPERAND (stmt, 0);
-  first = VEC_alloc (tree, heap, length/2);
-  second = VEC_alloc (tree, heap, length/2);
 
   /* Check that the operation is supported.  */
   if (!vect_strided_store_supported (vectype

Re: Memory leaks in compiler

[Ira Rosen]

(I am resending this, since some of the addresses got corrupted. My
apologies.)

Hi,

[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:

> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
> Sebastian, thanks for bringing this to our attention. I'll look into
this.
> I hope that removing stmts from a BB can be easily localized.
> -- Victor
>

The attached patch, mainly written by Victor, fixes memory leaks in the
vectorizer, that were found with the help of valgrind and by examining the
code.

Bootstrapped with vectorization enabled and tested on vectorizer testsuite
on ppc-linux. I still have to perform full regtesting.

Is it O.K. for 4.3? Or will it wait for 4.4?

Thanks,.
Victor and Ira

ChangeLog:

  * tree-vectorizer.c (free_stmt_vec_info): New function.
  (destroy_loop_vec_info): Move code to free_stmt_vec_info().
  Call free_stmt_vec_info(). Free LOOP_VINFO_STRIDED_STORES..
  * tree-vectorizer.h (free_stmt_vec_info): Declare.
  * tree-vect-transform.c (vectorizable_conversion): Free
  vec_oprnds0 if it was allocated.
  (vect_permute_store_chain): Remove unused VECs.
  (vectorizable_store): Free VECs that are allocated in the..
  function.
  (vect_transform_strided_load, vectorizable_load): Likewise.
  (vect_remove_stores): Simplify the code.
  (vect_transform_loop): Move code to vect_remove_stores().
  Call vect_remove_stores() and free_stmt_vec_info().


(See attached file: memleaks.txt)

Index: tree-vectorizer.c
===
--- tree-vectorizer.c   (revision 131899)
+++ tree-vectorizer.c   (working copy)
@@ -1558,6 +1558,22 @@ new_stmt_vec_info (tree stmt, loop_vec_i
 }
 
 
+/* Free stmt vectorization related info.  */
+
+void
+free_stmt_vec_info (tree stmt)
+{
+  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+
+  if (!stmt_info)
+return;
+
+  VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
+  free (stmt_info);
+  set_stmt_info (stmt_ann (stmt), NULL);
+}
+
+
 /* Function bb_in_loop_p
 
Used as predicate for dfs order traversal of the loop bbs.  */
@@ -1714,21 +1730,13 @@ destroy_loop_vec_info (loop_vec_info loo
 {
   basic_block bb = bbs[j];
   tree phi;
-  stmt_vec_info stmt_info;
 
   for (phi = phi_nodes (bb); phi; phi = PHI_CHAIN (phi))
-{
-  stmt_ann_t ann = stmt_ann (phi);
-
-  stmt_info = vinfo_for_stmt (phi);
-  free (stmt_info);
-  set_stmt_info (ann, NULL);
-}
+free_stmt_vec_info (phi);
 
   for (si = bsi_start (bb); !bsi_end_p (si); )
{
  tree stmt = bsi_stmt (si);
- stmt_ann_t ann = stmt_ann (stmt);
  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
 
  if (stmt_info)
@@ -1746,9 +1754,7 @@ destroy_loop_vec_info (loop_vec_info loo
}

  /* Free stmt_vec_info.  */
- VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
- free (stmt_info);
- set_stmt_info (ann, NULL);
+ free_stmt_vec_info (stmt);
 
  /* Remove dead "pattern stmts".  */
  if (remove_stmt_p)
@@ -1767,6 +1773,7 @@ destroy_loop_vec_info (loop_vec_info loo
   for (j = 0; VEC_iterate (slp_instance, slp_instances, j, instance); j++)
 vect_free_slp_tree (SLP_INSTANCE_TREE (instance));
   VEC_free (slp_instance, heap, LOOP_VINFO_SLP_INSTANCES (loop_vinfo));
+  VEC_free (tree, heap, LOOP_VINFO_STRIDED_STORES (loop_vinfo));
 
   free (loop_vinfo);
   loop->aux = NULL;
Index: tree-vectorizer.h
===
--- tree-vectorizer.h   (revision 131899)
+++ tree-vectorizer.h   (working copy)
@@ -667,6 +667,7 @@ extern bool supportable_narrowing_operat
 extern loop_vec_info new_loop_vec_info (struct loop *loop);
 extern void destroy_loop_vec_info (loop_vec_info, bool);
 extern stmt_vec_info new_stmt_vec_info (tree stmt, loop_vec_info);
+extern void free_stmt_vec_info (tree stmt);
 
 
 /** In tree-vect-analyze.c  **/
Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 131899)
+++ tree-vect-transform.c   (working copy)
@@ -3638,6 +3638,9 @@ vectorizable_conversion (tree stmt, bloc
   *vec_stmt = STMT_VINFO_VEC_STMT (stmt_info);
 }
 
+  if (vec_oprnds0)
+VEC_free (tree, heap, vec_oprnds0); 
+
   return true;
 }
 
@@ -4589,11 +4592,8 @@ vect_permute_store_chain (VEC(tree,heap)
   tree scalar_dest, tmp;
   int i;
   unsigned int j;
-  VEC(tree,heap) *first, *second;
   
   scalar_dest = GIMPLE_STMT_OPERAND (stmt, 0);
-  first = VEC_alloc (tree, heap, length/2);
-  second = VEC_alloc (tree, heap, length/2);
 
   /* Check that the operation is supported.  */
   if (!vect_strided_store_supported (vectype

Re: Memory leaks in compiler

[Ira Rosen]

Hi,

[EMAIL PROTECTED] wrote on 16/01/2008 15:20:00:

> > When a loop is vectorized, some statements are removed from the basic
> > blocks, but the vectorizer information attached to these BBs is never
> > freed.
>
> Sebastian, thanks for bringing this to our attention. I'll look into
this.
> I hope that removing stmts from a BB can be easily localized.
> -- Victor
>

The attached patch, mainly written by Victor, fixes memory leaks in the
vectorizer, that were found with the help of valgrind and by examining the
code.

Bootstrapped with vectorization enabled and tested on vectorizer testsuite
on ppc-linux. I still have to perform full regtesting.

Is it O.K. for 4.3? Or will it wait for 4.4?

Thanks,.
Victor and Ira

ChangeLog:

  * tree-vectorizer.c (free_stmt_vec_info): New function.
  (destroy_loop_vec_info): Move code to free_stmt_vec_info().):
  Call free_stmt_vec_info(). Free LOOP_VINFO_STRIDED_STORES.
  * tree-vectorizer.h (free_stmt_vec_info): Declare.
  * tree-vect-transform.c (vectorizable_conversion): Free
  vec_oprnds0 if it was allocated.
  (vect_permute_store_chain): Remove unused VECs.
  (vectorizable_store): Free VECs that are allocated in the
  function.
  (vect_transform_strided_load, vectorizable_load): Likewise.
  (vect_remove_stores): Simplify the code.
  (vect_transform_loop): Move code to vect_remove_stores().
  Call vect_remove_stores() and free_stmt_vec_info().


(See attached file: memleaks.txt)





Index: tree-vectorizer.c
===
--- tree-vectorizer.c   (revision 131899)
+++ tree-vectorizer.c   (working copy)
@@ -1558,6 +1558,22 @@ new_stmt_vec_info (tree stmt, loop_vec_i
 }
 
 
+/* Free stmt vectorization related info.  */
+
+void
+free_stmt_vec_info (tree stmt)
+{
+  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+
+  if (!stmt_info)
+return;
+
+  VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
+  free (stmt_info);
+  set_stmt_info (stmt_ann (stmt), NULL);
+}
+
+
 /* Function bb_in_loop_p
 
Used as predicate for dfs order traversal of the loop bbs.  */
@@ -1714,21 +1730,13 @@ destroy_loop_vec_info (loop_vec_info loo
 {
   basic_block bb = bbs[j];
   tree phi;
-  stmt_vec_info stmt_info;
 
   for (phi = phi_nodes (bb); phi; phi = PHI_CHAIN (phi))
-{
-  stmt_ann_t ann = stmt_ann (phi);
-
-  stmt_info = vinfo_for_stmt (phi);
-  free (stmt_info);
-  set_stmt_info (ann, NULL);
-}
+free_stmt_vec_info (phi);
 
   for (si = bsi_start (bb); !bsi_end_p (si); )
{
  tree stmt = bsi_stmt (si);
- stmt_ann_t ann = stmt_ann (stmt);
  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
 
  if (stmt_info)
@@ -1746,9 +1754,7 @@ destroy_loop_vec_info (loop_vec_info loo
}

  /* Free stmt_vec_info.  */
- VEC_free (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmt_info));
- free (stmt_info);
- set_stmt_info (ann, NULL);
+ free_stmt_vec_info (stmt);
 
  /* Remove dead "pattern stmts".  */
  if (remove_stmt_p)
@@ -1767,6 +1773,7 @@ destroy_loop_vec_info (loop_vec_info loo
   for (j = 0; VEC_iterate (slp_instance, slp_instances, j, instance); j++)
 vect_free_slp_tree (SLP_INSTANCE_TREE (instance));
   VEC_free (slp_instance, heap, LOOP_VINFO_SLP_INSTANCES (loop_vinfo));
+  VEC_free (tree, heap, LOOP_VINFO_STRIDED_STORES (loop_vinfo));
 
   free (loop_vinfo);
   loop->aux = NULL;
Index: tree-vectorizer.h
===
--- tree-vectorizer.h   (revision 131899)
+++ tree-vectorizer.h   (working copy)
@@ -667,6 +667,7 @@ extern bool supportable_narrowing_operat
 extern loop_vec_info new_loop_vec_info (struct loop *loop);
 extern void destroy_loop_vec_info (loop_vec_info, bool);
 extern stmt_vec_info new_stmt_vec_info (tree stmt, loop_vec_info);
+extern void free_stmt_vec_info (tree stmt);
 
 
 /** In tree-vect-analyze.c  **/
Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 131899)
+++ tree-vect-transform.c   (working copy)
@@ -3638,6 +3638,9 @@ vectorizable_conversion (tree stmt, bloc
   *vec_stmt = STMT_VINFO_VEC_STMT (stmt_info);
 }
 
+  if (vec_oprnds0)
+VEC_free (tree, heap, vec_oprnds0); 
+
   return true;
 }
 
@@ -4589,11 +4592,8 @@ vect_permute_store_chain (VEC(tree,heap)
   tree scalar_dest, tmp;
   int i;
   unsigned int j;
-  VEC(tree,heap) *first, *second;
   
   scalar_dest = GIMPLE_STMT_OPERAND (stmt, 0);
-  first = VEC_alloc (tree, heap, length/2);
-  second = VEC_alloc (tree, heap, length/2);
 
   /* Check that the operation is supported.  */
   if (!vect_strided_store_supported (vectype))
@@ -4976,6 +4976,11 @@ vectorizable_store (tree stmt, block_stm
}
 

Announce: MPFR 2.3.1 is released

[Vincent Lefevre]

MPFR 2.3.1 is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-2.3.1/

Thanks very much to those who sent us bug reports (in particular
Kevin Rauch) and/or tested the release candidates.

The MD5's:
8352b619e04dcc73411a38b39dd855f6  mpfr-2.3.1.tar.bz2
cf882c61f5da60c9f3a61746b8264dd2  mpfr-2.3.1.tar.gz
68697aff6cc4eda7186aaf262f6f56c7  mpfr-2.3.1.zip

Changes from version 2.3.0 to version 2.3.1:
- Changes in the behavior of mpfr_strtofr and in its documentation
  concerning particular cases where the code and the documentation
  did not match.
- Bug fixes; see .
- Configure test for TLS support.
- Improved MPFR manual.

You can send success and failure reports to <[EMAIL PROTECTED]>, and
give us the canonical system name as returned by the config.guess
script, the processor and compiler version, in order to complete
the "Platforms Known to Support MPFR" section of the MPFR 2.3.1
web page.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Fwd: _Unwind_Resume on the stack

[Pavan R]

No, We have compiled our application on RHEL 3 with libgcc-3.2.3-34.


On Jan 29, 2008 3:44 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
> Pavan R wrote:
> > Hi,
> >
> >  We find our application dumps core on Suse 10 SP1 that has
> > libgcc-4.1.2_20070115-0.11 shipped,  with the top of the stack as :
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0 0xf7aca09c in memcpy () from /lib/libc.so.6
> > (gdb) bt
> > #0 0xf7aca09c in memcpy () from /lib/libc.so.6
> > #1 0x08050a84 in uw_install_context_1 ()
> > #2 0x08050efc in _Unwind_Resume ()
> >
> > The findings are that, by having /lib/libgcc_s.so.1 replaced with the
> > version : libgcc42-4.2.1_20070724-17 we
> > got around with the issue.
> >
> > Can anyone plz point us to any related bugs fixed in the mentioned
> > libgcc version related to _Unwind_Resume.
>
> Did you compile your application on the same machine on which it was
> run?
>
> Andrew.
>

Re: _Unwind_Resume on the stack

[Andrew Haley]

Pavan R wrote:

Hi,

 We find our application dumps core on Suse 10 SP1 that has
libgcc-4.1.2_20070115-0.11 shipped,  with the top of the stack as :

Program terminated with signal 11, Segmentation fault.
#0 0xf7aca09c in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xf7aca09c in memcpy () from /lib/libc.so.6
#1 0x08050a84 in uw_install_context_1 ()
#2 0x08050efc in _Unwind_Resume ()

The findings are that, by having /lib/libgcc_s.so.1 replaced with the
version : libgcc42-4.2.1_20070724-17 we
got around with the issue.

Can anyone plz point us to any related bugs fixed in the mentioned
libgcc version related to _Unwind_Resume.


Did you compile your application on the same machine on which it was
run?

Andrew.

_Unwind_Resume on the stack

[Pavan R]

Hi,

 We find our application dumps core on Suse 10 SP1 that has
libgcc-4.1.2_20070115-0.11 shipped,  with the top of the stack as :

Program terminated with signal 11, Segmentation fault.
#0 0xf7aca09c in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xf7aca09c in memcpy () from /lib/libc.so.6
#1 0x08050a84 in uw_install_context_1 ()
#2 0x08050efc in _Unwind_Resume ()

The findings are that, by having /lib/libgcc_s.so.1 replaced with the
version : libgcc42-4.2.1_20070724-17 we
got around with the issue.

Can anyone plz point us to any related bugs fixed in the mentioned
libgcc version related to _Unwind_Resume.

Thanks in advance,
  - Pavan.