[Bug target/92030] Wrong asm code for aliases on MIPS.

2019-10-09 Thread anikulin at dlink dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030

Alexander Nikulin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Alexander Nikulin  ---
resolved.

[Bug target/92030] Wrong asm code for aliases on MIPS.

2019-10-09 Thread anikulin at dlink dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030

--- Comment #4 from Alexander Nikulin  ---
(In reply to Alexander Monakov from comment #3)
> The alias attribute usually works fine with declarations of static variables.
> 
> So, have you tried
> 
> static struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));
> 
> (i.e. with 'static' rather that 'extern')?

I was sure I did! And this reported smth like 'already defined' or similar.

Different combinations of attributes were tried and likely I lost this obvious
one.

Thanks a lot, it works.

So the decision is found.

If the .equiv behaviour is not buggy really, I guess the case may be closed.
Should I change its status myself or wait for an admin's verdict?


Thanks again.

[Bug target/92030] Wrong asm code for aliases on MIPS.

2019-10-09 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
The alias attribute usually works fine with declarations of static variables.

So, have you tried

static struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));

(i.e. with 'static' rather that 'extern')?

[Bug target/92030] Wrong asm code for aliases on MIPS.

2019-10-09 Thread anikulin at dlink dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030

--- Comment #2 from Alexander Nikulin  ---
(In reply to Richard Biener from comment #1)
> You're doing it behind the back of the compiler - maybe use
> __attribute__((alias("abc1"))) instead?

Hi Richard,

yes, I did.

It declares global symbol 'abc2':

-
-#APP
-   .equiv abc2, abc1
-
+   .globl  abc2
+   abc2 = abc1
.rdata
.align  2
-

00411010 d abc1
00411010 D abc2
 ^

and it works with my snippet:
@abc1 = 0x411010, abc2 = 0x411010, @abc2 = 0x411010

But as I understood, the developers would like to have a static alias-symbol
exactly.

Building FRR with __attribute__((alias(...))):
extern struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name)));

produces the expected:
.../grammar_sandbox.c:38: multiple definition of `MTYPE_CMD_TOKENS'
.../command_graph.c:29: first defined here


Am agreed that the .equiv trick may be treated as a hack, but I can not offer a
valid replacement. And it works fine on
x86_64: (Debian 8.2.0-16),
i686: (Debian 6.3.0-18+deb9u1),
very ancient xscale/armv5b: (gcc-4.4.3).

Now I have no aarch64 board to check a compiled binary, but I see LO calls for
abc2 in the generated asm.


If this is not a compiler bug but wrong coding approach, could you please offer
the decision which provides "static" aliases?

Thanks!

[Bug target/92030] Wrong asm code for aliases on MIPS.

2019-10-09 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030

Richard Biener  changed:

   What|Removed |Added

 Target||mips

--- Comment #1 from Richard Biener  ---
You're doing it behind the back of the compiler - maybe use
__attribute__((alias("abc1"))) instead?