> Still, the question if we want those in our crt is a separated issue.
> That's a question of being backward compatible, which is important IMO.
> Too bad those were introduced in the first place...
To me, this is the key question. I agree that breaking backward
compatibility is a bad thing.
> With this specific define set the boost package can indeed be compiled
> without issues (for both the x86 and x64 targets).
Yay!
> However, there's a catch! The boost build system doesn't embed this
> specific define in its installed headers. It expects that all
> boost-using projects (like q
> I vote for this. Boost can always be fixed, and it contains lots of
> ugly hacks around various platform obscurities. I think MSVC
> intrinsics combined with GCC are a valid obscurity.
> Granted, if Boost is to change, you might as well give them the best
> performance while we're at it :)
I
> I committed the patch with additional __MINGW_INTRIN_INLINE check so we
> can move on (to another problem on x64).
I committed the additional updates I had sent privately to Erik.
As for the __MINGW_INTRIN_INLINE thing, I guess I still don't quite
understand the value. If it isn't defined, is
Hello Jon and Kai!
On Sat, Jul 20, 2013 at 11:54 PM, JonY <10bottlesofb...@gmail.com> wrote:
> On 7/21/2013 11:47, Kai Tietz wrote:
>> Actually gcc provides libquadmath for 128-bit floating point math routines.
>>
>> It might be worth a look.
>>
>> Aloha
>> Kai
>
> Looks like it does provide the m
On 7/21/2013 11:47, Kai Tietz wrote:
> Actually gcc provides libquadmath for 128-bit floating point math routines.
>
> It might be worth a look.
>
> Aloha
> Kai
Looks like it does provide the math routines, I thought it was just
providing support constructs. Anyway, be aware that license is LGPL
Actually gcc provides libquadmath for 128-bit floating point math routines.
It might be worth a look.
Aloha
Kai
Am 20.07.2013 17:04 schrieb "JonY" :
> On 7/21/2013 01:58, K. Frank wrote:
> >
> > That would certainly make sense, but it doesn't square with what
> > numeric_limits is telling me:
>
On 7/21/2013 01:58, K. Frank wrote:
>
> That would certainly make sense, but it doesn't square with what
> numeric_limits is telling me:
>
>numeric_limits::digits10 = 18
>numeric_limits::max_digits10 = 21
>
> Just to check that numeric_limits isn't lying to me I ran a small program
> tha
On 7/21/2013 02:00, niXman wrote:
> After the discussion of the details, it was decided to merge the
> MinGW-builds and MinGW-w64 projects.
> Since then, the MinGW-builds project and all its achievements, are
> moving into the MinGW-w64 project and, thus, the MinGW-w64 project
> gets the official b
dw schreef op za 20-07-2013 om 02:07 [-0700]:
> Boost could:
> 1) Use winbase.h (via windows.h) like the MSDN docs say they should.
> In fact, I wonder if defining BOOST_USE_WINDOWS_H would work.
I just did some more testing. According to
http://sligt.wordpress.com/2011/03/05/compiling-boost-thre
Hi,
There is a problem in Ruben's builds
"x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z" and
"x86_64-w64-mingw32-gcc-4.8.0-linux64_rubenvb.tar.xz". The simple code
snippet below with argument "-static -O2 -flto" can reproduce the problem:
#include
int main(){
std::cout << "Foo = " << 101 << std::e
After the discussion of the details, it was decided to merge the
MinGW-builds and MinGW-w64 projects.
Since then, the MinGW-builds project and all its achievements, are
moving into the MinGW-w64 project and, thus, the MinGW-w64 project
gets the official builds of the toolchains.
The old MinGW-w64
Hi Jon!
Thanks for your reply.
On Sat, Jul 20, 2013 at 12:17 PM, JonY wrote:
> On 7/20/2013 23:43, K. Frank wrote:
>> Hello List!
>>
>> On 64-bit mingw-w64:
>>
>>g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)
>>
>> on 64-bit windows 7, I'm seeing that long doubles have a precision o
2013/7/20 Ruben Van Boxem:
> Hi,
>
> Although I am not strictly against it, it seems the MinGW-w64 files tree has
> dramatically changed, invalidating any old links to files.
>
> I'd appreciate if something like this happens, the person making the change
> notifies this list. Unless I missed the me
On 7/20/2013 23:43, K. Frank wrote:
> Hello List!
>
> On 64-bit mingw-w64:
>
>g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)
>
> on 64-bit windows 7, I'm seeing that long doubles have a precision of about
> 18 decimal digits. I would guess that this is a legacy of the old 8087 80-b
On Sat, 20 Jul 2013 11:41:46 -0400
Earnie Boyd wrote:
> On Sat, Jul 20, 2013 at 10:15 AM, Ozkan Sezer wrote:
> > On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
> > wrote:
> >> Hi,
> >>
> >> Although I am not strictly against it, it seems the MinGW-w64 files tree
> >> has
> >> dramatically cha
Hello List!
On 64-bit mingw-w64:
g++ (rubenvb-4.8-stdthread) 4.8.1 20130324 (prerelease)
on 64-bit windows 7, I'm seeing that long doubles have a precision of about
18 decimal digits. I would guess that this is a legacy of the old 8087 80-bit
internal floating-point number.
>From a quick te
On Sat, Jul 20, 2013 at 10:15 AM, Ozkan Sezer wrote:
> On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
> wrote:
>> Hi,
>>
>> Although I am not strictly against it, it seems the MinGW-w64 files tree has
>> dramatically changed, invalidating any old links to files.
>>
>> I'd appreciate if something
Hi,
On Sat, Jul 20, 2013, Ruben Van Boxem wrote:
> Hi,
>
> Although I am not strictly against it, it seems the MinGW-w64 files tree
> has dramatically changed, invalidating any old links to files.
>
> I'd appreciate if something like this happens, the person making the change
> notifies this lis
On Sat, Jul 20, 2013 at 5:24 PM, Ruben Van Boxem
wrote:
> 2013/7/20 Ozkan Sezer
>>
>> On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
>> wrote:
>> > Hi,
>> >
>> > Although I am not strictly against it, it seems the MinGW-w64 files tree
>> > has
>> > dramatically changed, invalidating any old li
2013/7/20 Ozkan Sezer
> On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
> wrote:
> > Hi,
> >
> > Although I am not strictly against it, it seems the MinGW-w64 files tree
> has
> > dramatically changed, invalidating any old links to files.
> >
> > I'd appreciate if something like this happens, t
On Sat, Jul 20, 2013 at 4:58 PM, Ruben Van Boxem
wrote:
> Hi,
>
> Although I am not strictly against it, it seems the MinGW-w64 files tree has
> dramatically changed, invalidating any old links to files.
>
> I'd appreciate if something like this happens, the person making the change
> notifies thi
Hi,
Although I am not strictly against it, it seems the MinGW-w64 files tree
has dramatically changed, invalidating any old links to files.
I'd appreciate if something like this happens, the person making the change
notifies this list. Unless I missed the message (which is possible), this
did not
2013/7/20 dw
> So, Erik was kind enough to try re-running some of his builds with the
> latest patches to winbase.h. With a bit of tweaking to the patch, x86 now
> builds. While I haven't checked it in yet, these DLLIMPORT things are
> fixed.
>
> Unfortunately, x64 does not build correctly.
On 07/20/13 12:22, Erik van Pienbroek wrote:
> dw schreef op za 20-07-2013 om 02:07 [-0700]:
>
>> An argument could be made that we have broken backward compatibility
>> and it's our responsibility to fix it. On the other hand, one could
>> say they are using our library incorrectly (by not includ
On 07/18/13 23:43, dw wrote:
>
>> I can confirm that with GCC 4.9. In cause of our headers, it always
>> chooses inline version, which is good.
>
> That is the best possible outcome. For this particular situation. But
> it's possible that's not always the case.
>
> What with normal implementations
dw schreef op za 20-07-2013 om 02:07 [-0700]:
>
> An argument could be made that we have broken backward compatibility
> and it's our responsibility to fix it. On the other hand, one could
> say they are using our library incorrectly (by not including any of
> our headers), and the fact that it
So, Erik was kind enough to try re-running some of his builds with the
latest patches to winbase.h. With a bit of tweaking to the patch, x86
now builds. While I haven't checked it in yet, these DLLIMPORT things
are fixed.
Unfortunately, x64 does not build correctly. If you want to see the r
28 matches
Mail list logo
