Github messages for voidlinux
 help / color / mirror / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: Package Request: GCC 9.1
Date: Mon, 03 Jun 2019 16:48:18 +0200	[thread overview]
Message-ID: <20190603144818.xwSsEzy7XrKrItcuPmcSd6UEmKjD8ifqQAmy3vJMkq8@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-11663@inbox.vuxu.org>

[-- 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?


       reply	other threads:[~2019-06-03 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-11663@inbox.vuxu.org>
2019-06-03 14:48 ` voidlinux-github [this message]
2019-06-03 14:48 ` voidlinux-github
2019-06-03 14:50 ` voidlinux-github
2019-06-03 14:50 ` voidlinux-github
2019-06-03 15:01 ` voidlinux-github
2019-06-03 23:44 ` voidlinux-github
2019-06-03 23:44 ` voidlinux-github
2019-06-19 19:01 ` voidlinux-github
2019-06-20 13:58 ` voidlinux-github
2019-06-28 14:13 ` voidlinux-github

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190603144818.xwSsEzy7XrKrItcuPmcSd6UEmKjD8ifqQAmy3vJMkq8@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).