--- Additional Comments From wilson at specifixinc dot com 2005-03-25
02:46 ---
Subject: Re: gas should avoid F-unit NOPs (and B-unit
probably, too)
On Thu, 2005-03-24 at 18:22, hjl at lucon dot org wrote:
> --- Additional Comments From hjl at lucon dot org 2005-03-25 02:2
On Thu, 2005-03-24 at 18:22, hjl at lucon dot org wrote:
> --- Additional Comments From hjl at lucon dot org 2005-03-25 02:22
> ---
> Can we modify the patch to have it a switch to turn it on/off and make it
> on by default? Then, we can just turn it off in the existing testcases and
> ad
--- Additional Comments From hjl at lucon dot org 2005-03-25 02:22 ---
Can we modify the patch to have it a switch to turn it on/off and make it
on by default? Then, we can just turn it off in the existing testcases and
add a new one for this.
--
http://sources.redhat.com/bugzilla/sho
--- Additional Comments From wilson at specifixinc dot com 2005-03-25
01:13 ---
The patch looks OK to me, but I expect it will break the IA-64 gas testsuite,
which means we need patches for that also. I haven't tried writing those
patches yet.
--
http://sources.redhat.com/bugzilla/s
--- Additional Comments From hjl at lucon dot org 2005-03-25 00:37 ---
Jim, is the proposed patch OK?
--
What|Removed |Added
CC||w
Chips derived from McKinley-core (Itanium 2, etc.) have an anomaly which can
cause stalls if an F-unit instruction (including a NOP) is issued right after
reading certain application registers (such as ar.bsp). Furthermore,
power-considerations also argue against the use of F-unit instructions unl
--- Additional Comments From davidm at hpl dot hp dot com 2005-03-24 23:25
---
Created an attachment (id=445)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=445&action=view)
Proposed fix
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=803
--- You are receiving
Please could you try the patch below which *might* work. I have not
tested it very much. You ought to regenerate the configure files after
applying this patch but in case this is a problem for you I am attaching
a compressed diff for them as well.
Results of testting:
checking for an known getop
While working on another issue I noticed a typo and some dead code.
This patch fixes those issues.
-Fred
2005-03-24 Fred Fish <[EMAIL PROTECTED]>
* dwarf2.c (struct comp_unit): Fix typo.
(scan_unit_for_functions): Remove unused local variable "name"
and dead code that
Hi Vladimir,
ian> Sorry, this patch is not OK. It will just lead us down the path of
ian> increasing the #ifdef over and over again. The question here is why
ian> HAVE_DECL_GETOPT is not defined.
ian>
ian> Looking at gcc, I would say that the binutils configure.in file should
ian> do the equivale
Well that should be long enough. I think that the patch is OK, but there
are two problems:
1. The patch should be submitted to the gcc project, since they control
the getopt.h header file.
2. You need to include a ChangeLog entry with your patch.
Patch rejected by libiberty maintainer (
Well that should be long enough. I think that the patch is OK, but
there are two problems:
1. The patch should be submitted to the gcc project, since they
control the getopt.h header file.
2. You need to include a ChangeLog entry with your patch.
I send proposed patch with ChangeLog entr
12 matches
Mail list logo
