Puzzle about CFG on rtl during delay slot schedule

[Amker.Cheng]

Hi :
   I'm wondering whether cfg is maintained properly during delay slot
scheduling,
Because when compiling libgcc/_divsc3.o, rtl dump in
libgcc2.c.198r.mach has following lines:

no bb for insn with uid = 293.
deleting insn with uid = 690.
deleting insn with uid = 904.
..

(note 298 905 303 [bb 25] NOTE_INSN_BASIC_BLOCK)

(note 303 298 304 [bb 26] NOTE_INSN_BASIC_BLOCK)
-cut here

after that pass, bb 25 still has il.rtl->head_ == insn_uid_690, which
has already deleted.
Seems the bb's head_/tail_ are not handled properly.

I traced cc1 and found it deleted insn_690 by function remove_insn,
It seems that the end the function takes BB_HEAD/BB_END into
consider, But the BLOCK_FOR_INSN(insn_690) is null, which results in
the problem.

BTW, the version working on is gcc-4.4.1, mips target.
So, any tips? Thanks very much.

-- 
Best Regards.

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

On Fri, Apr 2, 2010 at 11:28 AM, Amker.Cheng  wrote:
> Hi :
>   I'm wondering whether cfg is maintained properly during delay slot
> scheduling,

The CFG is not maintained during delay slot scheduling. This is, in
fact, a very old and well-known problem. Look for any e-mail on this
list that mentions reorg.c :-)

Ciao!
Steven

Fwd: Puzzle about CFG on rtl during delay slot schedule

[Amker.Cheng]

> The CFG is not maintained during delay slot scheduling. This is, in
> fact, a very old and well-known problem. Look for any e-mail on this
> list that mentions reorg.c :-)
>
Thanks, further more , It seems cfg are not maintained after delay
slot scheduling.
also find that problem just before final pass.


-- 
Best Regards.

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

On Fri, Apr 2, 2010 at 12:41 PM, Amker.Cheng  wrote:
>> The CFG is not maintained during delay slot scheduling. This is, in
>> fact, a very old and well-known problem. Look for any e-mail on this
>> list that mentions reorg.c :-)
>>
> Thanks, further more , It seems cfg are not maintained after delay
> slot scheduling.
> also find that problem just before final pass.

Yes. The CFG is constructed on GIMPLE and then maintained all the way
through to reorg.c (or actually pass_free_cfg). Once destroyed, we
cannot resurrect the CFG.

In a perfect world, reorg.c would get a rewrite and we'd maintain the
CFG all the way through to final. But in practice, reorg.c is not the
only problem (for example, var-tracking also destroys the CFG, as do
most machine reorgs).

Ciao!
Steven

default_weaktoshared timeouts

[Jack Howarth]

   I have noticed a tendency for timeouts to occur
in the 20_util/shared_ptr/thread/default_weaktoshared.cc...

Executing on host: 
/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc/g++ 
-shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc 
-nostdinc++ 
-L/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/libstdc++-v3/src
 
-L/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/libstdc++-v3/src/.libs
 -B/sw/lib/gcc4.5/i686-apple-darwin10/bin/ 
-B/sw/lib/gcc4.5/i686-apple-darwin10/lib/ -isystem 
/sw/lib/gcc4.5/i686-apple-darwin10/include -isystem 
/sw/lib/gcc4.5/i686-apple-darwin10/sys-include 
-B/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/./libstdc++-v3/src/.libs
 -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections 
-fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ 
-I/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/libstdc++-v3/include/i686-apple-darwin10
 
-I/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/libstdc++-v3/include
 
-I/sw/src/fink.build/gcc45-4.4.999-20100401/gcc-4.5-20100401/libstdc++-v3/libsupc++
 
-I/sw/src/fink.build/gcc45-4.4.999-20100401/gcc-4.5-20100401/libstdc++-v3/include/backward
 
-I/sw/src/fink.build/gcc45-4.4.999-20100401/gcc-4.5-20100401/libstdc++-v3/testsuite/util
 
/sw/src/fink.build/gcc45-4.4.999-20100401/gcc-4.5-20100401/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
-std=gnu++0x  ./libtestc++.a -L/sw/lib -liconv  -lm   -o 
./default_weaktoshared.exe(timeout = 600)
PASS: 20_util/shared_ptr/thread/default_weaktoshared.cc (test for excess errors)
Setting LD_LIBRARY_PATH to 
:/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/gcc:/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/./libstdc++-v3/../libgomp/.libs:/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/./libstdc++-v3/src/.libs::/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/gcc:/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/./libstdc++-v3/../libgomp/.libs:/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/i686-apple-darwin10/./libstdc++-v3/src/.libs
WARNING: program timed out.
FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
extra_tool_flags are:
  -std=gnu++0x 

