Fwd: Re: Fallout from fixing bug 354311

[Milian Wolff]

Forwarding to the mailing list.

@Maciej: please keep the list in CC when answering to my message please.

Thanks

----------  Forwarded Message  ----------

Subject: Re: Fallout from fixing bug 354311
Date: Sonntag, 14. Februar 2016, 21:09:25 CET
From: Milian Wolff <mail at milianw.de>
To: Maciej Cencora <m.cencora at gmail.com>

On Sonntag, 14. Februar 2016 18:37:08 CET Maciej Cencora wrote:
> Hi,
> 
> 2016-02-14 17:24 GMT+01:00 Milian Wolff <mail at milianw.de>:
> > On Sonntag, 14. Februar 2016 16:45:16 CET Maciej Cencora wrote:
> > > Hi,
> > > 
> > > 2016-02-14 15:52 GMT+01:00 Milian Wolff <mail at milianw.de>:
> > > > On Sonntag, 14. Februar 2016 15:35:49 CET Maciej Cencora wrote:
> > <snip>
> > 
> > > > 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.
> > > 
> > > For cross compiling you still won't get proper behavior with current
> > > solution in many cases.
> > > E.g. host machine 64bit, cross compile to 32bit, no amount of macros and
> > > includes fetched from gcc will help here.
> > 
> > Why? When you configure the cross compiler properly (by passing -m32
> > manually,
> > or if that is compiled-in as a default) then it will work.
> 
> Ok, I was under the impression that only defines and includes were passed
> to clang parser.

Yes, but that is - to my knowledge - all that defines the semantic analysis 
step that we need for the IDE usecase. The 32bit vs. 64bit case is handled via 
the defines (and include paths). Note that we disable all of clang's builtin 
include paths and defines and supply them all manually from the list we get 
from the chosen compiler in the settings.

> > > Anyway I don't consider the cross compile scenario a primary use case.
> > > Primary use case is developing for host machine, and that's currently
> > > broken and my solution fixes it reliably.
> > 
> > Why is it broken? So far, the only "brokenness" I can see is the
> > performance
> > claim you made. With GCC 5.3 I see zero issues in the unit test I added
> > back
> > then. What GCC are you using? Can you show the output of the unit test and
> > tell me what is missing so we can extend our list of builtins?
> 
> As you stated in the commit, this won't work for no ia32 architectures.
> You would have to provide gcc builtins for every architecture out there
> which is not really feasible.

I don't think its infeasible, the builtins are countably many after all.

> So basically your "crosscompile to arm" use case is broken right now.

And that is what we need to fix then. Your below proposal would not fix it 
either, as far as I can see.

> Anyway I don't think reaching the 100% correctness for crosscompilation use
> case is possible,

I disagree.

> but it is certainly possible for the primary use case where your target is
> host machine and your compiler is GCC.

And again: What is broken currently with the code we have and this setup? Can 
you please give me some more details as to what issues you are trying to solve 
for your specific usecase?

> So taking that into consideration let me modify my proposal:
> If user selected:
> 1) native GCC (host is same as target):
>     fetch defines and includes from clang++ -stdlib=libc++ -dM -E <
> /dev/null

I still don't think this is a good idea. Nor do I know how one would figure 
out that "host is same as target".

> 2) native clang:
>     clang++ -dM -E < /dev/null
> 3) user defined compiler/crosscompilation, MSVC:
>     as currently

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-----------------------------------------
-- 
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/6000de82/attachment-0001.sig>