--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:17
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:35
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 04:40
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
--- 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
--
What|Removed |Added
Attachment #8095|text/x-c|text/plain
mime type||
--- 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
--- 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
--- 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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:24
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
--
What|Removed |Added
AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu
||dot org
Status|ASSIGNED
--- 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
--- 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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-27 00:12
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
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
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- 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
--- 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
--- 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
--- 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 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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-25 18:26
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
: 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- 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
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--
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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-24 02:32
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 10:17
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19350
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:44
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- 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
--- 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
--- 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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 04:13
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 04:22
---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 06:37
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 06:58
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2005-01-13 08:11:21 |2005-01-18 09:19:09
date|
--
What|Removed |Added
BugsThisDependsOn||14295
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
--
What|Removed |Added
Attachment #7984|text/x-csrc |text/plain
mime type||
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- 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
--- 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
--
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 00:55
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-14 00:55
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- 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
--- 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
--
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
701 - 800 of 970 matches
Mail list logo