Is there a PR related to this and if not shouldn't one be opened?
It does appear to be a random problem though.
  Jac

Re: default_weaktoshared timeouts

[Paolo Carlini]

On 04/02/2010 02:09 PM, Jack Howarth wrote:
> Is there a PR related to this and if not shouldn't one be opened?
>   
I never times out for me on x86 and x86_64-linux. Thus, if you want to
open one, I would suggest a target PR. Jon may know better...

Paolo.

Re: default_weaktoshared timeouts

[Jack Howarth]

On Fri, Apr 02, 2010 at 02:15:05PM +0200, Paolo Carlini wrote:
> On 04/02/2010 02:09 PM, Jack Howarth wrote:
> > Is there a PR related to this and if not shouldn't one be opened?
> >   
> I never times out for me on x86 and x86_64-linux. Thus, if you want to
> open one, I would suggest a target PR. Jon may know better...
> 
> Paolo.

Paolo,
   I don't believe this occurs with the x86_64-apple-darwin10
target but only with i686-apple-darwin10 so it may well be
a bug in the 32-bit linker on darwin. I'll try benchmarking the
actual linkage command at both 32-bit and 64-bit to see if
it can be reproduced. If so, I'll file a radar bug report.
  Jack

Re: Puzzle about CFG on rtl during delay slot schedule

[Jeff Law]

On 04/02/10 05:26, Steven Bosscher wrote:


Yes. The CFG is constructed on GIMPLE and then maintained all the way
through to reorg.c (or actually pass_free_cfg). Once destroyed, we
cannot resurrect the CFG.

In a perfect world, reorg.c would get a rewrite and we'd maintain the
CFG all the way through to final. But in practice, reorg.c is not the
only problem (for example, var-tracking also destroys the CFG, as do
most machine reorgs).
   
And that rewrite would use standard, well known & understood dependence 
analysis.  reorg's methods for determine what insns can go into delay 
slots is utterly insane and can get extremely expensive.


jeff

Re: Puzzle about CFG on rtl during delay slot schedule

[Steven Bosscher]

On Fri, Apr 2, 2010 at 4:26 PM, Jeff Law  wrote:
> On 04/02/10 05:26, Steven Bosscher wrote:
>>
>> Yes. The CFG is constructed on GIMPLE and then maintained all the way
>> through to reorg.c (or actually pass_free_cfg). Once destroyed, we
>> cannot resurrect the CFG.
>>
>> In a perfect world, reorg.c would get a rewrite and we'd maintain the
>> CFG all the way through to final. But in practice, reorg.c is not the
>> only problem (for example, var-tracking also destroys the CFG, as do
>> most machine reorgs).
>>
>
> And that rewrite would use standard, well known & understood dependence
> analysis.  reorg's methods for determine what insns can go into delay slots
> is utterly insane and can get extremely expensive.

Indeed!

But before anyone starts such an effort (IIUC one of the new MIPS
people was thinking of this), right now it makes no sense to rewrite
reorg.c because the CFG is already broken even before that point. The
var-tracking changes from Alexandre and Jakub insert DEBUG_INSNs and
NOTEs in the wrong place so that verify_flow_info() already doesn't
pass anymore even before pass_free_cfg.

Plus, the machine reorgs need rewriting. There are already some
machine reorgs that resurrect the CFG (they can -- as long as you
don't verify_flow_info()), because they run right after
pass_free_cfg). I have patches to have an pass_early_free_cfg and a
pass_late_free_cfg that I intend to submit for GCC 4.6. Once I figure
out how to fix var-tracking, anyway...

Cheng, can you explain what lead you to this "discovery", and what
you're trying to achieve?

Ciao!
Steven

Re: default_weaktoshared timeouts

[Jonathan Wakely]

On 2 April 2010 14:12, Jack Howarth wrote:
>
> Paolo,
>   I don't believe this occurs with the x86_64-apple-darwin10
> target but only with i686-apple-darwin10 so it may well be
> a bug in the 32-bit linker on darwin. I'll try benchmarking the
> actual linkage command at both 32-bit and 64-bit to see if
> it can be reproduced. If so, I'll file a radar bug report.

It's running the test that is timing out rather than the linker
command.  It would be helpful to know if the test is actually stuck,
or just running so slowly it times out and gets killed.

