While input parameters to asm blocks are expressions (not lvalues), they
cannot (safely) be modified within the asm code unless they are also
listed as outputs. While this may appear to work, code that comes
*after* the asm block may fail.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin-m
On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
> On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz wrote:
>> That is a known issue of ld for pe-coff. If at least one symbol is
>> exported by dllexport, only those symbols are. If there is none, then
>> all symbols getting exported.
>>
>
> Just f
Hi Ozkan!
Thank you for your explanation.
On Wed, Jul 3, 2013 at 2:26 PM, Ozkan Sezer <> wrote:
> On Wed, Jul 3, 2013 at 9:08 PM, K. Frank <> wrote:
>> Hello List!
>>
>> strftime does not seem to parse the "%T" format specifier.
>> ...
>> Thanks for any feedback.
>>
>> K. Frank
>
> strftime() is
On Wed, Jul 3, 2013 at 9:08 PM, K. Frank wrote:
> Hello List!
>
> strftime does not seem to parse the "%T" format specifier.
>
> First of all, I don't actually know what is supposed to happen. However,
> this reference:
>
>http://www.cplusplus.com/reference/ctime/strftime/
>
> states that "%T
Hello List!
strftime does not seem to parse the "%T" format specifier.
First of all, I don't actually know what is supposed to happen. However,
this reference:
http://www.cplusplus.com/reference/ctime/strftime/
states that "%T" is supposed to be a synonym for "%H:%M:%S":
%T ISO 8601 t
On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz wrote:
> That is a known issue of ld for pe-coff. If at least one symbol is
> exported by dllexport, only those symbols are. If there is none, then
> all symbols getting exported.
>
Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7
l2.c
> $ i686-w64-mingw32-objdump -s t-dll2.o | grep -A 5 "Contents of section"
> Contents of section .text:
> 5589e5b8 0100 5dc39090 U...]...
> Contents of section .rdata$zzz:
> 4743433a 2028474e 55292034 2e382e32 GCC: (GNU) 4.8.2
> 0010 20323031 3330373
On Wed, Jul 3, 2013 at 11:13 AM, LRN wrote:
> On 03.07.2013 19:10, NightStrike wrote:
>> On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer wrote:
>>> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
2013/7/3 LRN :
> On 03.07.2013 00:43, Christer Solskogen wrote:
>> On 01.07.2013 16:02, L
6-w64-mingw32-objdump -s t-dll2.o | grep -A 5 "Contents of section"
Contents of section .text:
5589e5b8 0100 5dc39090 U...]...
Contents of section .rdata$zzz:
4743433a 2028474e 55292034 2e382e32 GCC: (GNU) 4.8.2
0010 20323031 33303730 33202870 72657265 20130703 (prere
0020
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03.07.2013 19:10, NightStrike wrote:
> On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer wrote:
>> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
>>> 2013/7/3 LRN :
On 03.07.2013 00:43, Christer Solskogen wrote:
> On 01.07.2013 16:02, LRN wr
On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer wrote:
> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
>> 2013/7/3 LRN :
>>> On 03.07.2013 00:43, Christer Solskogen wrote:
On 01.07.2013 16:02, LRN wrote:
>
> mingw-w64 should supply GL headers from [1].
> Specifically - GL/glext.h
2013/7/3 Ozkan Sezer :
> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
>> 2013/7/3 LRN :
>>> On 03.07.2013 00:43, Christer Solskogen wrote:
On 01.07.2013 16:02, LRN wrote:
>
> mingw-w64 should supply GL headers from [1].
> Specifically - GL/glext.h
>
Pardon my fre
On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
> 2013/7/3 LRN :
>> On 03.07.2013 00:43, Christer Solskogen wrote:
>>> On 01.07.2013 16:02, LRN wrote:
mingw-w64 should supply GL headers from [1].
Specifically - GL/glext.h
>>>
>>> Pardon my french, but why should mingw-w64 supp
2013/7/3 LRN :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03.07.2013 00:43, Christer Solskogen wrote:
>> On 01.07.2013 16:02, LRN wrote:
>>>
>>> mingw-w64 should supply GL headers from [1].
>>> Specifically - GL/glext.h
>>>
>>
>> Pardon my french, but why should mingw-w64 supply them?
Please do as much as you can to aid the debugging process.
Can you provide these traces?
Also, can you try to bisect down to the first GCC that breaks this for
you? There have been a lot of GCCs between 4.7.1 and 4.8.0 (can you
try with 4.8.1 now?)
I'm very sorry, I'd be glad to help, but unfo
Please do as much as you can to aid the debugging process.
Can you provide these traces?
Also, can you try to bisect down to the first GCC that breaks this for you?
There have been a lot of GCCs between 4.7.1 and 4.8.0 (can you try with
4.8.1 now?)
On Wed, Jul 3, 2013 at 1:33 PM, Haroogan wro
> This is known problem. See
> https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but
> for Qt4 is the same. You can't now use -O3 with mingw toolchains based
> on gcc-4.7.3+.
I think you got me wrong there.
I have no problems building the whole Qt (including QtCore) with -O3 flag.
It
On 07/03/13 12:22, Kai Tietz wrote:
> 2013/7/3 Jacek Caban :
>
>> Looks good to me.
>>
>> Thanks,
>> Jacek
> Yes, patch is ok. Jacek feel free to commit.
Committed as r5924.
Thanks,
Jacek
--
This SF.net email is sponsor
2013/7/3 Jacek Caban :
> On 07/03/13 02:29, dw wrote:
>> Thanks to both Kai and Jacek whose suggestions made this patch much
>> better.
>>
>> This patch includes two parts. The first (and more important) deals
>> with how MSVC's intrinsics are used in mingw-w64:
>>
>> winnt.h:
>>
>> - In all cases
On 07/03/13 02:29, dw wrote:
> Thanks to both Kai and Jacek whose suggestions made this patch much
> better.
>
> This patch includes two parts. The first (and more important) deals
> with how MSVC's intrinsics are used in mingw-w64:
>
> winnt.h:
>
> - In all cases (x86, x64, cygwin, not cygwin), r
2013/7/3 Alexpux:
> Yes. I try it today.
Thanks, Alexey!
> I finish my Ada toolchains with dirty hack. Need to create bug report.
Great!
--
Regards,
niXman
___
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.n
03.07.2013, в 12:23, niXman написал(а):
> 2013/7/3 Ruben Van Boxem:
>> The bug report clearly shows it is not ld.exe that is running out of memory,
>> but cc1plus.exe:
>>
>> cc1plus.exe: out of memory allocating 279536 bytes
>
> Yes, you right.
>
>> So linking the GCC compiler executables wit
2013/7/3 Ruben Van Boxem:
> The bug report clearly shows it is not ld.exe that is running out of memory,
> but cc1plus.exe:
>
> cc1plus.exe: out of memory allocating 279536 bytes
Yes, you right.
> So linking the GCC compiler executables with that flag might give it enough
> address space.
Alexey
2013/7/3 niXman
> 2013/7/3 niXman:
> > 2013/7/3 Alexey Pavlov:
> > > Mingw-builds binutils already built with this flags.
> > I know.
> > I wanted to make sure that Ruben confused nothing.
>
> Can anybody say with certainty whether this flag is needed to build GCC?
>
It is not "needed" per se, b
2013/7/3 niXman
> 2013/7/3 Alexey Pavlov:
> > Mingw-builds binutils already built with this flags.
> I know.
> I wanted to make sure that Ruben confused nothing.
>
The bug report clearly shows it is not ld.exe that is running out of
memory, but cc1plus.exe:
cc1plus.exe: out of memory allocating
2013/7/3 niXman:
> 2013/7/3 Alexey Pavlov:
> > Mingw-builds binutils already built with this flags.
> I know.
> I wanted to make sure that Ruben confused nothing.
Can anybody say with certainty whether this flag is needed to build GCC?
--
Regards,
niXman
_
2013/7/3 Alexey Pavlov:
> Mingw-builds binutils already built with this flags.
I know.
I wanted to make sure that Ruben confused nothing.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf
2013/7/3 niXman :
> 2013/7/3 Ruben Van Boxem:
>> That issue seems unrelated. And it might be fixable by linking the 32-bit
>> GCC compiler executables with -Wl,--enable-large-address-aware.
> or binutils executables?
>
Mingw-builds binutils already built with this flags.
>
2013/7/3 Ruben Van Boxem:
> That issue seems unrelated. And it might be fixable by linking the 32-bit
> GCC compiler executables with -Wl,--enable-large-address-aware.
or binutils executables?
--
This SF.net email is spons
2013/7/3 Alexey Pavlov
> This is known problem. See
> https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but
> for Qt4 is the same. You can't now use -O3 with mingw toolchains based
> on gcc-4.7.3+.
>
That issue seems unrelated. And it might be fixable by linking the 32-bit
GCC com
30 matches
Mail list logo
