Right, signed integer overflow is undefined in C. Try using -fwrapv to
make the compiler treat it more sanely, or do your arithmetic using
unsigned types and just cast to a signed type at the end.
--David Grayson
On Mon, Dec 9, 2024, 11:46 AM Hannes Domani via Mingw-w64-public <
mingw-
ot;Int8ToULong changed 0x7f to something else.");
if(INTSAFE_E_ARITHMETIC_OVERFLOW != Int8ToULong((-0ll - 1), &out))
error("Int8ToULong did not overflow when given (-0ll - 1)");
if (out != (ULONG)-1)
error("Int8ToULong gave wrong overflow output");
}
--David Gray
Indeed there are still numerous bugs in intsafe.h reported by my test
suite, even after applying the patch.
For example, SSIZETToLong is needlessly redefined, resulting in it having
the incorrect type for its first argument (LONGLONG instead of SSIZE_T).
My tests are here: https://github.com/Davi
Hey, original contributor of intsafe.h here. Thank you for fixing this
bug, which was introduced in 2019 by someone else.
I agree with Martin: let's keep the header short and readable, avoid
unneeded ifdefs, define functions in a way that they are obviously correct
on all systems, and not define
ecific details about what you are
trying to compile, what MSYS2 environment you are using, what MSYS2
packages you installed, what you tried, and the full error messages you got.
--David Grayson
On Thu, Nov 30, 2023 at 9:09 AM Frère Justin - Jérusalem <
frere.jus...@fraternites-jerusalem.org&g
I tested it just now and it appears to be supported. Pass the -municode
option to GCC.
--David
On Tue, Jan 3, 2023 at 11:23 AM Luca Bacci wrote:
> Hi,
>
> Is wmain supported by mingw GCC or CLang?
> https://learn.microsoft.com/en-us/cpp/c-language/using-wmain
>
> Otherwise where is the crt sour
and cause
problems for users with different opinions.
--David Grayson
On Sat, Dec 4, 2021 at 1:35 PM NightStrike wrote:
> On Thu, Nov 11, 2021 at 2:43 PM David Grayson
> wrote:
> >
> > Here is my recipe for building a GCC 8.2.0 cross-compiler targeting
> > mingw-w64. I
/master/mingw-w64/gcc/default.nix
I haven't compiled as many packages as the MSYS2 developers, so that's
probably why I didn't need so many patches.
--David Grayson
On Thu, Nov 11, 2021 at 11:37 AM Kacvinsky, Tom
wrote:
> Are these the patches necessary for building GCC f
The command "pacman -S mingw-w64-ucrt-x86_64-toolchain" works for me (at
least as far as finding the names of the packages to install).
Does your system have /etc/pacman.d/mirrorlist.ucrt64 ?
Maybe you need to run "pacman -Syuu" a few times to get that file and
update
What type of make.exe are you running? MSYS2 or MinGW? (Hint: type `which
make` in Bash.)
How exactly are you running it? From a Bash script, from a MinGW program,
from an MSYS2 program?
How are you passing paths to it? Are the paths in a file, on the command
line, or in environment variables
command line to convert Unix-style
paths to Windows-style paths whenever they are invoke a native Windows
program, so that could explain the behavior you are getting.
--David Grayson
On Tue, Mar 9, 2021 at 12:52 PM Paul Ausbeck wrote:
> gcc x86_64-w64-mingw32 can find and open absolute filenames or
It seems like the MinGW-w64 headers provide a declaration for strlwr_l but
it doesn't really work. On MSDN I do not see anything about that function,
but I do see the similarly named function _strlwr_l.
_strlwr_l is defined in libmsvcrt.a, but it is not mentioned in the
MinGW-w64 headers. That s
y good
job at converting those to Windows-style paths.
--David Grayson
On Sat, Nov 28, 2020 at 10:47 AM D G wrote:
>
> Hi everybody,
>
> mingw64 qt5 is not posix path aware.
>
> /home/didier means according to it, C:\home\didier.
>
> I don't know how to convert it wit
Makefiles"
-DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
make install DESTDIR=/
Here's an example project that uses those commands:
https://github.com/pololu/libusbp
--David Grayson
On Thu, Jan 23, 2020 at 3:30 PM David Mathog wrote:
> On 2020-01-23 15:08, David Grayson wrote:
> > Sin
Since CMake in MSYS2 is a native Windows program, if you ask it to make
/tmp, I expect it will make C:/tmp. Did that happen?
--David
On Thu, Jan 23, 2020 at 2:55 PM David Mathog wrote:
> On 2020-01-23 14:15, David Mathog wrote:
> > The CMakeLists.txt file after my signature works correctly in
the
command.
--David Grayson
On Tue, Jan 7, 2020 at 4:16 PM David Mathog wrote:
> In a mingw64 shell if one does something like:
>
> program -in /tmp/infile.txt -out /tmp/outfile.txt
>
> it will generally work because somewhere or other this will happen:
>
>/tmp/i
On Fri, Jan 3, 2020 at 3:23 PM David Mathog wrote:
> Please define "next to".
>
"platforms" would be in the same directory as your executable, if I recall
correctly. You could also try naming it "plugins" and you could also try
putting copies of it in a bunch of different places.
--David
qwindows.dll or qt5windows.dll. You can put that DLL in a directory named
"platforms" next to the main executable so that Qt can find it.
Of course, statically linking everything would be better if you can figure
out how to do that.
--David Grayson
Have you considered simply installing libxml2 by running this command?
pacman -S mingw-w64-i686-libxml2
Also, make sure you are running MSYS2 via mingw32.exe, and that you
have installed the proper GCC toolchain:
pacman -S mingw-w64-i686-toolchain
--David
On Wed, Dec 11, 2019 at 1:51 P
There used to be a halfway-decent mingw-w64 wiki page about how to
build a cross-compiler, but I can't find it.
Perhaps someone has already done the work to create a cross-compiler
package for your Linux distribution. This StackOverflow question
seems promising:
https://unix.stackexchange.com/que
It's not really a chicken and egg situation. You just need to
convince GCC to be a cross-compiler hosted on the mingw-msvcrt
environment and targeting the mingw-ucrt environment. Any libraries
you build targeting ucrt (including mingw-w64's) would go in a
directory like /mingw64-ucrt instead of /
51 AM David Grayson wrote:
>
> That script specifies pkgver=8.3.0, so it builds GCC 8.3.0.
>
> The script is meant to be run in MSYS2, not Cygwin. You could try
> following these instructions to build the GCC package with
> makepkg-mingw and see if it works:
>
> https:
That script specifies pkgver=8.3.0, so it builds GCC 8.3.0.
The script is meant to be run in MSYS2, not Cygwin. You could try
following these instructions to build the GCC package with
makepkg-mingw and see if it works:
https://github.com/msys2/msys2/wiki/Creating-Packages
--David
On Tue, Apr
In my nixcrpkgs project, I never had to use "--disable-multilib". I
just use "--host=x86_64-w64-mingw32" or "--host=i686-w64-mingw32" and
it seems to only build one library. Also I don't have a 32-bit GCC on
my path when building a 64-bit mingw-w64, so there would be no way for
it to build any 32
Your experience matches mine: the Cygwin ldd utility does not work properly
with MinGW DLLs and prints a bunch of question marks. There is an ntldd
utility you can use instead. If it's not on your path already, I'm not
sure the best way to obtain it. I just use MSYS2, because it's basically a
fo
For what it's worth, I just tried the latest version of mingw-w64 and I am
not seeing any issue with the CRT getting compiled again when `make
install` is run.
My build scripts are here:
https://github.com/DavidEGrayson/nixcrpkgs/tree/master/mingw-w64
The basic procedure is:
1) Before any mingw-
gt; doing this work here.
>
> On Mon 12 Mar 2018 at 12:20, Martin Storsjö wrote:
>
>> On Mon, 12 Mar 2018, Martin Storsjö wrote:
>>
>> > On Sun, 11 Mar 2018, David Grayson wrote:
>> >
>> >> Martell, did you send a bug report to clang too? That
Martell, did you send a bug report to clang too? That seems like a
serious bug for them to have.
Also, "asm volatile" statements cannot be removed, reordered or
cached, right? It seems like a bad idea to hamper GCC's optimizations
and performance as a workaround for a clang bug.
--David
On Sun
Since the first error is saying uint16_t is undefined, did you try adding
"#include " at the top of genlib.c?
--David Grayson
On Mar 11, 2018 5:06 AM, wrote:
> For some strange reason, I'm getting these errors when compiling the tools
> for MINGW-W64:
>
>
You can look at the header files in the Windows SDK as a reference,
but don't directly copy anything from there. Email the patch to this
list. Use a .txt extension for the patch so that Sourceforge does not
filter out your attachment. You can look in the list archives to see
examples of other pa
The mingw-w64 project has some documentation about how to build a
mingw-w64 GCC compiler:
https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/
https://github.com/mirror/mingw-w64/tree/master/mingw-w64-doc/howto-build
Or you could use MSYS2 and start with the build scr
Oftentimes there are things missing from the mingw-w64 headers and
what you can do is make a patch that fixes it and submit the patch on
this mailing list (see the archives for examples). Usually it's not
an intellectual property issue.
--David
On Tue, Oct 3, 2017 at 1:04 PM, John Warburton wro
Microsoft just published an article about this kind of thing:
https://blogs.msdn.microsoft.com/oldnewthing/20170927-00/?p=97095
It seems that casting pointers to uintptr_t before comparing them
would probably be safe.
--David Grayson
On Sat, Aug 5, 2017 at 12:44 PM, David Grayson wrote
uce my results
reliably by just running a few commands:
https://github.com/DavidEGrayson/nixcrpkgs
--David Grayson
On Wed, Aug 23, 2017 at 1:59 PM, Zebediah Figura wrote:
> Hello,
>
> I am interested in implementing, or helping to implement, support for 16-bit
> code and NE exe
Martell: OK, I looked at that link briefly. I think I understand what
you're worried about here: the markers that we have at the beginning
and end of our constructor/destructor sections might be removed by the
linker of clang or GCC if it is determined that no code is actually
referencing those va
On Fri, Aug 18, 2017 at 12:26 PM, Martin Storsjö wrote:
> Yup, that resolves the concern.
>
> As long as you just use one or the other of *_LIST__ or *_END__ in each
> function and use the sentinel values instead of comparing the pointers, it
> should be fine. Otherwise the compiler is free to reg
Thanks for the explanation of the binutils bug, Martell.
Also, your latest patch has bad newlines inserted by GMail again. It
might actually be better to use GMail's HTML mode, or just use an
attachment with a .txt extension (not .patch).
--David
On Fri, Aug 18, 2017 at 12:05 PM, Martell Malone
Martell, what was wrong with the sorting in the old binutils? It
seems like the only thing you're doing is changing "SORT" to
"SORT_BY_NAME" but I couldn't easily tell if that will make a
difference.
--David
On Fri, Aug 18, 2017 at 11:11 AM, Martell Malone
wrote:
>>
>> suddenly requiring the a
gt; on specific section names.
> The compiler has no recourse for optimising this out.
> It is the linker that will organise the sections and fill in the branch
> offsets.
> Even with LTO this would not fail.
>
> On Sat, Aug 5, 2017 at 8:44 PM, David Grayson
> wrote:
>
>
I would agree with Martin; I think it's a very good practice for
source files to have an error or not define a function instead of
defining a function that can't possibly work and letting the build
proceed with a broken function. Compiler and linker errors are much
easier to figure out than segmen
e but it should be fine otherwise.
> I would be cleaner and better to change the linker script though.
>
> On Sat, Aug 5, 2017 at 6:15 PM, David Grayson
> wrote:
>
>> Oops, here is the patch.
>>
>> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson
>> wrote:
>
Oops, here is the patch.
On Sat, Aug 5, 2017 at 10:14 AM, David Grayson wrote:
> I think Martell's last patch would have worked but it's not as safe as
> I would like it to be. I think the constructor and destructor lists
> should not be defined in gccmain.c where they are
tor sections, and
how it sorts those names, so I'm not sure that the symbols we are
defining would really be in the right place.
--David Grayson
On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone wrote:
> Hey David,
>
>
>> Your binutils patch did not apply cleanly to binutils-2.27 b
libraries since they are not EXEs.
--David
On Fri, Aug 4, 2017 at 6:12 PM, David Grayson wrote:
> Oh, I mean that I got the patch to apply, but I don't know if it
> really *works*; the toolchain is still building at this time. --David
>
> On Fri, Aug 4, 2017 at 6:11 PM, David Grays
Oh, I mean that I got the patch to apply, but I don't know if it
really *works*; the toolchain is still building at this time. --David
On Fri, Aug 4, 2017 at 6:11 PM, David Grayson wrote:
> Your binutils patch did not apply cleanly to binutils-2.27 but I got
> it to work. It l
e_base__
> to ___ImageBase and __ImageBase on x86 and x64 respectively.
> Best,
> Martell
>
> On Sat, Aug 5, 2017 at 12:20 AM, David Grayson
> wrote:
>
>> Martell:
>>
>> My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite
>> easy
Martell:
My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite
easy to try random patches and make sure that GCC can still be
bootstrapped and that I can build non-trivial applications. I tried
your patch (after fixing the linebreaks added by GMail) but
unfortunately it doesn't w
t the beginning of this thread could work
too, and putting it in a separate object file just for clang seems
like a good idea. I think Martell's patch is relying on sections to be
sorted in alphabetical order.
--David Grayson
--
Hell
Try sending it as ".txt" file and make sure your MIME-type is
something like text/plain.
--David
On Thu, Jul 13, 2017 at 11:29 AM, The Canadian Bacon
wrote:
> You're missing your attachment on this one.
>
> On Jul 13, 2017 11:05 AM, "Ruslan Garipov" wrote:
>
>>
>> This is a series of commits th
Riot, do you work for Riot Games?
Anyway, in this patch, the line of code being changed is guarded by
#ifndef _WIN32_WINNT. So if you define _WIN32_WINNT yourself, this
patch will have no effect on you. (I'm assuming that the value of
_WIN32_WINNT does not affect how the MinGW libraries are comp
I'd encourage you to try the mingw-w64 route. If you use mingw-w64
and GCC, you won't have to worry about the licensing restrictions
Microsoft puts on Visual Studio, which have changed over the years.
The mingw-w64 project provides a lot of the headers and functions that
Visual Studio has, and the
C++ has no standard ABI, so it is unlikely that you will be able to
mix C++ binaries that come from different compilers like that. I'm
not sure what the COMDAT error means, though.
Why do you want to build your application using both Visual Studio and
MinGW? Why not pick one and stick with it?
I was able to reproduce your problem. The issue is that you declared
a variable named stdout, which is a name used by the C standard. Just
rename that variable.
--David
On Sun, Jun 4, 2017 at 8:31 AM, bob by wrote:
> 2017-06-02 15:47 GMT+04:00 bob by
>
>> Can somebody here write a replacement
On Thu, Jun 1, 2017 at 11:49 AM, bob by wrote:
> I linked all libraries statically, before that it depended on
> libgcc_s_dw2-1.dll and libwinpthread-1.dll, and probably something
> else too. It was around 500 KiB originally, now it is almost 1000 KiB.
if your program depends on those DLLs, it me
Also, did you remember to run the binutils "strip" utility on your
executable before deciding it was huge?
--David
On Thu, Jun 1, 2017 at 10:54 AM, David Grayson wrote:
> How huge is "weirdly huge"? Does your executable depend on any MinGW
> DLLs, like libstdc++-6.dll
How huge is "weirdly huge"? Does your executable depend on any MinGW
DLLs, like libstdc++-6.dll?
The code in the "std" namespace is generally provided by libstdc++v3,
which is a component of GCC and can be found in the GCC source:
ftp://ftp.gnu.org/gnu/gcc/ You haven't said what version of GCC y
The boolean logic in the patch looks wrong to me. You're going to end
up disabling __in and __out for all GCC and Clang programs regardless
of what language they use because __GNUC__ will be defined.
Seems like this would be better:
#if defined(__cplusplus) && defined(__GNUC__)
// Don't define _
Oops, there's no attachment. Try sending it with a MIME type of
text/plain so SourceForge does not eat it; you might have to add a
.txt extension to it to make your mail client do that.
--David
On Sat, May 27, 2017 at 7:51 PM, Samuel Leslie wrote:
> Sounds like I've misinterpreted the correct u
,
and I can only find documentation for the latter pair, so it's a bit
confusing.
Now that I think about it again, given that driverspecs.h does not
define __in or __out, I am actually in favor of Mateusz's patch now,
because it will make mingw-w64 close
it somehow does not
include driverspecs.h?
--David Grayson
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://s
Here's the sed command again, without bad line wrapping:
https://gist.github.com/DavidEGrayson/ee9796a900eedda3d6b7c8f2324793a4
--David
On Wed, May 17, 2017 at 7:08 AM, David Grayson wrote:
> A GCC maintainer has spoken up and said they will accept a patch to
> rename __in and __o
orks too, and it's just as easy as getting other toolchain
builders to run the sed command. If we do change mingw-w64, what
would be the timeline for reverting that change? Would we wait until
the offending versions of libstdc++ have been replaced by fixed stable
for versions for, say, 5
If I were a mingw-w64 committer, I probably wouldn't make that change,
but I am OK with it. An argument in favor of that change is that it
isn't too hard to just use sed or carefully-placed #defines to fix any
Microsoft-style code that uses __in and __out. (It's not ideal, but
not terrible.) And
_locale.h \
config/locale/generic/c_locale.h \
config/locale/gnu/c_locale.h
--David
On Thu, May 11, 2017 at 9:55 AM, David Grayson wrote:
> Hello, gcc-help.
>
> There is an incompatibility between libstdc++ and the headers provided
> by Microsoft and mingw-w64, because libstdc++
4 without using hacky
workarounds.
--David
On Thu, May 11, 2017 at 7:29 AM, Liu Hao wrote:
> On 2017/5/11 21:51, David Grayson wrote:
>> Unfortunately, my patch seems to break several classes in libstdc++,
>> preventing Qt from building. The problem is that driverspecs.h defines
he include, so that it is
> user-defined, if this header should be included, or not.
> This might be a work-a-round for this, which should work for most.
>
> Regards,
> Kai
>
> 2017-05-11 15:51 GMT+02:00 David Grayson :
> > Unfortunately, my patch seems to break severa
includes both sal.h and driverspecs.h so that
shouldn't affect when the bug appears.
--David Grayson
On Wed, May 10, 2017 at 9:44 AM, David Grayson
wrote:
> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I purposely
> used the same include guard name as Microso
e driverspecs.h in
> specstrings.h.
> Date: Wed, 10 May 2017 08:24:25 -0700
> From: David Grayson
> To: Liu Hao
>
>
>
> OK, thanks. I've attached a new patch where the #include is after the
> __cplusplus stuff.
>
> I also included a second patch that
This patch adds "#include " near the end of specstrings.h,
because the same is done in Microsoft's version of specstrings.h. With
this patch, I am able to build Microsoft's devcon utility without
modification. Thanks!
--David Grayson
From bbe97312dabdbd7200b337ad8f8232786a
t necessary.
--David
On Wed, May 3, 2017 at 2:14 PM, Mateusz wrote:
> We could consider define DECLSPEC_SELECTANY to __attribute__((weak)) for
> old GCC.
>
> Patch for this attached.
>
> W dniu 2017-05-03 o 17:19, David Grayson pisze:
> > By the way, it's really no
ngw-w64, because
you would have to prevent any GUID definitions from being emitted by header
files.
--David
On Wed, May 3, 2017 at 8:12 AM, David Grayson
wrote:
> > It sounds like guiddef.h should probably check the GCC major version.
>> > Based on the tests people have reported in
>
> > It sounds like guiddef.h should probably check the GCC major version.
> > Based on the tests people have reported in this thread, I would guess
> that
> > for GCC 6 and above the selectany attribute on the declaration is
> required,
> > while on GCC 5 and below the selectany attribute on the
selectany attribute on the declaration is
forbidden. Or we could get fancy and add a test to the configure script to
figure out which is the case.
--David Grayson
On Tue, May 2, 2017 at 7:49 PM, Liu Hao wrote:
> On 2017/5/3 9:33, Liu Hao wrote:
> > Kai, should we revert it? We have to dea
fail to reproduce it?
--David Grayson
On Mon, May 1, 2017 at 6:41 PM, Liu Hao wrote:
> On 2017/5/2 3:08, David Grayson wrote:
> > Oops, I should have learned my lesson. Well, here it is again. I think
> my
> > original email 6 days ago was good though.
> I did see the p
; > >
> >
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> &
I sent a patch to this list 6 days ago that fixes a problem with the way we
use the selectany attribute. If you're getting multiple definition errors
for GUIDs, this will probably fix it. I'll attach it again.
--David
On Mon, May 1, 2017 at 9:34 AM, Mateusz Mikuła wrote:
> Symbols in libuuid.
atch fixes that by adding __declspec(selectany) to the GUID
declarations.
Thanks!
--David Grayson
From 7ce782720ce2190442bd835518ebc63e246b0050 Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Tue, 25 Apr 2017 07:41:45 -0700
Subject: [PATCH] guiddef.h: Use __declspec(selectany) on GUID dec
Hello. The attached patch adds some definitions and structs that were
missing from usbspec.h. I needed this to build the latest version of
Microsoft's usbview program (
https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ).
Thanks!
--David Grayson
Apr 7, 2017 at 9:31 AM, Kai Tietz wrote:
> 2017-04-07 17:21 GMT+02:00 David Grayson :
> >> type1 *foo(const type1 *my_const_ptr)
> >> {
> >> union {
> >> type1 *t1;
> >> const type1 *ct1;
> >> } v;
> >> v.ct1 = my_const_ptr;
>
Oh, it would be a warning with -Wcast-qual, ok, got it. --David
On Fri, Apr 7, 2017 at 8:21 AM, David Grayson
wrote:
> > type1 *foo(const type1 *my_const_ptr)
> > {
> > union {
> > type1 *t1;
> > const type1 *ct1;
> > } v;
> > v.ct1 = my_const_pt
> type1 *foo(const type1 *my_const_ptr)
> {
> union {
> type1 *t1;
> const type1 *ct1;
> } v;
> v.ct1 = my_const_ptr;
> return v.t1;
> }
Yes, that is sad, and it seems like just a matter of time before a C++
compiler looks at the code above and reasons that the write to ct1 can be
optimized aw
On Mon, Apr 3, 2017 at 10:02 AM, Liu Hao wrote:
> On 2017/4/4 0:48, David Grayson wrote:
> > I'm a bit confused about the different inlining keywords. From the GCC
> > documentation for inlining in the C language (
> > https://gcc.gnu.org/onlinedocs/gcc/Inline.htm
I looked into it a little more.
__NO_INLINE__ is a macro provided by GCC that is documented to be defined
if "no functions will be inlined into their callers". This seems to be
defined by GCC by default, but it is not defined when you provide the "-O2"
option.
__CRT__NO_INLINE is defined in ming
or look
into it more and figure out what the right logic really is.
--David
On Sun, Apr 2, 2017 at 8:12 PM, David Grayson
wrote:
> I just tested LH_Mouse's patch and it seems to work fine, so I am OK with
> using it instead of mine.
>
> However, that patch seems like it could be
I just tested LH_Mouse's patch and it seems to work fine, so I am OK with
using it instead of mine.
However, that patch seems like it could be wrong too, since when strsafe.h
is used to compile the library, all the library functions will have
__inline in their declarations even though we are compi
; >functions be inline and I was not sure, but probably the right way to
> >do
> >that is to use __CRT_INLINE.
> >
> >Thanks!
> >
> >--David Grayson
>
> --
> Check out the vibrant tech
so I
have attached a patch for doing that. I could have just removed the
"__inline" but it seems like mingw-w64 has a feature of making all its
functions be inline and I was not sure, but probably the right way to do
that is to use __CRT_INL
If the content type is left unspecified, then the attachment is
> deleted. I can add anything you like.
>
> On Sun, Mar 19, 2017 at 10:30 PM, David Grayson
> wrote:
> > NightStrike,
> >
> > The mailing list swallowed the patch in the message I sent on March 16th.
>
NightStrike,
The mailing list swallowed the patch in the message I sent on March 16th.
I can see in GMail that I did have a patch attached to my message, but no
attachment is visible in the archive here:
https://sourceforge.net/p/mingw-w64/mailman/message/35729302/
--David Grayson
On Sun, Mar
Hello.
Here is that patch again. Thanks!
--David Grayson
>From 63f1126b246df52e4252d148897f3e262931368b Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Thu, 16 Mar 2017 19:35:23 -0700
Subject: [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue.
Apparently &quo
t;. You can see
the difference for yourself by trying to compile this small bit of C
code:
#include
void x(const LPVOID);
void y(LPCVOID);
void test() {
const char * data;
x(data);
y(data);
}
Thanks!
--David Grayson
d changing the name of your class. When an
experienced Windows programmer sees "LoadImage(...)" in your code they
might think you are calling the Windows LoadImage functions but you
are actually constructing an instance of your class.
--David Grayson
On Tue, Mar 14, 2017 at 3:42 AM, Mar
If the compiler has a builtin for the intrinsic, why would mingw-w64
still provide a prototype for it? It seems like it would have no
benefit and be likely to just cause compiler errors in the future.
--David
On Fri, Feb 17, 2017 at 4:25 AM, Jacek Caban wrote:
> Please review.
>
> ---
> mingw-
ches used by
> MSYS2), I tried it also:
> https://paste.ubuntu.com/23957478/
>
> While for 3.9.x Clang `-fms-extensions` didn't hurt, master branch require
> some corrections but it is another issue.
>
>
> 2017-02-09 0:15 GMT+01:00 David Grayson :
>
>> I can con
generating LLVM code from
C/C++ code.
--David Grayson
On Wed, Feb 8, 2017 at 1:24 PM, Mateusz wrote:
> Opps, gmail put output into quote. Improved version:
> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
>
;; did you
> mean '_popcnt64'?
> unsigned __int64 ulr = __popcnt64(ul[i]);
>^~
>_popcnt64
> D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: note:
> '_popcnt64' declared here
> _popcnt64(long long __A)
> ^
> 3 errors gen
und it.
I read the documentation for intrin.h and intrin-impl.h and I believe this
patch follows all the rules. It would be great if it could be merged in.
Thanks!
--David Grayson
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
ind
Patch is not attached.
--David
On Sat, Nov 12, 2016 at 7:33 PM, Nakai Yuta wrote:
> C99 defines INFINITY and NAN macros as float.
> patch is attached.
>
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
That flag also fixes the return values of certain functions like
vsnprintf where the Microsoft behavior deviated from the standard.
--David
On Tue, Sep 6, 2016 at 3:01 PM, Jeroen Ooms wrote:
> On Tue, Sep 6, 2016 at 8:50 PM, Stefan Weil wrote:
>> I suggest using the ANSI format specifiers ("%ll
Having only thought about this for a few minutes, I am guessing that
you would need to use the Microsoft-style printf modifier and also use
a GCC pragma to suppress the warning:
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
--David
On Tue, Sep 6, 2016 at 9:06 AM, Jeroen Ooms wrote:
1 - 100 of 134 matches
Mail list logo
