Hi,
On 28/04/2018 18:41, Jason Merrill wrote:
On Fri, Apr 27, 2018 at 7:26 PM, Paolo Carlini wrote:
Hi again,
I'm now pretty sure that we have a latent issue in ocp_convert. The bug
fixed by Jakub shows that we used to not have issues with integer_zero_node.
That's easy to explain: at the beg
Hi,
atomic_capture-1.c contains the following bit:
...
fgot = 1.0;
fexp = 0.0;
#pragma acc data copy (fgot, fdata[0:N])
{
#pragma acc parallel loop
for (i = 0; i < N; i++)
{
float expr = 32.0;
#pragma acc atomic capture
fdata[i] = fgot = expr - fgot;
}
}
On April 29, 2018 1:06:47 AM GMT+02:00, David Edelsohn
wrote:
>Hi, Richi
>
>I had been using two source trees to speed the bisection and didn't
>realize
>that one defaulted to DWARF debugging and the other defaulted to XCOFF
>debugging, which confused the bisection result. The -f[no-]checking
>p
Hi,
this patch fixes the problem with more or less random code layout with
LTO. Currently we split unit into partitions, sort them by size (so parallel
compile works well) and output in this order. Problem is that the order of
final binary is then more or less random - dependent on partitioning
de
On Sat, Apr 28, 2018 at 11:55 AM, Jan Hubicka wrote:
> Hi,
> with number of cores increasing our partitioning algorithm needs some love,
> because it works quite bad.
>
> This patch fixes few issues with ballanced partitioning algorithm:
> 1) I have switched all size/boundary summaries to 64bit a
