jfb added a comment.
In D54604#1327893 <https://reviews.llvm.org/D54604#1327893>, @rsmith wrote:
> For the record: I'm OK with this direction. (I somewhat prefer removing the
> `-enable-long-wordy-thing` option and instead automatically disabling the
> `zero` option for clang release builds, but I'm OK with either approach.)
I'm inclined to go with what @kcc wants, because I want the data he'll gather.
For my own use, I don't really care. One thing I could do: check `__DATE__` and
generate a warning if it's above a certain value and `zero` is used? i.e. check
the date at which the compiler was compiled (not when it's used!) and error out
if it was compiled after a certain point in time? I'm throwing out options that
could makes folks more comfortable with `zero`...
================
Comment at: include/clang/Basic/Attr.td:3134-3142
+
+def TrivialAutoInit : InheritableAttr {
+ let Spellings = [Clang<"trivial_auto_init", 1>];
+ let Args = [EnumArgument<"TrivialAutoVarInit", "TrivialAutoVarInitKind",
+ ["uninitialized", "zero", "pattern"],
+ ["Uninitialized", "Zero", "Pattern"]>];
+ let Subjects = SubjectList<[LocalVar]>;
----------------
rsmith wrote:
> I'm unconvinced that we should add this attribute; it seems insufficiently
> motivated to me, and harmful to portability. I think we should have some way
> of saying "leave this uninitialized", but zero- and pattern-initialization
> really seem like things that should simply be written in the source code in
> the normal way.
>
> I think it would be reasonable to have a `__uninitialized__` keyword or
> similar that can be used as the initializer of an explicitly-uninitialized
> variable. If you want an attribute for this (for compatibility with other
> compilers), `[[clang::uninitialized]]` also seems reasonable. But absent a
> strong motivation, I do not think we should have an attribute that specifies
> a particular initial value.
I definitely think that we want *some* attribute: the usecase is primarily to
turn on automatic initialization for entire projects, and then turning it off
manually where you measure unacceptable runtime costs (until you can do
something better, or until the compiler fixes its perf problem). For example,
large stack arrays would be something that you'd want to slap this attribute on.
That being said, I agree that `__uninitialized__` or `[[clang::uninitialized]]`
would serve this purpose. I figured that mirroring the command-line options
would be more desirable, but I'm not sure anymore. I've updated the patch to
have `[[clang::uninitialized]]`.
I don't think we want user code to write it in the source: that's forcing user
code to add semantics which their code otherwise doesn't have. It's existing
practice, but IMO it's bad.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D54604/new/
https://reviews.llvm.org/D54604
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
