[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify digest, Vol 1 #880 - 3 msgs
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2004-08-19 3:05:22
Message-ID: E1BxdPi-0001ce-9L () 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-1011360 ] Problem in msys.bat under Windows 98 SE \
(SourceForge.net) 2. [ mingw-Bugs-1001932 ] gcc 3.3 - 3.4 SSE V4sf misalignement \
(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: Wed, 18 Aug 2004 04:27:56 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1011360 ] Problem in msys.bat under Windows 98 \
SE
Bugs item #1011360, was opened at 2004-08-18 13:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1011360&group_id=2435
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel (dbjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in msys.bat under Windows 98 SE
Initial Comment:
I noticed a problem when trying to run MSYS under
Windows 98 SE. It's probably more correct to say
"under command.com", but I haven't tested it under
Windows XP. The second line after the label _Resume
reads:
set WD=.\bin\
However, for Windows 98 SE (command.com) it should
read:
set WD=.\
I used MinGW-3.1.0-1.exe and
MSYS-1.0.11-2004.04.30-1.exe. After the change MSYS
runs fine.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1011360&group_id=2435
--__--__--
Message: 2
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Wed, 18 Aug 2004 14:37:04 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1001932 ] gcc 3.3 - 3.4 SSE V4sf misalignement
Bugs item #1001932, was opened at 2004-08-02 23:04
Message generated for change (Comment added) made by dannysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1001932&group_id=2435
Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Italianate (lorenzoseno)
Assigned to: Danny Smith (dannysmith)
Summary: gcc 3.3 - 3.4 SSE V4sf misalignement
Initial Comment:
gcc version: both core 3.3.1 and 3.4.0
MinGW version: 3.1.0
mingw-runtime: 3.3
w32api 2.5
ld version 2.13.90
OS: W2k sp4
When using SSE extension, if you declare any v4sf
vector __attribute__ ((aligned (16))) amid globals,
each one is allocated to the (shared) address 0x0,
which is a 16 byte-aligned location so that subsequent
movaps doesn't crash the run (but the code doesn't
work at all, of course).
If you declare the previous v4sfs amid the main
variables, the generated addresses are different, but not
16 bytes aligned (they end with an 0x8, in my run).
Subsequent movaps (automatically generated by gcc or
manually coded) will crash the run.
The code can be made working, but only manually
coding movups instead of movaps (in asm()).
The same things happen if you suppress the attribute -
aligned declaration.
The gcc 3.3 linux version works instead fine, it
automatically generates 16 byte-boundary-aligned v4sf
locations, w/o the need of declaring alignement
attributes.
----------------------------------------------------------------------
> Comment By: Danny Smith (dannysmith)
Date: 2004-08-19 09:37
Message:
Logged In: YES
user_id=11494
Hi,
I've attached a rebuilt crt2.o that fixes the testcase for me.
Could you install into your_mingw_root/lib directory and
confirm that it also fixes in your test harnesses?
Danny
----------------------------------------------------------------------
Comment By: Italianate (lorenzoseno)
Date: 2004-08-09 00:00
Message:
Logged In: YES
user_id=1095855
To document the misalignement diagnosis:
This one:
typedef int v4sf __attribute__ ((mode(V4SF))) __attribute__
((aligned (16)));
union f4vector
{
v4sf v;
float f[4];
} __attribute__ ((aligned (16)));
int main(int argc, char *argv[])
{
volatile union f4vector a __attribute__ ((aligned (16))), b
__attribute__ ((aligned (16)));
volatile union f4vector c __attribute__ ((aligned (16))), d
__attribute__ ((aligned (16)));
a.f[0] = 1; a.f[1] = 2; a.f[2] = 3; a.f[3] = 4;
b.f[0] = 5; b.f[1] = 6; b.f[2] = 7; b.f[3] = 8;
asm volatile ("movaps %1, %%xmm0\n\t"
"movaps %2, %%xmm1\n\t"
"mulps %%xmm0, %%xmm1\n\t"
"movaps %%xmm1, %0\n\t" : "=m" (c.v) : "m"
(a.v) , "m" (b.v));
// c.v = a.v * b.v;
printf("%f %f %f %f\n", c.f[0], c.f[1], c.f[2], c.f[3]);
return(0);
}
Compile in this way:
gcc -ggdb -o bug_asm.exe bug_asm.c
It will crash.
Now replace "movups" instead to "movaps".
Recompile.
It gives the correct result:
5.000000 12.000000 21.000000 32.000000
Regards.
----------------------------------------------------------------------
Comment By: Italianate (lorenzoseno)
Date: 2004-08-08 23:44
Message:
Logged In: YES
user_id=1095855
Tanks Danny and sorry for the delay. I was out.
About you question: I compiled this one:
typedef int v4sf __attribute__ ((mode(V4SF))) __attribute__
((aligned (16)));
union f4vector
{
v4sf v;
float f[4];
} __attribute__ ((aligned (16)));
int main(int argc, char *argv[])
{
volatile union f4vector a __attribute__ ((aligned (16))), b
__attribute__ ((aligned (16)));
volatile union f4vector c __attribute__ ((aligned (16))), d
__attribute__ ((aligned (16)));
a.f[0] = 1; a.f[1] = 2; a.f[2] = 3; a.f[3] = 4;
b.f[0] = 5; b.f[1] = 6; b.f[2] = 7; b.f[3] = 8;
c.v = a.v * b.v;
printf("%f %f %f %f\n", c.f[0], c.f[1], c.f[2], c.f[3]);
return(0);
}
both under Mingw and under Linux.
The linux code runs fine, where the windows crashes instead.
Disassemble of main under gdb are neverthless perfectly
identical.
I'm sorry, I'm not so aquainted about how physical memory
assignment is made in the gnu compile-linking-loading 386
process, so I can't give any useful suggestion on where the
misalignment can happen.
As this bug is quite important (the actual situation is such
that there is no way to use SSE code under Windows using
open-source compilers) can you submit the problem to the
guys in charge of assembler and linker?
Regards and thank you.
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-05 09:24
Message:
Logged In: YES
user_id=11494
Well my patch didn't do anything to your bug, but it fixed a
different one. Sigh. The output of objdump on your two tests
is really strange, with code in .rdata. When I look at the
assembly output by gcc -S I can't see any problems, so I
suspect this an assembler bug, probably in libbfd.
Could you have a look at the GCC -S output and see if you
can spot anything wrong.
Danny
Danny
----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith)
Date: 2004-08-04 23:44
Message:
Logged In: YES
user_id=11494
Thanks for the testcase. I'm testing patches against gcc-
3.5 and 3.4.1 now.
Danny
----------------------------------------------------------------------
Comment By: Italianate (lorenzoseno)
Date: 2004-08-04 21:36
Message:
Logged In: YES
user_id=1095855
Here an example (ld 2.15.90):
typedef int v4sf __attribute__ ((mode(V4SF))) __attribute__
((aligned (16)));
union f4vector
{
v4sf v;
float f[4];
} __attribute__ ((aligned (16)));
int main(int argc, char *argv[])
{
volatile union f4vector a __attribute__ ((aligned (16))), b
__attribute__ ((aligned (16)));
volatile union f4vector c __attribute__ ((aligned (16))), d
__attribute__ ((aligned (16)));
a.f[0] = 1; a.f[1] = 2; a.f[2] = 3; a.f[3] = 4;
b.f[0] = 5; b.f[1] = 6; b.f[2] = 7; b.f[3] = 8;
c.v = a.v * b.v;
return(0);
}
objdump:
55: 89 45 e4 mov %eax,0xffffffe4(%ebp)
c.v = a.v * b.v;
return(0);
}
58: 31 c0 xor %eax,%eax
5a: 0f 28 45 e8 movaps 0xffffffe8(%ebp),%xmm0
5e: 0f 28 4d d8 movaps 0xffffffd8(%ebp),%xmm1
62: 0f 59 c1 mulps %xmm1,%xmm0
65: 0f 29 45 c8 movaps %xmm0,0xffffffc8(%ebp)
69: c9 leave
6a: c3 ret
6b: 90 nop
Please note movaps 0xffffffe8 <-
Now note:
typedef int v4sf __attribute__ ((mode(V4SF))) __attribute__
((aligned (16)));
union f4vector
{
v4sf v;
float f[4];
} __attribute__ ((aligned (16)));
volatile union f4vector a __attribute__ ((aligned (16))), b
__attribute__ ((aligned (16)));
volatile union f4vector c __attribute__ ((aligned (16))), d
__attribute__ ((aligned (16)));
int main(int argc, char *argv[])
objdump:
68: a3 0c 00 00 00 mov %eax,0xc
c.v = a.v * b.v;
return(0);
}
6d: 31 c0 xor %eax,%eax
6f: 0f 28 05 00 00 00 00 movaps 0x0,%xmm0
76: 0f 28 0d 00 00 00 00 movaps 0x0,%xmm1
7d: 0f 59 c1 mulps %xmm1,%xmm0
80: 0f 29 05 00 00 00 00 movaps %xmm0,0x0
87: c9 leave
88: c3 ret
89: 90 nop
note multiple movaps 0x0.
Regards.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1001932&group_id=2435
--__--__--
Message: 3
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Wed, 18 Aug 2004 14:52:25 -0700
Subject: [Mingw-notify] [ mingw-Bugs-1008330 ] movaps problem with mingw
Bugs item #1008330, was opened at 2004-08-13 10:43
Message generated for change (Comment added) made by dannysmith
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: Danny Smith (dannysmith)
Date: 2004-08-19 09: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-14 05: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 23: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 13: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