[Bug target/84923] [8 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923

Vladimir Mezentsev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Vladimir Mezentsev  
---
 The bug is fixed but the status was not updated.

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923

--- Comment #7 from Vladimir Mezentsev  
---
About comment #3 and #4.
I cannot reproduce a problem.
Is it a cross compilation on x86 for aarch64 ?
What need to do to reproduce the problem ?

[Bug c/84923] gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923

--- Comment #2 from Vladimir Mezentsev  
---
I proposed the following fix but I don't know the fix was approved or not:

From: Vladimir Mezentsev 

When weakref_targets is not empty a target cannot be removed from weak_decls.
A small example is below when 'wv12' is removed from the weak list on aarch64:
  static vtype Wv12 __attribute__((weakref ("wv12")));
  extern vtype wv12 __attribute__((weak));

Bootstrapped on aarch64-unknown-linux-gnu including (c,c++ and go).
Tested on aarch64-linux-gnu.
No regression. The attr-weakref-1.c test passed.

ChangeLog:
2018-04-12  Vladimir Mezentsev  

PR gcc/84923
* varasm.c (weak_finish): clean up weak_decls
---
 gcc/varasm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/varasm.c b/gcc/varasm.c
index d24bac4..2a70234 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -5683,8 +5683,7 @@ weak_finish (void)
   nor multiple .weak directives for the latter.  */
for (p = _decls; (t2 = *p) ; )
  {
-   if (TREE_VALUE (t2) == alias_decl
-   || target == DECL_ASSEMBLER_NAME (TREE_VALUE (t2)))
+   if (TREE_VALUE (t2) == alias_decl)
  *p = TREE_CHAIN (t2);
else
  p = _CHAIN (t2);
-- 
1.8.3.1

[Bug c/84923] New: gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923

Bug ID: 84923
   Summary: gcc.dg/attr-weakref-1.c failed on aarch64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.mezentsev at oracle dot com
  Target Milestone: ---

ramana.radhakrish...@arm.com implemented (2015-11-06, commit
cd4fcdb8ff16ec2dad56f9e736ac4552f8f52001)
a new feature ('Switch constant pools to separate rodata sections').
An additional fix is needed for this feature.

The test below demonstrates problem:
% cat t.c
extern void abort(void);
typedef int vtype;
static vtype Wv12 __attribute__((weakref ("wv12")));
extern vtype wv12 __attribute__((weak));

#define chk(p) do { if (!p) abort (); } while (0)

int main () {
  chk (!);
  chk (!);
  return (0);
}

% gcc  t.c
/tmp/cciZgRxK.o:(.rodata+0x0): undefined reference to `wv12'
/tmp/cciZgRxK.o:(.rodata+0x8): undefined reference to `wv12'

% gcc  t.c -S
% cat t.s

.size   main, .-main
.weakrefWv12,wv12   <<<<<<   Not here. This should be after
definitions of Wv12 and wv12.
Wv12.section.rodata
.align  3
.LC0:
.xword  Wv12
.align  3
.LC1:
.xword  wv12


It is a regression after fixing PR68256.
We can temporary restore Ramana's workaround in 
aarch64_use_blocks_for_constant_p to avoid this regression:
% git diff gcc/config/aarch64/aarch64.c 
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4b5183b..222ea33 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7735,7 +7735,11 @@ 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::
+ return !aarch64_can_use_per_function_literal_pools_p ();
+ This return statement breaks gcc.dg/attr-weakref-1.c test.
+ For now we workaround this by returning false here.  */
+  return false;
 }

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

[vladimir.mezentsev at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256

Vladimir Mezentsev  changed:

   What|Removed |Added

 CC||vladimir.mezentsev at oracle 
dot c
   ||om

--- Comment #6 from Vladimir Mezentsev  
---
I restored fixes in gcc/config/aarch64/aarch64.c:
% git diff
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 1c14008..b377bc7 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6193,11 +6193,9 @@ aarch64_can_use_per_function_literal_pools_p (void)
 static bool
 aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
 {
-  /* 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;
+   /* 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 ();
 }

 /* Select appropriate section for constants depending


I cannot reproduce the problem.
I use the gcc116.fsffrance.org machine:
% uname -a
Linux gcc116 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:45:34 UTC 2016
aarch64 aarch64 aarch64 GNU/Linux

I run
% ../gcc/configure --enable-languages=c,c++,go --enable-bootstrap
--enable-multilib
% make -j8 bootstrap

 There is no bootstrap comparison failure.