[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 SK santoshkumar.a at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #12 from SK santoshkumar.a at gmail dot com 2011-12-26 14:08:05 UTC --- Invalid.
[Bug c/50186] New: junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186
Bug #: 50186
Summary: junk at end of line: `1
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: santoshkuma...@gmail.com
All,
I have built a Toolchain for powerpc 476 in little endian mode.
With below:
binutils-2.21
gcc-4.6.1
glibc-2.13
linux-2.6.39
While comiling linux kernel 2.6.39 with
make ARCH=powerpc CROSS_COMPILE=powerpc-476-linux-gnu-
I see the below error.
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
SKIPPED include/generated/compile.h
CC init/do_mounts_rd.o
{standard input}: Assembler messages:
{standard input}:665: Error: junk at end of line: `1'
If any one has faced this issue please let me know what needs to be done.
Thanks
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #1 from SK santoshkumar.a at gmail dot com 2011-08-25 10:33:22 UTC --- Created attachment 25099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25099 build errors build errors
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #3 from SK santoshkumar.a at gmail dot com 2011-08-25 11:53:59 UTC --- Created attachment 25101 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25101 do_mounts_rd.s assembly file
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #2 from SK santoshkumar.a at gmail dot com 2011-08-25 11:53:17 UTC --- Created attachment 25100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25100 intermidate file intermidate file do_mounts_rd.i
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #4 from SK santoshkumar.a at gmail dot com 2011-08-25 11:59:11 UTC --- Created attachment 25102 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25102 cross compile script cross compile script
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #5 from SK santoshkumar.a at gmail dot com 2011-08-25 12:02:09 UTC --- at line 665 in do_mounts_rd.s mfcr 27,1 is a wrong instruction generated. As per Power ISA™ Version 2.05 mfcr take only one argument i.e mfcr RT. Let me know if i have to change any components used.
[Bug c/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 --- Comment #9 from SK santoshkumar.a at gmail dot com 2011-08-25 15:01:26 UTC --- Just for checking i changed the instruction in .s file from mfcr 27,1 to mfcr 27 and used the assembler to generate the binary there was no error reported. Now i am confused whether it is fault with assembler if with compiler. Please suggest where to look into.
[Bug target/50186] junk at end of line: `1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50186 SK santoshkumar.a at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from SK santoshkumar.a at gmail dot com 2011-08-26 13:43:30 UTC --- (In reply to comment #9) Just for checking i changed the instruction in .s file from mfcr 27,1 to mfcr 27 and used the assembler to generate the binary there was no error reported. Now i am confused whether it is fault with assembler if with compiler. Please suggest where to look into. issue is resolved i had to use -mno-mfcrf. -mmfcrf was enabled by default and this generates mfcr with two args. Thanks
[Bug c/50705] New: Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 Bug #: 50705 Summary: Wrong assembly generated in ppc 476 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: santoshkuma...@gmail.com I built a GCC Little-Endian 32-bit Cross compiler for powerpc 476 with the below components. 1.GCC 4.6.1 2.GLIBC 2.13 3.BINUTILS 2.21.53 4.Linux kernel headers 2.6.39 I used the same to build Linux kernel 2.6.39.4 in Little-Endian 32-bit. The kernel while coming up in start_kernel does calls as shown below start_kernel -- pidhash_init -- alloc_large_system_hash. kernel/pid.c 1) When pidinit_hash with HASH_EARLY HASH_SMALL args call alloc_large_system_hash here at pid.c, line::5362 the if condition fails. Condition:: HASH_EARLY 0x1 HASH_SMALL 0x2 flags value is 0x3 therefore the below if is expected to pass, but it fails. if(flags HASH_EARLY) reason: it generates rlwinm r0,r7,1,31,31 with r7 = 3 this instruction results in 0 and jumps to 0x70305bf4 as shown in without_print/objdump_without_print file at line:: 980046. After i added a prink before if the condition passed as the assembly generated is different as as shown in with_print/objdump_print file at line:: 980044. I have encountered another bitwise and failing in arch/powerpc/mm/mmu_context_nohash.c at mmu_has_feature(MMU_FTR_47x)
[Bug c/50705] Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 SK santoshkumar.a at gmail dot com changed: What|Removed |Added URL||https://rapidshare.com/file ||s/1485249627/gcc_bug_ppc_47 ||6.rar --- Comment #1 from SK santoshkumar.a at gmail dot com 2011-10-12 16:36:26 UTC --- Attachment:: https://rapidshare.com/files/1485249627/gcc_bug_ppc_476.rar;
[Bug target/50705] Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 --- Comment #3 from SK santoshkumar.a at gmail dot com 2011-10-13 05:41:20 UTC --- Created attachment 25481 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25481 system map, objdump, source code As the earlier file was 14MB with large objdump.I have copied the code around the area of problem. In the objdump search for page_alloc.c:5362 where this issue is seen. You can compare the same with the code in the attachment.
[Bug target/50705] Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 --- Comment #4 from SK santoshkumar.a at gmail dot com 2011-10-13 10:46:32 UTC --- Please download the full dump(14MB)from ftp0.lsil.com by following below commands login: user: ftp, password: anonymous, cd pub binary # get gcc_bug_ppc_476_mini.zip (NOTE:: ls/dir not supported) quit
[Bug target/50705] Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 --- Comment #5 from SK santoshkumar.a at gmail dot com 2011-10-14 03:29:48 UTC --- Wrong assembly being is generated in most of the bitwise and's conditions that have pass are failing and those that have to fail are passing.
[Bug target/50705] Wrong assembly generated in ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
--- Comment #8 from SK santoshkumar.a at gmail dot com 2011-10-14 04:48:13
UTC ---
Yes the HW engine that is present on the controller works in Little endian
therefore we need linux to work in LE on PPC.
I changed
Binutils
GLIBC
GCC
GCC Changes::
Binutils
gas/configure:
case $endian in
big) ;;
little) ;;
GLIBC
GCC
1)
gcc/config/rs6000/sysv4.h
#defineTARGET_DEFAULT (MASK_POWERPC | MASK_NEW_MNEMONICS |
MASK_LITTLE_ENDIAN)
ASM_SPEC
2)
mcall-gnu :-mlittle;\
++ mcall-i960-old:-mlittle}\
++-mlittle
3)
#define CC1_ENDIAN_DEFAULT_SPEC %(cc1_endian_little)
#defineMULTILIB_DEFAULTS { mlittle, mcall-sysv }
4)
CC1_SPEC
mcall-gnu : -mlittle %(cc1_endian_little); \
+ mcall-i960-old: -mlittle %(cc1_endian_little); \
+ : %(cc1_endian_default)} \
5)
LINK_SPEC:
added -EL at the end
LINK_TARGET_SPEC
added --oformat elf32-powerpcle at end
[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
--- Comment #9 from SK santoshkumar.a at gmail dot com 2011-10-14 16:26:38
UTC ---
Below is another scenario::
test_bit called with args
PG_slab = 7;
page-flags = 0xc0;
test_bit(PG_slab, page-flags) returns value 0. This is used by PageSlab in
linux kernel.
/**
* test_bit - Determine whether a bit is set
* @nr: bit number to test
* @addr: Address to start counting from
*/
static inline int test_bit(int nr, const volatile unsigned long *addr)
{
return 1UL (addr[BIT_WORD(nr)] (nr (BITS_PER_LONG-1)));
}
but if i modify the return as
return (addr[BIT_WORD(nr)] (nr (BITS_PER_LONG-1)));
the results are as expected, which i dont understand.
Also in all the scenarios that i reported earlier the bitwise AND is in between
a variable and a constants.
[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705 --- Comment #10 from SK santoshkumar.a at gmail dot com 2011-10-17 17:16:36 UTC --- Please let me know if I have to add or remove any GCC options while configuring it or while compiling Linux. Any comment which can help me move further will be helpful.
[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
--- Comment #11 from SK santoshkumar.a at gmail dot com 2011-10-19 14:22:16
UTC ---
FILE::
/mm/page_alloc.c:5363
flags - 0x3
HASH_EARLY - 0x1
CODE::
if (flags HASH_EARLY)
Assembly:
70307c44: fe 0f e0 54 rlwinm r0,r7,1,31,31
r7 = 0x3 = 0011 (bits 0...31. So, bit 30 ==
1 and bit 31 == 1).
HASH_EARLY should ideally be seen by the compiler as
0001 (bits 0...31. So, bit 31 == 1).
So, if in Little Endian mode, then in PowerPC terms the above if is testing
bit 31 of the flags field.
In which case, the compiler should be generating assembly as: rlwinm
r0,r7,0,31,31
However, it appears the compiler sees HASH_EARLY as 1000
(bits 0...31. So, bit 0 == 1).
So, if in Little Endian mode, then in PowerPC terms the above if is testing
bit 0 of the flags field.
In which case, the compiler is generating assembly as: rlwinm r0,r7,1,31,31
CODE::
MMU_FTR_TYPE_47x has 0x40
cur_cpu_spec-mmu_features - 0x140040
static inline int mmu_has_feature(unsigned long feature) {
return(cur_cpu_spec-mmu_features feature); }
Assembly:
andis. r10,r11,512
What the above assembly instruction does is basically this: r10 = r11 (512
16) = r11 0x0200 (i.e. bit 6 is getting tested).
Now, where does 512 come from? Let's look at MMU_FTR_TYPE_47x:
MMU_FTR_TYPE_47x should ideally be seen by the compiler as
0100 (bits 0...31. So, bit 25 == 1).
So, if in Little Endian mode, then in PowerPC terms the above operation is
testing bit 25 of the cur_cpu_spec-mmu_features field.
In which case, the compiler should be generating assembly as: andi. r10,r11,64
However, it appears the compiler sees MMU_FTR_TYPE_47x as 0010
(bits 0...31. So, bit 6 == 1).
So, if in Little Endian mode, then in PowerPC terms the above is testing
bit 6 of the cur_cpu_spec-mmu_features field.
In which case, the compiler is generating assembly as: andis. r10,r11,512
++
Therefore it appears that constants are being interrupted wrongly i.e as a
mirror image.
Few Observations:
1) After I compile a small piece of code and run file binary the output
is
ELF 32-bit LSB executable, PowerPC, Versoin 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.39, not stripped
2) __LITTLE_ENDIAN is defined.
3) Though the above 2 are true the machine is still working in Big Endian.
confirmed by writing 1 into b and reading a[0]. which reads 0.
union endian{
unsigned int b;
unsigned char a[4] ;
}
++
