Re: [PATCH] D23284: Add -Rpass-with-hotness
dnovillo added a comment. In https://reviews.llvm.org/D23284#526389, @anemet wrote: > @dnovillo or @rsmith, can you please confirm if you agree that this new > option -Rpass-with-hotness should not be part of R_group. R_group options > enable/disable groups of remarks whereas this one is only modifying the text > of the remarks. Thanks! I'm fine with it, but I don't have much of a say in how option groups are organized. If Richard agrees, then it LGTM. https://reviews.llvm.org/D23284 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D11908: Clang support for -fthinlto.
On Fri, Oct 2, 2015 at 9:44 AM, Teresa Johnson via cfe-commits < cfe-commits@lists.llvm.org> wrote: As David mentioned, "inlineonly" is much too restrictive for what is > possible. I prefer to stick with "thin" since it refers to this new model > of keeping the whole program part very thin. > Agreed. "inlineonly" is too restrictive. > Does anyone have an opinion on "full" vs "monolithic" vs something else > for the traditional full/monolithic LTO? > I prefer Full LTO for the traditional mechanism (or even Traditional LTO). ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r249316 - [VFS] Add working directories to every virtual file system.
On Mon, Oct 5, 2015 at 9:55 AM, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: d0k
> Date: Mon Oct 5 08:55:20 2015
> New Revision: 249316
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249316&view=rev
> Log:
> [VFS] Add working directories to every virtual file system.
>
> For RealFileSystem this is getcwd()/chdir(), the synthetic file systems can
> make up one for themselves. OverlayFileSystem now synchronizes the working
> directories when a new FS is added to the overlay or the overlay working
> directory is set. This allows purely artificial file systems that have zero
> ties to the underlying disks.
>
> Differential Revision: http://reviews.llvm.org/D13430
>
> Modified:
> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=249316&r1=249315&r2=249316&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Oct 5 08:55:20
> 2015
> @@ -199,6 +199,25 @@ public:
>/// \note The 'end' iterator is directory_iterator().
>virtual directory_iterator dir_begin(const Twine &Dir,
> std::error_code &EC) = 0;
> +
> + /// Set the working directory. This will affect all following
> operations on
> + /// this file system and may propagate down for nested file systems.
> + virtual std::error_code setCurrentWorkingDirectory(const Twine &Path) =
> 0;
> + /// Get the working directory of this file system.
> + virtual llvm::ErrorOr getCurrentWorkingDirectory() const =
> 0;
> +
> + /// Make \a Path an absolute path.
> + ///
> + /// Makes \a Path absolute using the current directory if it is not
> already.
> + /// An empty \a Path will result in the current directory.
> + ///
> + /// /absolute/path => /absolute/path
> + /// relative/../path => /relative/../path
> + ///
> + /// \param Path A path that is modified to be an absolute path.
> + /// \returns success if \a path has been made absolute, otherwise a
> + /// platform-specific error_code.
> + std::error_code makeAbsolute(SmallVectorImpl &Path) const;
> };
>
> /// \brief Gets an \p vfs::FileSystem for the 'real' file system, as seen
> by
> @@ -230,6 +249,8 @@ public:
>llvm::ErrorOr>
>openFileForRead(const Twine &Path) override;
>directory_iterator dir_begin(const Twine &Dir, std::error_code &EC)
> override;
> + llvm::ErrorOr getCurrentWorkingDirectory() const override;
> + std::error_code setCurrentWorkingDirectory(const Twine &Path) override;
>
>typedef FileSystemList::reverse_iterator iterator;
>
> @@ -248,6 +269,7 @@ class InMemoryDirectory;
> /// An in-memory file system.
> class InMemoryFileSystem : public FileSystem {
>std::unique_ptr Root;
> + std::string WorkingDirectory;
>
> public:
>InMemoryFileSystem();
> @@ -260,6 +282,13 @@ public:
>llvm::ErrorOr>
>openFileForRead(const Twine &Path) override;
>directory_iterator dir_begin(const Twine &Dir, std::error_code &EC)
> override;
> + llvm::ErrorOr getCurrentWorkingDirectory() const override {
> +return WorkingDirectory;
> + }
> + std::error_code setCurrentWorkingDirectory(const Twine &Path) override {
> +WorkingDirectory = Path.str();
> +return std::error_code();
> + }
> };
>
> /// \brief Get a globally unique ID for a virtual file or directory.
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=249316&r1=249315&r2=249316&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Oct 5 08:55:20 2015
> @@ -89,6 +89,14 @@ FileSystem::getBufferForFile(const llvm:
>return (*F)->getBuffer(Name, FileSize, RequiresNullTerminator,
> IsVolatile);
> }
>
> +std::error_code FileSystem::makeAbsolute(SmallVectorImpl &Path)
> const {
> + auto WorkingDir = getCurrentWorkingDirectory();
> + if (!WorkingDir)
> +return WorkingDir.getError();
> +
> + return llvm::sys::fs::make_absolute(WorkingDir.get(), Path);
> +}
>
Ben,
This is causing:
tools/clang/lib/Basic/VirtualFileSystem.cpp:105:57: error: too many
arguments to function call, expected single argument 'path', have 2
arguments
return llvm::sys::fs::make_absolute(WorkingDir.get(), Path);
^~~~
[...]/llvm/llvm/include/llvm/Support/FileSystem.h:280:1: note:
'make_absolute' declared here
std::error_code make_absolute(SmallVectorImpl &path);
^
1 error generated.
Not sure which of t
Re: r249316 - [VFS] Add working directories to every virtual file system.
Never mind. My llvm and clang trees were out of sync.
Diego.
On Mon, Oct 5, 2015 at 11:15 AM, Diego Novillo wrote:
>
>
> On Mon, Oct 5, 2015 at 9:55 AM, Benjamin Kramer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: d0k
>> Date: Mon Oct 5 08:55:20 2015
>> New Revision: 249316
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=249316&view=rev
>> Log:
>> [VFS] Add working directories to every virtual file system.
>>
>> For RealFileSystem this is getcwd()/chdir(), the synthetic file systems
>> can
>> make up one for themselves. OverlayFileSystem now synchronizes the working
>> directories when a new FS is added to the overlay or the overlay working
>> directory is set. This allows purely artificial file systems that have
>> zero
>> ties to the underlying disks.
>>
>> Differential Revision: http://reviews.llvm.org/D13430
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=249316&r1=249315&r2=249316&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
>> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Oct 5 08:55:20
>> 2015
>> @@ -199,6 +199,25 @@ public:
>>/// \note The 'end' iterator is directory_iterator().
>>virtual directory_iterator dir_begin(const Twine &Dir,
>> std::error_code &EC) = 0;
>> +
>> + /// Set the working directory. This will affect all following
>> operations on
>> + /// this file system and may propagate down for nested file systems.
>> + virtual std::error_code setCurrentWorkingDirectory(const Twine &Path)
>> = 0;
>> + /// Get the working directory of this file system.
>> + virtual llvm::ErrorOr getCurrentWorkingDirectory() const
>> = 0;
>> +
>> + /// Make \a Path an absolute path.
>> + ///
>> + /// Makes \a Path absolute using the current directory if it is not
>> already.
>> + /// An empty \a Path will result in the current directory.
>> + ///
>> + /// /absolute/path => /absolute/path
>> + /// relative/../path => /relative/../path
>> + ///
>> + /// \param Path A path that is modified to be an absolute path.
>> + /// \returns success if \a path has been made absolute, otherwise a
>> + /// platform-specific error_code.
>> + std::error_code makeAbsolute(SmallVectorImpl &Path) const;
>> };
>>
>> /// \brief Gets an \p vfs::FileSystem for the 'real' file system, as
>> seen by
>> @@ -230,6 +249,8 @@ public:
>>llvm::ErrorOr>
>>openFileForRead(const Twine &Path) override;
>>directory_iterator dir_begin(const Twine &Dir, std::error_code &EC)
>> override;
>> + llvm::ErrorOr getCurrentWorkingDirectory() const override;
>> + std::error_code setCurrentWorkingDirectory(const Twine &Path) override;
>>
>>typedef FileSystemList::reverse_iterator iterator;
>>
>> @@ -248,6 +269,7 @@ class InMemoryDirectory;
>> /// An in-memory file system.
>> class InMemoryFileSystem : public FileSystem {
>>std::unique_ptr Root;
>> + std::string WorkingDirectory;
>>
>> public:
>>InMemoryFileSystem();
>> @@ -260,6 +282,13 @@ public:
>>llvm::ErrorOr>
>>openFileForRead(const Twine &Path) override;
>>directory_iterator dir_begin(const Twine &Dir, std::error_code &EC)
>> override;
>> + llvm::ErrorOr getCurrentWorkingDirectory() const override
>> {
>> +return WorkingDirectory;
>> + }
>> + std::error_code setCurrentWorkingDirectory(const Twine &Path) override
>> {
>> +WorkingDirectory = Path.str();
>> +return std::error_code();
>> + }
>> };
>>
>> /// \brief Get a globally unique ID for a virtual file or directory.
>>
>> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=249316&r1=249315&r2=249316&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
>> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Oct 5 08:55:20 2015
>> @@ -89,6 +89,14 @@ FileSystem::getBufferForFile(const llvm:
>>return (*F)->getBuffer(Name, FileSize, RequiresNullTerminator,
>> IsVolatile);
>> }
>>
>> +std::error_code FileSystem::makeAbsolute(SmallVectorImpl &Path)
>> const {
>> + auto WorkingDir = getCurrentWorkingDirectory();
>> + if (!WorkingDir)
>> +return WorkingDir.getError();
>> +
>> + return llvm::sys::fs::make_absolute(WorkingDir.get(), Path);
>> +}
>>
>
> Ben,
>
> This is causing:
>
> tools/clang/lib/Basic/VirtualFileSystem.cpp:105:57: error: too many
> arguments to function call, expected single argument 'path', have 2
> arguments
> return llvm::sys::fs::make_absolute(Wo
r245941 - Convert SampleProfile pass into a Module pass.
Author: dnovillo
Date: Tue Aug 25 10:25:13 2015
New Revision: 245941
URL: http://llvm.org/viewvc/llvm-project?rev=245941&view=rev
Log:
Convert SampleProfile pass into a Module pass.
Eventually, we will need sample profiles to be incorporated into the
inliner's cost models. To do this, we need the sample profile pass to
be a module pass.
This patch makes no functional changes beyond the mechanical adjustments
needed to run SampleProfile as a module pass.
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=245941&r1=245940&r2=245941&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Aug 25 10:25:13 2015
@@ -166,14 +166,6 @@ static void addObjCARCOptPass(const Pass
PM.add(createObjCARCOptPass());
}
-static void addSampleProfileLoaderPass(const PassManagerBuilder &Builder,
- legacy::PassManagerBase &PM) {
- const PassManagerBuilderWrapper &BuilderWrapper =
- static_cast(Builder);
- const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
- PM.add(createSampleProfileLoaderPass(CGOpts.SampleProfileFile));
-}
-
static void addAddDiscriminatorsPass(const PassManagerBuilder &Builder,
legacy::PassManagerBase &PM) {
PM.add(createAddDiscriminatorsPass());
@@ -301,10 +293,6 @@ void EmitAssemblyHelper::CreatePasses()
PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible,
addAddDiscriminatorsPass);
- if (!CodeGenOpts.SampleProfileFile.empty())
-PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible,
- addSampleProfileLoaderPass);
-
// In ObjC ARC mode, add the main ARC optimization passes.
if (LangOpts.ObjCAutoRefCount) {
PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible,
@@ -423,6 +411,9 @@ void EmitAssemblyHelper::CreatePasses()
MPM->add(createInstrProfilingPass(Options));
}
+ if (!CodeGenOpts.SampleProfileFile.empty())
+MPM->add(createSampleProfileLoaderPass(CodeGenOpts.SampleProfileFile));
+
PMBuilder.populateModulePassManager(*MPM);
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r250310 - Sample profiles - Update text profile documentation.
Author: dnovillo Date: Wed Oct 14 13:37:39 2015 New Revision: 250310 URL: http://llvm.org/viewvc/llvm-project?rev=250310&view=rev Log: Sample profiles - Update text profile documentation. There's been some changes to the text encoding for sample profiles. This updates the documentation and an example. Modified: cfe/trunk/docs/UsersManual.rst Modified: cfe/trunk/docs/UsersManual.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=250310&r1=250309&r2=250310&view=diff == --- cfe/trunk/docs/UsersManual.rst (original) +++ cfe/trunk/docs/UsersManual.rst Wed Oct 14 13:37:39 2015 @@ -1355,15 +1355,18 @@ read by the backend. LLVM supports three 1. ASCII text. This is the easiest one to generate. The file is divided into sections, which correspond to each of the functions with profile - information. The format is described below. + information. The format is described below. It can also be generated from + the binary or gcov formats using the ``llvm-profdata`` tool. 2. Binary encoding. This uses a more efficient encoding that yields smaller - profile files, which may be useful when generating large profiles. It can be - generated from the text format using the ``llvm-profdata`` tool. + profile files. This is the format generated by the ``create_llvm_prof`` tool + in http://github.com/google/autofdo. 3. GCC encoding. This is based on the gcov format, which is accepted by GCC. It - is only interesting in environments where GCC and Clang co-exist. Similarly - to the binary encoding, it can be generated using the ``llvm-profdata`` tool. + is only interesting in environments where GCC and Clang co-exist. This + encoding is only generated by the ``create_gcov`` tool in + http://github.com/google/autofdo. It can be read by LLVM and + ``llvm-profdata``, but it cannot be generated by either. If you are using Linux Perf to generate sampling profiles, you can use the conversion tool ``create_llvm_prof`` described in the previous section. @@ -1382,14 +1385,27 @@ of the other two, consult the ``ProfileD .. code-block:: console function1:total_samples:total_head_samples -offset1[.discriminator]: number_of_samples [fn1:num fn2:num ... ] -offset2[.discriminator]: number_of_samples [fn3:num fn4:num ... ] -... -offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ] - -The file may contain blank lines between sections and within a -section. However, the spacing within a single line is fixed. Additional -spaces will result in an error while reading the file. + offset1[.discriminator]: number_of_samples [fn1:num fn2:num ... ] + offset2[.discriminator]: number_of_samples [fn3:num fn4:num ... ] + ... + offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ] + offsetA[.discriminator]: fnA:num_of_total_samples + offsetA1[.discriminator]: number_of_samples [fn7:num fn8:num ... ] + offsetA1[.discriminator]: number_of_samples [fn9:num fn10:num ... ] + offsetB[.discriminator]: fnB:num_of_total_samples + offsetB1[.discriminator]: number_of_samples [fn11:num fn12:num ... ] + +This is a nested tree in which the identation represents the nesting level +of the inline stack. There are no blank lines in the file. And the spacing +within a single line is fixed. Additional spaces will result in an error +while reading the file. + +Any line starting with the '#' character is completely ignored. + +Inlined calls are represented with indentation. The Inline stack is a +stack of source locations in which the top of the stack represents the +leaf function, and the bottom of the stack represents the actual +symbol to which the instruction belongs. Function names must be mangled in order for the profile loader to match them in the current translation unit. The two numbers in the @@ -1398,6 +1414,14 @@ function (first number), and the total n in the prologue of the function (second number). This head sample count provides an indicator of how frequently the function is invoked. +There are two types of lines in the function body. + +- Sampled line represents the profile information of a source location. + ``offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ]`` + +- Callsite line represents the profile information of an inlined callsite. + ``offsetA[.discriminator]: fnA:num_of_total_samples`` + Each sampled line may contain several items. Some are optional (marked below): @@ -1451,6 +1475,24 @@ d. [OPTIONAL] Potential call targets and instruction that calls one of ``foo()``, ``bar()`` and ``baz()``, with ``baz()`` being the relatively more frequently called target. +As an example, consider a program with the call chain ``main -> foo -> bar``. +When built with optimizations enabled, the compiler may inline the +calls to ``bar`` and ``foo`` inside ``main``. The generated profile +could
r250705 - Sample Profiles - Fix location of binary encoding documentation. NFC.
Author: dnovillo Date: Mon Oct 19 10:53:17 2015 New Revision: 250705 URL: http://llvm.org/viewvc/llvm-project?rev=250705&view=rev Log: Sample Profiles - Fix location of binary encoding documentation. NFC. Modified: cfe/trunk/docs/UsersManual.rst Modified: cfe/trunk/docs/UsersManual.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=250705&r1=250704&r2=250705&view=diff == --- cfe/trunk/docs/UsersManual.rst (original) +++ cfe/trunk/docs/UsersManual.rst Mon Oct 19 10:53:17 2015 @@ -1380,7 +1380,7 @@ Sample Profile Text Format This section describes the ASCII text format for sampling profiles. It is, arguably, the easiest one to generate. If you are interested in generating any of the other two, consult the ``ProfileData`` library in in LLVM's source tree -(specifically, ``llvm/lib/ProfileData/SampleProfWriter.cpp``). +(specifically, ``include/llvm/ProfileData/SampleProfReader.h``). .. code-block:: console ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D21737: [PATCH] [CodeGen] Insert TargetLibraryInfoWrapperPass before anything else.
dnovillo accepted this revision. dnovillo added a comment. This revision is now accepted and ready to land. LGTM Repository: rL LLVM http://reviews.llvm.org/D21737 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D21823: [Driver] Add flags for enabling both types of PGO Instrumentation
On Sat, Jul 9, 2016 at 7:39 PM Sean Silva wrote: > silvas added a comment. > > In http://reviews.llvm.org/D21823#479418, @davidxl wrote: > > > I should have brought it up earlier, but I forgot.I think a better > (and simpler) proposal is to make -fprofile-generate and -fprofile-use turn > on IR based PGO. > > > > -fprofile-generate and -fprofile-use options were introduced by Diego > (cc'ed) recently for GCC option compatibility. At that time, IR based PGO > was not yet ready, so they were made aliases to FE instrumentation options > -fprofile-instr-generate and -fprofile-instr-use.Now I think it is time > to make it right. The documentation only says that these two options are > gcc compatible options to control profile generation and use, but does not > specify the underlying implementation. It is also likely that Google is the > only user of this option. If a user using this option really want FE > instrumentation, there is always -fprofile-instr-generate to use. It also > more likely that IR instrumentation is what user wants when using GCC > compatible options (as they behave more similarly). > > > This SGTM. > Likewise. > > It may cause some user confusion since there is no obvious distinction > between "profile generate" and "profile instr generate" from a user > perspective. But we can avoid that with improved documentation. > > My main concern is that the existing documentation already says that > -fprofile-generate behaves identically to -fprofile-instr-generate > http://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate > However, I think it is reasonable to change this behavior (and of course > the documentation), as users of this option are likely using it for > compatibility with GCC and so they likely don't care about the specifics of > clang FEPGO. > We probably want to at least leave a small note in the documentation > regarding this change of behavior. > I think the change in behaviour is needed. Better to make a clean break now that it is early enough in the PGO life cycle. Adding a note about it will help current users. Diego. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.
Nico, this is producing tons of warnings on an LLVM build and is actually
breaking our internal builds (we build with -Werror).
I fixed one file that was producing this, but there are several that have
the same problem (e.g., gtest-port.h). Could you fix them or rollback?
Thanks. Diego.
On Tue, Jan 19, 2016 at 10:15 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: nico
> Date: Tue Jan 19 09:15:31 2016
> New Revision: 258128
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258128&view=rev
> Log:
> Add -Wexpansion-to-undefined: warn when using `defined` in a macro
> definition.
>
> [cpp.cond]p4:
> Prior to evaluation, macro invocations in the list of preprocessing
> tokens that will become the controlling constant expression are replaced
> (except for those macro names modified by the 'defined' unary operator),
> just as in normal text. If the token 'defined' is generated as a result
> of this replacement process or use of the 'defined' unary operator does
> not match one of the two specified forms prior to macro replacement, the
> behavior is undefined.
>
> This isn't an idle threat, consider this program:
> #define FOO
> #define BAR defined(FOO)
> #if BAR
> ...
> #else
> ...
> #endif
> clang and gcc will pick the #if branch while Visual Studio will take the
> #else branch. Emit a warning about this undefined behavior.
>
> One problem is that this also applies to function-like macros. While the
> example above can be written like
>
> #if defined(FOO) && defined(BAR)
> #defined HAVE_FOO 1
> #else
> #define HAVE_FOO 0
> #endif
>
> there is no easy way to rewrite a function-like macro like `#define FOO(x)
> (defined __foo_##x && __foo_##x)`. Function-like macros like this are
> used in
> practice, and compilers seem to not have differing behavior in that case.
> So
> this a default-on warning only for object-like macros. For function-like
> macros, it is an extension warning that only shows up with `-pedantic`.
> (But it's undefined behavior in both cases.)
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
> cfe/trunk/lib/Lex/PPExpressions.cpp
> cfe/trunk/test/Lexer/cxx-features.cpp
> cfe/trunk/test/Preprocessor/expr_define_expansion.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=258128&r1=258127&r2=258128&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Jan 19 09:15:31
> 2016
> @@ -204,6 +204,7 @@ def OverloadedShiftOpParentheses: DiagGr
> def DanglingElse: DiagGroup<"dangling-else">;
> def DanglingField : DiagGroup<"dangling-field">;
> def DistributedObjectModifiers :
> DiagGroup<"distributed-object-modifiers">;
> +def ExpansionToUndefined : DiagGroup<"expansion-to-undefined">;
> def FlagEnum : DiagGroup<"flag-enum">;
> def IncrementBool : DiagGroup<"increment-bool",
> [DeprecatedIncrementBool]>;
> def InfiniteRecursion : DiagGroup<"infinite-recursion">;
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=258128&r1=258127&r2=258128&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Tue Jan 19
> 09:15:31 2016
> @@ -658,6 +658,13 @@ def warn_header_guard : Warning<
> def note_header_guard : Note<
>"%0 is defined here; did you mean %1?">;
>
> +def warn_defined_in_object_type_macro : Warning<
> + "macro expansion producing 'defined' has undefined behavior">,
> + InGroup;
> +def warn_defined_in_function_type_macro : Extension<
> + "macro expansion producing 'defined' has undefined behavior">,
> + InGroup;
> +
> let CategoryName = "Nullability Issue" in {
>
> def err_pp_assume_nonnull_syntax : Error<"expected 'begin' or 'end'">;
>
> Modified: cfe/trunk/lib/Lex/PPExpressions.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPExpressions.cpp?rev=258128&r1=258127&r2=258128&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/PPExpressions.cpp (original)
> +++ cfe/trunk/lib/Lex/PPExpressions.cpp Tue Jan 19 09:15:31 2016
> @@ -140,6 +140,51 @@ static bool EvaluateDefined(PPValue &Res
> PP.LexNonComment(PeekTok);
>}
>
> + // [cpp.cond]p4:
> + // Prior to evaluation, macro invocations in the list of preprocessing
> + // tokens that will become the controlling constant expression are
> replaced
> + // (except for those macro names modified by the 'defined' unary
> operato
Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.
On Tue, Jan 19, 2016 at 3:30 PM, Nico Weber wrote: > I'll take a look. If it's urgent it's also possible to disable this > warning. > Yeah. I think disabling it by default may be the better choice. Thanks. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.
On Tue, Jan 19, 2016 at 3:43 PM, Nico Weber wrote: > I mean you could pass a -Wno flag. It's undefined behavior that's actually > causing bugs in practice; it should probably be on by default. > But then you need to fix all the warnings it's producing in an llvm build. That is currently blocking several folks (us included). ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r258128 - Add -Wexpansion-to-undefined: warn when using `defined` in a macro definition.
Thanks! On Jan 19, 2016 3:34 PM, "Nico Weber" wrote: > I think I've fixed all warnings by now, and I've reenabled the warning for > LLVM builds (in r258210; that commit's commit message links to the > individual fixes.) > > On Tue, Jan 19, 2016 at 3:56 PM, Nico Weber wrote: > >> r258181 should stop the bleeding. I'll look at fixing the warnings now. >> >> On Tue, Jan 19, 2016 at 3:46 PM, Nico Weber wrote: >> >>> Back at my desk now, looking. >>> >>> On Tue, Jan 19, 2016 at 3:44 PM, Diego Novillo >>> wrote: >>> On Tue, Jan 19, 2016 at 3:43 PM, Nico Weber wrote: > I mean you could pass a -Wno flag. It's undefined behavior that's > actually causing bugs in practice; it should probably be on by default. > But then you need to fix all the warnings it's producing in an llvm build. That is currently blocking several folks (us included). >>> >>> >> > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255809 - Add -fsyntax-only to fix failure in read-only directories.
Author: dnovillo Date: Wed Dec 16 13:52:05 2015 New Revision: 255809 URL: http://llvm.org/viewvc/llvm-project?rev=255809&view=rev Log: Add -fsyntax-only to fix failure in read-only directories. Internally, this test is executed in a read-only directory, which causes it to fail because the driver tries to generate a file unnecessarily. Adding -fsyntax-only fixes the issue (thanks to Artem Belevich for figuring out the root cause). Modified: cfe/trunk/test/Driver/elfiamcu-header-search.c Modified: cfe/trunk/test/Driver/elfiamcu-header-search.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/elfiamcu-header-search.c?rev=255809&r1=255808&r2=255809&view=diff == --- cfe/trunk/test/Driver/elfiamcu-header-search.c (original) +++ cfe/trunk/test/Driver/elfiamcu-header-search.c Wed Dec 16 13:52:05 2015 @@ -1,6 +1,6 @@ // REQUIRES: x86-registered-target -// RUN: %clang -target i386-pc-elfiamcu -c -v %s 2>&1 | FileCheck %s +// RUN: %clang -target i386-pc-elfiamcu -c -v -fsyntax-only %s 2>&1 | FileCheck %s // CHECK-NOT: /usr/include // CHECK-NOT: /usr/local/include ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
