digitalmars.D.announce - GCC 11.1 Released
- Iain Buclaw (225/225) May 26 2021 Hi,
- rikki cattermole (2/4) May 27 2021 mm compact, very nice!
- M.M. (3/8) May 27 2021 A lot of work in the past development cycle of gcc. Well done! A
- Brian (2/2) May 27 2021 Thank you for your work. It has been a good experience so far
- WebFreak001 (2/5) May 27 2021 TIL, sponsored!
- Iain Buclaw (3/10) May 27 2021 Well, I am speechless. I've had a few surprises in my inbox this
- Guillaume Piolat (2/9) Jun 05 2021 ditto
- Imperatorn (2/9) Jun 05 2021 Ditto
- Dylan Graham (3/4) May 31 2021 Sponsored :)
- Elronnd (4/9) Jun 09 2021 Could this also support c++? If so, that seems like it could
- Iain Buclaw (4/13) Jun 09 2021 Because it works on the debug info/generic tree level, all
Hi, This year it's taken even longer than usual to get round to posting the formal announcement, but here it now is, and there has been a lot to sift through. As of last month (27th April), [GCC 11.1 has now been released](https://gcc.gnu.org/gcc-11/changes.html#d). For the D language front-end, there have been a significant number of changes, so it's probably best to start with the lowlights as they are comparatively small. --- Lowlights --------- 1. Contrary to the hopes of last years release announcement, this version still uses [D 2.076.1](https://dlang.org/changelog/2.076.1.html) as the baseline for D language support. Some significant blocking issues in upstream DMD meant that I could not commit to switching to self-hosted with full confidence, and said issues did not get resolved until after the feature window closed. 2. The promise of dynamically generating D bindings from C headers never really materialized. Actual work of adding a GCC compiler switch to dump D code was [completed to around 95% of what was needed](https://github.com/D-Programming-GDC/gcc/compare/1cb2d1d5ce178cb68f0bd475299d2e0b25a4a756. .ibuclaw/dumpspec), but then stalled on the just how this feature would integrate this into druntime. Then there's been the announcement of importC, which seems like a good reason to change tack and instead put effort into getting importC to the state where it is fit for purpose. Perhaps this utility could be released anyway, as an alternative to the likes of DStep, except leverages gcc to parse the sources instead via `gcc file.c -fdump-d-spec=file.d` 3. Whilst [my little project site](https://gdcproject.org) did recent a styling revamp, very little was done in the way of documentation. Though soon I hope to get changelog entries published there at least. 4. The [compiler explorer site](https://explore.dgnu.org) has also been updated, though the running compilers were left at version GCC 9.1. --- Highlights ---------- 1. Instead of updating language version, efforts have been driven towards increasing cross-platform support, there have been a number of new additions: - FreeBSD - DragonFlyBSD - OpenBSD - OS X - MinGW OpenBSD, OS X and MinGW do not enable Phobos by default, and are to be considered experimental at this time, you can override the building of Phobos with the `--enable-libphobos` configure switch. OS X has been the most tested of the experimental configurations, and is working generally well on all versions between Darwin 10 and 19. 2. Testing infrastructure has been expanded, and it is no longer Ubuntu-centric. There are now the following new platforms under test: - [CirrusCI](https://cirrus-ci.com/build/6373685910044672) - x86_64-linux-gnu - x86_64-portbld-freebsd12.2 - x86_64-apple-darwin19 - [Buildkite](https://buildkite.com/d-programming-gdc/gcc/builds/285) - x86_64-alpine-linux-musl - x86_64-unknown-netbsd - amd64-unknown-openbsd6.9 For everything else under Buildkite, the two pre-existing agents have had a CPU upgrade, and a third agent has been added into the infrastructure that has reduced overall build times by more than half. The servers I'm using for buildkite are ridiculously cheap, however if you are interested in helping support the monthly costs, you can do so by making a donation to the [D Language Foundation](https://dlang.org/foundation/donate.html), approximations of costs into USD are up on my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). --- **New features**: - A new bottom type `typeof(*null)` has been added to represent run-time errors and non-terminating functions. This also introduces a new standard alias for the type named `noreturn`, and is implicitly imported into every module. - [Printf-like and scanf-like](https://dlang.org/changelog/2.092.0.html#printfParams2) functions are now detected by prefixing them with pragma(printf) for printf-like functions or pragma(scanf) for scanf-like functions. - The __traits() expression now supports the extensions `isDeprecated`, `isDisabled`, `isFuture`, `isModule`, `isPackage`, `child`, `isReturnOnStack`, `isZeroInit`, `getTargetInfo`, `getLocation`, `hasPostblit`, `isCopyable`, `getVisibility`, and `totype`. - [An expression-based contract syntax](https://dlang.org/changelog/2.081.0.html#expression-ba ed_contract_syntax) has been added to the language. - [Function literals can now return](https://dlang.org/changelog/2.086.0.html#funcliteralsbyref) a value by reference with the `ref` keyword. - [A new syntax is available](https://dlang.org/changelog/2.087.0.html#aliasdecly_func) to declare aliases to function types using the `alias` syntax based on the assignment operator. - [New types](https://dlang.org/changelog/2.096.0.html#complex_types) `__c_complex_float`, `__c_complex_double`, `__c_complex_real`, and `__c_wchar_t` [have been added](https://dlang.org/changelog/2.084.0.html#wchar_t) for interfacing with C and C++ code, and are available from the `core.stdc.config` module. - [User-defined attributes](https://dlang.org/changelog/2.082.0.html#enum_attributes) can now be used to annotate enum members, alias declarations, and function parameters. - [Templates alias parameters](https://dlang.org/changelog/2.087.0.html#template_alias_ atches_basic_types) can now be instantiated with basic types such as `int` or `void function()`. - The mixin construct can now be used as types in the form `mixin(string) var`. - The mixin construct can now take an argument list, same as `pragma(msg)`. **New intrinsics**: - Bitwise rotate intrinsics `core.bitop.rol` and `core.bitop.ror` have been added. - Byte swap intrinsic `core.bitop.byteswap` for swapping bytes in a 2-byte `ushort` has been added. - Math intrinsics available from `core.math` now have overloads for `float` and `double` types. - Volatile intrinsics `core.volatile.volatileLoad` and `core.volatile.volatileStore` have been moved from the `core.bitop` module. **New attributes**: - The following GCC attributes are now recognized and available from the `gcc.attributes` module with short-hand aliases for convenience: - ` attribute("alloc_size", arguments)` or ` alloc_size(arguments)`. - ` attribute("always_inline")` or ` always_inline`. - ` attribute("used")` or ` used`. - ` attribute("optimize", arguments)` or ` optimize(arguments)`. - ` attribute("cold")` or ` cold`. - ` attribute("noplt")` or ` noplt`. - ` attribute("target_clones", arguments)` or ` target_clones(arguments)`. - ` attribute("no_icf")` or ` no_icf`. - ` attribute("noipa")` or ` noipa`. - ` attribute("symver", arguments)` or ` symver(arguments)`. - New aliases have been added to gcc.attributes for compatibility with ldc.attributes. - The ` allocSize(arguments)` attribute is the same as ` alloc_size(arguments)`, but uses a 0-based index for function arguments. - The ` assumeUsed` attribute is an alias for ` attribute("used")`. - The ` fastmath` attribute is an alias for ` optimize("Ofast")`. - The ` naked` attribute is an alias for ` attribute("naked")`. This attribute may not be available on all targets. - The ` restrict` attribute has been added to specify that a function parameter is to be restrict-qualified in the C99 sense of the term. - The ` optStrategy(strategy)` attribute is an alias for ` optimize("O0")` when the strategy is "none", otherwise ` optimize("Os")` for the `"optsize"` and `"minsize"` strategies. - The ` polly` attribute is an alias for ` optimize("loop-parallelize-all")`. - The ` section(name)` attribute is an alias for ` attribute("section", name)`. - The ` target(arguments)` attribute is an alias for ` attribute("target", arguments)`. - The ` weak` attribute is an alias for ` attribute("weak")`. **New language options**: - `-fweak-templates`, added to control whether declarations that can be defined in multiple objects should be emitted as weak symbols. The default is to emit all symbols with extern linkage as weak, unless the target lacks support for weak symbols. - `-Wdeprecated`, this option is now enabled by default. - `-Wextra`, this option now turns on all warnings that are not part of the core D language front-end - `-Waddress`, `-Wcast-result`, `-Wunknown-pragmas`. - `-Wvarargs`, added to turn on warnings about questionable usage of the `va_start` intrinsic. - *Deprecated and removed features*: - Compiler-recognized attributes are now made available from the `gcc.attributes` module, the former module `gcc.attribute` has been deprecated and will be removed in a future release. - The ` attribute("alias")` attribute has been removed, as it had been superseded by `pragma(mangle)`. - The ` attribute("forceinline")` attribute has been removed and renamed to ` always_inline`. - `__vector` types that are not supported in hardware are now rejected at compile-time. Previously all vector types were accepted by the compiler and emulated when target support was absent. - The `extern(Pascal)` linkage attribute [has been removed](https://dlang.org/changelog/2.095.0.html#extern-pascal). - [The deprecation phase](https://dlang.org/changelog/2.087.0.html#remove_visibility) for `-ftransition=import` and `-ftransition=checkimports` is finished. These switches no longer have an effect and are now removed. Symbols that are not visible in a particular scope will no longer be found by the compiler. - [It is now an error](https://dlang.org/changelog/2.079.0.html#fix17630) to use private variables selectively imported from other modules. Due to a bug, some imported private members were visible from other modules, violating the specification. - The `-fweak` compiler switch has been removed, as it existed only for testing. --- GCC 12 Development ------------------ Now the development cycle has started again, I have ambitions for a number disruptive changes to land during the next release cycle, and this time I hope I really do mean it. :-) 1. Switch implementation of the compiler from C++ to D. Rebase front-end with DMD master. Taking into account the alignment of release cycles - and assuming that DMD releases don't loose their cadence again - it would then be expected for GCC 12.1 to have DMD 2.102.0-beta.1 or 2.102.0-rc.1. The GCC 12.2 release will then have DMD 2.102.1, plus any other fixes that have gone into stable before the master/stable merge. 2. ImportC is still too early to tell, but it might be an interesting direction to steer in, so getting it to the point where all druntime bindings in libc are replaced with C sources would be the ambitious goal to acheive during this release cycle. 3. Begin hosting release binaries on the project site, update compilers on the explorer site to version 11, and just more generally keep adding to the build infrastruture. There are - as always - more things to do than I have available hours to do them in, but if this has pricked your interest, or you feel you could help in any way, please don't hesitate to jump on the [#gdc](https://dlang.slack.com/archives/C6LTP6MV1) channel on the Dlang Slack or [#d.gdc](irc://irc.libera.chat/d.gdc) on Libera.Chat IRC. Until the next major/minor release... Regards, Iain.
May 26 2021
rikki cattermole <rikki cattermole.co.nz> On 27/05/2021 1:04 PM, Iain Buclaw wrote:- New aliases have been added to gcc.attributes for compatibility with ldc.attributes.mm compact, very nice!
May 27 2021
On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:Hi, This year it's taken even longer than usual to get round to posting the formal announcement, but here it now is, and there has been a lot to sift through. [...]A lot of work in the past development cycle of gcc. Well done! A lot of work ahead. Good luck! Your work is very much appreciated.
May 27 2021
Thank you for your work. It has been a good experience so far running gdc on OpenBSD.
May 27 2021
On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:... my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). ...TIL, sponsored!
May 27 2021
On Thursday, 27 May 2021 at 14:14:40 UTC, WebFreak001 wrote:On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:Well, I am speechless. I've had a few surprises in my inbox this morning in relation to that link.... my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). ...TIL, sponsored!
May 27 2021
On Thursday, 27 May 2021 at 14:14:40 UTC, WebFreak001 wrote:On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:ditto... my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). ...TIL, sponsored!
Jun 05 2021
On Thursday, 27 May 2021 at 14:14:40 UTC, WebFreak001 wrote:On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:Ditto... my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). ...TIL, sponsored!
Jun 05 2021
On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:Hi,Sponsored :) Very excited for GDC 12!
May 31 2021
On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:2. The promise of dynamically generating D bindings from C headers never really materialized. Actual work of adding a GCC compiler switch to dump D code was [completed to around 95% of what was needed](https://github.com/D-Programming-GDC/gcc/compare/1cb2d1d5ce178cb68f0bd475299d2e0b25a4a756. .ibuclaw/dumpspec), but then stalled on the just how this feature would integrate this into druntime.Could this also support c++? If so, that seems like it could potentially be a reason to continue development on it preferentially to importC. Calypso-ish :)
Jun 09 2021
On Wednesday, 9 June 2021 at 07:15:40 UTC, Elronnd wrote:On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:Because it works on the debug info/generic tree level, all languages GCC supports can be used to emit D bindings for their code.2. The promise of dynamically generating D bindings from C headers never really materialized. Actual work of adding a GCC compiler switch to dump D code was [completed to around 95% of what was needed](https://github.com/D-Programming-GDC/gcc/compare/1cb2d1d5ce178cb68f0bd475299d2e0b25a4a756. .ibuclaw/dumpspec), but then stalled on the just how this feature would integrate this into druntime.Could this also support c++? If so, that seems like it could potentially be a reason to continue development on it preferentially to importC. Calypso-ish :)
Jun 09 2021