> Please take the hostility down a notch. I don't see why it's necessary.
I apologize (to both you and Kai) if that's how this came across. That
was not my intent. I routinely use weekends to work on new puzzles.
The reason I suggested it would give him plenty to think about over the
weekend
> >> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb
> >> > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf
> >> > fu hovers around the nano-fu level. While the failure is not a mingw-w64
> >> > bug, you guys likely have a better battle-tested solu
2013/3/29 dw
> While I haven't heard back from you about my response re volatile, I'm
> going to go ahead and write my post about why I think my understanding
> of the memory clobber is correct. Should give you plenty to think about
> over the weekend.
>
Please take the hostility down a notch.
> I agree that where the code would really be suboptimal, the intrinsics
> should be implemented using more efficient means. However, I doubt
> that, e.g., _InterlockedAdd() has the same problem. Each intrinsic
> should be evaluated separately.
Fair enough. When the first couple of intrinsics
While I haven't heard back from you about my response re volatile, I'm
going to go ahead and write my post about why I think my understanding
of the memory clobber is correct. Should give you plenty to think about
over the weekend.
In my original post, I said that I wanted to add the memory cl
Hello,
After careful thought, we have decided to make gendef, genidl and
genpeimg use GPLv3 or later for all future releases.
The change brings us closer to the Free software community, guaranteeing
Free access to the source code for all in perpetuity, especially for the
software developers and c
On Fri, Mar 29, 2013 at 9:42 AM, Jon wrote:
>> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb
>> > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf
>> > fu hovers around the nano-fu level. While the failure is not a mingw-w64
>> > bug, you guys li
2013/3/29 Earnie Boyd
> On Fri, Mar 29, 2013 at 8:55 AM, LRN wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 29.03.2013 15:15, Алексей Павлов wrote:
> Question #2: If MinGW64 'uname' will not be available any time
> soon, is there any problem in using the --build
> > I'm toying with lzo on Windows 7 32-bit (mingwbuilds 4.8.0 and rubenvb
> > 4.7.2) and want to create a solid patch for configure.ac, but my autoconf
> > fu hovers around the nano-fu level. While the failure is not a mingw-w64
> > bug, you guys likely have a better battle-tested solution than my
On Fri, Mar 29, 2013 at 9:13 AM, Earnie Boyd wrote:
>
> Caution: MSYSTEM=MINGW64 will be used for identifying
> i86_64-pc-mingw64 in config.guess; I submitted a patch for it to the
> maintainers of config.guess and config.sub last year.
Lacking the caffeine this morning s/i86_64/x86_64/
--
Earni
On Fri, Mar 29, 2013 at 8:55 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29.03.2013 15:15, Алексей Павлов wrote:
Question #2: If MinGW64 'uname' will not be available any time
soon, is there any problem in using the --build option when
you configure?
>>> I
On 28 March 2013 22:32, dw wrote:
> On 3/28/2013 3:52 AM, Václav Zeman wrote:
>> Why are those intrinsics even implemented using inline assembler
>> instead of GCC's own built-in functions like __builtin_ffs() for
>> _BitScanForward(), __sync_add_and_fetch() for _InterlockedAdd(), etc.?
> Actually,
On 23/3/13 8:47 AM, Ruben Van Boxem wrote:
> What gives?
Don't know. I reported the same error on gcc-help the 10th of January
this year.
--
chs
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to g
13 matches
Mail list logo
