--- Comment #18 from ubizjak at gmail dot com 2009-01-11 10:59 ---
Fixed for 4.3.4 and 4.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #19 from ubizjak at gmail dot com 2009-01-11 11:00 ---
(In reply to comment #18)
> Fixed for 4.3.4 and 4.0.
... and 4.4., of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
--- Comment #20 from ubizjak at gmail dot com 2009-01-11 14:35 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from ubizjak at gmail dot com 2009-01-11 14:37 ---
(In reply to comment #3)
> Please have a look at this:
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00033.html
But from the msg followup:
Actually, the s-osinte-linux-alpha.ads and s-osinte-linux-hppa.ads
file
--- Comment #9 from ubizjak at gmail dot com 2009-01-12 13:27 ---
Options should be wrapped in quotes, like:
COLLECT_GCC_OPTIONS='-O2' '-mtune=generic'
"/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1" "-quiet" "dir
test/hello.c&qu
--- Comment #10 from ubizjak at gmail dot com 2009-01-12 13:57 ---
(In reply to comment #9)
> Options should be wrapped in quotes, like:
>
> COLLECT_GCC_OPTIONS='-O2' '-mtune=generic'
> "/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1&q
--- Comment #12 from ubizjak at gmail dot com 2009-01-12 14:59 ---
Hm, on i686-pc-linux-gnu -v gives:
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic'
/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -quiet -v dir
test/hello.c -quiet -dumpbase h
--- Comment #4 from ubizjak at gmail dot com 2009-01-12 15:06 ---
-fno-ira fixes the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host tr
--- Comment #1 from ubizjak at gmail dot com 2009-01-14 09:40 ---
Created an attachment (id=17096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17096&action=view)
test log file of "make check_abi"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38834
--- Comment #2 from ubizjak at gmail dot com 2009-01-14 09:42 ---
Patch at http://gcc.gnu.org/ml/libstdc++/2009-01/msg00066.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
b450:0x2516250f
(gdb) x/4 $a2
0x11f2bb450:0x2516250f 0x33323130 0x37363534 0xc30fbedf
--
Summary: scheduler does not look for conflicting alias sets
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from ubizjak at gmail dot com 2009-01-17 17:04 ---
The problem is in a thinko in alias.c, base_alias_check (). For our problematic
addresses, we enter base_alias_check with:
x = (reg:DI 18 $18 [ i ])
and
y = (and:DI (reg/f:DI 16 $16 [orig:69 __result ] [69
--- Comment #3 from ubizjak at gmail dot com 2009-01-17 18:40 ---
(In reply to comment #2)
> That code is ancient, and wrong from day 1 if your analysis is correct :-)
Hm, no. The code is correct, but applies only to symbols involving ANDs.
We need somehing like this code also for
--- Comment #13 from ubizjak at gmail dot com 2009-01-19 18:53 ---
(In reply to comment #10)
> Fails on s390 and s390x as well.
And alpha.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
--- Comment #4 from ubizjak at gmail dot com 2009-01-20 19:49 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01018.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2009-01-21 07:09 ---
4.0.x and 4.1.x are not supported anymore. Please upgrade to 4.3.x or (soon)
4.4.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2009-01-21 18:50 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from ubizjak at gmail dot com 2009-01-22 08:25 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|uros at
--- Comment #4 from ubizjak at gmail dot com 2009-01-22 10:32 ---
Created an attachment (id=17160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17160&action=view)
Patch to fix insn attributes
Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
--- Comment #6 from ubizjak at gmail dot com 2009-01-22 13:12 ---
Fixed in mainline, latent on 4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target
--- Comment #2 from ubizjak at gmail dot com 2009-01-23 08:47 ---
Works for me with:
--cut here--
#define _GNU_SOURCE
#include
#include
#include
static void foo (int sig)
{
exit (0);
}
float __attribute__((noinline)) test (float x) { return 2.0f / x; };
int main()
{
volatile
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet:
http
--- Comment #1 from ubizjak at gmail dot com 2009-01-23 17:02 ---
1) The source as inlined in bugreport is useless, please see [1] for a detailed
bug report instructions and _attach_ generated preprocessed source (unless it
is a couple of tens of lines long...).
2) -march=native
--- Comment #5 from ubizjak at gmail dot com 2009-01-24 10:17 ---
(In reply to comment #4)
> I don't know why the bug was closed: I can confirm the erroneous behavior is
> present also in GCC 4.3.2.
Because it looks to me that this is libc problem with fetestexcept. As
--- Comment #8 from ubizjak at gmail dot com 2009-01-24 17:06 ---
There are numerous g++ EH failures even for x86-pc-linux-gnu, when gcc is
configured with --enable-sjlj-exceptions, so something is serious FUBAR w.r.t
to SJLJ exceptions.
=== g++ tests ===
Running
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:28 ---
Backported to 4.3 branch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone
--- Comment #1 from ubizjak at gmail dot com 2009-01-25 17:39 ---
Can you attach a working asm dump?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2009-01-25 19:55 ---
gcc should initialize pseudos from "x" variable in my_print_complex:
;; Function my_print_complex (my_print_complex)
;; Generating RTL for gimple basic block 2
;; D.2813 = internal_print_complex (x);
--- Comment #3 from ubizjak at gmail dot com 2009-01-26 17:20 ---
Following patch fixes this problem:
--cut here--
Index: calls.c
===
--- calls.c (revision 143671)
+++ calls.c (working copy)
@@ -992,7 +992,6
--- Comment #4 from ubizjak at gmail dot com 2009-01-26 17:22 ---
This is generic RTL optimization problem.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2009-01-27 10:27 ---
Fixed in the trunk.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #5 from ubizjak at gmail dot com 2009-01-27 19:55 ---
Created an attachment (id=17195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17195&action=view)
Patch to fix crtstuff.c failure
This patch fixes crtstuff failure with -mcmodel=large.
--
ubizjak at gm
--- Comment #6 from ubizjak at gmail dot com 2009-01-27 19:57 ---
Steve, can you test this patch if it fixes your bootstrap?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #8 from ubizjak at gmail dot com 2009-01-27 20:28 ---
(In reply to comment #7)
> Did you change cselib_hash_rtx too? I don't see that change in your patch but
> I know I need it to get to the shared rtx bug that your patch will hopefully
> fix.
The fix is
--- Comment #14 from ubizjak at gmail dot com 2009-01-29 08:05 ---
Cc the author of the patch:
Author: hubicka
Date: Tue Jan 6 15:08:44 2009
New Revision: 143119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143119
Log:
* i386.h (CONDITIONAL_CALL_USAGE): SSE
--- Comment #15 from ubizjak at gmail dot com 2009-01-29 08:06 ---
4.4 regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|codegen
--- Comment #12 from ubizjak at gmail dot com 2009-01-29 10:09 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2009-01-29 10:10 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from ubizjak at gmail dot com 2009-01-30 09:56 ---
You can workaround this PE/COFF problem with -fno-common.
*** This bug has been marked as a duplicate of 37216 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #51 from ubizjak at gmail dot com 2009-01-30 09:56 ---
*** Bug 39039 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-05-07 20:37 ---
(In reply to comment #0)
> I do not see any way to explicitly blacklist the opcode, and setting -march to
> i486, i386, or native does not avoid the problem.
>
> Could this be added as an architecture, or
--- Comment #2 from ubizjak at gmail dot com 2009-05-09 21:37 ---
(In reply to comment #1)
> There is no bug for current trunk. So bug fixed.
Not really, the move insn is moved to the beginning of the function:
0060 :
60: 89 f8 mov%edi,%eax
--- Comment #7 from ubizjak at gmail dot com 2009-05-10 14:28 ---
(In reply to comment #6)
> > /* X86_TUNE_USE_FFREEP */
> > m_AMD_MULTIPLE,
> Without having dug into the source, I'd guess that this is the exact location
> of the bug.
>
> > #define
--- Comment #9 from ubizjak at gmail dot com 2009-05-10 17:51 ---
(In reply to comment #8)
> > Can you send the output of "gcc -march=native -v"? It looks that the driver
> > doesn't detect correctly the type of your CPU.
Uh, I mean "gcc -march=native
--- Comment #11 from ubizjak at gmail dot com 2009-05-10 20:55 ---
(In reply to comment #10)
> COLLECT_GCC_OPTIONS=
> "/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1" "-quiet" "hello.c" "-march=athlon"
> "--param" "l1-cache-size
--- Comment #13 from ubizjak at gmail dot com 2009-05-10 22:00 ---
Created an attachment (id=17848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17848&action=view)
Patch
This patch looks at processor name to detect AMD geode CPU. As far as gcc is
concerned, "-march=
--- Comment #7 from ubizjak at gmail dot com 2009-05-12 12:07 ---
Oops, wrong PR number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37197
--- Comment #14 from ubizjak at gmail dot com 2009-05-12 12:08 ---
Author: uros
Date: Tue May 12 11:42:53 2009
New Revision: 147429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147429
Log:
PR target/37197
* config/i386/driver-i386.c (processor_signatur
--- Comment #1 from ubizjak at gmail dot com 2009-05-13 16:26 ---
It looks to me, that these test never really passed on x87. Compiling wiht
gcc-4.3, we get:
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl
--- Comment #2 from ubizjak at gmail dot com 2009-05-13 16:34 ---
Adding -ffloat-store also fixes these failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
--- Comment #5 from ubizjak at gmail dot com 2009-05-13 18:16 ---
(In reply to comment #4)
> So -- invalid?
There was a reason Paolo reported this problem, so let him have the last word.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
--- Comment #22 from ubizjak at gmail dot com 2009-05-13 18:22 ---
(In reply to comment #21)
> I guess! Your patch is absolutely correct for AMD AthlonTM 64 and AMD
> OpteronTM
> processors, but it is nonoptimal for Intel processors. Because:
...
CCing H.J for Intel opt
--- Comment #55 from ubizjak at gmail dot com 2009-05-14 07:51 ---
(In reply to comment #54)
> I've started work on the binutils support for this. Work-in-progress patch at
> http://sourceware.org/ml/binutils/2009-05/msg00228.html
>
> Once that's complete, I c
--- Comment #18 from ubizjak at gmail dot com 2009-05-14 08:25 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2009-05-18 16:37 ---
(In reply to comment #8)
> No, it's just i686-pc-linux-gnu. Without --target_board "etc." it
> works; with I got this spurious failure.
>
> But it's not a wrong code, so I think we can c
--- Comment #4 from ubizjak at gmail dot com 2009-05-21 18:30 ---
Also fixed for x86, see [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01802.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2009-05-22 17:27 ---
http://gcc.gnu.org/bugs.html#report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40226
--- Comment #3 from ubizjak at gmail dot com 2009-05-24 09:11 ---
(In reply to comment #2)
> what's wrong ? no more details were put e.g. here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37179
This was different problem, with -march=native. And according to [1],
-march=
--- Comment #4 from ubizjak at gmail dot com 2009-05-24 19:19 ---
(In reply to comment #1)
> I don't see why adding -mno-mmx is a problem (that disables all of the MMX and
> SSE instructions). -mno-mmx will always disabling all of the future subsets
> too.
No, MMX and S
--- Comment #2 from ubizjak at gmail dot com 2009-05-24 19:30 ---
There is a typo hiding somewhere, we should have "and:DI" instead of "and:SI".
Confirmed on 4.3.4.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #3 from ubizjak at gmail dot com 2009-05-24 20:06 ---
Created an attachment (id=17912)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17912&action=view)
patch
The mechanical patch that fixes the failure. However - do we need a realignment
at all on x86_64?
--
--- Comment #1 from ubizjak at gmail dot com 2009-05-27 08:06 ---
(In reply to comment #0)
> cat /proc/cpuinfo:
>
> flags : .sse sse2 ssse3 sse4_1 ...
Please post complete /proc/cpuinfo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40266
--- Comment #6 from ubizjak at gmail dot com 2009-05-27 08:41 ---
*** Bug 40268 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2009-05-27 08:41 ---
*** This bug has been marked as a duplicate of 40061 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-05-27 08:42 ---
(In reply to comment #5)
> FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the
> breakage.
Not really, see PR 40268 for description and proposed patch.
Confirmed fail on cross to alpha-lin
--- Comment #61 from ubizjak at gmail dot com 2009-05-28 21:45 ---
Fixed for 4.5.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from ubizjak at gmail dot com 2009-06-02 07:57 ---
So, fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from ubizjak at gmail dot com 2009-06-11 17:35 ---
*** This bug has been marked as a duplicate of 38222 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-06-11 17:35 ---
*** Bug 38909 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-06-16 18:16 ---
(In reply to comment #2)
> Could you check to see why store_multiple_sequence doesn't find this in the
> peephole in the ARM backend ?
Registers also need to be consecutive, starting from certain register,
--- Comment #1 from ubizjak at gmail dot com 2009-06-17 07:32 ---
Works for 4.4.1 and 4.5.0
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work
--- Comment #7 from ubizjak at gmail dot com 2009-06-17 09:18 ---
See Comment #2!
I tried to enhance ix86_secondary_reload target macro to return XMM
intermediate reg with movdi_to_sse handler for DImode -> DFmode moves. However,
handling of this macro has plenty of FIXMEs, and I
--- Comment #2 from ubizjak at gmail dot com 2009-06-19 13:58 ---
(In reply to comment #1)
> What are the excess errors?
>
Executing on host: /home/uros/gcc-build/gcc/xgcc -B/home/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/20080522-1.c-ansi
-pedantic-
--- Comment #3 from ubizjak at gmail dot com 2009-06-19 14:09 ---
Ah, they are truncated instead of removed:
r148664 | razya | 2009-06-18 18:08:00 +0200 (Thu, 18 Jun 2009) | 2 lines
see removal
I'll
--- Comment #6 from ubizjak at gmail dot com 2009-06-19 14:27 ---
(In reply to comment #4)
> > Ah, they are truncated instead of removed:
>
> The same is true for at least gcc/see.c.
I have removed this file as well in a follow-up commit.
Fixed.
--
ubizjak at g
--- Comment #2 from ubizjak at gmail dot com 2009-06-23 12:09 ---
(In reply to comment #1)
> Uros, this bug is from the pre-IRA times. Could you check if you still see
> this problem, please?
Yes, it is still present as of gcc 4.5.0 20090623
--
ubizjak at gmail dot com c
--- Comment #1 from ubizjak at gmail dot com 2009-06-24 06:35 ---
Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
approach from builtins-18.c) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
--- Comment #7 from ubizjak at gmail dot com 2009-06-24 11:57 ---
Adding x86 intrinsic expert...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 07:26 ---
(In reply to comment #2)
> > Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
> > approach from builtins-18.c) ?
>
> Attached diff. However, there's still a call left t
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 07:33 ---
(In reply to comment #5)
> I will simply disable builtins-65.c for non-C99 targets
... like this:
Index: builtins-65.c
===
--- builtins-6
--- Comment #14 from ubizjak at gmail dot com 2009-06-25 08:25 ---
(In reply to comment #13)
> Predictive commoning does exactly what you want.
It is not effective for the testcase in Comment #9. The dumps for innermost
loop are the same for -O2 -funroll-loops [-fpredictive-common
--- Comment #15 from ubizjak at gmail dot com 2009-06-25 08:31 ---
(In reply to comment #14)
> (In reply to comment #13)
> > Predictive commoning does exactly what you want.
Predictive commoning failed: no suitable chains
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 08:58 ---
Oops...
--
ubizjak at gmail dot com changed:
What|Removed |Added
Keywords
--- Comment #9 from ubizjak at gmail dot com 2009-06-25 09:03 ---
*** This bug has been marked as a duplicate of 21920 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #141 from ubizjak at gmail dot com 2009-06-25 09:03 ---
*** Bug 40537 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2009-06-25 17:09 ---
4.4 fixed movaps isse by calling ix86_expand_vector_move to generate unaligned
move.
The core of the problem is however in the middle end, where we expnd from:
main ()
{
vector float D.1414;
vector float D.1413
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 17:32 ---
The problem is also present on 4.5.0. The executable won't segfault, because
-O0 generates more temporaries on stack. However:
xorps %xmm1, %xmm1
movlps 56(%esp), %xmm1
(*) movhps 64(%esp),
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 17:49 ---
Middle end.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Component|target
--- Comment #8 from ubizjak at gmail dot com 2009-06-26 09:04 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2009-06-28 10:05 ---
(In reply to comment #7)
> D.1412 = BIT_FIELD_REF ;
>
> is certainly not the size of v2sf...
This happens in veclower pass.
--
ubizjak at gmail dot com changed:
What
--- Comment #10 from ubizjak at gmail dot com 2009-06-28 10:25 ---
(In reply to comment #9)
> This happens in veclower pass.
type_for_widest_vector_mode () is forcing operations from v2sf to v4sf. This is
not correct, since there will be garbage in the top two elements. For FP
val
--- Comment #11 from ubizjak at gmail dot com 2009-06-28 11:04 ---
Patch in testing:
Index: tree-vect-generic.c
===
--- tree-vect-generic.c (revision 148947)
+++ tree-vect-generic.c (working copy)
@@ -481,8 +481,10
--- Comment #13 from ubizjak at gmail dot com 2009-06-28 12:13 ---
(In reply to comment #12)
> Shouldn't we be able to use mmx regs here? Thus not rely on
> type_for_widest_vector_mode, but instead see if the original vector
> mode is supported by the backend?
Please
--- Comment #14 from ubizjak at gmail dot com 2009-06-28 15:13 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02123.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #18 from ubizjak at gmail dot com 2009-06-28 23:16 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ubizjak at gmail dot com 2009-06-28 23:36 ---
(In reply to comment #4)
> As an additional note:
> if compiled with -m3dnow the program produces nans
mmx instructions without [f]emms block x87 registers, so you will get nans.
Otherwise, mmx moves were re-tun
--- Comment #19 from ubizjak at gmail dot com 2009-06-28 23:36 ---
*** Bug 40553 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2009-06-29 08:35 ---
(In reply to comment #2)
> Still present in GCC 4.5.0 20090513.
Are you sure?
config/rs6000/rs6000.c has:
static tree
rs6000_builtin_conversion (unsigned int tcode, tree type)
rs6000 target is also a member
101 - 200 of 6742 matches
Mail list logo
