================ @@ -0,0 +1,19 @@ +//===--- AtomicOptions.def - Atomic Options database -------------*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// This file defines the Atomic language options. Users of this file +// must define the OPTION macro to make use of this information. +#ifndef OPTION +# error Define the OPTION macro to handle atomic language options +#endif + +// OPTION(name, type, width, previousName) +OPTION(NoRemoteMemory, bool, 1, First) +OPTION(NoFineGrainedMemory, bool, 1, NoRemoteMemory) +OPTION(IgnoreDenormalMode, bool, 1, NoFineGrainedMemory) ---------------- Artem-B wrote:
Can't say I'm a fan of negative options. IIUIC, from the comments on the RFC (https://discourse.llvm.org/t/rfc-add-clang-atomic-control-options-and-pragmas/80641/23), one of the reasons for sticking with them is that we currently have no way to have those options enabled by default. Would it make sense to improve this ability to specify the default value, and then stick to positive assertions and their negations in the control knobs' names? This sounds like something that would be generally useful improvement applicable beyond this patch, and it should address your concern that dropping those hints should preserve safe conservative behavior. https://github.com/llvm/llvm-project/pull/114841 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
