Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: RAD Studio 10 - new compiler experiences



Permlink Replies: 5 - Last Post: Oct 26, 2015 3:13 AM Last Post By: Kerem Demir
Josh Kelley

Posts: 75
Registered: 3/6/08
RAD Studio 10 - new compiler experiences
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2015 3:22 PM
Has anyone else tried to upgrade a 32-bit Windows project to use the new
Clang-based compiler yet?

I've spent over a week now updating a 400 kLOC project and am running
into one problem after another, and I was wondering if anyone else has
had more success than me.

Here are my thoughts and experiences so far, in case it helps anyone
else (either to let me know what I could do better or to avoid some
potential stumbling blocks yourself).

The good:

Having a compiler as powerful as Clang is really nice. Its warnings and
code analysis are a lot more powerful than bcc32's and have caught
several latent issues in our code.

The IDE's support for C++ seems much better. The Structure window,
various code navigation tools, and autocomplete all seem to be much more
capable than previous versions. (At least, they're better than XE4; I
haven't spent very much time in XE5 through XE8.) There are several
bugs in the new features, and I still feel like there are significant
shortcomings compared to other tools like Eclipse CDT or Visual C++ -
but I also no longer feel like C++ is RAD Studio's red-headed stepchild,
and that's very much appreciated.

There are, obviously, many worthwhile improvements in RAD Studio 10
besides the new compiler, but that's been my area of focus this week.

The okay:

I expected to spend some time updating code that wasn't
standards-compliant but was accepted by bcc32. Most of these are
relatively easily fixed:

Within templates, type names like "map<String, String::iterator" need to
have "typename" prefixed.

Class template code often needs "this->" added when accessing members.

Compiling templates is stricter: the compiler can catch more errors
before instantiation (which is good), but this also means that, e.g.,
you can't miss an #include when the template is declared and only
provide it later, when it's instantiated.

I had to update some of my use of enums - partly because bcc32c is
stricter about conversions, partly because some of the Delphi RTL enums
have been updated to use C++11's strongly typed enums. Strongly typed
enums are probably a good idea, but it does make for a bit of code
churn. (Not all enums have been updated; if anyone can shed light on
this inconsistency, I'd love to hear.)

We had some code that still depended on ATL, so I'd been copying forward
C++Builder 2010's version of ATL with each RAD Studio upgrade. bcc32c
can no longer compile that version of ATL (there's a lot of
old/non-compliant C++ code there), and bcc32c code probably wouldn't
work with 2010's bcbatl.lib even if it did compile, so I had to update
our code. Embarcadero's been discouraging the use of ATL for a few
years, so I can't complain.

The old bcc32 had trouble with the intersection of C++ features and
Delphi-compatible language extensions. (For example, templates +
closures (event handlers) didn't work well at all, and properties looked
like variables but often failed to act like them.) bcc32c works much
better, although bugs remain - at least one serious (RSP-12250), others
merely annoying (RSP-12300, RSP-12221).

Structured exception handling (SEH) and floating point exceptions seem
to be quite a bit different. I think this will cause some problems for
our code; I'm still trying to figure this out. The docwiki does, at
least, explain this well. (Search for "clang differences.") Floating
point math results are different but are (as far as I can tell) more
accurate. (I maybe ought to investigate more here, but my patience for
manually inspecting floating point calculations is limited.) Evaluating
floating point function calls in the debugger has bugs.

bcc32-compiled code and bcc32c-compiled code don't play well together.
For example, running a bcc32c exe with a bcc32 DLL may give an error,
"The procedure entry point __Unwind_SjLj_Register could not be located."
This incompatibility isn't surprising, but it's not well documented or
communicated either, and error messages like this are downright cryptic.

The bad:

The new toolchain has critical bugs. Writing floating point values to
ostreams is broken (RSP-11914; see there for a partial workaround).
Detecting when header files have changed and source files need to be
recompiled is broken (RSP-11212). These should never have escaped
testing and by themselves may be reason enough to not use bcc32c until
the next update.

C++11 support is not all there. A few language features are missing (as
detailed in the docwiki), although nothing too important to me. Missing
C++11 library features are a bigger problem (and one which isn't well
documented). The new math functions that C++11 took from C99 are
missing. Other C++11 library updates are done incorrectly. For example,
the following code correctly fails to compile in bcc32 (if you don't
define VCL_IOSTREAM or provide your own operator<<):

cout << UnicodeString("Hello, world!\n");

In bcc32c, it compiles: it implicitly calls cout's operator bool (to
determine if cout is valid, even though C++11 says that a stream's bool
operator cannot be implicitly called), converts it to an int, creates a
Variant from the UnicodeString, and calls operator<<(int, Variant) to
left-shift cout's status by "Hello, world!\n"'s amount.

As others have discussed, the new compiler is slow. Parallel
compilation helps, and it even works with command-line builds, which is
much appreciated. However, parallel compilation has problems of its own:
it has to be manually configured on every project (instead of being a
user-wide preference, and causing problems when sharing projects across
different computers), its UX is rather poor (compiler messages aren't
neatly organized, there's no progress bar or line count, I can find no
way to cancel once it starts), and it has bugs (RSP-12322, RSP-12303,
RSP-12301, RSP-12299). It's particularly frustrating when I compare
this with TwineCompile, which gets almost all of this right and has done
so for years, without the benefit of access to RAD Studio's internals.

The debugger and IDE have problems with bcc32 versus bcc32c. Features
like "Open file at cursor" and single-stepping into the standard library
keep wanting to use Boost 1.39 and bcc32's dinkumware. Going under
Project Options, Debugger and adding $(BDS)\include\dinkumware64 helps,
but it doesn't fix everything.

The debugger has major limitations. The std::string visualizer is
broken. Evaluate/Modify is unable to handle lots of template functions
(dereferencing smart pointers, indexing vectors, calling
string::c_str()). Evaluate/Modify has problems with scoping within
functions, floating point, anonymous namespaces, and namespaces in
general. Evaluating Application->Title doesn't work. "Step Over"
sometimes resumes execution (i.e., resumes and never pauses again).

Exception handling is weird in ways I can't pin down: sometimes I get
the expected Delphi exception, sometimes I get EEFACE even when a Delphi
exception is being thrown, sometimes the debugger pauses on the
offending line but doesn't give any message. I'm sure there's a
pattern, but I can't figure it out.

I still get linker out of memory errors. The fact that the linker has
had these problems for years, and the fact that the problems still exist
after all of the toolchain updates, is immensely frustrating.

A side note on performance:

One of the comments from someone at Embarcadero is that bcc32c is slower
than bcc32 but produces much better code. I thought I'd see how it
compared for my own code. If you're at all interested in this topic, you
should, of course, test this yourself, using your own workload, instead
of trusting numbers from some random guy on the Internet, but here are
the results of building and running our application's test suite:

XE4, bcc32, debug build: 19,346kB, executes in 4.406 sec
Seattle, bcc32c, debug build: 22,306kB, executes in 5.610 sec

XE4, bcc32, release build: 49,571kB, executes in 3.804 sec (We leave
assertions in release build; I suspect this plus excessive inlining
explains the size.)
Seattle, bcc32c, release build: 21,786kB, executes in 5.447 sec

Conclusion:

I really wanted to like this release, but there are just too many
problems. I've decided to give up on bcc32c for now. Maybe Update 1
will help; maybe TwineCompile will come out with bcc32c support soon;
maybe I'll have to wait six months for the next major release. We'll see.

If anyone else has had a better experience, I'd love to hear from you.
I've been looking forward to C++11 support and would like to get things
working.

--
Josh Kelley
Stephen Fewer

Posts: 6
Registered: 9/12/02
Re: RAD Studio 10 - new compiler experiences
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2015 2:18 AM   in response to: Josh Kelley in response to: Josh Kelley
We have a ~200 kLOC project we want to build with the new bcc32c compiler. After a few hours of fixing some header issues we could get it to build successfully in about 20 minutes, we enabled parallel compiling and got that down to about 3 minutes which is great.

We thought we were on a roll but then we began hitting issues. We cannot do a debug build due to the linker failing (RSP-11737) which makes it impossible to debug and test as we develop.

When we tested a release build we came across several show stoppers, which seem to be code gen issues (but might be the linker) (RSP-11744).

So we simply can't use the new clang compiler, which is very disappointing after the long wait to get a 32bit clang compiler. Hopefully they will rewrite the 32/64 bit linkers for the next release.

Its also worrying they are using clang/llvm 3.3.1 (22 May 2012) for both bcc32c and bcc64, when the latest release is 3.7 (01 Sep 2015). I hope they address this shortfall as LLVM has addressed a ton of issues in the last 3 years.
Josh Kelley

Posts: 75
Registered: 3/6/08
Re: RAD Studio 10 - new compiler experiences
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 23, 2015 10:00 AM   in response to: Josh Kelley in response to: Josh Kelley
On 9/18/2015 6:22 PM, Josh Kelley wrote:
Structured exception handling (SEH) and floating point exceptions seem
to be quite a bit different. I think this will cause some problems for
our code; I'm still trying to figure this out. The docwiki does, at
least, explain this well. (Search for "clang differences.") Floating
point math results are different but are (as far as I can tell) more
accurate. (I maybe ought to investigate more here, but my patience for
manually inspecting floating point calculations is limited.)

In case anyone else runs into this, I think the bulk of the floating
point differences that I'm seeing are because bcc32c uses SSE/SSE2
(which uses 64-bit floating point registers) by default, while bcc32
uses the x86 FPU (which uses 80-bit floating point registers). So
bcc32c's results are slightly less precise, although there's a good
chance that actually depending on the precision of 80-bit intermediate
values is a mistake.

--
Josh Kelley
Kerem Demir

Posts: 7
Registered: 7/26/12
Re: RAD Studio 10 - new compiler experiences
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 23, 2015 7:06 AM   in response to: Josh Kelley in response to: Josh Kelley
Josh Kelley wrote:
Exception handling is weird in ways I can't pin down: sometimes I get
the expected Delphi exception, sometimes I get EEFACE even when a Delphi
exception is being thrown, sometimes the debugger pauses on the
offending line but doesn't give any message. I'm sure there's a
pattern, but I can't figure it out.

--

Hello Josh,

I'm trying to port my application to bcc32c, too. Its very anoying that exception handling is not working as It should.
Could you figure out, why the debugger stops at every catch but does not show any message?

Kind regards
Kerem

Update: I have managed to get the IDE show the exceptions again. There where some exceptions hidden in the IDE settings.

Edited by: Kerem Demir on Oct 23, 2015 7:37 AM
Josh Kelley

Posts: 75
Registered: 3/6/08
Re: RAD Studio 10 - new compiler experiences [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 23, 2015 8:51 AM   in response to: Kerem Demir in response to: Kerem Demir
On 10/23/2015 10:38 AM, Kerem Demir wrote:
I'm trying to port my application to bcc32c, too. Its very anoying that exception handling is not working as It should.
Could you figure out, why the debugger stops at every catch but does not show any message?

Update: I have managed to get the IDE show the exceptions again. There where some exceptions hidden in the IDE settings.

I was never able to figure it out. (Part of the problem was that, by
that point, I'd already spent more time than I felt like I could afford.)

What setting did you change?

--
Josh Kelley
Kerem Demir

Posts: 7
Registered: 7/26/12
Re: RAD Studio 10 - new compiler experiences [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 26, 2015 3:13 AM   in response to: Josh Kelley in response to: Josh Kelley
Josh Kelley wrote:
On 10/23/2015 10:38 AM, Kerem Demir wrote:
I'm trying to port my application to bcc32c, too. Its very anoying that exception handling is not working as It should.
Could you figure out, why the debugger stops at every catch but does not show any message?

Update: I have managed to get the IDE show the exceptions again. There where some exceptions hidden in the IDE settings.

I was never able to figure it out. (Part of the problem was that, by
that point, I'd already spent more time than I felt like I could afford.)

What setting did you change?
Under

Tools - Options - Debugger Options - Embarcadero Debugger - Language Exceptions

I deleted hidden exceptions. It seem that the Debugger has a problem tho handele those.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02