[Bug target/84923] [8 regression] gcc.dg/attr-weakref-1.c failed on aarch64
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
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
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 MezentsevWhen 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
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.
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.