Re: PATCH: PR boehm-gc/48299: FAIL: boehm-gc.c/thread_leak_test.c

2012-02-25 Thread Jack Howarth
On Thu, Feb 23, 2012 at 10:35:05PM -0500, Patrick Marlier wrote:
> On 02/23/2012 09:34 PM, Jack Howarth wrote:
>> On Thu, Feb 23, 2012 at 02:14:17PM -0500, Patrick Marlier wrote:
>>> On 02/23/2012 02:04 PM, Patrick Marlier wrote:
 Hello,

 As I see in my x86_64/linux gcc build and for example recently in:
 http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg02269.html

 === boehm-gc tests ===
 Running target unix/-m32
 FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors)
 === boehm-gc Summary for unix/-m32 ===
 Running target unix
 FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors)

 due to redefinition of GC_LINUX_THREADS.

 Any reason why this patch was not applied?
 http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01903.html

 Thanks!
 --
 Patrick
>>>
>>> Also note that the trunk boehm-gc seems to be fixed like this:
>>>
>>> Index: testsuite/boehm-gc.c/thread_leak_test.c
>>> ===
>>> --- testsuite/boehm-gc.c/thread_leak_test.c (revision 184398)
>>> +++ testsuite/boehm-gc.c/thread_leak_test.c (working copy)
>>> @@ -1,4 +1,7 @@
>>> -#define GC_LINUX_THREADS
>>> +#ifndef GC_THREADS
>>> +# define GC_THREADS
>>> +#endif
>>> +
>>>   #include "leak_detector.h"
>>>   #include
>>>   #include
>>
>> Patrick,
>> This form still randomly fails on x86_64-apple-darwin11 with the
>> logged output of...
>>
>> Setting LD_LIBRARY_PATH to 
>> .:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/./boehm-gc/.libs:.libs:.:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/./boehm-gc/.libs:.libs
>> Leaked composite object at 0x10192bfe0 
>> (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15,
>>  sz=4, NORMAL)
>>
>> Leaked composite object at 0x10192bf80 
>> (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15,
>>  sz=4, NORMAL)
>>
>> Leaked composite object at 0x10192bfb0 
>> (/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120223/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:15,
>>  sz=4, NORMAL)
>>
>> Leaked composite object at start: 0x10192bf90, appr. length: 48
>>
>> when the test hangs.
>>  Jack
>
> This is another problem (related to darwin) as discussed in PR48299.
> You should try the bdwgc trunk (https://github.com/ivmai/bdwgc/) and see  
> if the test passes. It could give a indication if it is still an  
> unsolved issue or not.

Patrick,
The failures in the /thread_leak_test execution tests don't occur in
ivmai-bdwgc-8b168d0 from upstream on darwin. The attached patch is the
minimal changes which need to be backported from upstream for this test.
I've left out the MS Windows specific changes from upstream but the
rest seem rational to backport. Using this patch, the resulting 
thread_leak_test at -m64 on x86_64-apple-darwin11 never fails.
   Jack

>
> Patrick.
Index: testsuite/boehm-gc.c/thread_leak_test.c
===
--- testsuite/boehm-gc.c/thread_leak_test.c (revision 184568)
+++ testsuite/boehm-gc.c/thread_leak_test.c (working copy)
@@ -1,13 +1,17 @@
-#define GC_LINUX_THREADS
+
+#ifndef GC_THREADS
+# define GC_THREADS
+#endif
+
 #include "leak_detector.h"
+
 #include 
+
 #include 
 
 void * test(void * arg) {
 int *p[10];
 int i;
-GC_find_leak = 1; /* for new collect versions not compiled  */
-/* with -DFIND_LEAK.*/
 for (i = 0; i < 10; ++i) {
 p[i] = malloc(sizeof(int)+i);
 }
@@ -15,25 +19,53 @@ void * test(void * arg) {
 for (i = 1; i < 10; ++i) {
 free(p[i]);
 }
-}   
+#   ifdef GC_PTHREADS
+  return arg;
+#   else
+  return (DWORD)(GC_word)arg;
+#   endif
+}
 
 #define NTHREADS 5
 
-int main() {
+int main(void) {
 int i;
-pthread_t t[NTHREADS];
+#   ifdef GC_PTHREADS
+  pthread_t t[NTHREADS];
+#   else
+  HANDLE t[NTHREADS];
+  DWORD thread_id;
+#   endif
 int code;
 
+GC_find_leak = 1; 
+ /* with -DFIND_LEAK.   */
+GC_INIT();
+
 for (i = 0; i < NTHREADS; ++i) {
-   if ((code = pthread_create(t + i, 0, test, 0)) != 0) {
-   printf("Thread creation failed %d\n", code);
+#   ifdef GC_PTHREADS
+  code = pthread_create(t + i, 0, test, 0);
+#   else
+  t[i] = CreateThread(NULL, 0, test, 0, 0, &thread_id);
+  code = t[i] != NULL ? 0 : (int)GetLastError();
+#   endif
+if (code != 0) {
+printf("Thread creation failed %d\n", code);
 }
 }
+
 for (i = 0; i < NTHREADS; ++i) {
-   if ((code = pthread_join(t[i], 0)) != 0) {
-pr

Bootstrapping and C++ compiler

2012-02-25 Thread Gabriel Dos Reis
Hi,

Now that we build the C-family compilers with a C++ compiler by
default, is the changed documented anywhere?  I looked
at the "installation" part of the manual but I could not find anything
there.  I looked at the wiki page, but many things there seem not
to be updated.  Where should I have looked?  Thanks,

--Gaby


optimization report

2012-02-25 Thread Mahmood Naderan
Hi
Does GCC report on optimizations? I mean, using -O3, it is good to see which 
part of code was the hardest part in optimization process. Or a report that 
shows which part of code used largest memory.

 
// Naderan *Mahmood;


Re: optimization report

2012-02-25 Thread Jonathan Wakely
On 25 February 2012 19:06, Mahmood Naderan wrote:
>
> Does GCC report on optimizations? I mean, using -O3, it is good to see which 
> part of code was the hardest part in optimization process. Or a report that 
> shows which part of code used largest memory.

Have you looked at -fmem-report and -ftime-report?  Both are
documented in the manual.

(This isn't really appropriate for the gcc@ list, any further
questions about using GCC should probably only go to the gcc-help@
list.)


Re: Bootstrapping and C++ compiler

2012-02-25 Thread Marc Glisse

On Sat, 25 Feb 2012, Gabriel Dos Reis wrote:


Now that we build the C-family compilers with a C++ compiler by
default, is the changed documented anywhere?  I looked
at the "installation" part of the manual but I could not find anything
there.  I looked at the wiki page, but many things there seem not
to be updated.  Where should I have looked?  Thanks,


configure.html does say:
--enable-build-poststage1-with-cxx
When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
rather than a C compiler. Stage 1 is still built with a C compiler.
This is enabled by default and may be disabled using
--disable-build-poststage1-with-cxx.

There are other hints like the default value of --with-boot-ldflags which 
includes -static-libstdc++.


build.html doesn't say anything. Options have to be passed through 
BOOT_CFLAGS which doesn't look much like CXX, but then it doesn't matter.


--
Marc Glisse


gcc-4.7-20120225 is now available

2012-02-25 Thread gccadmin
Snapshot gcc-4.7-20120225 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120225/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 184577

You'll find:

 gcc-4.7-20120225.tar.bz2 Complete GCC

  MD5=b906a1595b3b55c637b32d0e8ff8254c
  SHA1=4ab45c57f8c35c03d0a97948dc8a47d871087665

Diffs from 4.7-20120218 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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.