Jump to page: 1 2
Thread overview
GCC 11.1 Released
May 27, 2021
Iain Buclaw
May 27, 2021
rikki cattermole
May 27, 2021
M.M.
May 27, 2021
Brian
May 27, 2021
WebFreak001
May 27, 2021
Iain Buclaw
Jun 05, 2021
Guillaume Piolat
Jun 05, 2021
Imperatorn
May 31, 2021
Dylan Graham
Jun 09, 2021
Elronnd
Jun 09, 2021
Iain Buclaw
May 27, 2021

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.

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 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, 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 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 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
      • x86_64-linux-gnu
      • x86_64-portbld-freebsd12.2
      • x86_64-apple-darwin19
    • Buildkite
      • 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, approximations of costs into USD are up on my Github Sponsor page.


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 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 has been added to the language.

  • Function literals can now return a value by reference with the ref keyword.

  • A new syntax is available to declare aliases to function types using the alias syntax based on the assignment operator.

  • New types __c_complex_float, __c_complex_double, __c_complex_real, and __c_wchar_t have been added for interfacing with C and C++ code, and are available from the core.stdc.config module.

  • User-defined attributes can now be used to annotate enum members, alias declarations, and function parameters.

  • Templates alias parameters 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.

    • The deprecation phase 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 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 channel on the Dlang Slack or #d.gdc on Libera.Chat IRC.

Until the next major/minor release...

Regards,
Iain.

May 27, 2021
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.

...

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:

>

...

my Github Sponsor page.

...

TIL, sponsored!

Well, I am speechless. I've had a few surprises in my inbox this morning in relation to that link.

May 31, 2021

On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote:

>

Hi,

Sponsored :)

Very excited for GDC 12!

June 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:

>

...

my Github Sponsor page.

...

TIL, sponsored!

ditto

June 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:

>

...

my Github Sponsor page.

...

TIL, sponsored!

Ditto

June 09, 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 :)
« First   ‹ Prev
1 2