[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

2021-08-12 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 --- Comment #5 from Martin Liška --- (In reply to Stefan Kneifel from comment #4) > Yes, but a programmer might choose to implement target clones for a shared > library using another language, e.g. hand-optimized assembler code (this was > the a

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

2021-08-11 Thread stefan.kneifel at bluewin dot ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 --- Comment #4 from Stefan Kneifel --- Yes, but a programmer might choose to implement target clones for a shared library using another language, e.g. hand-optimized assembler code (this was the actual problem I had). Forbidding target_clone de

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

2021-08-11 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 --- Comment #3 from Martin Liška --- So the solution won't be so easy. We generally face the problem that: voidfoo (void) __attribute__ ((target_clones("avx512f,avx2,avx,default"))); is only a declaration. If we consider anot

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

2021-08-03 Thread stefan.kneifel at bluewin dot ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 --- Comment #2 from Stefan Kneifel --- OK, so declaring the default function as local might make gcc assume that the function body is available in the same translation unit, thus rendering the relocation locally resolvable. Thus said, I tried

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

2021-08-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101726 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org,