Re: Thread model: simple and C

2010-08-05 Thread Jonathan Wakely 
On 5 August 2010 04:54,   wrote:
> On Wed, August 4, 2010 8:45 pm, Jonathan Wakely wrote:
>> On 4 August 2010 13:56, Marcos Dione wrote:
>>>    so, in short: does a simple Thread model have any impact on C-only
>>> programs that could use threads? in particular, how it does impact
>>> Boehm's GC usage in a C-only program? if the impact is negative, would
>>
>> IIUC GCC's thread model doesn't affect how you use threads in your own
>> program, only how GCC's libraries (e.g. the C++ and ObjC runtimes) use
>> threads.
>
>    so it is wrong that some projects (in particular, Boehm's GC) test
> thread availability by looking at the output of 'gcc -v' because that
> would be assuming that it will use the same libraries compiled along
> with that gcc?

I don't know that it's "wrong," it might just be a requirement of
using that project that you use suitable runtime libraries that match
the compiler used to build the project.  It's not up to GCC to decide
other projects' requirements.

> in particular, this platform uses its own libc
> implementation... also, you don't mention libc at all. is it different

I have no idea, that's something you'd have to ask the libc
maintainers, not the GCC list.

> with it? and last one: can anyone explain *how* it affects stdlibc++
> and others?

The library is called libstdc++, see
http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_concurrency.html
and http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html
and for more details see the code. With thread model "single" all
calls to atomic operations are always turned into plain integer
arithmetic.  So for example, std::string reference counting uses
simple increments and decrements, with no memory synchronisation and
no protection against data races.  You could still write a
multithreaded program which uses std::string, but the library will
behave as though you have a single-threaded program so if you share
objects between threads you will get problems.
Additionally, features of the library which require thread-related
components such as mutexes will be disabed and unavailable if GCC was
configured without a supported thread model.

Re: constraints and predicates

2010-08-05 Thread roy rosen 
I haven't mentioned that I am using gcc 4.6 latest version.
To generalize the question. If I use an operand like lc_operand
(below) and leave the constraint open, is it guaranteed that the
register that would be chosen would be of class lc?

2010/8/3 roy rosen :
> Hi All,
>
> If I don't use a constraint, is it possible that during ira I get a
> register which is not acceptable by the predicate?
> In my port I have the following to support HW loops:
>
> (define_predicate "lc_operand"
>    (match_operand 0 "register_operand")
> {
>        unsigned int regno;
>        if (GET_CODE (op) == SUBREG)
>            op = SUBREG_REG (op);
>        regno = REGNO (op);
>        return (regno >= FIRST_PSEUDO_REGISTER ||
> REGNO_REG_CLASS(regno) == LC_REGS);
> }
> )
>
> (define_expand "doloop_end"
>  [(use (match_operand 0 "" ""))        ; loop pseudo
>   (use (match_operand 1 "" ""))        ; iterations; zero if unknown
>   (use (match_operand 2 "" ""))        ; max iterations
>   (use (match_operand 3 "" ""))        ; loop level
>   (use (match_operand 4 "" ""))]       ; label
>  ""
>  {
>    if (INTVAL (operands[3]) > 4
>    )
>        FAIL;
>    emit_jump_insn (gen_doloop_end_internal (operands[4], operands[0]));
>    DONE;
>  }
> )
>
> (define_insn "doloop_end_internal"
>  [(set (pc)
>        (if_then_else (ne (match_operand:SI 1 "lc_operand" "")
>                          (const_int 0))
>                      (label_ref (match_operand 0 "" ""))
>                      (pc)))
>   (set (match_dup 1) (plus:SI (match_dup 1) (const_int -1)))]
>  ""
>  "doloop_end%b1 %!"
> )
>
> I see that during ira operand 1 in doloop_end_internal is getting
> "best GENERAL_REGS" and eventually ends up as a register of a class
> other than LC_REGS.
> I thought that if I have predicate lc_operand then I don't need a
> constraint since all other register classes would be rejected in all
> stages for this operand.
> What might be the problem here?
>
> Thanks, Roy.
>

Re: Thread model: single and C programs

2010-08-05 Thread Marcos Dione 
On Thursday 05 August 2010 10:33:11 Jonathan Wakely wrote:
> On 5 August 2010 04:54,   wrote:
> >so it is wrong that some projects (in particular, Boehm's GC) test
> > thread availability by looking at the output of 'gcc -v' because that
> > would be assuming that it will use the same libraries compiled along
> > with that gcc?
> 
> I don't know that it's "wrong," it might just be a requirement of
> using that project that you use suitable runtime libraries that match
> the compiler used to build the project.  It's not up to GCC to decide
> other projects' requirements.

you're right, I was asking in the general sense. from the rest of the mail 
it seems that a check like that is meaningful only if you're going to use any 
of the libraries that comes with gcc (which is not my case). now, is it 
possible that if a project does not use libstdc++ or any other library that 
comes with gcc still be affected by the thread model? for example, does it 
affect the C code produced? you only mentioned that it doesn't affect on the 
usage of threads.

> > also, you don't mention libc at all. is it different
> 
> I have no idea, that's something you'd have to ask the libc
> maintainers, not the GCC list.

ah, sorry, the fact that libstdc++ is part of gcc got me to think that 
glibc was also, but didn't check.

> The library is called libstdc++

yes, sorry, that's what happens when you answer technical mails (or 
otherwise) at 5AM.

> Additionally, features of the library which require thread-related
> components such as mutexes will be disabed and unavailable if GCC was
> configured without a supported thread model.

just to be sure, you're still talking about libstdc++?

-- 
Lic. Marcos Dione
Engineer Expert - Hop Project
http://hop.inria.fr/
INRIA Sophia Antipolis - Méditerranée
Phone: +33 (0)4 92 38 79 67

Re: constraints and predicates

2010-08-05 Thread Georg Lay 
roy rosen schrieb:
> Hi All,
> 
> If I don't use a constraint, is it possible that during ira I get a
> register which is not acceptable by the predicate?
> In my port I have the following to support HW loops:
> 
> (define_predicate "lc_operand"
> (match_operand 0 "register_operand")
> {
> unsigned int regno;
> if (GET_CODE (op) == SUBREG)
> op = SUBREG_REG (op);
> regno = REGNO (op);
> return (regno >= FIRST_PSEUDO_REGISTER ||
> REGNO_REG_CLASS(regno) == LC_REGS);
> }
> )
> 
> (define_expand "doloop_end"
>   [(use (match_operand 0 "" ""))  ; loop pseudo
>(use (match_operand 1 "" ""))  ; iterations; zero if unknown
>(use (match_operand 2 "" ""))  ; max iterations
>(use (match_operand 3 "" ""))  ; loop level
>(use (match_operand 4 "" ""))]   ; label
>   ""
>   {
> if (INTVAL (operands[3]) > 4
> )
> FAIL;
> emit_jump_insn (gen_doloop_end_internal (operands[4], operands[0]));
> DONE;
>   }
> )
> 
> (define_insn "doloop_end_internal"
>   [(set (pc)
>   (if_then_else (ne (match_operand:SI 1 "lc_operand" "")
> (const_int 0))
> (label_ref (match_operand 0 "" ""))
> (pc)))
>(set (match_dup 1) (plus:SI (match_dup 1) (const_int -1)))]
>   ""
>   "doloop_end%b1 %!"
> )
> 
> I see that during ira operand 1 in doloop_end_internal is getting
> "best GENERAL_REGS" and eventually ends up as a register of a class
> other than LC_REGS.
> I thought that if I have predicate lc_operand then I don't need a
> constraint since all other register classes would be rejected in all
> stages for this operand.

No. Predicates are used for pattern matching, not for register allocation.

> What might be the problem here?

Define and use proper constraint(s).
> 
> Thanks, Roy.
>

CALL_USED_REGISTERS per function basis

2010-08-05 Thread Claudiu Zissulescu 
Hi,

I want to use a different CALL_USED_REGISTER set per individual
function. The issue here is to inform a caller about the callee
CALL_USED_REGISTERS and save/restore at caller level the possible
altered registers.  This should reduce the number of saved/restored
operation in a function.

Can someone give me some pointers in this direction?

Thank you,
Claudiu

Re: How to get attual method in GCC AST

2010-08-05 Thread Tom Tromey 
> "Kien" == Kien Nguyen Trung  writes:

Kien> obj_type_ref
Kien>   indirect_ref (test.cpp:21-17)

Kien> The problem is method read() of class B is get from a virtual method
Kien> of based class A. And i cannot get the real name of  this method.
Kien> Do you have any ideal to help me. Thansk

You may be able to extract it from the OBJ_TYPE_REF node.
I would suggest looking at how the devirtualization pass works to see if
this helps.

Maybe the information is completely lost in some cases.  (I don't really
know.)  If so I would suggest adding a bit more info to OBJ_TYPE_REF to
assist you.

Tom

Re: CALL_USED_REGISTERS per function basis

2010-08-05 Thread Richard Henderson 
On 08/05/2010 06:48 AM, Claudiu Zissulescu wrote:
> I want to use a different CALL_USED_REGISTER set per individual
> function. The issue here is to inform a caller about the callee
> CALL_USED_REGISTERS and save/restore at caller level the possible
> altered registers.  This should reduce the number of saved/restored
> operation in a function.
> 
> Can someone give me some pointers in this direction?

A sketch of the idea:

In struct cgraph_local_info, add a HARD_REG_SET with the call-used
register set for that function.  It is initialized to the ABI.

In the various appropriate places, caller-save.c, ira-*.c, reload1.c,
sel-sched.c, and replace the bare uses of the target_hard_regs sets
with calls to something like

  HARD_REG_SET get_call_used_reg_set (const_rtx call_insn);
  HARD_REG_SET get_regs_invalidated_by_call (const_rtx call_insn);

which digs into the actual call to find the symbol_ref, and from
there to the SYMBOL_REF_DECL, to the cgraph node from whence you
can return the saved register set.  If any of that fails, you 
must return the ABI set.

At the end of compilation for a function, iterate over the function
to see what's really changed.  The set of call-clobbered registers
that might be used can change right up until at least machine_reorg.
Of course one must OR in the sets used by any callees.  Store this
collected register set back into cgraph_local_info that it may be
used during the compilation of the function's callers.

Given that cgraph has already performed a topological sort on the
set of functions to be emitted, you should in this way be able to
collect the call-used register set of most functions before they
are used by their callers.  The case of cycles is handled by assuming
the worst by the initialization to the ABI call-used set.


r~


PS: Bonus points for adding an __attribute__((call_used(register-set)))
to allow programmers to describe the behaviour of hand-written 
assembly, or force the function to save more registers in its
prologue.  The later, of course, means having to adjust the prologue
and epilogue code the target(s) you care about.  One can support
this feature without adjusting the target merely be restricting this
to hand-written assembly.  Detect this by generating an error if the
attribute is used with a function that has a body and is not merely
a declaration.

Re: constraints and predicates

2010-08-05 Thread Richard Sandiford 
Georg Lay  writes:
> roy rosen schrieb:
>> What might be the problem here?
>
> Define and use proper constraint(s).

Right.  doloop_end is a notoriously difficult case though, because jump
insns aren't allowed to have output reloads.  Something like:

(define_insn "doloop_end_internal"
  [(set (pc)
(if_then_else (ne (match_operand:SI 1 "lc_operand" "+lc")
  (const_int 0))
  (label_ref (match_operand 0 "" ""))
  (pc)))
   (set (match_dup 1) (plus:SI (match_dup 1) (const_int -1)))]
  ...)

isn't allowed because it might generate an output reload from an
lc_register to either a general register or memory.  The predicates
and constraints have to accept all allocatable registers for SImode
and at least (mem (reg)).

See the MeP port for one example of how to do this.

Richard

Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Toon Moene 

The program is attached.

The command line was:

gfortran -c  -O3 inv_dee_main.f

with this gfortran:

Using built-in specs.
COLLECT_GCC=/usr/crz/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/crz/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-checking=release 
--prefix=/usr/crz --disable-multilib --disable-nls --with-arch-64=native 
--with-tune-64=native --enable-languages=fortran,c++ --disable-werror

Thread model: posix
gcc version 4.6.0 20100805 (experimental) (GCC)

gdb backtrace gives:

$ gdb /usr/crz/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) run  inv_dee_main.f -ffixed-form -march=core2 -mcx16 -msahf 
--param l1-cache-size=32 --param l1-cache-line-size=64 --param 
l2-cache-size=4096 -mtune=core2 -quiet -dumpbase inv_dee_main.f -auxbase 
inv_dee_main -O3 -version -fintrinsic-modules-path 
/usr/crz/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccpApakj.s
Starting program: 
/usr/crz/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 inv_dee_main.f 
-ffixed-form -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param 
l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -quiet 
-dumpbase inv_dee_main.f -auxbase inv_dee_main -O3 -version 
-fintrinsic-modules-path 
/usr/crz/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccpApakj.s
GNU Fortran (GCC) version 4.6.0 20100805 (experimental) 
(x86_64-unknown-linux-gnu)
	compiled by GNU C version 4.6.0 20100805 (experimental), GMP version 
