Re: Package Request: GCC 9.1

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-493672670
Comment:
Another strange thing is the only call to `bch_bkey_dump` is from `drivers/md/bcache/bset.c:31` and there an `#ifdef CONFIG_BCACHE_DEBUG` is around that code. This macro is not defined in our `x86_64-dotconfig` and consequently it is not set in either of the `/boot/config-4.19.44_1` files of the two kernel builds.
This explains why `gcc-8.3.0` decided to drop the static `bch_key_dump` function but why does `gcc-9.1.0` not do the same?

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-493716506
Comment:
An interesting answer related to the question whether unnamed struct members are initialized can be found here https://stackoverflow.com/questions/330793/ in the comment https://stackoverflow.com/a/37701574/

Specifically ISO/IEC 9899:2011 and ISO/IEC 9899:2018 are said to retain the paragraph 9 statement:

> Except where explicitly stated otherwise, for the purposes of this subclause unnamed members of objects of structure and union type do not participate in initialization. **Unnamed members of structure objects have indeterminate value even after initialization.**

So if gcc9 implemented ISO/IEC 9899:2011 and ISO/IEC 9899:2018 verbatim one would hope the https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html statement

> Omitted field members are implicitly initialized the same as objects that have static storage duration.

still holds true. Other C99 compliant compilers may not initialize the unnamed struct members as gcc8 did and, let's hope, gcc9 still does. If gcc9 does not, well...

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-494061403
Comment:
FWIW explicitly initializing the other struct members in `const struct btree_key_ops bch_btree_key_ops = {…` doesn't change a thing. I initialized a bcache device created from a 16GB backing device (`/dev/vdb1`) and a 1GB cache device (`/dev/vdb2`) as [described here](https://wiki.archlinux.org/index.php/Bcache). I can then do `mkfs.ext4 -L bcache /dev/bcache0` and already checking it with `e2fsck /dev/bcache0` corrupts it immediately.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-498294310
Comment:
I tried to enable the D language with the update and I added some new subpackages to `gcc`:
+ `gcc-gdc` contains `/usr/bin/gdc` the GNU D compiler
+ `libgd` contains `/usr/lib/libgdruntime.so.76.3.0` and symlink `/usr/lib/libgdruntime.so.76`
+ `libdg-devel` contains `/usr/lib/libgdruntime.{so,a}` and `/usr/lib/gcc/<triplet>/<ver>/include/d/*`
+ `libgphobos` contains `/usr/lib/libgphobos.so.76.0.3`, symlink `/usr/lib/libgphobos.so.76`, and `/usr/lib/libgphobos.spec`
+ `libgphobos-devel` contains `/usr/lib/libgphobos.{so,a}`

I'll also add [`gdmd`](https://github.com/D-Programming-GDC/GDMD) as a new package to my fork.
The idea is it should then be pssible to bootstrap `dmd` with the help of `gdmd`.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-493500921
Comment:
For those who want to do some testing, specifically the bcache corruption issue, you can use unsigned https://misc.voidlinux.de/gcc91/ packages to create a live ISO and test it.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-493500921
Comment:
For those who want to do some testing, specifically the bcache corruption issue, you can use unsigned https://repo.voidlinux.de/gcc91/ packages to create a live ISO and test it.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-503688107
Comment:
I just read [Linux 5.1.12 fixed two bugs in bcache](https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.12). I'll be testing if bcache works now in the next days.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-504036535
Comment:
Good news: the bcache bugs seem to be solved with `linux4.19-4.19.53_1`. I could create and use bcache devices with btrfs and subvolumes without problems.

I'll create two live ISOs for `x86_64` for testers to run in a VM or on bare hardware. I'll upload them to [my gcc91 repo's live directory](https://repo.voidlinux.de/gcc91/live).

It would also be interesting to have people test a mixture of packages from our main repo and (some) packages built with gcc-9.1.0, installed from https://repo.voidlinux.de/gcc91/, to see if and how well especially packages linking against libstdc++ play together.

Re: [ISSUE] [CLOSED] Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

Closed issue by Jackojc on void-packages repository

https://github.com/void-linux/void-packages/issues/11663
Description: Just wondering if there is any plan or progress on GCC 9.1.

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

New comment by Jackojc on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-506748972
Comment:
Awesome, thanks @pullmoll !

Re: Package Request: GCC 9.1

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/11663#issuecomment-493635699
Comment:
Interesting detail for the [Red Hat Bugzilla – Bug 1708315](https://bugzilla.redhat.com/show_bug.cgi?id=1708315):

~~If I look at Void's `gcc-8.3.0` built `linux4.19-4.19.44_1` module `bcache.ko` there is no symbol `bch_bkey_dump` **at all**. Compiled with `gcc-9.1.0` that symbol is indeed there in the `bcache.ko`.~~ You can inspect both using e.g. `Cutter` which is what I did.
**Correction:** the symbol is there in both modules if I look at it with `objdump --disassemble=bch_bkey_dump bcache.ko`, however `Cutter` does not load or resolve it for the module built with `gcc-8.3.0` so the guesswork following is to be taken with a grain of salt.

Since the function `bch_bkey_dump` is `static` it looks as if `gcc-8.3.0` has optimized it away because it decided the condition when it would be called will never occur. `gcc-9.1.0` OTOH decided to include it and, as we can see in the above bugreport, it is indeed called.

I think the problem could be a result of different handling of partially initialized structs between gcc8 and gcc9 and in this specific case the two declarations of
```
extern const struct btree_keys_ops bch_btree_keys_ops;
extern const struct btree_keys_ops bch_extent_keys_ops;
```
which can be found in `drivers/md/bcache/extents.h`.

In the file `drivers/md/bcache/extents.c` the `const struct btree_keys_ops bch_btree_keys_ops = {…` defines just some of the fields and, specifically **not** the `is_extents = false,` which would apply here. In the `const struct btree_keys_ops bch_extents_keys_ops = {…` more fields are initialized (all?) and `.is_extents = true` is there.

I don't know what happens to an unspecified struct member of type bool. My guess is the default initialization value should be `false` but is this really how it is?