[arch-general] Changing compilation flags

[Jordan Glover]

I just looked into it and created simple patch. Anyone could test it and/or submit upstream?

Index: include/clang/Driver/Options.td
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2497,6 +2497,7 @@
defm non_call_exceptions : BooleanFFlag<"non-call-exceptions">, Group<clang_ignored_f_Group>;
defm peel_loops : BooleanFFlag<"peel-loops">, Group<clang_ignored_gcc_optimization_f_Group>;
defm permissive : BooleanFFlag<"permissive">, Group<clang_ignored_f_Group>;
+defm plt : BooleanFFlag<"plt">, Group<clang_ignored_f_Group>;
defm prefetch_loop_arrays : BooleanFFlag<"prefetch-loop-arrays">, Group<clang_ignored_gcc_optimization_f_Group>;
defm printf : BooleanFFlag<"printf">, Group<clang_ignored_f_Group>;
defm profile : BooleanFFlag<"profile">, Group<clang_ignored_f_Group>;

Index: test/Driver/clang_f_opts.c
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -275,12 +275,14 @@
// RUN: -fno-fat-lto-objects -ffat-lto-objects \
// RUN: -fno-merge-constants -fmerge-constants \
// RUN: -fno-caller-saves -fcaller-saves \
+// RUN: -fno-plt \
// RUN: -fno-reorder-blocks -freorder-blocks \
// RUN: -fno-schedule-insns2 -fschedule-insns2 \
// RUN: -fno-stack-check \
// RUN: -fno-check-new -fcheck-new \
// RUN: -ffriend-injection \
// RUN: -fno-implement-inlines -fimplement-inlines \
+// RUN: -fplt \
// RUN: -fstack-check \
// RUN: -fforce-addr \
// RUN: -malign-functions=100 \

> -------- Original Message --------
> Subject: Re: [arch-dev-public] Changing compilation flags
> From: arch-dev-public at archlinux.org
> To: Evangelos Foutras <evangelos at foutrelis.com>
> Daniel Micay <danielmicay at gmail.com>, Public mailing list for Arch Linux development <arch-dev-public at archlinux.org>
>> So I think it would be a good idea to flip the default to -z,now in
>> the
>> linker if we"re going to use -fno-plt. I think they"d take a patch for
>> that upstream. Clang issue could be avoided with a 1 line patch adding
>> another no-op flag and they"d take that upstream. It"s harmless to use
>> the slower lazy linking calling convention when -fno-plt is passed.
> This is literally just +1 LOC for Clang b/c it has a system for adding
> no-op flags already, which is mostly used for GCC compatibility.
> It even uses it in cases that are quite dubious like making -fstack-
> check into a no-op, despite it not just being an optional optimization /
> code generation change like -fno-plt.