[Bug libgcc/56300] New: Add __sync_fetch_and_add_8 and other 8-byte atomic functions to 32-bit MIPS targets

2013-02-12 Thread chaoyingfu at gcc dot gnu.org 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300



 Bug #: 56300

   Summary: Add __sync_fetch_and_add_8 and other 8-byte atomic

functions to 32-bit MIPS targets

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgcc

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: chaoyin...@gcc.gnu.org





There is no hardware support for 8 bytes atomic operations on 32-bit MIPS

targets.  Unfortunately, programmers still want to use them.  Ex: please check

this webkit bug: https://bugs.webkit.org/show_bug.cgi?id=106739 and the

following example.



Ex:

fu@debian6:~/dev/test$ cat sync.c

long long K;

void main()

{

   __sync_fetch_and_add(K, 1);

}



fu@debian6:~/dev/test$ gcc -o sync sync.c

/tmp/ccUoSg9M.o: In function `main':

sync.c:(.text+0x28): undefined reference to `__sync_fetch_and_add_8'

collect2: ld returned 1 exit status



That will be great, if we can add missing atomic functions (via pthread

implementation or other methods) to libgcc for 32-bit MIPS targets.



Thanks a lot!

[Bug libgcc/56300] Add __sync_fetch_and_add_8 and other 8-byte atomic functions to 32-bit MIPS targets

2013-02-12 Thread chaoyingfu at gcc dot gnu.org 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56300



--- Comment #2 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot 
gnu.org 2013-02-12 22:21:09 UTC ---

(In reply to comment #1)

 Use libatomic in 4.8 to fix this.



Good to know this.  Thanks!

[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions

2012-08-30 Thread chaoyingfu at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369

--- Comment #3 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot 
gnu.org 2012-08-31 00:38:39 UTC ---
The fall-through path of this jump has a barrier (resulted from
__builtin_unreachable), and the target of this jump has a return instruction.

The algorithm in reorg.c may be more conservative to keep this jump for code
correctness.  Just another solution to this issue.  Thanks!

[Bug rtl-optimization/54369] New: Delayed-branch pass in reorg.c removes too many instructions

2012-08-24 Thread chaoyingfu at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369

 Bug #: 54369
   Summary: Delayed-branch pass in reorg.c removes too many
instructions
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chaoyin...@gcc.gnu.org


Created attachment 28079
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28079
A simple test for an issue in reorg.c

Please check this example when using GCC 4.6 for mips-linux-gnu.
(I think the issue is in GCC 4.7 and later as well.  But due to the basic block
ordering, I cannot reproduce this issue.)
Ex:
# /gcc46branch/build-mips/gcc/cc1plus -quiet Bug.i -o Bug.s -mips32r2 -O2
# cat Bug.s
_Z3bugP9ValueRTRK:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
lw  $2,0($4) -
lw  $2,0($2) - (NO RETURN IN THIS FUNCTION.)
.setmacro
.setreorder
.end_Z3bugP9ValueRTRK
.cfi_endproc
$LFE13:
.size   _Z3bugP9ValueRTRK, .-_Z3bugP9ValueRTRK
.ident  GCC: (GNU) 4.6.4 20120823 (prerelease) [gcc-4_6-branch
revision
 190613]

  The delayed-branch pass in reorg.c is too aggressive, such that a return
instruction and others are removed.  From debugging code in reorg.c:
delete_jump() - delete_computation() - delete_related_insn(), I think we
should not use delete_related_insn() that removes branches and all the
following instructions.  A simple fix may be just using delete_insn() in
delete_computation().
Ex: # svn diff reorg.c
Index: reorg.c
===
--- reorg.c (revision 190636)
+++ reorg.c (working copy)
@@ -3298,7 +3298,7 @@
   delete_prior_computation (note, insn);
 }

-  delete_related_insns (insn);
+  delete_insn (insn);
 }

 /* If all INSN does is set the pc, delete it,

Ex: (Bug.s after this fix.)
# cat Bug.s
_Z3bugP9ValueRTRK:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
lw  $2,0($4)
lw  $2,0($2)
$L4:
j   $31  - OK
srl $2,$2,8  - OK

.setmacro
.setreorder
.end_Z3bugP9ValueRTRK
.cfi_endproc
$LFE13:
.size   _Z3bugP9ValueRTRK, .-_Z3bugP9ValueRTRK
.ident  GCC: (GNU) 4.6.4 20120823 (prerelease) [gcc-4_6-branch
revision
 190613]

Thanks!

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread chaoyingfu at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209

--- Comment #2 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot 
gnu.org 2012-08-09 17:23:40 UTC ---
MIPS provides a version of link.h in Android NDK as follows:
Ex:
From android-ndk-r8b/platforms/android-9/arch-mips/usr/include# cat link.h
/*
   For building unwind-dw2-fde-glibc.c for MIPS frame unwinding,
   we need to have link.h that defines struct dl_phdr_info,
   ELFW(type), and dl_iterate_phdr().
*/

#include sys/types.h
#include elf.h

struct dl_phdr_info
{
Elf32_Addr dlpi_addr;
const char *dlpi_name;
const Elf32_Phdr *dlpi_phdr;
Elf32_Half dlpi_phnum;
};

#if _MIPS_SZPTR == 32
#define ElfW(type)  Elf32_##type
#elif _MIPS_SZPTR == 64
#define ElfW(type)  Elf64_##type
#endif

int
dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void *data),
void *data);

  For x86, you can create link.h as well.  Or we can guard this define with
MIPS targets.
Ex:
#if !defined(inhibit_libc)  defined(HAVE_LD_EH_FRAME_HDR) \
 defined(__BIONIC__)  defined(__mips__)
# define USE_PT_GNU_EH_FRAME
#endif

  Thanks!

[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86

2012-08-09 Thread chaoyingfu at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209

--- Comment #4 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot 
gnu.org 2012-08-09 18:45:41 UTC ---
(In reply to comment #3)
 (In reply to comment #2)
  MIPS provides a version of link.h in Android NDK as follows:
  Ex:
  From android-ndk-r8b/platforms/android-9/arch-mips/usr/include# cat link.h
  /*
 For building unwind-dw2-fde-glibc.c for MIPS frame unwinding,
 we need to have link.h that defines struct dl_phdr_info,
 ELFW(type), and dl_iterate_phdr().
  */
  
  #include sys/types.h
  #include elf.h
  
  struct dl_phdr_info
  {
  Elf32_Addr dlpi_addr;
  const char *dlpi_name;
  const Elf32_Phdr *dlpi_phdr;
  Elf32_Half dlpi_phnum;
  };
  
  #if _MIPS_SZPTR == 32
  #define ElfW(type)  Elf32_##type
  #elif _MIPS_SZPTR == 64
  #define ElfW(type)  Elf64_##type
  #endif
  
  int
  dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void 
  *data),
  void *data);
  
For x86, you can create link.h as well.  Or we can guard this define with
  MIPS targets.
 
 Why isn't link.h in AOSP Bionic C library?

  ARM doesn't use eh_frame, so there is no need to create link.h at the
beginning for the Android project, I guess.  For MIPS, we create our own link.h
to work with eh_frame unwinding.  Thanks!