Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
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 entry to gcc-patches maillist and libiberty maintainers ( http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02286.html ) Vladimir ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
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 ( http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02291.html ): 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 equivalent of gcc_AC_CHECK_DECLS(getopt) to get ian> HAVE_DECL_GETOPT defined appropriately. I am not gury in configure magic and then I can't provide acceptable patch. Sorry. Vladimir ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
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 equivalent of gcc_AC_CHECK_DECLS(getopt) to get ian> HAVE_DECL_GETOPT defined appropriately. I am not gury in configure magic and then I can't provide acceptable patch. *sigh* I hate configure file hacking. 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. Cheers Nick Index: binutils/configure.in === RCS file: /cvs/src/src/binutils/configure.in,v retrieving revision 1.48 diff -c -3 -p -r1.48 configure.in *** binutils/configure.in 16 Mar 2005 17:18:15 - 1.48 --- binutils/configure.in 24 Mar 2005 21:04:39 - *** if test $bu_cv_decl_time_t_types_h = yes *** 180,185 --- 180,195 [Is the type time_t defined in ?]) fi + AC_MSG_CHECKING(for an known getopt prototype in unistd.h) + AC_CACHE_VAL(bu_cv_decl_getopt_unistd_h, + [AC_TRY_COMPILE([#include ], [extern int getopt (int, char *const*, const char *);], + bu_cv_decl_getopt_unistd_h=yes, bu_cv_decl_getopt_unistd_h=no)]) + AC_MSG_RESULT($bu_cv_decl_getopt_unistd_h) + if test $bu_cv_decl_getopt_unistd_h = yes; then + AC_DEFINE([HAVE_DECL_GETOPT], 1, + [Is the prototype for getopt in in the expected format?]) + fi + # Under Next 3.2 apparently does not define struct utimbuf # by default. AC_MSG_CHECKING([for utime.h]) Index: binutils/config.in === RCS file: /cvs/src/src/binutils/config.in,v retrieving revision 1.16 diff -c -3 -p -r1.16 config.in *** binutils/config.in 13 Oct 2004 14:33:50 - 1.16 --- binutils/config.in 24 Mar 2005 21:04:39 - *** *** 178,183 --- 178,186 /* Is the type time_t defined in ? */ #undef HAVE_TIME_T_IN_TYPES_H + /* Is the prototype for getopt in in the expected format? */ + #undef HAVE_DECL_GETOPT + /* Does define struct utimbuf? */ #undef HAVE_GOOD_UTIME_H binutils.config.patch.supplimental.bz2 Description: BZip2 compressed data ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Fix typo in dwarf2.c and remove some dead code
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 set it.
Index: dwarf2.c
===
RCS file: /cvs/src/src/bfd/dwarf2.c,v
retrieving revision 1.63
diff -c -p -r1.63 dwarf2.c
*** dwarf2.c17 Mar 2005 08:24:28 - 1.63
--- dwarf2.c24 Mar 2005 20:32:54 -
*** struct comp_unit
*** 132,138
/* Keep the bdf convenient (for memory allocation). */
bfd *abfd;
! /* The lowest and higest addresses contained in this compilation
unit as specified in the compilation unit header. */
struct arange arange;
--- 132,138
/* Keep the bdf convenient (for memory allocation). */
bfd *abfd;
! /* The lowest and highest addresses contained in this compilation
unit as specified in the compilation unit header. */
struct arange arange;
*** scan_unit_for_functions (struct comp_uni
*** 1326,1332
struct abbrev_info *abbrev;
struct attribute attr;
struct funcinfo *func;
- char *name = 0;
abbrev_number = read_unsigned_leb128 (abfd, info_ptr, &bytes_read);
info_ptr += bytes_read;
--- 1326,1331
*** scan_unit_for_functions (struct comp_uni
*** 1370,1378
break;
case DW_AT_name:
-
- name = attr.u.str;
-
/* Prefer DW_AT_MIPS_linkage_name over DW_AT_name. */
if (func->name == NULL)
func->name = attr.u.str;
--- 1369,1374
*** scan_unit_for_functions (struct comp_uni
*** 1394,1411
break;
}
}
- else
- {
- switch (attr.name)
- {
- case DW_AT_name:
- name = attr.u.str;
- break;
-
- default:
- break;
- }
- }
}
if (abbrev->has_children)
--- 1390,1395
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
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 getopt prototype in unistd.h... yes But terminated with message: In file included from /usr/home/wanderer/pkg/build/binutils/src/src/binutils/addr2line.c:35: /usr/home/wanderer/pkg/build/binutils/src/src/binutils/../include/getopt.h:116: warning: function declaration isn't a prototype gmake[3]: *** [addr2line.o] Error 1 gmake[3]: Leaving directory `/usr/home/wanderer/pkg/build/binutils/obj/binutils' obj/binutils/config.h have: /* Is the prototype for getopt in in the expected format? */ #define HAVE_DECL_GETOPT 1 And then configure part work fine at FreeBSD but binutils/config.h not #included in addr2line.c Vladimir ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- 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 this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] New: gas should avoid F-unit NOPs (and B-unit probably, too)
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 unless they're really needed. Similarly, using B-unit NOPs is probably not a great idea for McKinley-derived cores: certain templates with B unit instructions cause split-issue and the BBB template in particular causes a branch-prediction anomaly (the first two branches are predicated based on the slot 0 hints. I'll attach a patch which appears to fix this problem. If it looks OK, please check it in. Note: the new policy won't be optimal for Itanium (Merced) chips. I don't think anyone will care. -- Summary: gas should avoid F-unit NOPs (and B-unit probably, too) Product: binutils Version: 2.17 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: davidm at hpl dot hp dot com CC: bug-binutils at gnu dot org,hjl at lucon dot org GCC build triplet: ia64-linux GCC host triplet: ia64-linux GCC target triplet: ia64-linux http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From hjl at lucon dot org 2005-03-25 00:37 --- Jim, is the proposed patch OK? -- What|Removed |Added CC||wilson at specifixinc dot ||com http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- 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/show_bug.cgi?id=803 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- 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/show_bug.cgi?id=803 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/803] 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: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. Such as a -mcpu=itanium1 switch? I suppose that could work. Or we could try fixing the testsuite to use explicit bundles, so that it stops changing every time the bundling heuristics change. Or we could just say to heck with it and regenerate all of the .d files. Or we could try to make the .d files be bundling independent. Try looking at some of the ones that Jan Beulich has added. He uses "." to match bundles when nops are involved, so that it is bundling independent. See for instance align.d. However, before we make a decision, I really think that someone should run the gas testsuite first, and check to see whether we have a problem, and if so, how big of a problem it is. There is no sense to trying to write a complicated solution if we only have a simple problem. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- 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: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. Such as a -mcpu=itanium1 switch? I suppose that could work. Or we could try fixing the testsuite to use explicit bundles, so that it stops changing every time the bundling heuristics change. Or we could just say to heck with it and regenerate all of the .d files. Or we could try to make the .d files be bundling independent. Try looking at some of the ones that Jan Beulich has added. He uses "." to match bundles when nops are involved, so that it is bundling independent. See for instance align.d. However, before we make a decision, I really think that someone should run the gas testsuite first, and check to see whether we have a problem, and if so, how big of a problem it is. There is no sense to trying to write a complicated solution if we only have a simple problem. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