4.3.2, MPFR version 2.4.2, MPC version 0.8.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.6.0 20100805 (experimental) 
(x86_64-unknown-linux-gnu)
	compiled by GNU C version 4.6.0 20100805 (experimental), GMP version 
4.3.2, MPFR version 2.4.2, MPC version 0.8.2

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Program received signal SIGSEGV, Segmentation fault.
find_uses_to_rename_use (bb=0x7f91a552e9c0, use=0x7f91a56e82c0, 
use_blocks=, need_phis=0x1316ec0) at 
../../gcc/gcc/tree-ssa-loop-manip.c:1242

1242}
(gdb) where
#0  find_uses_to_rename_use (bb=0x7f91a552e9c0, use=0x7f91a56e82c0, 
use_blocks=, need_phis=0x1316ec0) at 
../../gcc/gcc/tree-ssa-loop-manip.c:1242

#1  0x0a00 in ?? ()
#2  0x0136d510 in ?? ()
#3  0x01373a50 in ?? ()
#4  0x in ?? ()

Note that 1242 is the last line of tree-ssa-loop-manip.c - it looks like 
most of the stack has been blown away, and the segmentation fault simply 
happens on return ...


This revision works: 162679
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
  subroutine inv_dee_main
  implicit none
 INTEGER
 1 JPMXGICL , JPMXGRCL
 2,JPMXICRL , JPMXICHL , JPMXICBL
 3,JPMXICDL 
 4,JPMXOCRL , JPMXOCHL , JPMXOCBL
 5,JPMXOCDL , JPMXDEPL
 PARAMETER(
 1 JPMXGICL=   1, JPMXGRCL=  2 000 000
 2,JPMXICRL=  164811, JPMXICHL= 581, JPMXICBL=  72
 3,JPMXICDL=3072
 4,JPMXOCRL=  164811, JPMXOCHL= 581, JPMXOCBL=  72
 5,JPMXOCDL=3072, JPMXDEPL= 319   ) 
 INTEGER
 1 JPMXLID  , JPMXPCD  , JPMXRE1
 2,JPMXRE2  , JPMXDE1  , JPMXDE2
 3,JPMXRBLE , JPMXDBLE
 4,JPMXRDF  , JPMXDDF  , JPMXADF
 5,JPMXSBI2 , JPMXSMI2 , JPMXSMV
 6,JPMXSMW  , JPMXSMX  , JPMXSMY
 7,JPMXSMA  , JPMXSMB  , JPMXSMC
 8,JPMXSBI1
 PARAMETER (
 1 JPMXLID =   9, JPMXPCD =  13, JPMXRE1 =  30
 2,JPMXRE2 =  30, JPMXDE1 =  30, JPMXDE2 =  30
 3,JPMXRBLE=  30, JPMXDBLE=  30
 4,JPMXRDF =   5, JPMXDDF =   7, JPMXADF =   7
 5,JPMXSBI2=   5, JPMXSMI2=   4, JPMXSMV =   3
 6,JPMXSMW =   3, JPMXSMX =   5, JPMXSMY =   7
 7,JPMXSMA =   3, JPMXSMB =   3, JPMXSMC =   3
 8,JPMXSBI1=   5  )
 INTEGER
 1 JPMXOTP  , JPMXOCT
 2,JPMXUP   , JPMXAD   , JPMXVAR
 3,JPMXTOCH , JPMXSSCH
 4,JPXT

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Sebastian Pop 
Toon,
>From your backtrace it looks like a problem in LNO.
Please submit a bug report and attach your testcase.

