Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=25206
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=25204
Your paranoid android
Dan Kegel writes:
> On Fri, Apr 19, 2013 at 10:38 AM, Dan Kegel wrote:
>> Hooking is a fragile business. Somebody somewhere is probably
>> making assumptions about how hooking works (like, how many stack
>> frames are pushed), and inlining call_hook_proc probably violates one
>> of those assump
On Fri, Apr 19, 2013 at 10:38 AM, Dan Kegel wrote:
> Hooking is a fragile business. Somebody somewhere is probably
> making assumptions about how hooking works (like, how many stack
> frames are pushed), and inlining call_hook_proc probably violates one
> of those assumptions.
That said, this is
On Fri, Apr 19, 2013 at 10:13 AM, Qian Hong wrote:
> Curiosity killed the cat, what is the theory behind this patch?
Hooking is a fragile business. Somebody somewhere is probably
making assumptions about how hooking works (like, how many stack
frames are pushed), and inlining call_hook_proc prob
Am 19.04.2013 19:13, schrieb Qian Hong:
> On Sat, Apr 20, 2013 at 12:52 AM, Dan Kegel wrote:
>> I suspect this is a real fix, and there is no gcc bug.
>
> Thanks for clarify.
>
> Curiosity killed the cat, what is the theory behind this patch?
> I tried explicitly add 'inline' to every static fun
On Sat, Apr 20, 2013 at 12:52 AM, Dan Kegel wrote:
> I suspect this is a real fix, and there is no gcc bug.
Thanks for clarify.
Curiosity killed the cat, what is the theory behind this patch?
I tried explicitly add 'inline' to every static functions in hook.c
but complie with -O0, to see if the
Hrm, I sent the wrong version of the patch, I had actually moved the
depth/stencil check earlier (so yeah, totally agree on that part).
Also you're right about WINED3DFMT_FLAG_RENDERTARGET, for some reason
I thought we were setting that in check_fbo_compat() but it's clearly
not the case.
I'm send
I suspect this is a real fix, and there is no gcc bug.
On Fri, Apr 19, 2013 at 9:47 AM, Qian Hong wrote:
> Hi Dan,
>
> Thanks for working on it! It is really an annoying bug, however, is
> adding DECLSPEC_NOINLINE a workaround or a real fix? If it is only a
> workaround, would that hide some real
Hi Dan,
Thanks for working on it! It is really an annoying bug, however, is
adding DECLSPEC_NOINLINE a workaround or a real fix? If it is only a
workaround, would that hide some real bug behind it? Or is that
possible that there is a gcc bug here that we want to report to gcc?
Thanks for your tim
On 04/19/2013 02:46 AM, Dmitry Timoshkov wrote:
Sam Edwards wrote:
This change only affects malformed fonts that have glyphs with splines
that go above the maximum ascent as specified in the font's hhea/os2
table. For that reason, any tests for this change would have to include
a malformed fon
On 19 April 2013 17:39, Stefan Dösinger wrote:
> The tricky bit is the lowest_disabled_stage because we have two pieces
> of code that use it. One is wined3d_device_set_texture_stage_state,
> which uses it to find nop state changes. The other one are the state
> application function and device_map
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-19 16:26, schrieb Henri Verbeet:
> I think we'll want a separate structure for this. Note that you
> essentially have two different kinds of data you're concerned with
> here though. One is derived state like e.g. the texture unit map,
> t
On 18 April 2013 21:20, Matteo Bruni wrote:
> +/* FIXME: We can't handle "partial" sRGB decode support
> right now, we could
> + * introduce a new format flag and check for that. */
As mentioned on IRC, I don't think this is really an issue. The patch
looks
On 18 April 2013 21:19, Matteo Bruni wrote:
> +if (!format->glInternal) continue;
> +
> +gl_info->gl_ops.ext.p_glGetInternalformativ(GL_TEXTURE_2D,
> format->glInternal,
> +GL_FRAMEBUFFER_RENDERABLE, 1, &value);
> +if (value == GL_FULL_SUPPO
On 19 April 2013 11:20, Stefan Dösinger wrote:
> Potential alternatives include keeping the status quo or introducing a
> separate structure that holds these derived limits that is owned by the
> device and linked in the contexts. We could also put it into gl_info,
> but I dislike this idea becaus
Hi Akihiro,
2013/4/19 Akihiro Sagawa
>
> According to MSDN, _mbsncoll_l receives a number of characters, but
> _mbsnbcoll_l receives a number of bytes. This is a big difference in
> multibyte code page.
> So you should properly handle this situation, or add FIXME message based
> on multibyte code
On Fri, 19 Apr 2013 14:42:50 +0800, Jactry Zeng wrote:
> +/*
> + * _mbsncoll_l(MSVCRT.@)
> + */
> +int CDECL _mbsncoll_l(const unsigned char *str1, const unsigned char *str2,
> MSVCRT_size_t count,
> +
Sir,
I will be applying for GSoC 2013 under your mentoring team.
Sorry for contacting very late with you as I was not aware of this program.
I came to know yesterday that Gsoc is going to start.
As a CS student and I have a well understanding of C C++ and Java and Data
structures I am always very k
On 04/19/2013 12:43 AM, Austin English wrote:
With wine-1.5.20 and clang 3.2, the test suite is in the same state on
my Fedora 18 machine as gcc-4.7.2
llvm version: git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@179768
91177308-0d34-0410-b5e6-96231b3b80d8
clang version: git-svn-id:
20 matches
Mail list logo
