[Interest] to -fno-exceptions or not ...

[Thiago Macieira]

On Wednesday 10 December 2014 20:38:20 René J.V. Bertin wrote:
> >Set the flag. I'm not sure if you'll have problems with QtXmlPatterns, but
> >I don't think you will.
> 
> That's what I saw after reading up a bit more on the topic. But if
> QtXmlPatterns doesn't build without them, I'm stuck with -fexceptions as
> KDE uses QtXmlPatterns ...

Try and see. I think xmlpatterns.pro turns it back on, but I could be wrong. 
You'll see in the output of configure whether it got enabled or not.

> BTW, you didn't confirm if -no-exceptions does or does not put a
> -fno-exceptions in the mkspecs ?

It doesn't add to the mkspec, but it does pass -fno-exceptions in the Qt 
build. The difference is whether it affects other applications built with qmake: 
modifying the mkspec does, the configure option doesn't.

> >Yes. Note we're talking about memory usage, not about code execution
> >performance. The exceptional code paths and the exception tables need to be
> >loaded in memory, even if you never use them. And since Qt does not ever
> >use
> I understood that, but loading into memory is not an instantaneous
> operation, so if the overhead is large enough to be worth mentioning, the
> load time overhead must be measurable too.

You have to measure. The exception tables themselves mustn't be larger than a 
few pages. The big difference is the exceptional code paths. I don't know how 
big the size difference is. In any case, I'm more concerned about L1 cache 
misses than the actual size.

> Fortunately, when comparing the memory footprints between Qt/KDE(4) and Mac
> native applications, the balance is usually very much in favour of the
> former.
>
> >Qt 5 made the option of compiling all modules except for QtCore and
> >QtXmlPatterns without exceptions.
> 
> Why make it an option, if they're not used internally?

It's not an option.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center