gmane.comp.compilers.clang.devel

Crisp: Coding rule checking using clang and LLVM

Guillem Marpons — 2012-05-17T00:14:15

Hi,

I've been working the last months on a coding rule validation add-on
for clang/LLVM, called Crisp:

    https://github.com/gmarpons/Crisp

Coding Rules constrain admissible constructs of a language to help
produce better code (improving reliability, portability,
maintainability, etc.). Some well-known coding rule sets are:

- MISRA-C/C++ (no public access available)
- High Integrity C++ Coding Standard (HICPP): http://www.codingstandard.com/
- CERT's Secure Coding Standards: http://www.cert.org/secure-coding/

Coding rule sets can include style conventions but they go typically
further. Rules range from purely syntactic properties (e.g. "Do not
use the ‘inline’ keyword for member functions") to those that need
deep static analyses to be automated (e.g. "Do not return non-const
handles to class data from const member functions", both examples are
from HICPP).

There are some tools that can be used to define and enforce coding
rules on C/C++ code. Some distinctive features of our tool are:

- Rules (i

Re: -no-implicit-float for ARM

Sandeep Patel — 2012-05-16T22:30:56

Perhaps I'm just missing something here, but why would I want the FP
hardware to be used implicitly if I have -msoft-float set? I could see
doing so if -mfloat-abi=soft, but not if we're fully soft-float.

deep

Re: Obtaining C++ AST.

Manuel Klimek — 2012-05-16T22:15:42

See:
http://clang.llvm.org/docs/Tooling.html
http://clang.llvm.org/docs/RAVFrontendAction.html

and in case you decide to give LibTooling a try:
http://clang.llvm.org/docs/LibTooling.html

Cheers,
/Manuel

On Wed, May 16, 2012 at 10:38 PM, Slav <slavmfm-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: [RFC] Bump up clang's __GNUC_MINOR__

Joerg Sonnenberger — 2012-05-16T20:32:48

Fully agreed. There are very few things that *fail* because of that,
e.g. current db4 is one example because they want to redefine a builtin.
Except that, it is mostly a question of quality of implementation, if
additional builtins are used.

Joerg

Obtaining C++ AST.

Slav — 2012-05-16T20:38:26

Hello.
I am traying to get AST of specified file and iterate trough it. Here is my
code:


class MyDiagnosticConsumer: public clang::DiagnosticConsumer
{
public:
    clang::DiagnosticConsumer* clone(clang::DiagnosticsEngine &Diags) const
    {
        return new MyDiagnosticConsumer;
    }
};

class MyModuleLoader: public clang::ModuleLoader
{
public:
    clang::Module* loadModule(clang::SourceLocation importLoc,
clang::ModuleIdPath path, clang::Module::NameVisibilityKind visibility,
bool isInclusionDirective)
    {
        //just do some parsing, forget about modules:
        return NULL;
    }
};

class MyASTConsumer: public clang::SemaConsumer
{
public:

    bool HandleTopLevelDecl(clang::DeclGroupRef D)
    {
        //never get here...

        return true;
    }

    void HandleTranslationUnit(clang::ASTContext &Ctx)
    {
        //not here either...
    }
};


int main()
{
    clang::IntrusiveRefCntPtr<clang::DiagnosticIDs> diags;
    MyDiagnosticConsumer dc;
    clang::DiagnosticsEngine de(diags, &d

Re: [RFC] Bump up clang's __GNUC_MINOR__

Benjamin Kramer — 2012-05-16T19:56:16

On 16.05.2012, at 21:09, PaX Team wrote:


ah, ok. I guess they left it in the tree for entertainment purposes then.


Their runtime stuff (initfini.c) uses a weird mixture of module-level inline
asm and C code which breaks when the compiler doesn't preserve the
order.


Apart from integrated-as issues, which is mostly missing support for some
macros and some other minor issues, missing support for tls_model is an
issue, but that should be fixable if someone really cares.

Their configure script also checks for http://llvm.org/bugs/show_bug.cgi?id=12554
which is … crazy.


It is a hardening feature and there are hundreds of projects out there that
enable it by default in their makefiles. It may not give a lot of value but
discouraging its use will only bring us "clang is insecure" comments and
angry users.

- Ben

Re: [RFC] Bump up clang's __GNUC_MINOR__

PaX Team — 2012-05-16T19:09:07


__builtin_return/__builtin_apply seem to be used in dlfcn/eval.c only
which is no longer built by glibc since 2004 according to git log.

-fno-toplevel-reorder can be a real problem, i wonder where glibc relies
on its behaviour though.

are you aware of any other incompatibility that prevents clang from
compiling glibc (i'm just preparing mentally for the day i get to try
this one day ;)?


ok, i misunderstood the original issue as being with glibc itself, not
with its headers used everywhere else. in that case i suggest that you
simply ignore this problem and stipulate that distros building with
clang not define _FORTIFY_SOURCE (it's not a big loss anyway).

Re: [RFC] Bump up clang's __GNUC_MINOR__

David Chisnall — 2012-05-16T18:03:35


Technically, we don't do that for 4.2 either, since we don't implement the __builtin_apply() stuff, which GCC 4.2 does (or, rather, claims to - it works in some cases on some platforms), nor do we support nested functions (unless someone added that while I was asleep).  

Perhaps I missed something, but I am not certain what the advantage of bumping the gcc version that we claim is.  We are not gcc, we are clang.  We advertise GCC 4.2 compatibility, because that makes porting code easier - anything that worked with GCC 4.2 should work with clang.  

We also provide a rich set of feature test macros that allow people to check for specific features.  By chasing a specific GCC version, we would be telling people that GCC is the standard compiler, look to it for a reference.  I don't believe this is the correct message to be sending.  The definition of __GNUC__ should be regarded as a legacy compatibility hack, not a maintained feature.

If the real problem is glibc not turning on features that we support, the

Re: ParamDecls missing from function DeclContext

Abramo Bagnara — 2012-05-16T17:49:50

Il 16/05/2012 17:57, Douglas Gregor ha scritto:

Just to be clear, I was not thinking to transform FunctionTypeLoc in a
DeclContext, but to put a DeclContext* in FunctionTypeLoc data.

This pointer points to FunctionDecl itself when the FunctionTypeLoc is
the type of a FunctionDecl, otherwise it points to a specific class
derived from DeclContext (FunctionTypeDeclContext?) that contains only
the ParmVarDecl's.


How you would skip them?

What about template instantiation of these? Everything would be added to
TranslationUnit?

Perhaps I'm the only to feel this way, but to add Decls to contexts
where they don't belong sincerely appears like a little mess to me...

Re: Using scan-build with custom checker plugins

Anna Zaks — 2012-05-16T17:39:23

Hi Thomas,

I am not aware of anyone else using scan-build with plugin checkers. I think the best way to implement this would be to add command line options to scan-build to specify the plugins and have scan-build pass those on to c++-analyzer. This is how other flags are supported, for example, see "-enable-checker". Would be great if you submit the patch for this to the open source codebase!

Cheers,
Anna.


On May 16, 2012, at 5:49 AM, Thomas Hauth wrote:



_______________________________________________
cfe-dev mailing list
cfe-dev-Tmj1lob9twqVc3sceRu5cw< at >public.gmane.org
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: [RFC] Bump up clang's __GNUC_MINOR__

Chandler Carruth — 2012-05-16T17:04:38



This isn't about compiling glibc, it's about compiling the *public glibc
headers*. As a consequence, any code which (transitively) includes a glibc
header would break.
_______________________________________________
cfe-dev mailing list
cfe-dev-Tmj1lob9twqVc3sceRu5cw< at >public.gmane.org
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: [RFC] Bump up clang's __GNUC_MINOR__

Konstantin Tokarev — 2012-05-16T16:58:37


16.05.2012, 17:19, "Benjamin Kramer" <benny.kra< at >googlemail.com>:

I think if you claim that compiler is a drop-in replacement of certain GCC version you must support all of its intrinsics, and glibc is merely a test case.

Re: -no-implicit-float for ARM

Chad Rosier — 2012-05-16T16:44:25

On May 14, 2012, at 5:43 PM, Sandeep Patel <deeppatel1987-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


No, -msoft-float does not imply -no-implicit-float on ARM.


Yes, I would like to be able to use -no-implicit-float in isolation.

 Chad

Re: getting clang to find non-default libstdc++

Marc J. Driftmeyer — 2012-05-16T16:43:14

Doing an update on clang pulled in libcxx and compiler-rt.

Removing both today only restores place holders and a Makefile for both 
compiler-rt and libcxx.

So clearly, something prematurely got injected into both of those paths.

- Marc

On 05/16/2012 06:41 AM, Chandler Carruth wrote:

Re: [RFC] Bump up clang's __GNUC_MINOR__

Benjamin Kramer — 2012-05-16T16:10:14

On 16.05.2012, at 18:01, PaX Team wrote:


that's easy:
clang -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 foo.c

However the problem is not compiling glibc. That's something completely different that won't ever work with clang unless the glibc maintainers move. It uses extensions that are broken beyond repair like __builtin_apply and -fno-toplevel-reorder, making it a lot worse to deal with than the linux kernel.

The problem is that glibc uses those extensions in the standard header files (if FORTIFY_SOURCE is specified) so any code base using e.g. stdio.h and FORTIFY_SOURCE will have to change the gcc version clang simulates, which is not acceptable.

- Ben

Re: [RFC] Bump up clang's __GNUC_MINOR__

PaX Team — 2012-05-16T16:01:42


have you considered making the simulated/claimed gcc version configurable
on the clang command line? this way distros/etc could just set it in the
CFLAGS used for compiling glibc, so it'd be a very simple change in the
existing build/packaging systems.

cheers,
 PaX Team

Re: ParamDecls missing from function DeclContext

Douglas Gregor — 2012-05-16T15:57:58

On May 16, 2012, at 2:23 AM, Abramo Bagnara wrote:



The C(++) languages don't actually place such declarations in any particular context, so it's not clear where they belong in the AST. Introducing some kind of abstract function declaration  that is the DeclContext might conceivably work, but that's a rather heavyweight solution just to maintain an invariant. Using FunctionTypeLoc doesn't really work, because DeclContexts are supposed to be Decls.

Personally, I'm fine with having parameters in the lexical DeclContext of the translation unit for this case, but we can investigate other designs.

- Doug

Re: Why clang creates ELF section group with only one section in it?

Dmitri Shubin — 2012-05-16T15:18:43

Hi Rafael!

On 16.05.2012 16:46, Rafael Espíndola wrote:

Opened http://llvm.org/bugs/show_bug.cgi?id=12851

Thanks!
_______________________________________________
cfe-dev mailing list
cfe-dev< at >cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: [RFC] Bump up clang's __GNUC_MINOR__

Benjamin Kramer — 2012-05-16T14:08:10

On 16.05.2012, at 15:40, Rafael Espíndola wrote:


__builtin_va_arg_pack was introduced in 4.3 and is used by glibc as a wrapper for many vararg functions when FORTIFY_SOURCE is enabled. We can't afford breaking open(2) for everyone on linux :(

Arguing against uses of __builtin_va_arg_pack is also hard, as the only other way to implement the same features for FORTIFY_SOURCE is a variadic macro. While this is perfectly fine with the standard, some code may break if it sees a macro instead of a real function.

It may be possible to persuade the glibc maintiners into using the same fallback path as gcc 4.2 uses (some stuff is implemented with macros and some checks seem to be missing). But turnaround time for glibc is really slow. Debian stable is still stuck at a 3 year old version and RHEL is probably even older.

- Ben

Re: getting clang to find non-default libstdc++

Chandler Carruth — 2012-05-16T13:41:56

I dunno what this error is, will look into it more depth later, but the
patch I committed only touched documentation, so it seems unlikely to have
caused this. I suspect these are independent issues.

On Wed, May 16, 2012 at 3:50 AM, Marc J. Driftmeyer <mjd-32keA/m2dUefJOJzLBvvIA< at >public.gmane.org>wrote:

_______________________________________________
cfe-dev mailing list
cfe-dev-Tmj1lob9twqVc3sceRu5cw< at >public.gmane.org
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: [RFC] Bump up clang's __GNUC_MINOR__

Rafael Espíndola — 2012-05-16T13:40:28

What version of glibc do we have to support? It does look like the
current maintainers are more reasonable, so if the really bad parts
were fixed we   might be able to bump GNUC_MINOR one day.

Would it be worth it trying to bump it to only 4.3 for now?


Cheers,
Rafael