Sebastian Pop wrote:
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,numob
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
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: ../gc
