Slashdot Mirror
GCC 5.2 Released
AmiMoJo writes: The release of GCC 5.2 brings lots of bug fixes and a number of new features. The change list is extensive, featuring improvements to the C compiler, support for new languages like OpenACC, improvements for embedded systems, updates to the standard library and more.
All of those new features were in 5.1. 5.2 is just a few bug fixes.
Instead of "bug fixes and new features", why isn't software ever delivered with the simple truth? "Lots of new bugs."
This is just a bugfix release. With the old (GCC 4) versioning scheme this would've been called 5.0.1.
I've been configuring a toolchain for Algoram's programmable radio transceiver, which has a SmartFusion 2 containing a Cortex M3. Until today, I've been working with GCC 5.1. Building GCC for cross-compilation on a no-MMU, no-FP processor and a software platform that doesn't support shared libraries isn't trivial, though it should be. GCC has many configure scripts, one for each library that it builds and at least one for the compiler. You run across many configure issues which are difficult to debug. For example, the configure file, a macro-expanded shell script, doesn't have source code line numbers from its configure.ac file. Error messages do not in general indicate the actual problem, and are difficult to trace. Figuring out what to fix is far from trivial. I ended up not being able to use multilibs (which would have allowed me to build for FP processors like Cortex M4F as well), couldn't link in ISL, couldn't build libjava.
Some of these are beginner problems - I'm new to building cross-toolchains and have avoided autotools as much as possible before this project. But not all of them.
One would think that we could build a better system today than such voluminous M4 and shell. Perhaps basing it on a test framework might be the right approach.
Bruce Perens.
I use clang as well because I develop on a mac and I don't care clang VS GCC. I just hope that clang continues to be compatible with GCC and that GCC continues to move forward. I guess we are now in a kind of golden age for developing on UNIX with such compatible choices to choose from.
But because clang is so reliant on Apple's benefaction, I see this as a potential point of failure. What if apple has a change of heart and puts all their efforts in one language I don't care about, or they start to deviate from standards for their own purposes, or they start to develop for internal use only, or there is a fight between the corporate sponsors and it gets reflected in clang, or something else critical? All it takes is one person in a position of authority with other ideas to have a huge impact on the project... and me.
So regardless of ideology, GCC is still important.
Ugh. Visual Studio 2015 requires Windows 8.1. No thanks.
* https://www.visualstudio.com/e...
Here is the list of bugs fixed in
* GCC 5.2 compiler issues
* MSVC 2015 compiler issues
Additional MSVC 2015 bug fixes ...
* MSVC 2015 Features
* MSVC 2015 (C++11/14/17)
* MSVC 2015 STL part 1
* MSVC 2015 STL part 2
Perhaps you could demonstrate the difficulty of building a cross-GCC by phrasing your rant in the form of a good Stack Overflow question. Explain what you are trying to do, what web search queries you used, what you tried, what you expected, and what each failure looked like. If they are in fact "beginner problems", getting the question onto SO should eventually help future web searchers find the answer more easily. Or if Stack Overflow scares you, you might try looking at how it was done in devkitARM.
For line numbers in an M4 script, have you tried adding --synclines ?
If error messages from some compiler or interpreter are unhelpful, have you tried filing bugs against said compiler or interpreter to improve the usefulness of its error messages?
A compiler for embedded systems needs to understand and use a smaller foot print. Current version cannot run in less than 128MB of memory.
I think the idea is that even if you're targeting an embedded system, you're still hosting the compiler on something with a keyboard big enough to comfortably edit code, such as a server, desktop PC, or laptop PC. Even dinky little Atom-powered tablets come with 2 GB of RAM nowadays.
But there's a different size issue: footprint of the GNU implementation of the C++ standard library when it is statically linked. Years ago, I used devkitARM, a distribution of GCC targeting the Game Boy Advance, a platform with 256 KiB* of main RAM, 32 KiB of tightly coupled fast RAM generally used for the stack and certain inner loops, and 96 KiB of video memory. (It also had up to 32 MiB of cartridge ROM, but not if receiving the program from a GameCube or from the first player in a multiplayer network.) I compiled C++ "hello world" programs using the static Newlib and libstdc++ that shipped with devkitARM. A hello world program using <cstdio> was less than 16 KiB, including the statically linked terminal. So as long as I stuck to C libraries, I was fine. But a similar program using <iostream> produced an 180,032 byte executable, even after turning on relatively aggressive options to remove dead code. That left less than one-third of main RAM free for actual program code and data. I debugged into it, and the culprit turned out to be "locale" stuff (date, time, and currency formatting) that got initialized on std::cout even if the program never printed any date, time, or currency types.
* That's 262,144 bytes, about a quarter of a megabyte, or about a four-thousandth of a gigabyte.
The compiler? Why would you want to run that on an embedded system?
Visual Studio 2015 development environment supports https://www.visualstudio.com/v...
Windows 7 Service Pack 1
Windows 8.1
Windows 8
Windows Server 2008 R2 SP1
Windows Server 2012
Windows Server 2012 R2
Windows 10
But can compile for a target as old as WinXP.
You are a complete moron for using OpenMP.
That was very helpful; full of thoughtful reasoning and examples. The level of detail in explaining the rational to avoid OpenMP was, to say the least, above and beyond. You sir or madam have made us proud. Well done.
It must have been something you assimilated. . . .
Conclusion: never use iostreams.
Why would I waste my time explaining things to idiot morons?
Knowledge should be passed along, not hoarded. Everyone is at a different place on the learning curve. In practical terms, that means everyone is an idiot moron with respect to someone else - or, in your case, obviously many others.
It must have been something you assimilated. . . .
Did they fix the conflict between gcc-multilib and gcc-arm-linux-gnueabihf?
Since Ubuntu Trusty was released, over a year ago, there has been a conflict between gcc-multilib (needed for building and running 32-bit application on 64-bit Intel/AMD architectures) and several cross compiler suites including gcc-arm-linux-gnueabihf (the cross-compiler suite needed for developing applications for ARM processors, such as those on the BeagleBones and many Internet of Things devices.)
This means if you want to do cross-development and you have a 64-bit machine running a 64-bit install and doing builds for itself for both 64 and 32 bit environments, or running some 32-bit applications, you can't just install the cross-tools from the repository and dig in. You need a separate machines for cross-development, or you need to take time out to do your own hacking of the tools.
I've looked around the net for solutions: The issue seems to be a disconnect between teams, primarily over conflicting uses of the symlink at /usr/include/asm. But I haven't found any clear description of how to work around this, nor has the problem been fixed in the repositories. After over a year I find this very disappointing.
Has this been addressed with this new release of the underlying compilers?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Pretending to be am armchair expert who is still struggling to understand ad hominem attacks just makes you look like an complete tool but then what can you expect from an Anonymous Coward. /sarcasm Clearly the rest of us are doing it wrong.
I'm not the AC, but I'll try to share the knowledge.
I'm a kernel programmer and worked on a Linux based realtime highdef broadcast quality H.264 video encoder that used a hybrid mix of multiple cores and FPGAs, so I'm fairly familiar with at least one use case.
openMP has uses for parallelizing workloads via pragmas in the compiler code. That is, take an app that is designed for a single CPU, add some pragmas and some openMP calls and let the compiler parallelize it. It does this [mostly] by paralleling loops that it finds.
Parallelizing [simple] loops can be done in [at least] two ways:
(1) A single loop can be parallelized across multiple cores
(2) If a function does loop A followed by loop B and loop A and B share no data, they can be done in parallel.
openMP assumes a shared memory architecture (e.g. all cores are on the same motherboard). Contrast this to MPI that can go "off board" [via a network link]. There are hybrid implementations that use both in a complementary fashion.
A good use case for this is weather prediction/simulation which is highly compute intensive but doesn't have realtime requirements. We just want our final answer ASAP, but what the program does moment-to-moment doesn't matter. Another use case is protein folding.
But, neither openMP nor MPI is well suited to a realtime situation that requires precise control over latency. Also, openMP doesn't support compare-and-swap. And, it's prone to race conditions.
Ideally, designing a given app from the ground up for parallelism is a better choice. If one does that, the fanciness of openMP isn't required. My last implementation of an openMP equivalent [that also incorporated what MPI does] was ~1000 lines of code because the app was pre-split into threads set up in a pipeline. It supported a multi-master, distributed, map/reduce equivalent using worker threads [still within 1000 lines].
Consider the second loop parallelization case. It's easy enough for a programmer to see that loop A and loop B are disjoint and put them in separate threads (e.g. A and B). But, if one is aware of this, the splitup can be done even if loop A and B share some data because one can control the synchronization between threads precisely. Extend this to 40-50 threads that have a more complex dependency graph.
Note that latency means that a given thread A will deliver its results to thread B in a finite/precise/predictable/repeatable amount of time. In video processing, each stage must finish processing within a the allotted for a video frame [usually 1/30th of a second]. With extra buffering, that can be relaxed a bit, but the average must be 1/30th and can't vary too widely (e.g. no frame could take [say] 1/2 second).
Thus, the AC, although snide, is partially right. If I were doing an implementation, I believe the result would be better not using openMP. But, I've got 40+ years doing realtime systems. Not everybody does. Most consumers of openMP [and/or MPI] are usually scientists/researchers who are [no doubt] experts in their field, but they're usually not expert level programmers. And, they usually don't have the restrictions imposed by a realtime system. Notable exceptions: programming for MRI/PET/etc machines.
Like a good neighbor, fsck is there
WTF? I use Clang on Linux and link against the GNU C++ runtime library all the time. It works just fine. Why are you spreading FUD?
I don't think clang+llvm will just fail once Apple drops support. There are so many other companies supporting clang+llvm and use them to do important things. See: http://llvm.org/Users.html
1. Most corporate environments don't allow tweaks like startisback. Most don't allow much registry tweaking either.
2. Metro is a pain in the ass on the desktop. Win10 fixes some of this, but still leaves much to be desired.
3. People who like to focus on getting the job done don't want extra hassles and steps added to their workflows by idiot managers who insist on software upgrades because newversion > currentversion.