Fallout from fixing bug 354311

Milian Wolff mail at milianw.de
Sun Feb 14 14:52:31 UTC 2016


On Sonntag, 14. Februar 2016 15:35:49 CET Maciej Cencora wrote:
> Hi,
> 
> 2016-02-14 11:44 GMT+01:00 Milian Wolff <mail at milianw.de>:
> > On Freitag, 12. Februar 2016 16:51:19 CET Maciej Cencora wrote:
> > > Hi,
> > > 
> > > commit 170edf25 "Improve GCC compatibility by adding stubs for some
> > > builtins" fixed bug 354311 by adding stubbed version of gcc builtins.
> > > 
> > > Besides the caveats already mentioned in the commit this fix has two
> > 
> > more:
> > > 1) it depends on specific gcc version, if new gcc introduces new
> > > builtins
> > > we will have to modify our stubbed version accordingly
> > 
> > Yep, when I wrote this I was not aware how much in flux this list really
> > is.
> > 
> > > 2) it breaks code completion since now clang proposes all the __builin_*
> > > symbols as candidates
> > 
> > Should be simple to filter out.
> 
> Maybe it is, but I suppose it will still have negative perf impact since
> there are ~1000 of these.

That difference is negligible. If you think you feel the performance impact, 
just use a clang compiler in the config page and you won't be affected by this 
change at all. Just to make it clear: The patch that affects bug 354311 only 
kicks in when you have selected a non-clang compiler.

> > > With the last issue being very annoying, I think current solution is not
> > > the right way to solve the original problem.
> > 
> > I'm open for better suggestions.
> > 
> > > In my opinion the proper fix would be to pass the same options to parser
> > 
> > as
> > 
> > > one would use when compiling a project with clang but libstdc++ library.
> > > I.e. all the include directories, compilation options and preprocessor
> > > definitions should be fetched from:
> > > clang++ -stdlib=libstdc++ -dM -E - < /dev/null
> > > instead of from g++!
> > 
> > When clang is installed, then it will be used by default. If you don't use
> > it,
> > then either you manually selected GCC, or have run KDevelop before the
> > change
> > got it a few weeks ago, and the old default (gcc) got persisted.
> > 
> > You can select the compiler of choice from within the compiler & includes/
> > defines configuration page of a project.
> 
> Yes, I am aware of that and if I wasn't clear enough the following three
> points correspond to the option chosen from compiler & includes config page.

See below, we seem to be talking about different things.

> > > Considering we officially support 3 compilers my proposal is:
> > > If selected compiler is
> > > 1) GCC -> take options from "clang++ -stdlib=libstdc++ -dM -E - <
> > 
> > /dev/null"
> > 
> > The whole reason we allow the user to change the compiler that is
> > selected, is
> > to emulate its environment. Using the appropriate defines is crucial to
> > get
> > close to the real target environment. GCC is still used extremely often
> > for
> > crosscompile toolchains, and it is really important to use the correct
> > defines
> > there then.
> 
> In my experience using "clang++ -stdlib=libstdc++" is the closest you can
> get to emulate the GCC environment,
> since clang's goal is to be a drop in replacement for gcc.
> You can prove me wrong, but that's what I have been using at work to enable
> sanitizers and additional warnings while we had too old gcc.

I think we are talking about different things here. How would you get the 
defines of a cross compile toolchain using your approach? How would you use 
your approach e.g. when you work against an arm-eabi GCC, where, among others, 
the endianess will be different from your host? Using your clang line will be 
wrong then.

> > > 2) clang -> take options from "clang++ -stdlib=libc++ -dM -E - <
> > 
> > /dev/null"
> > 
> > > by default or use user's -stdlib option
> > 
> > I'm using clang but not libc++, so this will break stuff for me.
> 
> How come?
> If you don't use libc++ then you must be passing -stdlib=libstdc++ and that
> will be forwarded to clang parser too so you will get proper defines and
> includes.

Not true:

$ cat test.cpp
int main() { return 0; }
$ clang++ test.cpp
$ ldd a.out | grep std
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa84e061000)

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160214/f29442a6/attachment.sig>


More information about the KDevelop-devel mailing list