Thanks,
Sebastian

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread H.J. Lu 
On Thu, Aug 5, 2010 at 12:33 PM, Sebastian Pop  wrote:
> Toon,
> From your backtrace it looks like a problem in LNO.
> Please submit a bug report and attach your testcase.
>

I saw

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==23110== Invalid read of size 8
==23110==at 0xB7FE2B: gimple_bb (gimple.h:1148)
==23110==by 0xB8175F: find_uses_to_rename_use (tree-ssa-loop-manip.c:247)
==23110==by 0xB81888: find_uses_to_rename_stmt (tree-ssa-loop-manip.c:284)
==23110==by 0xB81A3B: find_uses_to_rename_bb (tree-ssa-loop-manip.c:305)
==23110==by 0xB81B7E: find_uses_to_rename (tree-ssa-loop-manip.c:331)
==23110==by 0xB81C4E: rewrite_into_loop_closed_ssa
(tree-ssa-loop-manip.c:391)
==23110==by 0xAA54E8: ldist_gen (tree-loop-distribution.c:1094)
==23110==by 0xAA575A: distribute_loop (tree-loop-distribution.c:1167)
==23110==by 0xAA5809: tree_loop_distribution (tree-loop-distribution.c:1199)
==23110==by 0x936418: execute_one_pass (passes.c:1564)
==23110==by 0x936601: execute_pass_list (passes.c:1619)
==23110==by 0x936622: execute_pass_list (passes.c:1620)
==23110==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==23110==
inv_dee_main.f: In function ‘inv_dee_main’:
inv_dee_main.f:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
==23110==


