--
Bug 18107 depends on bug 17406, which changed state.
Bug 17406 Summary: [4.0 regression] ICE dwarf2out_frame_debug_expr, at
dwarf2out.c:1692
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406
What|Old Value |New Value
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-29 00:23
---
This is virtually certain to be a bug in either pam or some other system
library that you're linking with. The error message means that someone
didn't link some shared library agai
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-29 00:25
---
Indeed, if libc doesn't have all the symbols that it should, it's a netbsd bug.
--
What|Removed
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-29 00:32
---
The problem mentioned in comment 8 is not a bug.
(float&)MASK
has the exact same semantics as
*(float *)&MASK
which, as we all ought to know by now, is undefined. Open another PR
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-29 00:42
---
I don't reproduce this with a build from last night.
Try again with today's sources. In particular, the symptom looks as if the
fpu has been put into mmx mode. Which might be solved with
2004-12-2
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-29 01:25
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-31 23:30
---
I think that this sort of thing *ought* to work. How, exactly, to teach
cgraph to make it happen is perhaps tricky...
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-01 00:21
---
When references are involved, like this, reduction to MAX_EXPR is wrong to
begin with. The cast is only an additional symptom.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
--
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-01 01:45
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-01 02:42
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-02 07:54
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-03 20:39
---
Yep. When we do these stepwise filtering of patterns all of them have to have
the same predicates, even if the constraints are more strict.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19240
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-03 23:16
---
The Ada compiler may do it, but the C compiler does not. This test case,
written in C, is invalid.
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-03 23:51
---
No, with pic the address of ustrzcat is not a constant. Ergo the impossible
constraint error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19228
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-03 23:56
---
Not really. Gcc and binutils must agree on what leading underscore convention
to use. On normal ELF systems, we're forcing them to disagree for this test
case
so it's not really surprising that w
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-04 00:03
---
I'm willing to lay money this is the same problem as PR 19235.
*** This bug has been marked as a duplicate of 19235 ***
--
What|Removed |
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-04 00:03
---
*** Bug 19174 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-04 09:14
---
Subject: Re: Unaligned access to fields inside packed records
> Could you tell on what grounds? AFAICS all fields are still addressable.
Not really, they aren't. I've argued in the past t
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-04 10:04
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 19107 depends on bug 19235, which changed state.
Bug 19235 Summary: [4.0 regression] GCC generates SSE2 instructions for
AthlonXP which doesn't support them.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19235
What|Old Value |New Value
---
--
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-05 20:03
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-05 20:31
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-06 01:22
---
No chance this is getting done for 4.0.
--
What|Removed |Added
Target Milestone|3.4.4
--
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-06 04:18
---
I believe it to be fixed. Reopen if not.
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00323.html
--
What|Removed |Added
--
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-06 06:26
---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00331.html
Should be fixed.
--
What|Removed |Added
--
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-06 06:53
---
Just defining SLOW_UNALIGNED_ACCESS is not enough to get the desired result
from 3.4. Lots of this has been rearranged in mainline, and I don't feel
like backporting it. We do not select TImode in mai
--
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-09 04:46
---
Actually, I have a standards question here.
Assume for the purposes of discussion here that a source-level reference
variable
"X" is represented as a pointer variable "x" in the interme
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-09 18:46
---
I hadn't realized aliases to COMMON symbols ever worked...
--
What|Removed |
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-09 18:49
---
Indeed, they DO NOT work, and never have. The warning is correct.
--
What|Removed |Added
--- 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 .
--
What|Re
--- 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-fl
--- 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
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 05:41
---
Not invalid. The asm is a pointer escape point.
--
What|Removed |Added
Last reconfirmed|
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 05:41
---
.
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
--
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 functions.
It is absolutely ESSENTIAL that we do NOT emit mmx vector operations UNLESS
the routines are used. Doing so without the compiler also
being able to insert emms instructions is
--- 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|-MA
--- 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 u
--- 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-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 y
--
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 "<
--- 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
--- 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
--
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
--- 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 is not in use. The instruction selection thing
can still be seen with the SSE unit though, if you widen the vectors to
--- 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||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19518
--
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-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 th
--- 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
--- 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
--- 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|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 i
--
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-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&#x
--- 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
--- 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
701 - 800 of 974 matches
Mail list logo
