GCC 11.1 Released

[Iain Buclaw]

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-based_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_matches_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.