[Bug gas/3990] New: [PATCH] IA64 gas DV: reports spurious WAW hazards
Here's a small patch to fix a spurious WAW hazard reported on this
for p2:
{.mmi
cmp.eq.or.andcm p3,p2=r49,r39
cmp.ne.and p2,p1=r49,r36
nop.i 0 ;;
}
Index: tc-ia64.c
===
RCS file: /cvs/src/src/gas/config/tc-ia64.c,v
retrieving revision 1.190
diff -b -u -r1.190 tc-ia64.c
--- tc-ia64.c 1 Feb 2007 14:12:18 - 1.190
+++ tc-ia64.c 3 Feb 2007 10:06:06 -
@@ -9001,14 +9001,18 @@
int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P;
int or_andcm = strstr (idesc->name, "or.andcm") != NULL;
int and_orcm = strstr (idesc->name, "and.orcm") != NULL;
+ int and = strstr (idesc->name, "and") != NULL;
+ int or = strstr (idesc->name, "or") != NULL;
if ((idesc->operands[0] == IA64_OPND_P1
|| idesc->operands[0] == IA64_OPND_P2)
&& p1 >= 1 && p1 < 16)
{
specs[count] = tmpl;
- specs[count].cmp_type =
- (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE));
+ specs[count].cmp_type = (or_andcm ? CMP_OR :
+ (and_orcm ? CMP_AND :
+(and ? CMP_AND :
+ (or ? CMP_OR : CMP_NONE;
specs[count++].index = p1;
}
if ((idesc->operands[1] == IA64_OPND_P1
@@ -9016,8 +9020,10 @@
&& p2 >= 1 && p2 < 16)
{
specs[count] = tmpl;
- specs[count].cmp_type =
- (or_andcm ? CMP_AND : (and_orcm ? CMP_OR : CMP_NONE));
+ specs[count].cmp_type = (or_andcm ? CMP_AND :
+ (and_orcm ? CMP_OR :
+(and ? CMP_AND :
+ (or ? CMP_OR : CMP_NONE;
specs[count++].index = p2;
}
}
@@ -9123,14 +9129,18 @@
int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P;
int or_andcm = strstr (idesc->name, "or.andcm") != NULL;
int and_orcm = strstr (idesc->name, "and.orcm") != NULL;
+ int and = strstr (idesc->name, "and") != NULL;
+ int or = strstr (idesc->name, "or") != NULL;
if ((idesc->operands[0] == IA64_OPND_P1
|| idesc->operands[0] == IA64_OPND_P2)
&& p1 >= 16 && p1 < 63)
{
specs[count] = tmpl;
- specs[count].cmp_type =
- (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE));
+ specs[count].cmp_type = (or_andcm ? CMP_OR :
+ (and_orcm ? CMP_AND :
+(and ? CMP_AND :
+ (or ? CMP_OR : CMP_NONE;
specs[count++].index = p1;
}
if ((idesc->operands[1] == IA64_OPND_P1
@@ -9138,8 +9148,10 @@
&& p2 >= 16 && p2 < 63)
{
specs[count] = tmpl;
- specs[count].cmp_type =
- (or_andcm ? CMP_AND : (and_orcm ? CMP_OR : CMP_NONE));
+ specs[count].cmp_type = (or_andcm ? CMP_AND :
+ (and_orcm ? CMP_OR :
+(and ? CMP_AND :
+ (or ? CMP_OR : CMP_NONE;
specs[count++].index = p2;
}
}
@@ -9587,22 +9599,28 @@
int p2 = CURR_SLOT.opnd[1].X_add_number - REG_P;
int or_andcm = strstr (idesc->name, "or.andcm") != NULL;
int and_orcm = strstr (idesc->name, "and.orcm") != NULL;
+ int and = strstr (idesc->name, "and") != NULL;
+ int or = strstr (idesc->name, "or") != NULL;
if (p1 == 63
&& (idesc->operands[0] == IA64_OPND_P1
|| idesc->operands[0] == IA64_OPND_P2))
{
specs[count] = tmpl;
- specs[count++].cmp_type =
- (or_andcm ? CMP_OR : (and_orcm ? CMP_AND : CMP_NONE));
+ specs[count].cmp_type = (or_andcm ? CMP_OR :
+ (and_orcm ? CMP_AND :
+(and ? CMP_AND :
+ (or ? CMP_OR : CMP_NONE;
}
if (p2 == 63
&& (idesc->operands[1] == IA64_OPND_P1
|| idesc->operands[1] == IA64_OPND_P2))
{
[Bug gas/3993] New: Assembler accepts extra qualifer in Intel syntax
[EMAIL PROTECTED] intel]$ cat foo.s .intel_syntax noprefix mov rax,qword ptr rax [EMAIL PROTECTED] intel]$ gcc -c foo.s [EMAIL PROTECTED] intel]$ objdump -d foo.o foo.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 48 89 c0mov%rax,%rax Is "qword ptr" valid here? -- Summary: Assembler accepts extra qualifer in Intel syntax Product: binutils Version: 2.18 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: hjl at lucon dot org CC: bug-binutils at gnu dot org,jbeulich at novell dot com GCC target triplet: x86_64-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From hjl at lucon dot org 2007-02-07 14:24 --- Also this one: [EMAIL PROTECTED] intel]$ cat bar.s .intel_syntax noprefix mov %rax, rax [EMAIL PROTECTED] intel]$ gcc -c bar.s [EMAIL PROTECTED] intel]$ objdump -d bar.o bar.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 48 89 c0mov%rax,%rax Should assembler accept "%rax" when there is ".intel_syntax noprefix"? -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From jbeulich at novell dot com 2007-02-07 15:03 --- The first case must be accepted, since masm allows this as long as the pointer width specified matches the register width. masm fails when the latter isn't true, while gas emit a warning only. I don't think that's a problem, though. As to whether the noprefix handling is correct the way it currently is - that doesn't depend on Intel mode only, as the register parsing logic is, afaics, the same in both AT&T and Intel modes. Generally I would say current behavior is wrong at least in Intel mode, but someone with more profound AT&T syntax knowledge would need to clarify whether this should be changed for both modes or just for Intel. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From hjl at lucon dot org 2007-02-07 15:10 --- I would vote for not allowing any prefix when noprefix is specified for both Intel and AT&T modes. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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: arm-elf-as 2.16.1 always gives "relocation truncated to fit: R_ARM_PC24"
On Tue, Feb 06, 2007 at 04:04:02PM -0800, Bryce Schober wrote: > Not sure if this is true on latest binutils, but arm-elf-as 2.16.1 always > gives: I doubt that error is coming from the same place. Please file a bug report with a complete assemblable and linkable testcase that shows the error, including command lines. -- Daniel Jacobowitz CodeSourcery ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From hjl at lucon dot org 2007-02-07 17:19 --- I saw [EMAIL PROTECTED] invalid]$ cat foo.s .intel_syntax noprefix mov rax,oword ptr rbx [EMAIL PROTECTED] invalid]$ gcc -c foo.s [EMAIL PROTECTED] invalid]$ objdump -d foo.o foo.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 48 89 d8mov%rbx,%rax Is this expected? -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From amodra at bigpond dot net dot au 2007-02-07 17:29 --- Regarding comment #2 and #3, I think the purpose of noprefix is to *allow* source to omit the "%" prefix, ie. make the prefix optional. I don't think it should force you to omit the prefix, especially in AT&T mode. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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/3993] Assembler accepts extra qualifer in Intel syntax
--- Additional Comments From hjl at lucon dot org 2007-02-07 17:51 --- (In reply to comment #5) > Regarding comment #2 and #3, I think the purpose of noprefix is to *allow* > source to omit the "%" prefix, ie. make the prefix optional. I don't think it > should force you to omit the prefix, especially in AT&T mode. I don't mind keeping the current behavior for "noprefix". But we should update manual and add a couple testcases for both Intel and AT&T modes. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3993 --- 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 ld/3998] New: Weird path problem
Hi, I am trying to build coss-compiler, and I get following message: 'ld: cannot find /some/absolute/path/lib/libcrt.so inside /some/absolute/path' I found that this message is printed by ldfile_open_file function (ld/ldfile.c, line 417). Could you look on this issue? I suspect that I am doing sth wrongly with my compilation, but I don't know what should I change :) -- Summary: Weird path problem Product: binutils Version: 2.16 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: bugzilla at poradnik-webmastera dot com CC: bug-binutils at gnu dot org GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: i686-pc-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=3998 --- 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
