--- Additional Comments From guardia at sympatico dot ca 2005-06-09 20:44
---
So where exactly should we specify such a directory? I was not able to find any
other configuration variables that we can change and that would do the job...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From guardia at sympatico dot ca 2005-06-10 03:15
---
Through fstab, yes, but the problem is it only works with specially compiled
binaries. Right off the tar ball, gcc compiles to a native win32 program and
does not honor MSYS's fstab... so no, for a
--- Additional Comments From guardia at sympatico dot ca 2005-06-21 13:26
---
Hum, it will be interesting to test this (it will have to wait a couple of
weeks), but the problem with this here is that there is no "mov" instructions
that can move stuff between MMX registe
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 21:59
---
Yup, excited, today, I just compiled the mainbranch to check this out
(gcc-4.1-20050618) and it seems to be fixed! I don't see any strange movlps in
any of the code I tried to compile with it. Can be mov
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 22:59
---
Thanks to Uros and everybody!
--
What|Removed |Added
Status|RESOLVED
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guardia at sympatico dot ca
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
--- Additional Comments From guardia at sympatico dot ca 2005-01-19 14:59
---
Created an attachment (id=7991)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7991&action=view)
gcc -O3 -S -msse moo.c --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 17:20
---
I think the "relative path" issue with MSYS and MinGW should be added for
example in the notes at:
http://gcc.gnu.org/install/specific.html
It would save a lot of grief from people trying to build
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guardia at sympatico dot ca
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-min
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 17:31
---
Created an attachment (id=8054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8054&action=view)
new t-mingw32
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 18:09
---
MMX intrinsics don't seem to be a standard (?), but I'm under the impression
that _mm_cvtsi32_si64 is supposed to generate MMX code. I just tested With (GCC)
4.0.0 20050123, and with -mmmx flag, the
--- Additional Comments From guardia at sympatico dot ca 2005-01-26 23:51
---
I'm wondering, would there be a #pragma directive that would we could use to
surround the MMX instrinsics function, and that would prevent the compiler from
using the XMM registers??
--
http://gcc.gn
--- Additional Comments From guardia at sympatico dot ca 2005-01-26 23:59
---
Even stranger, it doesn't do it with -march=athlon either... only
-march=pentium, pentium2 or pentium3... ?
That seems like some weird bug here. There musn't be a THAT big of a difference
between th
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 00:08
---
Oh oh, I think I'm getting somewhere... if I use both -march=athlon and -msse
flags I get the "bad" code. Let me summarize this :
-march=pentium3 = bad
-msse = bad
-march=athlon = good (ie.:
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 02:30
---
Ok ok, SSE is not enabled by default on Athlon...
So, is there some sort of "pragma" that could be used to disable SSE registers
(force -mmmx sort of) for only part of some code?
The way I s
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 06:19
---
Ok, so from what I gather, the backend is being designed for the autovectorizer
which will probably only work right with SSE2 (on x86 that is), as mucking with
emms will probably bring too much trouble. Second
--- Additional Comments From guardia at sympatico dot ca 2005-01-27 22:55
---
I think I'm starting to see the problem here... I tried to understand more of
the code, and from this and what you tell me, gcc find registers to use and then
finds instructions to that fits the bil
--- Additional Comments From guardia at sympatico dot ca 2005-01-29 04:47
---
Hum, there apparently seems to be a problem with the optimization stages.. I
cooked up another snippet :
void moo(__m64 i, unsigned int *r)
{
unsigned int tmp = __builtin_ia32_vec_ext_v2si (i, 0);
*r
--- Additional Comments From guardia at sympatico dot ca 2005-01-29 19:21
---
Hum, ok we can do a "movd %mm0, %eax", that's why it gets combined...
Well, I give up. The V8QI (and whatever) -> V2SI conversion seems to be causing
all the trouble here if we look at th
19 matches
Mail list logo