-- 
H.J.

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Sebastian Pop 
On Thu, Aug 5, 2010 at 15:00, H.J. Lu  wrote:
> I saw
> ==23110==    by 0xAA5809: tree_loop_distribution 
> (tree-loop-distribution.c:1199)

Mine.

Thanks for running the trace,
Sebastian

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Sebastian Pop 
I'm delta reducing this.
Toon, have you opened a bug, or do you want me to open the bug report?

Thanks,
Sebastian

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Sebastian Pop 
On Thu, Aug 5, 2010 at 15:07, Sebastian Pop  wrote:
> I'm delta reducing this.

Reduced it looks like this, and it seems like the bug is in the loop
distribution
for memset zero changes.

  parameter(numlev=3,numoblev=1000)
  integer i_otyp(numoblev,numlev), i_styp(numoblev,numlev)
  logical l_numob(numoblev,numlev)
  do ixe=1,numoblev
 do iye=1,numlev
i_otyp(ixe,iye)=0
i_styp(ixe,iye)=0
l_numob(ixe,iye)=.false.
 enddo
  enddo
  do i=1,m
 do j=1,n
if (l_numob(i,j)) then
   write(20,'(7I4,F12.2,4F16.10)') i_otyp(i,j),i_styp(i,j)
endif
 enddo
  enddo
  end

