GCC 10.1 Released
A year has lapsed away since the release of last major GCC release, more than 33 years passed since the first public GCC release and the GCC developers survived repository conversion from SVN to GIT earlier this year. Today, we are glad to announce another major GCC release, 10.1. This release makes great progress in the C++20 language support, both on the compiler and library sides, some C2X enhancements, various optimization enhancements and bug fixes, several new hardware enablement changes and enhancements to the compiler back-ends and many other changes. There is even a new experimental static analysis pass." More information can be found in the release notes.
| From: | Jakub Jelinek <jakub-AT-redhat.com> | |
| To: | info-gnu-AT-gnu.org | |
| Subject: | GCC 10.1 Released | |
| Date: | Thu, 7 May 2020 15:00:53 +0200 | |
| Message-ID: | <20200507130053.GP8462@tucnak> | |
| Archive-link: | Article |
A year has lapsed away since the release of last major GCC release, more than 33 years passed since the first public GCC release and the GCC developers survived repository conversion from SVN to GIT earlier this year. Today, we are glad to announce another major GCC release, 10.1. This release makes great progress in the C++20 language support, both on the compiler and library sides [1], some C2X enhancements, various optimization enhancements and bug fixes, several new hardware enablement changes and enhancements to the compiler back-ends and many other changes. There is even a new experimental static analysis pass [2]. Some code that compiled successfully with older GCC versions might require source changes, see http://gcc.gnu.org/gcc-10/porting_to.html for details. See https://gcc.gnu.org/gcc-10/changes.html for more information about changes in GCC 10.1. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-10.1.0/ subdirectory. If you encounter difficulties using GCC 10.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GNU Compiler Collection would not be possible without support from its many contributors. Not to only mention its developers but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually! Please consider a donation to the GNU Toolchain Fund to support the continued development of GCC! [3] ---- [1] See https://gcc.gnu.org/projects/cxx-status.html, and https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.ht... [2] See https://developers.redhat.com/blog/2020/03/26/static-anal... [3] See https://my.fsf.org/civicrm/contribute/transact?reset=1&... -- If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.
Posted May 7, 2020 15:10 UTC (Thu)
by BirAdam (guest, #132170)
[Link] (7 responses)
Anyway, good to hear the git change is complete. Also, excited to dig into the release notes! New compiler releases are like Christmas... but for people who get too excited about software.
Posted May 7, 2020 15:13 UTC (Thu)
by BirAdam (guest, #132170)
[Link]
OpenMP and OpenACC now support offloading to AMD Radeon (GCN) GPUs; supported are the third-generation Fiji (fiji) and the fifth-generation VEGA 10/VEGA 20 (gfx900 or gfx906).
Posted May 7, 2020 18:31 UTC (Thu)
by cesarb (subscriber, #6266)
[Link]
That's to be expected, since RedHat bought Cygnus (https://en.wikipedia.org/wiki/Cygnus_Solutions), which was a major contributor to GCC.
Posted May 7, 2020 19:33 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (4 responses)
Posted May 7, 2020 20:17 UTC (Thu)
by RedDwarf (guest, #89472)
[Link] (3 responses)
Not exactly up to date.
Posted May 8, 2020 4:52 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
Posted May 9, 2020 0:35 UTC (Sat)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted May 9, 2020 1:14 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 7, 2020 16:47 UTC (Thu)
by SPYFF (subscriber, #131114)
[Link]
Posted May 7, 2020 19:38 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (46 responses)
Posted May 8, 2020 8:34 UTC (Fri)
by scientes (guest, #83068)
[Link] (45 responses)
Posted May 8, 2020 9:04 UTC (Fri)
by peter-b (guest, #66996)
[Link] (44 responses)
Posted May 8, 2020 16:16 UTC (Fri)
by ballombe (subscriber, #9523)
[Link]
Posted May 8, 2020 16:50 UTC (Fri)
by karkhaz (subscriber, #99844)
[Link] (42 responses)
Posted May 8, 2020 17:31 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 8, 2020 18:33 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (19 responses)
Posted May 8, 2020 18:45 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted May 11, 2020 11:42 UTC (Mon)
by anton (subscriber, #25547)
[Link] (4 responses)
Apple did not want to comply with GPL v2 when they built the Objective-C front end for gcc (but eventually complied). Not really a sign that they are fine with GPLv2.
Posted May 11, 2020 16:00 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
And it's absolutely GPLv3. Apple has no problems shipping GPLv2, but they went as far as rewriting SMB implementation to avoid shipping Samba 3.
Posted May 15, 2020 20:28 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted May 15, 2020 20:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> I wouldn't put much stock in their opinions of the GPL.
Posted May 15, 2020 21:04 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Wasn't that under threat of lawsuit though? I wouldn't call that willful compliance.
Posted May 10, 2020 12:33 UTC (Sun)
by zoobab (guest, #9945)
[Link] (12 responses)
We are under the threat of a permissive license, which imply, for example, no obligation to release the source code of custom patches, which is pretty common in the embedded world.
This will lead to the refusal from routers manufacturers (like the routers where you can run OpenWRT) to release the sources of their compiler.
Posted May 10, 2020 13:24 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link] (6 responses)
If your router arrives without the compiler, then you have no standing to demand a copy of the source code for the compiler.
Posted May 11, 2020 4:54 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Jul 13, 2020 13:04 UTC (Mon)
by immibis (subscriber, #105511)
[Link] (1 responses)
Posted Jul 18, 2020 10:58 UTC (Sat)
by flussence (guest, #85566)
[Link]
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
OpenWRT is a whole OS-building SDK unto itself: a cross-compiler is bundled with it, is not a typical component found in a host OS, and cannot be trivially replaced (not least due to the fact that it's a heavily patched copy of GCC).
Posted May 11, 2020 6:17 UTC (Mon)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Jul 18, 2020 11:10 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
If I can claim your actions have damaged me, I have a claim against you. If the GPL says you have to give me a copy of the source, certainly under - I think it's now called the Consumer Rights Act (used to be Sale of Goods and Services) - I could sue you for providing faulty/incomplete goods. And if I was damaged by them I can go for damages, never mind that the goods were free. The GPL's disclaimer of warranty wouldn't apply because the suit would say you had forgone the GPL therefore weren't protected by it...
Not sure how well that would fly, but I think it would stand a good chance.
Cheers,
Posted Jul 28, 2020 8:30 UTC (Tue)
by flussence (guest, #85566)
[Link]
Posted May 11, 2020 7:00 UTC (Mon)
by joib (subscriber, #8541)
[Link] (4 responses)
Considering jra was one of the authors of the GPLv3, and has relicensed some significant software to GPLv3, he being disillusioned with it, and with copyleft enforcement in general, might tell something.
If, for the sake of argument, we take jra's arguments at face value, what are the implications? I suggest something like
- Might as well choose a permissive license, to get the largest possible user base. That is, instead of viewing FOSS as a commons (see Ostrom), view it as a public good.
- The four freedoms are as important as before, if not more. But if not copyleft enforcement, how to achieve it? a) jra's "documented and interoperable protocols" suggestion 2) Right to repair legislation? 3) Address the power imbalance between the citizens and internet giants (social media, cloud providers); Maybe view them as utilities subject to legislation like telecom and electricity?
- Implement federated/distributed architectures that respect user freedom and privacy, and circumvent the scale advantages of the internet giants. So far things like FreedomBox and Mastodon haven't really been killer apps, but maybe there's something out there to be discovered?
I have to admit this feels uncomfortable, as it relies to a large extent on "traditional" political activism. Which is uncomfortable for a nerd; we'd rather just write code and pretend that slapping on a copyleft license takes care of the political part.
Posted May 12, 2020 22:28 UTC (Tue)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted May 13, 2020 9:32 UTC (Wed)
by joib (subscriber, #8541)
[Link] (2 responses)
There exists both copyleft and permissive licenses that don't suffer from these problems.
Posted May 13, 2020 15:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
OMG NO!!!
That is my beef with the GPL3 - patent language does not belong in a copyright licence!!! By all means stick a defensive clause in, but hopefully actually it's all moot now. I don't know the latest state of play, but I think software patents have pretty much been killed by SCOTUS now.
> wasn't really anything to do with copyleft vs permissive, but rather that the license itself was unclear
and the defendant thought he could assume, BECAUSE the language was unclear, that the stuff was actually in the public domain. If you read the wiki article, it sounds like that's what he persuaded the court first time around, but the appeal court knocked that on the head. "If the conditions are unclear, it doesn't mean there are no conditions. It means the copyright holder has gone to the trouble of setting conditions and you must assume you need a licence".
Cheers,
Posted May 15, 2020 2:59 UTC (Fri)
by songmaster (subscriber, #1748)
[Link]
Sadly that doesn’t seem to have happened, the US patent office wrote some guidance for its examiners that effectively contradicted the SCOTUS Alice ruling and it’s now back to giving out stupid patents again. See this Techdirt article [1] for more details.
[1] https://www.techdirt.com/articles/20200423/15295144360/us...
Posted May 8, 2020 18:46 UTC (Fri)
by sorpigal (guest, #36106)
[Link] (5 responses)
Posted May 8, 2020 20:14 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
This does not preclude another standard from existing, of course, but if it's not in the C standard, I imagine most implementers would simply ignore it.
Posted May 8, 2020 23:03 UTC (Fri)
by sorpigal (guest, #36106)
[Link] (1 responses)
Posted May 8, 2020 20:33 UTC (Fri)
by madscientist (subscriber, #16861)
[Link]
Admittedly it's a minimal standard but it gets all the major options and behaviors.
Posted May 8, 2020 20:33 UTC (Fri)
by ballombe (subscriber, #9523)
[Link]
Posted May 8, 2020 20:46 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (14 responses)
One example: both GCC and clang support precompiled headers. However the format of the PCH files is very different, so that clang can't read GCC's file and vice versa. That's perfectly reasonable, and GCC creates PCH files suffixed with .gch and clang suffixes its PCH files with .pch.
What's not so great is that clang ALSO tries to read files using GCC's extension .gch, and then fails (with a somewhat cryptic message) if it can't parse it (because it's a real GCC PCH file).
This is a serious problem if you're trying to use both GCC and clang at the same time (for example, maybe you're using clangd for code inspection or similar but still build code with GCC).
In this case the attempt to make it easy to switch from GCC to clang, by reusing the GCC filename, is certainly causing problems.
Posted May 8, 2020 23:00 UTC (Fri)
by atai (subscriber, #10977)
[Link] (13 responses)
Posted May 8, 2020 23:23 UTC (Fri)
by madscientist (subscriber, #16861)
[Link]
However, you _can_ tell the difference between the two compilers if you need to... one way is that GCC doesn't define any of the clang predefined macros like __clang__ etc.
Posted May 8, 2020 23:53 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (4 responses)
It reports itself as 4.2.1. clang was designed to be compatible with GCC 4.2.1, with the notable exception of nested functions, and maybe a few other esoteric features. Intel C++ started defining __GNUC__, et al long before clang existed, so in practice __GNUC__ hasn't implied GCC for a long-time. What's more annoying is how Apple's build of clang reports itself. Apparently Apple uses a time machine to fetch their branch: clang 11 hasn't been released. In fact, clang 10 was just released about a month ago. Although, if you just accept that clang is effectively Apple's project--that Apple has veto power over anything they dislike, much like the FSF and Stallman with GCC--and not a completely independent open source project, then it's less objectionable, although no less confusing. clang did introduce useful feature test macros like __has_attribute, __has_extension, etc, which permit direct feature detection. But the most useful test macro, __has_builtin, is relatively recent--adopted by GCC 9, and broken (or at least unusable) prior to clang 10.
Posted May 10, 2020 5:44 UTC (Sun)
by ndesaulniers (subscriber, #110768)
[Link]
How's that?
Posted May 10, 2020 8:20 UTC (Sun)
by felix.s (guest, #104710)
[Link]
Posted May 10, 2020 9:16 UTC (Sun)
by ballombe (subscriber, #9523)
[Link]
Posted May 10, 2020 13:46 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
No, this is because you have Xcode 11. Apple builds the Xcode toolchain off an internal branch of the repository and has a completely different versioning scheme (cf. the difference between the Clang and AppleClang compiler ids in CMake).
Posted May 10, 2020 13:44 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (6 responses)
When detecting compilers, this is generally the detection order I'd suggest:
- nvcc (because *sigh*)
It is for this reason as well that GCC can't add a "I'm really GCC!" definition: other compilers would end up having to emulate *that* definition as well to get off the ground.
Posted May 10, 2020 20:12 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
Posted May 10, 2020 21:43 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted May 11, 2020 2:35 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Aside: This is poor practice. You should serve a basic HTML page that works in any reasonable* browser, and then use JavaScript to progressively enable functionality that the current browser actually supports. That JavaScript should call into the server (if necessary) and pass information about the client (if necessary). At no point should the server be in a position of trying to guess a browser's capabilities based on HTTP headers alone, unless the client is not a browser and therefore not capable of executing JavaScript (at which point you are well off the beaten track and "best practices" are no longer a thing).
This does mean that users with JavaScript disabled will get a less functional website than would otherwise be possible to provide (for example, it might lack modern CSS functionality and look uglier than strictly necessary). But those differences should be mostly presentational, and should not interfere with the core functionality of the website (unless you hate your users).
* For whatever definition of "reasonable" your market research has led you to use. In practice, this is usually "Chrome plus some other ones," but whether that list includes IE, Opera, etc. may vary. A corporate intranet site has very different needs from google.com.
Posted May 11, 2020 6:38 UTC (Mon)
by flussence (guest, #85566)
[Link] (1 responses)
There seems to be a gradual movement in web development back to inert content, following a collective realisation that doing everything in Javascript is a horrendous idea for performance, security and durability.
Posted May 11, 2020 9:14 UTC (Mon)
by oldtomas (guest, #72579)
[Link]
I was under the impression that only a disruptive (possibly "external") event could derail this horror train. It just meshes too well with surveillance capitalism (and even worse "surveillance" things, with some perverse common interests).
So thanks for shining some light of hope into an otherwise gray day :-)
Posted May 11, 2020 14:38 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
I was more thinking about deciding to use whatever experimental HTTP headers browsers support these days more than serving up different code based on the user agent.
Probably should have said "HTTP servers are" rather than "server-side-only is".
Posted May 8, 2020 15:08 UTC (Fri)
by jonquark (guest, #45554)
[Link] (2 responses)
"GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking. "
Posted May 9, 2020 19:16 UTC (Sat)
by RedDwarf (guest, #89472)
[Link] (1 responses)
Was that variable supposed to be shared by those two files or not?
I can't even imagine how much fun the Fedora packagers must have had with Fedora 32. I guess more than one must have started to simply add "-fcommon" to his packages CFLAGS out of desperation.
Posted May 10, 2020 13:09 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link]
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
Chris Lattner had already been hired by Apple in February 2005. The first GPL v3 draft was published in January 2006, with the announcement of the work on GPL v3 in late 2005.
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
Well, it's a different way of saying it. But Apple really was OK with GPLv2, they actually open sourced their gcc-based Objective-C compiler in 90-s. I think it was esr who convinced them to do that?
The problem is, Apple is not unique in their approach to GPLv3. It's explicitly banned in all large companies that I've worked in so far.
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
Wol
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
see the JMRI case <https://en.wikipedia.org/wiki/Jacobsen_v._Katzer>
GCC 10.1 Released
GCC 10.1 Released
Wol
GCC 10.1 Released
Is there any standard for cc command line options besides the de-facto standard of "whatever gcc does"?
GCC 10.1 Released
GCC 10.1 Released
I'm not surprised that C doesn't specify any CLI standard, just that POSIX doesn't. Some standard ought to, I think.
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
This explain some awkwardness like -Wl, etc.
See <https://pubs.opengroup.org/onlinepubs/7908799/xcu/cc.html>
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
% cc -dM -E - < /dev/null | grep clang
#define __VERSION__ "4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.17)"
#define __clang__ 1
#define __clang_major__ 11
#define __clang_minor__ 0
#define __clang_patchlevel__ 0
#define __clang_version__ "11.0.0 (clang-1100.0.33.17)"
GCC 10.1 Released
Are you referring to the fact that GCC 10.1 Released
__has_builtin returns 0 for those built-ins that are not functions, but keywords? Because that’s hardly ‘unusable’, especially that keywords can be tested for via !__is_identifier.
GCC 10.1 Released
For a long time they shipped broken version of gcc, and now they ship broken version of clang.
I though that clang was a pile of cruft until I tried the Debian build and then suddenly it was
almost on par with gcc.
GCC 10.1 Released
GCC 10.1 Released
- platform toolchains (xlc, acc, etc.)
- vendor toolchains (icc, msvc, etc.)
- clang
- gcc
- #error unknown (or #warning and assume GCC-alike)
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
GCC 10.1 Released
Even if it was not intended to be shared, maybe the program is only working by accident and is going to break if I add the "static"s?
This was probably the most painful GCC update that I've participated in a while. Almost all of my development time for Fedora 32 was spent fixing broken builds caused by this change in GCC. Not that I think it was a bad change, but I did not expect how much breakage it caused...
GCC 10.1 Released