On 08/11/15 11:42, Andreas Schwab wrote:
> This is causing a bootstrap comparison failure in gcc/go/gogo.o.
>
> Andreas.
>
I've had a look at this for sometime this afternoon 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 in add instructions when
built with debug and without debug. 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 will still look into the underlying
issue.
Bootstrapped on aarch64-none-linux-gnu including (c,c++ and go) - testing
finished ok.
Ok ?
Ramana
PR bootstrap/68256
* config/aarch64/aarch64.c (aarch64_use_constant_blocks_p): Return false.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1b7be83..1fff878 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5251,9 +5251,11 @@ aarch64_can_use_per_function_literal_pools_p (void)
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