Can you reproduce it just by building the attached file with
-std=gnu++0x and running it in a loop?  This is just a standalone copy
of the testsuite that doesn't need the testsuite_hooks.h header.  If
it is getting stuck please CC me on a bug report.

Thanks,

Jonathan
// Copyright (C) 2006, 2007, 2008, 2009 Free Software Foundation
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.

// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.

// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING3.  If not see
// .

// 20.6.6.2 Template class shared_ptr [util.smartptr.shared]

// { dg-do run { target *-*-freebsd* *-*-netbsd* *-*-linux* *-*-solaris* *-*-cygwin *-*-darwin* alpha*-*-osf* mips-sgi-irix6* } }
// { dg-options "-pthread -std=gnu++0x" { target *-*-freebsd* *-*-netbsd* *-*-linux* alpha*-*-osf* mips-sgi-irix6* } }
// { dg-options "-pthreads -std=gnu++0x" { target *-*-solaris* } }
// { dg-options " -std=gnu++0x " { target *-*-cygwin *-*-darwin* } }

#include 
#include 
#include 
#include 
#define VERIFY assert
#include 
#include 

#include 

#ifdef _GLIBCXX_HAVE_UNISTD_H
#include 	// To test for _POSIX_THREAD_PRIORITY_SCHEDULING
#endif

/* This (brute-force) tests the atomicity and thus thread safety of the
 * shared_ptr <- weak_ptr
 * assignment operation by allocating a test object, retrieving a weak
 * reference to it, and letting a number of threads repeatedly create strong
 * references from the weak reference.
 * Specifically, this tests the function _Sp_counted_base::add_ref_lock()
 */


const unsigned int HAMMER_MAX_THREADS = 10;
const unsigned int POOL_SIZE = 1000;
const unsigned long HAMMER_REPEAT = 10;
const unsigned long KILL_ONE_IN = 1000;

struct A
  {
static _Atomic_word counter;
A()
  {
	__gnu_cxx::__atomic_add(&counter, 1);
  }
~A()
  {
	__gnu_cxx::__atomic_add(&counter, -1);
  }
  };

_Atomic_word A::counter = 0;

typedef std::shared_ptr sp_A_t;
typedef std::weak_ptr wp_A_t;

typedef std::vector sp_vector_t;
typedef std::vector wp_vector_t;

struct shared_and_weak_pools
{
  sp_vector_t& shared_pool;
  wp_vector_t& weak_pool;
  
  shared_and_weak_pools(sp_vector_t& _shared_pool, wp_vector_t& _weak_pool)
: shared_pool(_shared_pool), weak_pool(_weak_pool)
{ }
};

void* thread_hammer_and_kill(void* opaque_pools)
{
  shared_and_weak_pools& pools = *static_cast(opaque_pools);
  // Using the same parameters as in the RNG test cases.
  std::mersenne_twister_engine<
unsigned long, 32, 624, 397, 31,
0x9908b0dful, 11,
0xul, 7,
0x9d2c5680ul, 15,
0xefc6ul, 18, 1812433253ul> rng;
  
  sp_vector_t::iterator cur_shared = pools.shared_pool.begin();
  wp_vector_t::iterator cur_weak = pools.weak_pool.begin();
  
  for (unsigned int i = 0; i < HAMMER_REPEAT; ++i)
{
  try
  {
sp_A_t strong(*cur_weak);
  }
  catch (std::bad_weak_ptr& exception)
  {
++cur_weak;
if (cur_weak == pools.weak_pool.end())
  break;
  }
  
  if (rng() % KILL_ONE_IN == 0)
  {
cur_shared->reset();
++cur_shared;
  }
}
  return 0;
}

void* thread_hammer(void* opaque_weak)
{
  wp_vector_t& weak_pool = *static_cast(opaque_weak);
  // Using the same parameters as in the RNG test cases.
  std::mersenne_twister_engine<
unsigned long, 32, 624, 397, 31,
0x9908b0dful, 11,
0xul, 7,
0x9d2c5680ul, 15,
0xefc6ul, 18, 1812433253ul> rng;

  wp_vector_t::iterator cur_weak = weak_pool.begin();

  for (unsigned int i = 0; i < HAMMER_REPEAT; ++i)
{
  try
  {
sp_A_t strong(*cur_weak);
  }
  catch (std::bad_weak_ptr& exception)
  {
++cur_weak;
if (cur_weak == weak_pool.end())
  break;
  }
}
  return 0;
}

