[Bug middle-end/19687] [4.0 Regression] ICE with union initializer
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19687
[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:35 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19689
[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-30 02:46:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19690
[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-30 02:48:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19700
[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 04:40 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19690
[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 07:30 --- No, Steven, this is a different problem. Note that there are not two memory references, as in the other PR. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 07:45 --- That said, what are you expecting here for massage48? On K8, the latency of imul for a 32-bit register operand is 3 cycles. Alternately, we can break this down into leal (%eax,%eax,2), %eax sall $4, $eax # Use eax unscaled Which is 2 cycles latency for the leal and one for the sall, so gcc rightly chooses to use the single multiply instruction, since the alternative is no cheaper. On pentium4, timings are different, and we select the leal+sall sequence. I don't see anything in this test case at all that could be made to use more complex addressing modes. As for the Real World code that uses a variable imul instead of a constant, that would be more interesting to examine. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-28 08:11 --- I'm starting to think there's something wrong with the system 64-bit libc. Lets close for now, and I'll report again if I can find something reproducible. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes
-- What|Removed |Added Attachment #8095|text/x-c|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19680
[Bug c++/14329] [tree-ssa] badly formatted warnings for SRA replacements
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 09:33 --- C++ front end left to update. See http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01988.html for an example of something that almost but does not quite work. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Component|tree-optimization |c++ Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 18:41 --- No, no extra anything. This is on a newly installed fedora core 4 system, so glibc 2.3.4 and gcc 3.4.3-20050113 as bootstrap compiler. I guess I'll try again and post a .i file if reproducible, or fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 20:34 --- Subject: Re: PPC64 64-bit build failure On Thu, Jan 27, 2005 at 07:09:58PM -, dje at watson dot ibm dot com wrote: --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gcc-version-trigger=/home/dje/src/src/gcc/version.c --enable-languages=c,c++ I'm using no special options. In particular, no --with-cpu=default32. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:47 --- Hmm. Seems to only happen with -march=pentium3, and not -march=pentium4... -- What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2005-01-20 18:44:05 |2005-01-26 15:47:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:11 --- Tricky. Part the first, I thought, is that the mode of the FIELD_DECL doesn't match the mode of the FIELD_DECL's type. Except that doesn't actually appear to matter. I shall fix it anyway. As for combine, the problem on i386 is that we merge the mem with the QImode AND, which prevents the later combination with the SImode AND. The problem on PowerPC is a missing optimization in make_field_assignment. Perhaps we can avoid the zero_extend and use a paradoxical subreg instead... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-12 03:56:39 |2005-01-26 18:11:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
-- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:40 --- Sorry, but this appears to be unfixable without a complete rewrite of MMX support. Everything I tried had side effects where MMX instructions were used when we were not using MMX intrinsics. -- What|Removed |Added BugsThisDependsOn||19161 Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 00:11 --- (In reply to comment #10) That seems like some weird bug here. There musn't be a THAT big of a difference between the code for pentium3 and the one for athlon right? Well, duh, athlon doesn't have sse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 00:12 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
-- Bug 19466 depends on bug 18008, which changed state. Bug 18008 Summary: [4.0 Regression] Duplicate mask on bitfield insertion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
[Bug bootstrap/19601] [4.0 Regression] make bootstrap-lean fails: insn-conditions.c:189: error: `flag_unsafe_math_optimizations' undeclared
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 00:14 --- I don't replicate this on powerpc64-linux. We don't completely bootstrap in 64-bit mode either (PR19645), but I get farther than your log indicates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19601
[Bug tree-optimization/13000] [3.4 Regression] [unit-at-a-time] Using -O2 cannot detect missing return statement in a function
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 01:58 --- I am uninterested in fixing this for 3.4. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13000
[Bug tree-optimization/14329] [tree-ssa] badly formatted warnings for SRA replacements
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-09-07 16:58:14 |2005-01-27 01:59:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 03:52 --- 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? No. __m64 should always be on mmx registers, and __m128 should always be on xmm registers. Well, yes and no. Given SSE2, one *can* implement *everything* in mmintrin.h with SSE registers. I can also prevent it from using an xmm register by [...] ... doing something complicated enough that, for the existing patterns defined by the x86 backend, it very much more strongly prefers the mmx registers. Your problems with preferencing will come only when the register in question is only used for data movement. Which, as can be seen in your _mm_unpacklo_pi8 test case, can happpen at surprising times. There are *two* registers to be register allocated there. The one that does the actual unpack operation *is* forced to be in an MMX register. The other moves the result to the return register, and that's the one that gets mis-allocated to the SSE register set. If one wants to move one 32 bit integer to a mmx register, that should be the job of a specialized intrinsics (_mm_cvtsi32_si64) which maps to a MOVD instruction. With gcc, NONE of the intrinsics is strict 1-1 mapping to ANY instruction. Does it make sense? Is this what you mean by a complete rewrite or were you thinking of something else? Gcc has some facilities for generic vector operations. Ones that don't use any of the foointrin.h header files. When that happens, the compiler starts trying to use the MMX registers. But it doesn't know how to place the necessary emms instruction, which is Bad. At the moment, the only way to prevent this from happening is to strongly discourage gcc from using the MMX registers to move data around. This is done in such a way that the only time it will use an MMX register is when we have no other choice. Which is why you see the compiler starting to use SSE registers when they are available. You might think that we could easily use some pragma or something when mmintrin.h is in use, since it's the user's responsibility to call _mm_empty when necessary. Except that due to how gcc is structured internally, you'd not be able to be 100% certain that all of the mmx data movement remained where you expected. Indeed, we have open PRs where this kind of movement is in fact shown to happen. Thus the ONLY solution that is sure to be correct is to teach the compiler what using MMX registers means, and where to place emms instructions. Which is the subject of the PR against which this PR is marked as being blocked. This cannot be addressed in any satisfactory way for 4.0. Frankly, I wonder if it's worth addressing at all. To my mind it's just as easy to write pure assembly for MMX. And pretty soon the vast majority of ia32 machines will have SSE2, and that is what the autovectorizer will be targeting anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 03:55 --- PS, your best solution, for now, is simply to use -mno-sse for the files in which you have mmx code. Move the sse code to a separate file. That really is all I can do or suggest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 06:05 --- Steven, you do realize this is essentially unfixable without a new pass that optimially places widened operations, don't you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 06:24 --- I say you've completely mis-diagnosed the problem, since 0x66 0x66 0x90 is a PERFECTLY LEGITIMATE x86-64 nop sequence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug middle-end/18902] Naive (default) complex division algorithm
-- Bug 18902 depends on bug 19609, which changed state. Bug 19609 Summary: [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-25 18:26 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-25 18:51 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01815.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19556
[Bug target/19584] [4.0 Regression] ICE: insn does not satisfy its constraints
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-25 18:51 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01815.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19584
[Bug tree-optimization/19633] New: local address incorrectly thought to escape
struct S { int w, x, y, z; };
struct T { int r; struct S s; };
void bar (struct S, int);
void foo (int a, struct T b)
{
struct S *c = 0;
if (a)
c = b.s;
bar (*c, a);
}
The call to bar appears to not be marked [tail-call] because b is marked
as a call-clobbered local variable. Which IIRC means that the aliasing code
thinks that the address of b escapes. Which is untrue -- no address escapes
from this function.
--
Summary: local address incorrectly thought to escape
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19633
[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-24 21:49:21 |2005-01-24 22:23:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-24 23:23 --- Yes, I see that. My eyes crossed while transcribing the algorithm to trees, and I failed to notice that a computation is (b - (a * ratio)) in one branch and ((a * ratio) - b) in the other. And so incorrectly believed that the branches could be rewritten to share code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug middle-end/19609] [4.0 Regression] real and imaginary part interchanged when flags_complex_divide_method=1
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-25 06:28 --- Please do. I seem to have screwed up the ia64 build as well (user error on my side), and won't see results until tommorow gmt-8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-23 22:04 --- No, it should not. See the AMD K8 documentation for recommended nop sequences. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug target/19556] [4.0 Regression] ICE with -march=pentium-m (during bootstrap)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-21 02:11:18 |2005-01-24 01:11:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19556
[Bug target/19584] [4.0 Regression] ICE: insn does not satisfy its constraints
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-23 16:15:16 |2005-01-24 01:32:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19584
[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-20 18:00:11 |2005-01-24 02:13:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19486
[Bug middle-end/18902] Naive (default) complex division algorithm
-- Bug 18902 depends on bug 19486, which changed state. Bug 19486 Summary: flags_complex_divide_method=1 doesn't work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19486 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug middle-end/19486] flags_complex_divide_method=1 doesn't work
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-24 02:32 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19486
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-22 23:23 --- (In reply to comment #10) Should patch to sse_comparison_operator [...] be reverted in this case? Nah. As I said in that message, allowing these operators in this manner doesn't actually give the register allocator any more freedom, and therefore doesn't do what was hoped. See e.g. alpha's movsicc_internal for an example of how the comparisons would have to be reworked in order to give that freedom. Anyway, fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-21 22:03 --- I've found the problem, via binary search on the povray source and then visual inspection of the file found to be miscompiled. The mov[sd]fcc_1_sse patterns are missing an earlyclobber. The fix isn't quite as simple as just adding '' to the pattern, but I should have it done today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug target/16533] ICE on va-arg-25.c testcase when -Os and -msse are given
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-11-06 18:25:06 |2005-01-20 09:48:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16533
[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-16 18:50:28 |2005-01-20 09:52:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19350
[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 10:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19350
[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19350
[Bug target/19418] _mm_cast*, icc8.1 new intrinsics
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-13 05:47:29 |2005-01-20 10:22:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19418
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 11:28 --- (In reply to comment #7) So we cannot use count_type_elements in gimplify_init_constructor. Well, not for unions anyway. I think we should somehow compute the size of the CONSTRUCTOR and compare it with int_size_in_bytes (TREE_TYPE (object))...? For unions, that may be what we have to do. With any luck, the element being initialized will be the largest element of the union, which would mean we wouldn't have to emit the clear. For structures, this would mean that any structure with holes would get cleared. Which would clearly pessimize a very common case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:03 --- (In reply to comment #12) But, what about structures that contain a union? We'll need to consider the question do we need to clear one nesting level at a time, and propagate it up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-20 18:44:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:44 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/16533] ICE on va-arg-25.c testcase when -Os and -msse are given
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:46 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01351.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16533
[Bug target/19418] _mm_cast*, icc8.1 new intrinsics
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 19:09 --- Fixed. If someone wants to go over the rest of the headers item by item and compare them to the Intel documentation, that would be great. But by eyes claim they'll go on strike if I try to do that. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19418
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 19:12 --- (In reply to comment #4) This functionality is missing after FP compares rewrite... No, it got moved to ix86_expand_fp_movcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-21 00:26:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-19 21:21 --- Yes, it's certainly possible. But indeed pr19511 shows that you can't even get that far with --with-arch=pentium3 at the moment, due to changes that post-date this report. After I get a fix for that problem, will you please re-test? Hopefully I'll have magically fixed this problem which was never sufficiently isolated... -- What|Removed |Added BugsThisDependsOn||19511 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174
[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for i686 with -msse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 01:02 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-14 07:17:07 |2005-01-20 01:03:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19427
[Bug tree-optimization/17884] asm 'volatile' is not honored as documented
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 01:33 --- In reply to comment #20: Again, this is not scheduling, per se. This is register rematerialization. We have a value at some point, and we decide that it's cheaper to move the computation rather than store and reload it. This is really no different than if we decided to CSE the computation as in __fnstsw(s1); __fldenv(envp-x87);/* volatile */ __fnstsw(s2); - __fnstsw(s1); __fldenv(envp-x87);/* volatile */ s2 = s1; I must repeat myself that the original source code is buggy. You've got asms that affect, or are affected by, architectural state that is not visible to the compiler. As such you REALLY REALLY MUST mark the asm as volatile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 04:13 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 04:22 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for i686 with -msse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 06:37 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19427
[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226
-- Bug 19174 depends on bug 19511, which changed state. Bug 19511 Summary: [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174
[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 06:58 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511
[Bug target/19496] [4.0 Regression] ICE in gcc.c-torture/execute/ieee/fp-cmp-8.c for x86_64 and i686 with -msse2 -mfpmath=sse
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-18 09:18:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19496
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
-- What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2005-01-13 08:11:21 |2005-01-18 09:19:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
-- What|Removed |Added BugsThisDependsOn||14295 Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 09:50 --- Found the tree-ssa aggregate copy-propagation pr. Made this pr depend on it, as this has a different sort of test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug target/17415] 3dNOW and gcc3.3 possible oddities
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 09:52 --- *** This bug has been marked as a duplicate of 19161 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17415
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 09:52 --- *** Bug 17415 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||plm at pcug dot org dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug rtl-optimization/19398] secondary reloads don't consider m alternatives
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 11:20 --- This doesn't really have anything to do with sse. We have a value in f and decide it should be in x, and discount the m alternative. Could be fixed by having reload look at m when considering secondary reloads. It's sure to be mildly complicated by wanting to not keep the value in memory if it could be inherited by multiple instructions, but it's definitely a win for x86 code density to avoid explicit loads when the value is otherwise unused. The only target solution I can think of is peepholes. But we could easily need Quite A Lot of them in the x86 port, so I don't think this an ideal solution. -- What|Removed |Added Component|target |rtl-optimization Keywords|ssemmx | Summary|Non-optimal code with |secondary reloads don't |cvttss2si |consider m alternatives http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 11:34 --- No, Andrew, mainline is not plainly wrong. We are correctly not using the MMX unit when mmintrin.h is not in use. The instruction selection thing can still be seen with the SSE unit though, if you widen the vectors to 16 bytes. The problem is that ix86_rtx_costs has no idea about the cost of vector operations. For what little it's worth, K8 thinks paddw and psllw are equivalent -- both can be issued to fadd or fmul pipelines. -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 20:35 --- Can you attach the patch you used? I'm not replicating this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-18 20:42 --- Nevermind, I got it. Yaye CCmode moves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
-- What|Removed |Added Attachment #7984|text/x-csrc |text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug target/19518] [alpha] unrecognizable insn (set (reg:V4HI) (const_vector:V4HI)) with builtins
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-19 00:02:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
[Bug debug/19521] [4.0 Regression] omitted stab for gcov initialization function
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-19 02:35 --- So the bug is the end stab without the start stab? Or do you think that this bit of code that corresponds not at all to any user code should have full stabs? If the later, why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
[Bug target/19511] [4.0 Regression] ICE in in reload_cse_simplify_operands, at postreload.c:391
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-18 21:18:28 |2005-01-19 05:08:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19511
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-17 21:08 --- Yes, the patch in comment 15 is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-13 08:11 --- My new code, so I'll own the bug. But I'm a bit confused by this. In what sort of situation are we requiring the subreg built, and simplify_subreg is rejecting the subreg as illegal? Could you run the compiler with your patch, but instead of a call to simplify_gen_subreg, call simplify_subreg (like below), but abort if it returns NULL? And then see if it triggers within the gcc source tree or something handy like that where it's legally easier to give me .i file? If you can't find anything but spec to produce this, we'll work something out, but I'm lazy and wanna try this the easy way first. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-07 12:24:56 |2005-01-13 08:11:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 00:55 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug target/19252] sub optimal use of fpu comparisons in SSE code
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 00:55 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
[Bug target/19250] minss/maxss SSE insn not generated for -mfpmath=sse
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 01:03 --- I believe the problem you ascribe to this bug is fixed. Note that we do not generate minss for the given example because = is not the operation of the minss instruction; it performs . Which is relevant for +0.0 -0.0. We *ought* to emit minss with -ffast-math, but that should happen via noce_try_minmax invoking the sminsf3 pattern, rather than special-casing this in the back-end. Open a separate PR for that if you like. But on the bright side, we at least generate a conditional move sequence: cmpless %xmm1, %xmm0 andps %xmm0, %xmm2 andnps %xmm1, %xmm0 orps%xmm2, %xmm0 -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19250
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 01:36 --- I would consider (1) wrong. I'm not sure about (2); I think at one time there was a target that put fp return values in the integer registers even when a coprocessor was present. But there doesn't seem to be such a target in the tree now. Perhaps it got purged. I don't like (3) because that forces -mhard-float to imply MASK_FLOAT_RETURN, which would interfere with (2) if it still existed. As for (4), what do you think the problem *is* anyway? It's the fact that fxch is marked TARGET_80387, and the only reason *that* got emitted is to put the return value in the right place for MASK_FLOAT_RETURN. Duh. And my suggestion is to add if (!TARGET_80387) target_flags = ~MASK_FLOAT_RETURNS; somewhere in the middle of override_options. Preferably near the other bits that talk about fpmath etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
-- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug middle-end/19391] [4.0 Regression] missed optimization with size of 8 vectors
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 09:54 --- Try again with mmintrin.h functions. It is absolutely ESSENTIAL that we do NOT emit mmx vector operations UNLESS the mmintrin.h routines are used. Doing so without the compiler also being able to insert emms instructions is wrong-code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19391
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 19:47 --- In reply to comment #5: Perhaps I am out of touch with what's extant in the embedded space. I havn't been paid to care about that in quite some time. I'll defer. Using -MASK_80387|-MASK_FLOAT_RETURNS is incorrect. It should be -(MASK_80387|MASK_FLOAT_RETURNS). I agree with Ralf's later comment that -mno-80387 and -msoft-float should probably stay in sync. Though of course -msoft-float doesn't really mean as much as it sounds like it ought in conjunction with -mfpmath. In reply to comment #7: Yes, I did mean trap #7 handler for an fpu emulator. Though of course there are different levels of emulation. One thing that has been done before for MIPS is to provide a trap handler, but only implement the move instructions. This allows the ABI to remain unchanged by pretending that the appropriate registers exist, but not having to incur most of the overhead for trapping for all arithmetic instructions. Since RTEMS is multilibed, this is much less of an advantage. In any case, Joel, would you please take ownership of this bug and see it through? You're the one that would have to be doing the RTEMS testing anyway... -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-13 01:51
---
(In reply to comment #10)
{ hard-float, MASK_80387, N_(Use hardware fp) }, \
- { soft-float,-MASK_80387, N_(Do not use hardware fp) }, \
+ { soft-float,-(MASK_80387|MASK_FLOAT_RETURNS), \
+N_(Do not use hardware fp) }, \
One thing that I notice about this is that -msoft-float and -mhard-float are
no longer inverses. Perhaps it would be better to modify override_options to
notice when, after all options are processed, that MASK_80387 is off and then
turn off MASK_FLOAT_RETURNS to match.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19418] _mm_cast*, icc8.1 new intrinsics
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-13 05:40 --- What file does Intel put them in? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19418
[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-11 21:53 --- Fixed. No chance of a backport to 3.4. As a workaround, use _mm_set_pi16 instead of the explicit constructor. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366
[Bug target/19356] [4.0 regression] ICE with SSE intrinsics
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-11 22:12 --- Fixed with the patch for PR13366. Of course, __builtin_ia32_setzero128 doesn't exist anymore, but presumably this was after reducing the real testcase that used emmintrin.h. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19356
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-11 23:58 --- Your first test case is fixed by the patch for PR13366. We now get .align 16 .LC0: .long 1067869798 .long 1067869798 .long 1067869798 .long 1067869798 ... movaps .LC0, %xmm0 movups %xmm0, 56(%esp) I really don't know what you expected out of your second test case. Perhaps the problem is that we don't expose what movups means to the compiler. I can see that perhaps we could reuse MISALIGNED_INDIRECT_REF to represent this (which as a side benefit would result in movhps+movlps instead of one movups, which runs faster). But I doubt that we have the machinery at the tree level to copy-propagate the aggregate initialization from val1[4] - result[4]. I'm pretty sure that we have open enhancement requests for this already. So shall we mark this fixed? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
-- Bug 19379 depends on bug 19307, which changed state. Bug 19307 Summary: [4.0 Regression] ICE with -msse2 -mno-80387 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 00:19 --- And it works with today's compiler too. As for the use of the 80387 move instructions, even with -mno-80387, this isn't a regression. At least 3.2 did this as well. One could argue that -msoft-float should imply -mno-fp-ret-in-387, but it doesn't. Changing it now would be an ABI change that I'm not interested in making, considering the lack of use this option gets. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 00:28 --- Well, you have a problem. What do you want the ABI for soft-float to be? As RTEMS is probably the only user of -msoft-float, you get to choose. Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to supply it yourself, or do you want to admit that all shipping processors have an fpu and/or the os has an emulator? There really aren't many other options. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-12 00:28:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19250] minss/maxss SSE insn not generated for -mfpmath=sse
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-04 08:27:31 |2005-01-12 02:48:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19250
[Bug target/19252] sub optimal use of fpu comparisons in SSE code
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-12 02:48:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-27 01:00:43 |2005-01-12 02:49:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