Re: Segmentation fault for the following Fortran program at -O3 on x86-64.

2010-08-05 Thread Sebastian Pop 
On Thu, Aug 5, 2010 at 15:17, Sebastian Pop  wrote:
> On Thu, Aug 5, 2010 at 15:07, Sebastian Pop  wrote:
>> I'm delta reducing this.
>
> Reduced it looks like this, and it seems like the bug is in the loop
> distribution
> for memset zero changes.
>
>      parameter(numlev=3,numoblev=1000)
>      integer i_otyp(numoblev,numlev), i_styp(numoblev,numlev)
>      logical l_numob(numoblev,numlev)
>      do ixe=1,numoblev
>         do iye=1,numlev
>            i_otyp(ixe,iye)=0
>            i_styp(ixe,iye)=0
>            l_numob(ixe,iye)=.false.
>         enddo
>      enddo
>      do i=1,m
>         do j=1,n
>            if (l_numob(i,j)) then
>               write(20,'(7I4,F12.2,4F16.10)') i_otyp(i,j),i_styp(i,j)
>            endif
>         enddo
>      enddo
>      end
>

This is now http://gcc.gnu.org/PR45199

Sebastian

re: mirror site http://gcc-ca.internet.bs

2010-08-05 Thread Mark Hahn 

this mirror seems to be stuck at versions around late 2009.