int
test01()
{
  bool test __attribute__((unused)) = true;
  sp_vector_t obj_pool(POOL_SIZE);
  
  for(sp_vector_t::iterator cur = obj_po

site.exp and newlib_ldflags

[Joel Sherrill]

Hi,

I ran into a lot of GCC test failures on a
Coldfire target board which did not use the default
multilib.  When I investigated, it turned out
that this line in the site.exp rule in gcc/Makefile.in
was causing it to link the default 68020
multilib instead of the right Coldfire one.

 echo "set newlib_ldflags \"-B$(objdir)/../$(target_subdir)/newlib/\"" 
>> ./tmp0; \


My solution was to ignore the variable
newlib_ldflags in my board.exp file.  But
this seems like a broader issue and that
I might have missed something.

Does the above need to be multilib aware?

Is there a trick I missed?

Is it a bug?

--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: gmp 5.0.1 and gcc 4.5?

[Roman Kononov]

On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth
 wrote:

>I've not seen any discussion of testing gcc trunk
> against the newer gmp 5.0 or 5.0.1 releases. Has anyone
> done significant testing with the newer gmp releases
> ... ?

I use gcc 4.4.4 and 4.5.0 with gmp 5.0.1. I compile and use PostgreSQL
and other stuff, and have not noticed any misbehavior related to gmp or
mpfr. Although, I cannot say that I use gcc in a way that makes a lot
of gmp or mpfr testing.

Re: question about copy right assignment form

[David Edelsohn]

On Thu, Apr 1, 2010 at 11:56 PM, Michael Han  wrote:
> Hello,
>
> May I know where or whom should I contact to obtain the copyright
> assignment form? I want to contribute some code to gcc so I think
> having these forms in place earlier would be a good idea.

Assignment request form sent privately.

> Another question is I am working full time for a software company and
> the job is irrelevant to compiler development. I spend my spare time
> with gcc so I don't think the company owns my work but I am not sure..
> In this case, should I also obtain and sign the employer disclaimer
> form?

As you said, it depends on the disposition of your work.  If your
company owns all of your programming work, especially if you do any
work on GCC using company equipment, even if not part of your official
duties, you need an employer disclaimer.

David

Help with an Wierd Error

[Balaji.Iyer]

Hello Everyone,
  I am trying to build an OpenRISC port of GCC. I am not getting much 
response from the OR32 people, and this error sounds a bit generic from google 
searches so I thought if someone would know how to solve it.

I build binutils, gcc and newlib  as they mentioned in the or32 website. But 
now I am getting this wierd error when I am trying to compile "Hello World" 
program

==
or32-elf-gcc -v /tmp/test.c
Reading specs from /opt/or32/lib/gcc/or32-elf/4.2.2/specs
Target: or32-elf
Configured with: ../gcc-4.2.2/configure --target=or32-elf --prefix=/opt/or32 
--with-gnu-as --with-gnu-ld --disable-libssp --with-newlib --enable-languages=c 
--disable-checking
Thread model: single
gcc version 4.2.2
 /opt/or32/libexec/gcc/or32-elf/4.2.2/cc1 -quiet -v test.c -quiet -dumpbase 
test.c -auxbase test -version -o 
/var/folders/kX/kXco8IKOGbKCP9ef7v-8KTI/-Tmp-//cch1Gb3x.s
ignoring nonexistent directory 
"/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/or32/lib/gcc/or32-elf/4.2.2/include
 /opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/include
End of search list.
GNU C version 4.2.2 (or32-elf)
compiled by GNU C version 4.2.1 (Apple Inc. build 5646) (dot 1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9e4259fc872a297ae129c5bc285bd4ea
 /opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/bin/as -o 
/var/folders/kX/kXco8IKOGbKCP9ef7v-8KTI/-Tmp-//ccMYERCM.o 
/var/folders/kX/kXco8IKOGbKCP9ef7v-8KTI/-Tmp-//cch1Gb3x.s
 /opt/or32/libexec/gcc/or32-elf/4.2.2/collect2 
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/crt0.o 
-L/opt/or32/lib/gcc/or32-elf/4.2.2 
-L/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib 
/var/folders/kX/kXco8IKOGbKCP9ef7v-8KTI/-Tmp-//ccMYERCM.o -lgcc -lc -lgcc 
-lor32 -lc -lgcc -lc -lor32
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/crt0.o: In function 
`loop':
(.text+0x54): undefined reference to `_stack'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/crt0.o: In function 
`loop':
(.text+0x64): undefined reference to `___bss_start'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/crt0.o: In function 
`loop':
(.text+0x6c): undefined reference to `__end'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/libc.a(lib_a-findfp.o):
 In function `__sfmoreglue':
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdio/../../../../../gcc-4.2.2/newlib/libc/stdio/findfp.c:88:
 undefined reference to `___mulsi3'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/libor32.a(sbrk.o): In 
function `sbrk':
/home_dir/Research/OpenRISC/b-gcc/or32-elf/libgloss/or32/../../../../gcc-4.2.2/libgloss/or32/sbrk.c:37:
 undefined reference to `__stack'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/libgloss/or32/../../../../gcc-4.2.2/libgloss/or32/sbrk.c:35:
 undefined reference to `__end'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/libc.a(lib_a-vfprintf.o):
 In function `_vfprintf_r':
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdio/../../../../../gcc-4.2.2/newlib/libc/stdio/vfprintf.c:1314:
 undefined reference to `___umodsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdio/../../../../../gcc-4.2.2/newlib/libc/stdio/vfprintf.c:1315:
 undefined reference to `___udivsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdio/../../../../../gcc-4.2.2/newlib/libc/stdio/vfprintf.c:1597:
 undefined reference to `___modsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdio/../../../../../gcc-4.2.2/newlib/libc/stdio/vfprintf.c:1598:
 undefined reference to `___divsi3'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/libc.a(lib_a-dtoa.o): 
In function `quorem':
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/dtoa.c:60:
 undefined reference to `___udivsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/dtoa.c:73:
 undefined reference to `___mulsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/dtoa.c:74:
 undefined reference to `___mulsi3'
/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/libc.a(lib_a-mprec.o):
 In function `__multiply':
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/mprec.c:366:
 undefined reference to `___mulsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/mprec.c:368:
 undefined reference to `___mulsi3'
/home_dir/Research/OpenRISC/b-gcc/or32-elf/newlib/libc/stdlib/../../../../../gcc-4.2.2/newlib/libc/stdlib/mprec.c:383:
 undefined reference to `___mulsi3'
/opt/or32/lib/gcc/or32-elf/4.2

8x compilation time increase after r157834

[Roman Kononov]

Hi,

r157834 of the trunk made compilation time almost 8(eight!) times
longer. The time went from 38 to 291 seconds.

$ svnversion ~/src/gcc
157833
$ make -C ~/src/gcc install
...
$ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
-Wno-parentheses -I../ check.cpp -o check -MMD -lrt
37.65user 0.56system 0:38.26elapsed 99%CPU (0avgtext+0avgdata \
0maxresident)k
0inputs+0outputs (0major+85545minor)pagefaults 0swaps

$ svnversion ~/src/gcc
157834
$ make -C ~/src/gcc install
...
$ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
-Wno-parentheses -I../ check.cpp -o check -MMD -lrt
290.90user 0.63system 4:51.56elapsed 99%CPU (0avgtext+0avgdata \
0maxresident)k
0inputs+0outputs (0major+101971minor)pagefaults 0swaps

$ g++ -dumpmachine
x86_64-unknown-linux-gnu

Configured by
$ ./configure --prefix=$HOME/gcc --disable-multilib

Would it be acceptable to revert c157834 or it fixes an important bug?
It is unclear from the commit log message and the 43593 bugzilla report.
I did not notice any influence of c157834 to the compiled program
performance.

Thanks,

Roman

Re: 8x compilation time increase after r157834

[Richard Guenther]

On Fri, Apr 2, 2010 at 8:47 PM, Roman Kononov  wrote:
> Hi,
>
> r157834 of the trunk made compilation time almost 8(eight!) times
> longer. The time went from 38 to 291 seconds.
>
> $ svnversion ~/src/gcc
> 157833
> $ make -C ~/src/gcc install
> ...
> $ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
> -Wno-parentheses -I../ check.cpp -o check -MMD -lrt
> 37.65user 0.56system 0:38.26elapsed 99%CPU (0avgtext+0avgdata \
> 0maxresident)k
> 0inputs+0outputs (0major+85545minor)pagefaults 0swaps
>
> $ svnversion ~/src/gcc
> 157834
> $ make -C ~/src/gcc install
> ...
> $ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
> -Wno-parentheses -I../ check.cpp -o check -MMD -lrt
> 290.90user 0.63system 4:51.56elapsed 99%CPU (0avgtext+0avgdata \
> 0maxresident)k
> 0inputs+0outputs (0major+101971minor)pagefaults 0swaps
>
> $ g++ -dumpmachine
> x86_64-unknown-linux-gnu
>
> Configured by
> $ ./configure --prefix=$HOME/gcc --disable-multilib
>
> Would it be acceptable to revert c157834 or it fixes an important bug?
> It is unclear from the commit log message and the 43593 bugzilla report.
> I did not notice any influence of c157834 to the compiled program
> performance.

The patch is about debuginfo.  Can you file a bugzilla and attach
preprocessed source for the testcase?

Thanks,
Richard.

> Thanks,
>
> Roman
>
>
>

Re: 8x compilation time increase after r157834

[Roman Kononov]

On 2010-04-02, 20:50 CDT, Richard Guenther said:
>The patch is about debuginfo.  Can you file a bugzilla and attach
>preprocessed source for the testcase?

$g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l
24526

The preprocessed source has 24526 non-blank lines. Should I attach it?
Should I make a new bugzilla or add a comment to #43593?

Thanks,

Roman

Re: 8x compilation time increase after r157834

[Richard Guenther]

On Fri, Apr 2, 2010 at 9:11 PM, Roman Kononov  wrote:
> On 2010-04-02, 20:50 CDT, Richard Guenther said:
>>The patch is about debuginfo.  Can you file a bugzilla and attach
>>preprocessed source for the testcase?
>
> $g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l
> 24526
>
> The preprocessed source has 24526 non-blank lines. Should I attach it?
> Should I make a new bugzilla or add a comment to #43593?

make a new bugzilla and attach it.

richard.

> Thanks,
>
> Roman
>

Re: default_weaktoshared timeouts

[Jack Howarth]

On Fri, Apr 02, 2010 at 06:10:29PM +0100, Jonathan Wakely wrote:
> On 2 April 2010 14:12, Jack Howarth wrote:
> >
> > Paolo,
> >   I don't believe this occurs with the x86_64-apple-darwin10
> > target but only with i686-apple-darwin10 so it may well be
> > a bug in the 32-bit linker on darwin. I'll try benchmarking the
> > actual linkage command at both 32-bit and 64-bit to see if
> > it can be reproduced. If so, I'll file a radar bug report.
> 
> It's running the test that is timing out rather than the linker
> command.  It would be helpful to know if the test is actually stuck,
> or just running so slowly it times out and gets killed.
> 
> Can you reproduce it just by building the attached file with
> -std=gnu++0x and running it in a loop?  This is just a standalone copy
> of the testsuite that doesn't need the testsuite_hooks.h header.  If
> it is getting stuck please CC me on a bug report.
> 
> Thanks,
> 
> Jonathan

> // Copyright (C) 2006, 2007, 2008, 2009 Free Software Foundation
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
> // terms of the GNU General Public License as published by the
> // Free Software Foundation; either version 3, or (at your option)
> // any later version.
> 
> // This library is distributed in the hope that it will be useful,
> // but WITHOUT ANY WARRANTY; without even the implied warranty of
> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> // GNU General Public License for more details.
> 
> // You should have received a copy of the GNU General Public License along
> // with this library; see the file COPYING3.  If not see
> // .
> 
> // 20.6.6.2 Template class shared_ptr [util.smartptr.shared]
> 
> // { dg-do run { target *-*-freebsd* *-*-netbsd* *-*-linux* *-*-solaris* 
> *-*-cygwin *-*-darwin* alpha*-*-osf* mips-sgi-irix6* } }
> // { dg-options "-pthread -std=gnu++0x" { target *-*-freebsd* *-*-netbsd* 
> *-*-linux* alpha*-*-osf* mips-sgi-irix6* } }
> // { dg-options "-pthreads -std=gnu++0x" { target *-*-solaris* } }
> // { dg-options " -std=gnu++0x " { target *-*-cygwin *-*-darwin* } }
> 
> #include 
> #include 
> #include 
> #include 
> #define VERIFY assert
> #include 
> #include 
> 
> #include 
> 
> #ifdef _GLIBCXX_HAVE_UNISTD_H
> #include// To test for _POSIX_THREAD_PRIORITY_SCHEDULING
> #endif
> 
> /* This (brute-force) tests the atomicity and thus thread safety of the
>  * shared_ptr <- weak_ptr
>  * assignment operation by allocating a test object, retrieving a weak
>  * reference to it, and letting a number of threads repeatedly create strong
>  * references from the weak reference.
>  * Specifically, this tests the function 
> _Sp_counted_base::add_ref_lock()
>  */
> 
> 
> const unsigned int HAMMER_MAX_THREADS = 10;
> const unsigned int POOL_SIZE = 1000;
> const unsigned long HAMMER_REPEAT = 10;
> const unsigned long KILL_ONE_IN = 1000;
> 
> struct A
>   {
> static _Atomic_word counter;
> A()
>   {
>   __gnu_cxx::__atomic_add(&counter, 1);
>   }
> ~A()
>   {
>   __gnu_cxx::__atomic_add(&counter, -1);
>   }
>   };
> 
> _Atomic_word A::counter = 0;
> 
> typedef std::shared_ptr sp_A_t;
> typedef std::weak_ptr wp_A_t;
> 
> typedef std::vector sp_vector_t;
> typedef std::vector wp_vector_t;
> 
> struct shared_and_weak_pools
> {
>   sp_vector_t& shared_pool;
>   wp_vector_t& weak_pool;
>   
>   shared_and_weak_pools(sp_vector_t& _shared_pool, wp_vector_t& _weak_pool)
> : shared_pool(_shared_pool), weak_pool(_weak_pool)
> { }
> };
> 
> void* thread_hammer_and_kill(void* opaque_pools)
> {
>   shared_and_weak_pools& pools = 
> *static_cast(opaque_pools);
>   // Using the same parameters as in the RNG test cases.
>   std::mersenne_twister_engine<
> unsigned long, 32, 624, 397, 31,
> 0x9908b0dful, 11,
> 0xul, 7,
> 0x9d2c5680ul, 15,
> 0xefc6ul, 18, 1812433253ul> rng;
>   
>   sp_vector_t::iterator cur_shared = pools.shared_pool.begin();
>   wp_vector_t::iterator cur_weak = pools.weak_pool.begin();
>   
>   for (unsigned int i = 0; i < HAMMER_REPEAT; ++i)
> {
>   try
>   {
> sp_A_t strong(*cur_weak);
>   }
>   catch (std::bad_weak_ptr& exception)
>   {
> ++cur_weak;
> if (cur_weak == pools.weak_pool.end())
>   break;
>   }
>   
>   if (rng() % KILL_ONE_IN == 0)
>   {
> cur_shared->reset();
> ++cur_shared;
>   }
> }
>   return 0;
> }
> 
> void* thread_hammer(void* opaque_weak)
> {
>   wp_vector_t& weak_pool = *static_cast(opaque_weak);
>   // Using the same parameters as in the RNG test cases.
>   std::mersenne_twister_engine<
> unsigned long, 32, 624, 397, 31,
> 0x9908b0dful, 11,
> 0xul, 7,
> 0x9d2c5680ul, 15,
> 0xefc6ul, 18, 1812433253ul> rng;
> 
>   wp_vector_t::iterator cur_weak = weak_pool.begin();
> 
>   for (unsigne

Re: gmp 5.0.1 and gcc 4.5?

[Allan McRae]

On 03/04/10 03:28, Roman Kononov wrote:

On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth
  wrote:

   

I've not seen any discussion of testing gcc trunk
against the newer gmp 5.0 or 5.0.1 releases. Has anyone
done significant testing with the newer gmp releases
... ?
 

I use gcc 4.4.4 and 4.5.0 with gmp 5.0.1. I compile and use PostgreSQL
and other stuff, and have not noticed any misbehavior related to gmp or
mpfr. Although, I cannot say that I use gcc in a way that makes a lot
of gmp or mpfr testing.
   



The Arch Linux toolchain was built with gmp-5.0.1 about two weeks ago 
and all software linking to gmp-4 was rebuilt with gmp-5.  We have seen 
no gmp-5 related issues so far.


Allan

Re: About behavior of -save-temps=obj option on GCC 4.5

[Tadashi Koike]

Hi Mike,

I'm sorry to spend a week to response your replay, and thank you
for explanation of -save-temps=obj specifications.

> I tend to agree with Richard, that if there are multiple source inputs, it
> should be an error to use -save-temps=obj without the -c/-S option.

I reached a true understanding, and this explanation should help
my project.

Certainly this case is not god. In this case(= multiple input
files that have same filename), compiling should became failure
neither by -save-temps=cwd nor by -save-temps=obj. It is difficult ...

However this suggestion also gave idea to help my project.

> Yes, the motivation was for doing large builds (notably spec 2006) where
> several of the files have the same base name but are in different
> subdirectories.  In particular, I could not build 436.cactusADM with -j8
> without getting conflicts (bugzilla 39293).  Even if I built it with -j1 so
> they wouldn't interfere, I would lose the asm files for some of the builds,
> which would mean my static analysis programs would miss some objects.
>
> I have also seen conflicts with -save-temps if you use have -j numbers when
> doing a compiler bootstrap.

I have sympathies with you strongly. On my project, I had same
motivation.

I have a tiny project, GAST (Gcc Automatically Save Temps).
  GAST: http://en.sourceforge.jp/projects/gast/
  (I am weak in English, so pleas forgive my English mistake in Web page)

This project provides a wrapper script to preserve intermediate
files automatically. In this project, I made an effort to preserve
intermediate files which are from source file having same base name
but in different subdirectories. To preserve all the intermediate
files and not to interfere with build process, I had to control -j
number to 1. But this is not friendly to larger builds (like a linux
 kernel building), so that I was grad when I heard about
-save-temps=obj option. I expected -save-temps=obj option to liberate
me to control -j numbers.
But in case of multiple input files, if -save-temps=obj option is
added automatically with no consideration, it interfere build process,
so I am confused.

However, I understood the specification of -save-temps=obj, and then
I had an idea for a workaround in GAST implementation. the GAST script
can detected a number of input files, so that only if GAST detected
a number of input file as 1, GAST use -save-temps=obj option (the other
hands if multiple input files are detected, GAST use -save-temps).
This method still has a small risk of interfering parallel build, but
probably it is usable in almost all the case.

I thank Michael and Richard from the bottom of my heart for your kindness.

Best regards,
Tadashi Koike

2010/3/26 Michael Meissner :
> On Thu, Mar 25, 2010 at 11:33:17PM +0900, Tadashi Koike wrote:
>> Hi Richard
>>     (* I am weak in English, so pleas forgive my English mistake.)
>>
>> Thank you for your reply, and I'm sorry to be late a reply.
>>
>> > On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike  wrote:
>> >> [ summary ]
>> >>     compiling is failed when more than two source file are
>> >>    specified with both -save-temps=obj and -o options.
>>   :
>> >>  [[ operations being error ]]
>> >>     % gcc -save-temps=obj -o hellow main.c func.c
>> >>     % gcc -save-temps=obj -o obj_dir/hellow main.c func.c
>>
>> 2010/3/21 Richard Guenther :
>> >
>> > It should be an error to use -save-temps=obj with multiple
>> > input files.  Mike, can you look at this?
>> >
>> > Thanks,
>> > Richard.
>> >
>>
>> After I received your reply, I confirm an information about 
>> "-save-temps=obj".
>
> I tend to agree with Richard, that if there are multiple source inputs, it
> should be an error to use -save-temps=obj without the -c/-S option.
>
> Though it might be friendlier to allow:
>
>        gcc -o dir/exe a.c b.c c.c
>
> and put the temp files in:
>
>        dir/a.{s,i}
>        dir/b.{s,i}
>        dir/c.{s,i}
>
> But it would fail for doing:
>
>        gcc -o exe dir1/a.c dir2/a.c
>
> where the names overlap.  Let me look at it.
>
>> In this URL(http://gcc.gnu.org/gcc-4.5/changes.html), "-save-temps=obj"
>> option are introduced as follow:
>>
>>   | The -save-temps=obj switch will write files into the directory specified
>>   | with the -o option, and the intermediate filenames are based on the
>>   | output file.
>>
>> If above is a specification of "-save-temps=obj" option, found behaviors
>> in my report about "-save-temps=obj" are true behaviors (but cannot
>> deal in case of multiple input files).
>>
>> I considered. And I read a purpose of this option in above URL :
>>
>>   | This will allow the user to get the compiler intermediate files when
>>   | doing parallel builds without two builds of the same filename located in
>>   | different directories from interfering with each other.
>>
>> My recognition is below:
>>   - True purpose is a failure of compiling under parallel builds. In detail,
>>     problem is a compiling failure  under parallel builds cause

Re: About behavior of -save-temps=obj option on GCC 4.5

[Tadashi Koike]

Sorry, I miss. follow it:

2010/4/3 Tadashi Koike :
> Hi Mike,
>
> I'm sorry to spend a week to response your replay, and thank you
> for explanation of -save-temps=obj specifications.
>
>> I tend to agree with Richard, that if there are multiple source inputs, it
>> should be an error to use -save-temps=obj without the -c/-S option.
>
> I reached a true understanding, and this explanation should help
> my project.
>

This quotation is forgotten

>> Though it might be friendlier to allow:
>>
>>gcc -o dir/exe a.c b.c c.c
>>
>> and put the temp files in:
>>
>>dir/a.{s,i}
>>dir/b.{s,i}
>>dir/c.{s,i}
>>
>> But it would fail for doing:
>>
>>gcc -o exe dir1/a.c dir2/a.c
>>
>> where the names overlap.  Let me look at it.

> Certainly this case is not god. In this case(= multiple input
> files that have same filename), compiling should became failure
> neither by -save-temps=cwd nor by -save-temps=obj. It is difficult ...
　　:

Best regards,
Tadashi Koike