llvm dev - Dec 2019 - X86 does not follow -fuse-init-array

Hi Devs,

consider below testcases,
$cat test.cc
class B {
public:
B(int t) {
j=t;
}
int j;
};
B b(1);
=============$clang test.cc -target -i386 -c -fuse-init-array
$llvm-objdump -h test.o |grep ctors
  7 .ctors          00000004 00000000 DATA
  8 .rel.ctors      00000008 00000000

As you can see it ignores the -fuse-init-array options.It happens for
x86,Other target like aarch64 is doing fine.

like to community thoughts on this, before going after fix?

./kamlesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191210/ac1a823b/attachment-0001.html>

I bet if you use `-target i386-linux` it will work. You passed `-target
-i386`, which is a triple with no OS, so Clang is doing something
arbitrary. Grepping Clang sources shows that this flag is handled in an
OS-specific manner:

$ git grep -i fuse_init_array ../clang/lib/Driver/
../clang/lib/Driver/ToolChains/Fuchsia.cpp:  if
(DriverArgs.hasFlag(options::OPT_fuse_init_array,
../clang/lib/Driver/ToolChains/Gnu.cpp:  if
(DriverArgs.hasFlag(options::OPT_fuse_init_array,
../clang/lib/Driver/ToolChains/NetBSD.cpp:  if
(DriverArgs.hasFlag(options::OPT_fuse_init_array,
../clang/lib/Driver/ToolChains/WebAssembly.cpp:  if
(DriverArgs.hasFlag(clang::driver::options::OPT_fuse_init_array,

The Gnu.cpp file most likely handles the case of Linux.

This logic looks like it is ripe for refactoring. Patches very welcome. =(

On Tue, Dec 10, 2019 at 3:11 AM kamlesh kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Devs,
>
> consider below testcases,
> $cat test.cc
> class B {
> public:
> B(int t) {
> j=t;
> }
> int j;
> };
> B b(1);
> =============> $clang test.cc -target -i386 -c -fuse-init-array
> $llvm-objdump -h test.o |grep ctors
>   7 .ctors          00000004 00000000 DATA
>   8 .rel.ctors      00000008 00000000
>
> As you can see it ignores the -fuse-init-array options.It happens for
> x86,Other target like aarch64 is doing fine.
>
> like to community thoughts on this, before going after fix?
>
> ./kamlesh
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191210/0d3d3996/attachment.html>

On 2019-12-10, Reid Kleckner via llvm-dev wrote:
>I bet if you use `-target i386-linux` it will work. You passed `-target
-i386`,
>which is a triple with no OS, so Clang is doing something arbitrary.
Grepping
>Clang sources shows that this flag is handled in an OS-specific manner:
>
>$ git grep -i fuse_init_array ../clang/lib/Driver/
>../clang/lib/Driver/ToolChains/Fuchsia.cpp:  if (DriverArgs.hasFlag
>(options::OPT_fuse_init_array,
>../clang/lib/Driver/ToolChains/Gnu.cpp:  if (DriverArgs.hasFlag
>(options::OPT_fuse_init_array,
>../clang/lib/Driver/ToolChains/NetBSD.cpp:  if (DriverArgs.hasFlag
>(options::OPT_fuse_init_array,
>../clang/lib/Driver/ToolChains/WebAssembly.cpp:  if (DriverArgs.hasFlag
>(clang::driver::options::OPT_fuse_init_array,
>
>The Gnu.cpp file most likely handles the case of Linux.
>
>This logic looks like it is ripe for refactoring. Patches very welcome. =(
We should probably make -fuse-init-array the CC1 default and the default
for Driver/ToolChains/Gnu.cpp. Very few platforms actually use
.ctors/.dtors nowadays. (This caused a bug this year which was fixed by
https://reviews.llvm.org/D62509)

If my suggestion does not sound too stupid, I can create a patch.