SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Edit it: FWIW, 5.12.0 has been built and installed, and is running as it should in -current with the Nvidia-465.24.02 driver and the VirtualBox test build 6.1.21-revision-143957 and its companion extension pack.
Last edited by cwizardone; 04-25-2021 at 05:46 PM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,105
Original Poster
Rep:
Year 2021, Round 29.
Another batch of updates has been scheduled for release on Wednesday, 28 April 2021, at approximately 07:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,105
Original Poster
Rep:
From Mr. Torvalds,
Quote:
New warnings with gcc-11
From: Linus Torvalds
Date: Tue Apr 27 2021 - 19:44:15 EST
I've updated to Fedora 34 on one of my machines, and it causes a lot
of i915 warnings like
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
of type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
and the reason is that gcc now seems to look at the argument array
size more, and notices that
(a) intel_print_wm_latency() takes a "const u16 wm[8]" argument
but
(b) most of the arrays passed in tend to look like 'u16 pri_latency[5]'
I think I will make the argument type to intel_print_wm_latency() be
just "const u16 wm[]" for now, just to avoid seeing a ton of silly
warnings.
I'm not sure if there is a better solution (like making all of those
latency arrays be 8 entries in size), so I'm just letting you know
about my change in this area in case anybody has a better idea.
Re: New warnings with gcc-11
From: Linus Torvalds
Date: Tue Apr 27 2021 - 20:27:18 EST
On Tue, Apr 27, 2021 at 4:43 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I think I will make the argument type to intel_print_wm_latency() be
> just "const u16 wm[]" for now, just to avoid seeing a ton of silly
> warnings.
After fixing the trivial ones, this one remains:
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display/intel_dp.c:4554:22: warning:
‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4
[-Wstringop-overread]
4554 | !drm_dp_channel_eq_ok(&esi[10],
intel_dp->lane_count)) {
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/display/intel_dp.c:4554:22: note: referencing
argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’}
In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
./include/drm/drm_dp_helper.h:1459:6: note: in a call to function
‘drm_dp_channel_eq_ok’
1459 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
| ^~~~~~~~~~~~~~~~~~~~
and I'm not fixing that one, because it actually looks like a valid
warning, and doesn't have an obvious fix.
That "esi[]" array is 14 bytes in size (DP_DPRX_ESI_LEN). So when it
does that "&esi[10]" and passes it in as an argument, then only 4
bytes remain of the array.
And drm_dp_channel_eq_ok() supposedly takes a "const u8
link_status[DP_LINK_STATUS_SIZE]", which is 6 bytes.
There may be some reason this is ok, but it does look a bit fishy, and
the compiler warning is appropriate.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
