* 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
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
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.1
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
this mirror seems to be stuck at versions around late 2009.
regards, mark hahn.
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)
>
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)
lo
I'm delta reducing this.
Toon, have you opened a bug, or do you want me to open the bug report?
Thanks,
Sebastian
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
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==
Toon,
>From your backtrace it looks like a problem in LNO.
Please submit a bug report and attach your testcase.
Thanks,
Sebastian
: ../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
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)
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 numb
> "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 idea
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 so
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")
> {
>
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
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 const
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 us
20 matches
Mail list logo
