[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify digest, Vol 1 #882 - 3 msgs
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2004-08-19 12:29:01
Message-ID: E1Bxm8T-0008Uq-ED () sc8-sf-list1 ! sourceforge ! net
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-admin@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Bugs-1008330 ] movaps problem with mingw (SourceForge.net)
2. [ mingw-Bugs-1008330 ] movaps problem with mingw (SourceForge.net)
3. [ mingw-Bugs-1008330 ] movaps problem with mingw (SourceForge.net)
--__--__--
Message: 1
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Thu, 19 Aug 2004 04:42:26 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1008330 ] movaps problem with mingw
Bugs item #1008330, was opened at 2004-08-12 18:43
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Daws (mattdaws)
Assigned to: Danny Smith (dannysmith)
Summary: movaps problem with mingw
Initial Comment:
I have a slightly complicated program which is crashing
when I compile with certain options. I have narrowed
the problem down to the fact that MinGW is generating
MOVAPS instructions which are trying to access memory
at an unaligned point. If I edit the assembler file
and replace these with MOVUPS instructions and then
assemble and link, my program works fine.
I thought this was linked to my use of threads and/or
the printf instruction. However, I've removed the
printf's and still get the problem. I am now
suspecting my use of threads. I tried changing from
using CreateThread to using _beginthreadex, but this
didn't help.
A Google search reveals that other people have been
having a general problem with GCC, MOVAPS and threads.
Thus this *might* be a problem with GCC. However,
people in the know are blaming the problem on system
calls which are not setting up the stack in an aligned
manner when starting a thread. Hence my hope that
_beginthreadex would help.
The problem does not occur with Mingw 3.3.3, but this
seems to be down to the fact that the compiler no
longer produces MOVAPS instructions.
I am using Mingw 3.4.1, Windows XP SP1. The compiler
flags I use are:
-Wall -ffast-math -O3 -march=pentium4 -mthreads
But anything enabling SSE seems to give problems.
I could send the code, but it is rather long. I could
also try to generate a smaller example which does the
same thing, but perhaps the bug will not occur.
Here is a snippit of the offending assembly (produced
with the -S flag in g++):
__ZN9Landscape4DrawEv:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl $236, %esp
movl 8(%ebp), %edi
flds 8(%edi)
flds 40(%edi)
.....
movaps %xmm4, -104(%ebp)
.....
movaps %xmm0, -136(%ebp)
Many thanks in advance for any hints! --Matt Daws
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 07:42
Message:
Logged In: YES
user_id=15438
What about adding:
-mpreferred-stack-boundary= Attempt to keep stack aligned
to this power of 2
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 07:12
Message:
Logged In: YES
user_id=1103054
Hmm, I've been playing with swapping _beginthreadex for
CreateThread (which shouldn't be used, I think, as I'm using
the CRT). The result is a change of alignment on the stack,
but it still isn't aligned on a 16-byte boundary.
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 07:01
Message:
Logged In: YES
user_id=1103054
Earnie: Nope, doesn't do a thing. Sorry!
I really do think this is a stack alignment issue, which now
seems solved for main(), but not for new threads.
--Matt
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 06:47
Message:
Logged In: YES
user_id=15438
Currious: Does -mms-bitfields help?
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 06:08
Message:
Logged In: YES
user_id=1103054
Danny,
Thanks for all your work! I've looked at 1001932 and tried
the new crt2.o This seems to fix problems in the main
thread of my program, but I am still having issues in the
second thread which I start up. In particular, it's the
same stack alignment issue: it seems that GCC assumes that
every function should be called with the stack aligned, so
that then the calling address is saved, meaning that the
function starts with esp+4 aligned, not esp.
This isn't true if I use _beginthreadex to start a new
thread. Is this correct, or should I be using some other
function to start a new thread? I cannot quite see what
alignment _beginthreadex is making: I am tempted to
conjecture it makes no alignment beyond to a 4-byte boundary.
Thanks, --Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-18 17:52
Message:
Logged In: YES
user_id=11494
Your right, it is a diferent bug -- at least the simple fix that
worked for 1001932 doesn't work for this. Thanks for your
analysis on the GCC bugzilla report.
Danny
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 13:32
Message:
Logged In: YES
user_id=1103054
Hmm, okay, I've now made a small(ish) example program. The
key points seem to be:
i) -finline-functions is needed to create the movaps
instruction.
ii) Threads *are* important. If the example is run as a
single-thread, all is okay. If I start a new thread to run
the offending code in, it crashes.
I guess this IS an alignment issue, so I'll leave the bug as
closed and see if 1001932 goes anywhere...
See attached C++ file. Compile it as, for example, g++
-Wall -ffast-math -O2 -march=pentium4 -finline-functions
main.cpp -o test.exe
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 07:06
Message:
Logged In: YES
user_id=1103054
Not sure what the protocol here is: I'm not going to re-open
the bug for now.
However, I've been doing some more playing, and have found
that the optimisation -finline-functions is responsible:
without this, a small function of mine is called, and my
code works. With it, the function is not called, but is
inlined (as expected). However, the curious movaps
instruction is now generated.
I'm not sure this is a duplicate bug, as I'm not trying to
use SSE data types: the instruction is just being generated
automatically by GCC, whereas the 1001932 bug relates to the
explicit use of SSE data types. Furthermore, I'm not
explicitly telling the compiler to use SSE to do maths, only
that it is running on a P4, and so is free to use SSE if it
so wishes.
As the problem only occurs when inlining, I wonder if this
is a code generation bug? Furthermore, my trick of
replacing the movaps by movups seems to also work if I
simply remove the movaps instructions completely, which is a
little odd.
The same is true if I use -mfpmath=sse, i.e. the inlining
causes the error. Furthermore, in this case, if I change
movaps to movups, the problem still occurs (but with an
Access Violation as the program tries to read from address
-1). The same occurs if I remove the movaps instructions
which reference memory.
I will try and make a simple program which duplicates these
problems.
--Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-12 21:31
Message:
Logged In: YES
user_id=11494
Duplicate of 1001932, which has a self-contained testcase.
The bug has also been reported to GCC's bugzilla,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16890
but no response yet.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
--__--__--
Message: 2
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Thu, 19 Aug 2004 05:16:38 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1008330 ] movaps problem with mingw
Bugs item #1008330, was opened at 2004-08-12 22:43
Message generated for change (Comment added) made by mattdaws
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Daws (mattdaws)
Assigned to: Danny Smith (dannysmith)
Summary: movaps problem with mingw
Initial Comment:
I have a slightly complicated program which is crashing
when I compile with certain options. I have narrowed
the problem down to the fact that MinGW is generating
MOVAPS instructions which are trying to access memory
at an unaligned point. If I edit the assembler file
and replace these with MOVUPS instructions and then
assemble and link, my program works fine.
I thought this was linked to my use of threads and/or
the printf instruction. However, I've removed the
printf's and still get the problem. I am now
suspecting my use of threads. I tried changing from
using CreateThread to using _beginthreadex, but this
didn't help.
A Google search reveals that other people have been
having a general problem with GCC, MOVAPS and threads.
Thus this *might* be a problem with GCC. However,
people in the know are blaming the problem on system
calls which are not setting up the stack in an aligned
manner when starting a thread. Hence my hope that
_beginthreadex would help.
The problem does not occur with Mingw 3.3.3, but this
seems to be down to the fact that the compiler no
longer produces MOVAPS instructions.
I am using Mingw 3.4.1, Windows XP SP1. The compiler
flags I use are:
-Wall -ffast-math -O3 -march=pentium4 -mthreads
But anything enabling SSE seems to give problems.
I could send the code, but it is rather long. I could
also try to generate a smaller example which does the
same thing, but perhaps the bug will not occur.
Here is a snippit of the offending assembly (produced
with the -S flag in g++):
__ZN9Landscape4DrawEv:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl $236, %esp
movl 8(%ebp), %edi
flds 8(%edi)
flds 40(%edi)
.....
movaps %xmm4, -104(%ebp)
.....
movaps %xmm0, -136(%ebp)
Many thanks in advance for any hints! --Matt Daws
----------------------------------------------------------------------
> Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 12:16
Message:
Logged In: YES
user_id=1103054
Okay, I've tried -mpreferred-stack-boundary= It doesn't stop
the crash.
Looking at the assmebly output, the following happens:
i) In _main, we always have something like:
pushl %ebp // Setup stack frame
movl %esp, %ebp
pushl %ebx // Save ebx, doesn't always occur
subl $148, %esp // Allocate local storage
andl $-32, %esp // ALIGN STACK
call __alloca // Call some helper functions:
call ___main // I don't know what these do.
The value used in "andl $-32, %esp" changes with
preferred-stack-boundary, as expected. Notice, however,
that this occurs AFTER the stack-frame is setup, so that
%ebp can still be unaligned. However, any function called
from _main will be fine, as ESP is aligned. This is what
was causing the problem in BUG 1001932 I believe, and I
guess Danny changed some code in crt2.o to mean that %esp is
aligned at the start, and so %ebp becomes aligned from the
start as well. Of course, preferred-stack-boundary doesn't
change this!
ii) GCC keeps the stack aligned to the requested boundary,
so that each function contains a "subl $val, %esp" and $val
is changed with preferred-stack-boundary. This works fine,
but it assumes that the stack starts out aligned correctly.
I guess this is why the code in _main changes, but it seems
odd that it does it too late. Furthermore, it means that
there is no mechanism for dealing with threads, as then
_main never gets called to align the stack.
I am currently playing about with assembler to try to write
my own thread-launching code to align the stack. I'll let
you know if I get it to work (sadly GCC doesn't allow inline
asm to alter %esp, which I guess is not too surprising, but
a bit annoying).
--Matt
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 11:42
Message:
Logged In: YES
user_id=15438
What about adding:
-mpreferred-stack-boundary= Attempt to keep stack aligned
to this power of 2
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 11:12
Message:
Logged In: YES
user_id=1103054
Hmm, I've been playing with swapping _beginthreadex for
CreateThread (which shouldn't be used, I think, as I'm using
the CRT). The result is a change of alignment on the stack,
but it still isn't aligned on a 16-byte boundary.
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 11:01
Message:
Logged In: YES
user_id=1103054
Earnie: Nope, doesn't do a thing. Sorry!
I really do think this is a stack alignment issue, which now
seems solved for main(), but not for new threads.
--Matt
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 10:47
Message:
Logged In: YES
user_id=15438
Currious: Does -mms-bitfields help?
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 10:08
Message:
Logged In: YES
user_id=1103054
Danny,
Thanks for all your work! I've looked at 1001932 and tried
the new crt2.o This seems to fix problems in the main
thread of my program, but I am still having issues in the
second thread which I start up. In particular, it's the
same stack alignment issue: it seems that GCC assumes that
every function should be called with the stack aligned, so
that then the calling address is saved, meaning that the
function starts with esp+4 aligned, not esp.
This isn't true if I use _beginthreadex to start a new
thread. Is this correct, or should I be using some other
function to start a new thread? I cannot quite see what
alignment _beginthreadex is making: I am tempted to
conjecture it makes no alignment beyond to a 4-byte boundary.
Thanks, --Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-18 21:52
Message:
Logged In: YES
user_id=11494
Your right, it is a diferent bug -- at least the simple fix that
worked for 1001932 doesn't work for this. Thanks for your
analysis on the GCC bugzilla report.
Danny
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 17:32
Message:
Logged In: YES
user_id=1103054
Hmm, okay, I've now made a small(ish) example program. The
key points seem to be:
i) -finline-functions is needed to create the movaps
instruction.
ii) Threads *are* important. If the example is run as a
single-thread, all is okay. If I start a new thread to run
the offending code in, it crashes.
I guess this IS an alignment issue, so I'll leave the bug as
closed and see if 1001932 goes anywhere...
See attached C++ file. Compile it as, for example, g++
-Wall -ffast-math -O2 -march=pentium4 -finline-functions
main.cpp -o test.exe
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 11:06
Message:
Logged In: YES
user_id=1103054
Not sure what the protocol here is: I'm not going to re-open
the bug for now.
However, I've been doing some more playing, and have found
that the optimisation -finline-functions is responsible:
without this, a small function of mine is called, and my
code works. With it, the function is not called, but is
inlined (as expected). However, the curious movaps
instruction is now generated.
I'm not sure this is a duplicate bug, as I'm not trying to
use SSE data types: the instruction is just being generated
automatically by GCC, whereas the 1001932 bug relates to the
explicit use of SSE data types. Furthermore, I'm not
explicitly telling the compiler to use SSE to do maths, only
that it is running on a P4, and so is free to use SSE if it
so wishes.
As the problem only occurs when inlining, I wonder if this
is a code generation bug? Furthermore, my trick of
replacing the movaps by movups seems to also work if I
simply remove the movaps instructions completely, which is a
little odd.
The same is true if I use -mfpmath=sse, i.e. the inlining
causes the error. Furthermore, in this case, if I change
movaps to movups, the problem still occurs (but with an
Access Violation as the program tries to read from address
-1). The same occurs if I remove the movaps instructions
which reference memory.
I will try and make a simple program which duplicates these
problems.
--Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-13 01:31
Message:
Logged In: YES
user_id=11494
Duplicate of 1001932, which has a self-contained testcase.
The bug has also been reported to GCC's bugzilla,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16890
but no response yet.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
--__--__--
Message: 3
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Thu, 19 Aug 2004 05:25:41 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1008330 ] movaps problem with mingw
Bugs item #1008330, was opened at 2004-08-12 22:43
Message generated for change (Comment added) made by mattdaws
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Daws (mattdaws)
Assigned to: Danny Smith (dannysmith)
Summary: movaps problem with mingw
Initial Comment:
I have a slightly complicated program which is crashing
when I compile with certain options. I have narrowed
the problem down to the fact that MinGW is generating
MOVAPS instructions which are trying to access memory
at an unaligned point. If I edit the assembler file
and replace these with MOVUPS instructions and then
assemble and link, my program works fine.
I thought this was linked to my use of threads and/or
the printf instruction. However, I've removed the
printf's and still get the problem. I am now
suspecting my use of threads. I tried changing from
using CreateThread to using _beginthreadex, but this
didn't help.
A Google search reveals that other people have been
having a general problem with GCC, MOVAPS and threads.
Thus this *might* be a problem with GCC. However,
people in the know are blaming the problem on system
calls which are not setting up the stack in an aligned
manner when starting a thread. Hence my hope that
_beginthreadex would help.
The problem does not occur with Mingw 3.3.3, but this
seems to be down to the fact that the compiler no
longer produces MOVAPS instructions.
I am using Mingw 3.4.1, Windows XP SP1. The compiler
flags I use are:
-Wall -ffast-math -O3 -march=pentium4 -mthreads
But anything enabling SSE seems to give problems.
I could send the code, but it is rather long. I could
also try to generate a smaller example which does the
same thing, but perhaps the bug will not occur.
Here is a snippit of the offending assembly (produced
with the -S flag in g++):
__ZN9Landscape4DrawEv:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl $236, %esp
movl 8(%ebp), %edi
flds 8(%edi)
flds 40(%edi)
.....
movaps %xmm4, -104(%ebp)
.....
movaps %xmm0, -136(%ebp)
Many thanks in advance for any hints! --Matt Daws
----------------------------------------------------------------------
> Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 12:25
Message:
Logged In: YES
user_id=1103054
Okay, my hack seems to work. But it's a hack: it needs some
syncronistation code added to make it remotely thread-safe...
The code always starts a new thread by running a small
function which aligns ESP and then calls the real function
which we want. We have to jump through some hoops to get
GCC to issue the correct assembly output, so a more elegant
way would be to write the helper-function in assembly to
start with. I'm a bit rusty with asm though.
unsigned (__stdcall *func_address) (void *);
unsigned int __stdcall hack_stack(void *param)
{
// Align stack: GCC stack frame means that we can change
// ESP here and it'll be reset later.
unsigned tmp;
asm volatile ( "movl %%esp,%%eax; subl $15, %%eax; andl
$-16, %%eax; mov %%eax,%%esp;" : "=a"(tmp) );
// Some random code to ensure GCC issues a CALL to
// func_address, and not just a long jump
int temp,i;
for (i=0; i<1000; i++) temp+=i;
func_address(param);
// Some more random code.
int j;
for (j=0; j<1000; j++) temp+=j;
}
unsigned long my_start_thread(unsigned (__stdcall *addr)
(void *), unsigned *ret)
{
// Should sync here
func_address=addr;
return _beginthreadex(NULL,0,hack_stack,NULL,0,ret);
}
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 12:16
Message:
Logged In: YES
user_id=1103054
Okay, I've tried -mpreferred-stack-boundary= It doesn't stop
the crash.
Looking at the assmebly output, the following happens:
i) In _main, we always have something like:
pushl %ebp // Setup stack frame
movl %esp, %ebp
pushl %ebx // Save ebx, doesn't always occur
subl $148, %esp // Allocate local storage
andl $-32, %esp // ALIGN STACK
call __alloca // Call some helper functions:
call ___main // I don't know what these do.
The value used in "andl $-32, %esp" changes with
preferred-stack-boundary, as expected. Notice, however,
that this occurs AFTER the stack-frame is setup, so that
%ebp can still be unaligned. However, any function called
from _main will be fine, as ESP is aligned. This is what
was causing the problem in BUG 1001932 I believe, and I
guess Danny changed some code in crt2.o to mean that %esp is
aligned at the start, and so %ebp becomes aligned from the
start as well. Of course, preferred-stack-boundary doesn't
change this!
ii) GCC keeps the stack aligned to the requested boundary,
so that each function contains a "subl $val, %esp" and $val
is changed with preferred-stack-boundary. This works fine,
but it assumes that the stack starts out aligned correctly.
I guess this is why the code in _main changes, but it seems
odd that it does it too late. Furthermore, it means that
there is no mechanism for dealing with threads, as then
_main never gets called to align the stack.
I am currently playing about with assembler to try to write
my own thread-launching code to align the stack. I'll let
you know if I get it to work (sadly GCC doesn't allow inline
asm to alter %esp, which I guess is not too surprising, but
a bit annoying).
--Matt
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 11:42
Message:
Logged In: YES
user_id=15438
What about adding:
-mpreferred-stack-boundary= Attempt to keep stack aligned
to this power of 2
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 11:12
Message:
Logged In: YES
user_id=1103054
Hmm, I've been playing with swapping _beginthreadex for
CreateThread (which shouldn't be used, I think, as I'm using
the CRT). The result is a change of alignment on the stack,
but it still isn't aligned on a 16-byte boundary.
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 11:01
Message:
Logged In: YES
user_id=1103054
Earnie: Nope, doesn't do a thing. Sorry!
I really do think this is a stack alignment issue, which now
seems solved for main(), but not for new threads.
--Matt
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2004-08-19 10:47
Message:
Logged In: YES
user_id=15438
Currious: Does -mms-bitfields help?
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-19 10:08
Message:
Logged In: YES
user_id=1103054
Danny,
Thanks for all your work! I've looked at 1001932 and tried
the new crt2.o This seems to fix problems in the main
thread of my program, but I am still having issues in the
second thread which I start up. In particular, it's the
same stack alignment issue: it seems that GCC assumes that
every function should be called with the stack aligned, so
that then the calling address is saved, meaning that the
function starts with esp+4 aligned, not esp.
This isn't true if I use _beginthreadex to start a new
thread. Is this correct, or should I be using some other
function to start a new thread? I cannot quite see what
alignment _beginthreadex is making: I am tempted to
conjecture it makes no alignment beyond to a 4-byte boundary.
Thanks, --Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-18 21:52
Message:
Logged In: YES
user_id=11494
Your right, it is a diferent bug -- at least the simple fix that
worked for 1001932 doesn't work for this. Thanks for your
analysis on the GCC bugzilla report.
Danny
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 17:32
Message:
Logged In: YES
user_id=1103054
Hmm, okay, I've now made a small(ish) example program. The
key points seem to be:
i) -finline-functions is needed to create the movaps
instruction.
ii) Threads *are* important. If the example is run as a
single-thread, all is okay. If I start a new thread to run
the offending code in, it crashes.
I guess this IS an alignment issue, so I'll leave the bug as
closed and see if 1001932 goes anywhere...
See attached C++ file. Compile it as, for example, g++
-Wall -ffast-math -O2 -march=pentium4 -finline-functions
main.cpp -o test.exe
--Matt
----------------------------------------------------------------------
Comment By: Matt Daws (mattdaws)
Date: 2004-08-13 11:06
Message:
Logged In: YES
user_id=1103054
Not sure what the protocol here is: I'm not going to re-open
the bug for now.
However, I've been doing some more playing, and have found
that the optimisation -finline-functions is responsible:
without this, a small function of mine is called, and my
code works. With it, the function is not called, but is
inlined (as expected). However, the curious movaps
instruction is now generated.
I'm not sure this is a duplicate bug, as I'm not trying to
use SSE data types: the instruction is just being generated
automatically by GCC, whereas the 1001932 bug relates to the
explicit use of SSE data types. Furthermore, I'm not
explicitly telling the compiler to use SSE to do maths, only
that it is running on a P4, and so is free to use SSE if it
so wishes.
As the problem only occurs when inlining, I wonder if this
is a code generation bug? Furthermore, my trick of
replacing the movaps by movups seems to also work if I
simply remove the movaps instructions completely, which is a
little odd.
The same is true if I use -mfpmath=sse, i.e. the inlining
causes the error. Furthermore, in this case, if I change
movaps to movups, the problem still occurs (but with an
Access Violation as the program tries to read from address
-1). The same occurs if I remove the movaps instructions
which reference memory.
I will try and make a simple program which duplicates these
problems.
--Matt
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-13 01:31
Message:
Logged In: YES
user_id=11494
Duplicate of 1001932, which has a self-contained testcase.
The bug has also been reported to GCC's bugzilla,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16890
but no response yet.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1008330&group_id=2435
--__--__--
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic