September 2021 - Wine-Devel

Re: [PATCH vkd3d 4/6] vkd3d-shader/hlsl: Use cached vector types in more places.

by Matteo Bruni

Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH vkd3d 3/6] vkd3d-shader/hlsl: Avoid hardcoding the size of the operands array.

by Matteo Bruni

Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH vkd3d 2/6] vkd3d-shader/hlsl: Specify the destination register in struct sm4_instruction as an array.

by Matteo Bruni

Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH vkd3d v2 1/6] vkd3d-shader/hlsl: Parse state blocks in variable definitions.

by Matteo Bruni

Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH 1/6] dlls/msvcrt*: ensure variable sse2_cw is set for all code paths in _control87 (GCC11)

by Eric Pouech

Le 30/09/2021 à 19:39, Zebediah Figura a écrit : > On 9/30/21 12:14 PM, Eric Pouech wrote: >> >>>> >>>> which still gives me the warnings, when compiling the 32bit part of a >>>> wow64 conf >>>> >>>> (but not on a pure 32bit conf) >>>> >>>> your solution doesn't generate warnings on neither of the two >>>> >>>> so will need further investigation on: >>>> >>>> - discrepency wrt wow >>>> >>>> - why the difference between the two patches >>> >>> I don't get warnings with that diff either. What version of GCC do you >>> have? >> >> well, o well.... >> >> retesting today, and couldn't get any warnings with the patch I posted >> yesterday...<grrr> >> >> >> moreover, in this patch, if I change the if (_control... by if >> (!control... (inverting the test), I get no warnings either which makes >> absolutely no sense >> >> >> I'm starting to wonder if the -Wmaybe-uninitialized warning could be a >> little fragile at this point >> >> >> there are a couple of bugs reports on gcc bugzilla reguarding this >> warning >> >> potentially bugs report like may link to the same type of issues >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381 >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101768 >> >> >> I may wait a bit to let things settle down before taking any action on >> this fix in msvcrt > > I mean, -Wmaybe-uninitialized has always been at least somewhat > heuristic, throughout the entire history of gcc, and there have been > false positives and false negatives. But I've found that it tends to > behave nicely for idiomatically structured code. I've found very few > cases where "just initialize the variable to zero" seems like the best > solution to me. I'm not suggesting at this point to disable -Wmaybe-unitialized I'm just facing instability in tests results here: - either because of me - hw instability (i've seen some abnormal crashes) - heisenbug in gcc (listed in decreasing probability) A+

Sept. 30, 2021

Re: [PATCH 1/6] dlls/msvcrt*: ensure variable sse2_cw is set for all code paths in _control87 (GCC11)

by Zebediah Figura

On 9/30/21 12:14 PM, Eric Pouech wrote: > >>> >>> which still gives me the warnings, when compiling the 32bit part of a >>> wow64 conf >>> >>> (but not on a pure 32bit conf) >>> >>> your solution doesn't generate warnings on neither of the two >>> >>> so will need further investigation on: >>> >>> - discrepency wrt wow >>> >>> - why the difference between the two patches >> >> I don't get warnings with that diff either. What version of GCC do you >> have? > > well, o well.... > > retesting today, and couldn't get any warnings with the patch I posted > yesterday...<grrr> > > > moreover, in this patch, if I change the if (_control... by if > (!control... (inverting the test), I get no warnings either which makes > absolutely no sense > > > I'm starting to wonder if the -Wmaybe-uninitialized warning could be a > little fragile at this point > > > there are a couple of bugs reports on gcc bugzilla reguarding this warning > > potentially bugs report like may link to the same type of issues > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101768 > > > I may wait a bit to let things settle down before taking any action on > this fix in msvcrt I mean, -Wmaybe-uninitialized has always been at least somewhat heuristic, throughout the entire history of gcc, and there have been false positives and false negatives. But I've found that it tends to behave nicely for idiomatically structured code. I've found very few cases where "just initialize the variable to zero" seems like the best solution to me.

Sept. 30, 2021

Re: [PATCH 1/6] dlls/msvcrt*: ensure variable sse2_cw is set for all code paths in _control87 (GCC11)

by Eric Pouech

>> >> which still gives me the warnings, when compiling the 32bit part of a >> wow64 conf >> >> (but not on a pure 32bit conf) >> >> your solution doesn't generate warnings on neither of the two >> >> so will need further investigation on: >> >> - discrepency wrt wow >> >> - why the difference between the two patches > > I don't get warnings with that diff either. What version of GCC do you > have? well, o well.... retesting today, and couldn't get any warnings with the patch I posted yesterday...<grrr> moreover, in this patch, if I change the if (_control... by if (!control... (inverting the test), I get no warnings either which makes absolutely no sense I'm starting to wonder if the -Wmaybe-uninitialized warning could be a little fragile at this point there are a couple of bugs reports on gcc bugzilla reguarding this warning potentially bugs report like may link to the same type of issues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101768 I may wait a bit to let things settle down before taking any action on this fix in msvcrt A+

Sept. 30, 2021

Re: [PATCH 2/2] secur32: Remove macOS backend.

by Hans Leidekker

Signed-off-by: Hans Leidekker <hans(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH 1/2] bcrypt: Remove macOS backend.

by Hans Leidekker

Signed-off-by: Hans Leidekker <hans(a)codeweavers.com>

Sept. 30, 2021

Re: [PATCH 2/2] riched20: Use regular allocation helpers for text services objects.

by Huw Davies

Signed-off-by: Huw Davies <huw(a)codeweavers.com>

Sept. 30, 2021