> This is causing a bootstrap comparison failure in gcc/go/gogo.o.
I've had a look at this and the trigger is the
aarch64_use_constant_blocks_p change which appears to be causing a
bootstrap comparison failure because of differences to offsets when
built with debug and without debug. I don't think the problem is
specifically in the backend but this needs some careful
investigation. For now, in the interest of go bootstraps continuing on
trunk - I'm proposing a patch that partially rolls back the change in
aarch64_use_constant_blocks_p and am still looking into the issue but
it will take me some more time to get to the bottom of the issue.
Bootstrapped on aarch64-none-linux-gnu including (c,c++ and go) -
testing finished ok.
2015-11-10 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
PR bootstrap/68256
* config/aarch64/aarch64.c (aarch64_use_constant_blocks_p):
Return false.
From-SVN: r230085
+2015-11-10 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
+
+ PR bootstrap/68256
+ * config/aarch64/aarch64.c (aarch64_use_constant_blocks_p):
+ Return false.
+
2015-11-09 Eric Botcazou <ebotcazou@adacore.com>
PR target/57845
static bool
aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
{
- /* We can't use blocks for constants when we're using a per-function
- constant pool. */
- return !aarch64_can_use_per_function_literal_pools_p ();
+ /* Fixme:: In an ideal world this would work similar
+ to the logic in aarch64_select_rtx_section but this
+ breaks bootstrap in gcc go. For now we workaround
+ this by returning false here. */
+ return false;
}
/* Select appropriate section for constants depending