regards, mark hahn.

gcc-4.5-20100805 is now available

2010-08-05 Thread gccadmin 
Snapshot gcc-4.5-20100805 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100805/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 162923

You'll find:

gcc-4.5-20100805.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20100805.tar.bz2 C front end and core compiler

gcc-ada-4.5-20100805.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20100805.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20100805.tar.bz2  C++ front end and runtime

gcc-java-4.5-20100805.tar.bz2 Java front end and runtime

gcc-objc-4.5-20100805.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20100805.tar.bz2The GCC testsuite

Diffs from 4.5-20100729 are available in the diffs/ subdirectory.

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

transitioning cloog to ppl-0.11

2010-08-05 Thread Jack Howarth 
Sebastian,
   I have been mulling over how to transition the
current gcc4x and cloog packages in fink to the new
ppl-0.11 release and believe we really need to have
a soversion bump on cloog to safely do this on
systems with pre-existing packages. My initial
inclination was to create a new ppl2-0.11 package
that conflicted against the current ppl-0.10.2
package and rebuild cloog-0.15.9 against that.
However this will leave all prebuilt gcc4x compilers
on the machine with broken linkages. The compilers
will show...

[MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L f951
f951:
/sw/lib/libintl.8.dylib (compatibility version 9.0.0, current version 
9.2.0)
/sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)
/sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 
1.0.0)
/sw/lib/libppl_c.2.dylib (compatibility version 4.0.0, current version 
4.0.0)
/sw/lib/libppl.7.dylib (compatibility version 9.0.0, current version 
9.0.0)
/sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 
6.2.0)
/sw/lib/libmpc.2.dylib (compatibility version 3.0.0, current version 
3.0.0)
/sw/lib/libmpfr.1.dylib (compatibility version 4.0.0, current version 
4.2.0)
/sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 
9.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.3)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
438.0.0)
/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 125.2.0)

since they were built with cloog and ppl-0.10.2, but the new cloog.0.dylib will 
be linked as...

[MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L 
/sw/lib/libcloog.0.dylib
/sw/lib/libcloog.0.dylib:
/sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 
1.0.0)
/sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 
9.2.0)
/sw/lib/libppl_c.4.dylib (compatibility version 5.0.0, current version 
5.0.0)
/sw/lib/libppl.9.dylib (compatibility version 10.0.0, current version 
10.0.0)
/sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 
6.2.0)

So one would have to make ppl2/ppl2-shlibs both conflict with ppl/ppl-shlibs
to force all of the old compiler builds to be deinstalled. It would be far
simplier if a new cloog was released with a soversion bump so that one could 
have
a new cloog2 package and co-existing cloog-shlibs/cloog2-shlibs packages.
I suspect Debian will run into this as well.
Jack

RE: transitioning cloog to ppl-0.11

2010-08-05 Thread Jack Howarth 
Sebastian,
   An alternative solution to a version bump would be to
modify current cloog build such that the shared libraries
could be built under a different basename (but retain
the same libcloog.dylib symlink and header names otherwise
for development purposes).
  Jack

Re: transitioning cloog to ppl-0.11

2010-08-05 Thread Ralf Wildenhues 
* Jack Howarth wrote on Fri, Aug 06, 2010 at 02:31:31AM CEST:
>I have been mulling over how to transition the
> current gcc4x and cloog packages in fink to the new
> ppl-0.11 release and believe we really need to have
> a soversion bump on cloog to safely do this on
> systems with pre-existing packages.

Not sure I understand, but why should ppl soversion bump require a cloog
soversion bump?  In which way is this different from any other library
dependency that undergoes such a bump, and why should it be handled
differently?

Thanks,
Ralf