Re: libgcc/sync.c vs. cgraph alias tracking
> Jan Hubicka writes:
> >> MIPS16 code can't do atomic operations directly, so it calls into
> >> out-of-line
> >> versions that are compiled as -mno-mips16. These out-of-line versions use
> >> the same open-coded implementation as you'd get in normal -mno-mips16 code.
> >
> > Hmm, and I assume you don't want to use target attribute for this...
>
> You mean so that any code that calls a __sync function would become
> -mno-mips16? Yeah, we want to avoid that. There are specific mips16
> and nomips16 attributes for setting the ISA mode, but the idea is to
> allow functions to be compiled as -mips16 wherever possible.
>
> >> This is done by libgcc/sync.c, which contains code like like:
> >>
> >> static void
> >> sync_synchronize (void)
> >> {
> >> __sync_synchronize ();
> >> }
> >> typeof (sync_synchronize) __sync_synchronize
> >> __attribute__((alias ("sync_synchronize")));
> >>
> >> With the recent cgraph changes, we follow the alias and the function
> >> becomes
> >> an infinite loop.
> >
> > Yep, here you define two symbols of same assembler name, so they will be
> > identified.
> > How exactly the code worked before?
>
> You'd know better than me how it worked before. :-) All I know is
> that until the recent changes, the gimple optimisers didn't redirect
> __sync_synchronize() to sync_synchronize(), so the original call
> survived until expand and so got replaced with a sync instruction.
> This is in contrast to:
>
> void
> __sync_synchronize (void)
> {
> __sync_synchronize ();
> }
>
> which the compiler always treated as an infinite loop. That's why
> the alias indirect was used.
I see, the previous implementation tricked the one-declaration rule by
introducing two names. What made the difference is that the second name
is expanded as builtin...
So you don't have __bulitin_sync_synchronize() at hand that would be translated
to __sync_synchronize libcall?
>
> Thanks,
> Richard
cortex-m3(gcc.4.6.3)
Dear Group,
The below asm is generated for target cortex-m3 (gcc-4.6.3)
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push {r3, r4, r5, lr}
bl vAlgTNoOptimize
movs r0, #170
bl vFnCall
bl vAlgTOptimize
ldr r4, .L22
add r5, r4, #88
.L20:
ldr r1, [r4, #4]!
movs r0, #2
ldr r2, [r4, #88]
bl ucCheckResult
cbnz r0, .L19
cmp r4, r5
bne .L20
ldr r0, .L22+4
ldr r1, .L22+8
pop {r3, r4, r5, lr}
b printf
.L19:
ldr r0, .L22+12
ldr r1, .L22+8
pop {r3, r4, r5, lr}
b printf
>From the main prologue ,we can see that the instruction " push
{r3, r4, r5, lr} " ,where we are saving r3-r5 and lr and restoring the
same in the epilogue,saving r4,r5 (callee save ) and
lr(call_used_register) make sense here w.r.t ARM EABI,But i didn't get
why we save r3 here and where we don't use r3 in the function ???.
Or i'm missing something here ???
Thanks
~Umesh
Re: cortex-m3(gcc.4.6.3)
> On Oct 9, 2013, at 2:14 AM, Umesh Kalappa wrote:
>
> Dear Group,
>
> The below asm is generated for target cortex-m3 (gcc-4.6.3)
>
> main:
>@ args = 0, pretend = 0, frame = 0
>@ frame_needed = 0, uses_anonymous_args = 0
>push {r3, r4, r5, lr}
>bl vAlgTNoOptimize
>movs r0, #170
>bl vFnCall
>bl vAlgTOptimize
>ldr r4, .L22
>add r5, r4, #88
> .L20:
>ldr r1, [r4, #4]!
>movs r0, #2
>ldr r2, [r4, #88]
>bl ucCheckResult
>cbnz r0, .L19
>cmp r4, r5
>bne .L20
>ldr r0, .L22+4
>ldr r1, .L22+8
>pop {r3, r4, r5, lr}
>b printf
> .L19:
>ldr r0, .L22+12
>ldr r1, .L22+8
>pop {r3, r4, r5, lr}
>b printf
>
> From the main prologue ,we can see that the instruction " push
> {r3, r4, r5, lr} " ,where we are saving r3-r5 and lr and restoring the
> same in the epilogue,saving r4,r5 (callee save ) and
> lr(call_used_register) make sense here w.r.t ARM EABI,But i didn't get
> why we save r3 here and where we don't use r3 in the function ???.
>
> Or i'm missing something here ???
Yes stack alignment.
>
> Thanks
> ~Umesh
Re: libgcc/sync.c vs. cgraph alias tracking
On Wed, Oct 09, 2013 at 10:59:35AM +0200, Jan Hubicka wrote:
> I see, the previous implementation tricked the one-declaration rule by
> introducing two names. What made the difference is that the second name
> is expanded as builtin...
>
> So you don't have __bulitin_sync_synchronize() at hand that would be
> translated
> to __sync_synchronize libcall?
No, __sync_* and __atomic_* builtins don't use __builtin_ prefix.
Would asm redirect instead of alias work?
void sync_synchronize (void) __asm ("__sync_synchronize");
or is that going to break too (or might break soon)?
Jakub
GCC retargeting
Dear Group , We are re-targeting the GCC to the CISC target ,which has the eight 8-bit registers and same register set can used as pair register for 16 bit computation i.e four 16-bits . Any one in the group tell me ,How do i model this requirement using the target macros like REG_CLASS_NAMES and REG_CLASS_CONTENTS etc. Thanks ~Umesh
Re: libgcc/sync.c vs. cgraph alias tracking
Jakub Jelinek writes:
> On Wed, Oct 09, 2013 at 10:59:35AM +0200, Jan Hubicka wrote:
>> I see, the previous implementation tricked the one-declaration rule by
>> introducing two names. What made the difference is that the second name
>> is expanded as builtin...
>>
>> So you don't have __bulitin_sync_synchronize() at hand that would be
>> translated
>> to __sync_synchronize libcall?
>
> No, __sync_* and __atomic_* builtins don't use __builtin_ prefix.
>
> Would asm redirect instead of alias work?
> void sync_synchronize (void) __asm ("__sync_synchronize");
> or is that going to break too (or might break soon)?
Thanks, that works. I'll change libgcc/sync.c and test.
Would it be OK to add a test like the below so that it gets some
non-MIPS coverage? I checked that it passes on x86_64-linux-gnu
with {,-m32,-m32/-march=i386}.
Richard
gcc/testsuite/
* gcc.target/i386/asm-rename-1.c: New file.
Index: gcc/testsuite/gcc.target/i386/asm-rename-1.c
===
--- /dev/null 2013-10-09 10:21:20.288269980 +0100
+++ gcc/testsuite/gcc.target/i386/asm-rename-1.c2013-10-09
10:49:02.941805955 +0100
@@ -0,0 +1,8 @@
+void sync_synchronize (void) __asm ("__sync_synchronize");
+void sync_synchronize (void)
+{
+ __sync_synchronize ();
+}
+/* { dg-final { scan-assembler "__sync_synchronize" } } */
+/* { dg-final { scan-assembler "\t(lock;|mfence)" } } */
+/* { dg-final { scan-assembler-not "\tcall" } } */
Re: libgcc/sync.c vs. cgraph alias tracking
On Wed, Oct 09, 2013 at 10:56:33AM +0100, Richard Sandiford wrote:
> gcc/testsuite/
> * gcc.target/i386/asm-rename-1.c: New file.
>
> Index: gcc/testsuite/gcc.target/i386/asm-rename-1.c
> ===
> --- /dev/null 2013-10-09 10:21:20.288269980 +0100
> +++ gcc/testsuite/gcc.target/i386/asm-rename-1.c 2013-10-09
> 10:49:02.941805955 +0100
> @@ -0,0 +1,8 @@
> +void sync_synchronize (void) __asm ("__sync_synchronize");
> +void sync_synchronize (void)
> +{
> + __sync_synchronize ();
> +}
> +/* { dg-final { scan-assembler "__sync_synchronize" } } */
> +/* { dg-final { scan-assembler "\t(lock;|mfence)" } } */
AFAIK {%;} doesn't always expand to ;, for -masm=intel or
if HAVE_AS_IX86_REP_LOCK_PREFIX then it will expand without.
So perhaps you should take the ; out. And I'll leave to Honza
to comment whether he doesn't intend to make the above not to
work soon.
BTW, not sure if the __asm string doesn't need some adjustment if
__USER_LABEL_PREFIX__ is not empty.
> +/* { dg-final { scan-assembler-not "\tcall" } } */
Jakub
GCC 4.8.2 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.8.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009 and shortly its mirrors. It has been generated from SVN revision 203308. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.8.2 in the middle of next week. Jakub
GCC 4.8.2 Status Report (2013-10-09)
Status == The GCC 4.8.2-rc1 release candidate has been released. The branch is frozen now, all changes require release manager approval until the final release of GCC 4.8.2 which should happen roughly one week after the release candidate. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 67 + 2 P3 61 + 19 --- --- Total 128 + 21 Previous Report === http://gcc.gnu.org/ml/gcc/2013-05/msg00307.html The next report will be sent by me again.
Re: GCC retargeting
On Oct 9, 2013, at 5:24 AM, Umesh Kalappa wrote: > Dear Group , > > We are re-targeting the GCC to the CISC target ,which has the eight > 8-bit registers and same register set can used as pair register for > 16 bit computation i.e four 16-bits . > > Any one in the group tell me ,How do i model this requirement using > the target macros like > > REG_CLASS_NAMES and REG_CLASS_CONTENTS etc. > > > Thanks > ~Umesh There probably are other examples, but one you could look at is pdp11, which has 16 bit registers that also can be used in even/odd pairs for 32 bit operations. paul
X86-64 System V Application Binary Interface group announcement
Hi, www.x86-64.org was down for several months and it is up now, but not in its full capacity. I created a x86-64 psABI group: https://groups.google.com/forum/?hl=en#!forum/x86-64-abi so that there is a mailing list we can discuss x86-64 psABI related issues. Thanks. -- H.J.
RE: Cilk Library
Dear Jeff and the rest of Steering committee members, Thank you very much for approving the license terms of the Cilk Library. I couldn't attach the zipped copy of the patch due to its size, so here is a link to the Cilk library patch that can be applied to the trunk: (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sharing). Is it OK for trunk? Here are the ChangeLog entries: ChangeLog: 2013-10-09 Balaji V. Iyer * Makefile.def: Add libcilkrts to target_modules. Make libcilkrts depend on libstdc++ and libgcc. * configure.ac: Added libcilkrts to target binaries. * configure: Likewise. * Makefile.in: Added libcilkrts related fields to support building it. libcilkrts/ChangeLog: 2013-10-09 Balaji V. Iyer * libcilkrts/Makefile.am: New file. Libcilkrts version 3613. * libcilkrts/Makefile.in: Likewise. * libcilkrts/README: Likewise. * libcilkrts/aclocal.m4: Likewise. * libcilkrts/configure: Likewise. * libcilkrts/configure.ac: Likewise. * libcilkrts/include/cilk/cilk.h: Likewise. * libcilkrts/include/cilk/cilk_api.h: Likewise. * libcilkrts/include/cilk/cilk_api_linux.h: Likewise. * libcilkrts/include/cilk/cilk_stub.h: Likewise. * libcilkrts/include/cilk/cilk_undocumented.h: Likewise. * libcilkrts/include/cilk/common.h: Likewise. * libcilkrts/include/cilk/holder.h: Likewise. * libcilkrts/include/cilk/hyperobject_base.h: Likewise. * libcilkrts/include/cilk/metaprogramming.h: Likewise. * libcilkrts/include/cilk/reducer.h: Likewise. * libcilkrts/include/cilk/reducer_file.h: Likewise. * libcilkrts/include/cilk/reducer_list.h: Likewise. * libcilkrts/include/cilk/reducer_max.h: Likewise. * libcilkrts/include/cilk/reducer_min.h: Likewise. * libcilkrts/include/cilk/reducer_min_max.h: Likewise. * libcilkrts/include/cilk/reducer_opadd.h: Likewise. * libcilkrts/include/cilk/reducer_opand.h: Likewise. * libcilkrts/include/cilk/reducer_opmul.h: Likewise. * libcilkrts/include/cilk/reducer_opor.h: Likewise. * libcilkrts/include/cilk/reducer_opxor.h: Likewise. * libcilkrts/include/cilk/reducer_ostream.h: Likewise. * libcilkrts/include/cilk/reducer_string.h: Likewise. * libcilkrts/include/cilktools/cilkscreen.h: Likewise. * libcilkrts/include/cilktools/cilkview.h: Likewise. * libcilkrts/include/cilktools/fake_mutex.h: Likewise. * libcilkrts/include/cilktools/lock_guard.h: Likewise. * libcilkrts/include/internal/abi.h: Likewise. * libcilkrts/include/internal/cilk_fake.h: Likewise. * libcilkrts/include/internal/cilk_version.h: Likewise. * libcilkrts/include/internal/inspector-abi.h: Likewise. * libcilkrts/include/internal/metacall.h: Likewise. * libcilkrts/include/internal/rev.mk: Likewise. * libcilkrts/mk/cilk-version.mk: Likewise. * libcilkrts/mk/unix-common.mk: Likewise. * libcilkrts/runtime/acknowledgements.dox: Likewise. * libcilkrts/runtime/bug.cpp: Likewise. * libcilkrts/runtime/bug.h: Likewise. * libcilkrts/runtime/c_reducers.c: Likewise. * libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise. * libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise. * libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise. * libcilkrts/runtime/cilk-abi-vla.c: Likewise. * libcilkrts/runtime/cilk-abi.c: Likewise. * libcilkrts/runtime/cilk-ittnotify.h: Likewise. * libcilkrts/runtime/cilk-tbb-interop.h: Likewise. * libcilkrts/runtime/cilk_api.c: Likewise. * libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise. * libcilkrts/runtime/cilk_fiber-unix.h: Likewise. * libcilkrts/runtime/cilk_fiber.cpp: Likewise. * libcilkrts/runtime/cilk_fiber.h: Likewise. * libcilkrts/runtime/cilk_malloc.c: Likewise. * libcilkrts/runtime/cilk_malloc.h: Likewise. * libcilkrts/runtime/component.h: Likewise. * libcilkrts/runtime/doxygen-layout.xml: Likewise. * libcilkrts/runtime/doxygen.cfg: Likewise. * libcilkrts/runtime/except-gcc.cpp: Likewise. * libcilkrts/runtime/except-gcc.h: Likewise. * libcilkrts/runtime/except.h: Likewise. * libcilkrts/runtime/frame_malloc.c: Likewise. * libcilkrts/runtime/frame_malloc.h: Likewise. * libcilkrts/runtime/full_frame.c: Likewise. * libcilkrts/runtime/full_frame.h: Likewise. * libcilkrts/runtime/global_state.cpp: Likewise. * libcilkrts/runtime/global_state.h: Likewise. * libcilkrts/runtime/jmpbuf.c: Likewise. * libcilkrts/runtime/jmpbuf.h: Likewise. * libcilkrts/runtime/local_state.c: Likewise. * libcilkrts/runtime/local_state.h: Likewise. * libcilkrts/runtime/metacal
RE: Cilk Library
Some observations: * Various source files include x86-specific asm. At some point it will need restructuring so that the architecture-specific parts go in architecture-specific files and it's clear what to do to add support for another architecture. * Given that architecture dependency, the toplevel configure.ac needs to take care to disable building this library for unsupported targets. See what's done for libatomic, libitm, libsanitizer or libvtv, using a configure.tgt file in the library's subdirectory to avoid toplevel configure.ac needing to hardcode such target information directly. * In fact, I think the dependency is not just x86, but hosted POSIX system on x86, given the use of -lpthread -ldl. * You have: +GENERAL_FLAGS += -DBUILD_USER=\"$(USER)\" +GENERAL_FLAGS += -DBUILD_HOST=\"`hostname`\" Please remove this, and the uses of __DATE__ and __TIME__. It is becoming increasingly clear that it would be desirable for free software binaries, including complete GNU/Linux distributions, to be bit-for-bit reproducible from sources when bootstrapped by different people on different systems from different starting points. So nothing should end up in the binaries that would depend unnecessarily on the build system. * You have, in libcilkrts/mk/unix-common.mk, code setting a variable OUT, determining (I think) the configuration in some way, based on running "uname". This is obviously inappropriate for cross-compilation. You need to ensure that when building in the GCC source tree, this variable (if it matters at all) is set based on the host triplet for which the library is configured (host for a target library = target for toplevel configure). Or, if this file is unused (and I don't see anything obvious using it), it could just be removed from the source tree in GCC. * Could you confirm whether the library uses symbol versioning, defaults to hidden visibility or otherwise ensures that only those symbols specifically intended to be part of the public interface get exported from the shared library? If not, it would be a very good idea to make it do so (see libgomp for example). -- Joseph S. Myers jos...@codesourcery.com
libgccjit.so: an embeddable JIT-compilation library based on GCC
As some may have seen I posted a patch to gcc-patches that adds a way to embed GCC as a shared library, for Just-In-Time compilation, for use e.g. by bytecode interpreters: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html I've gone ahead and created a git-only on the mirror as branch "dmalcolm/jit": http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/dmalcolm/jit and I've been committing patches there. I plan to post some of the patches for review against trunk (am bootstrapping/regtesting them as I write). An example of using it can be seen at: https://github.com/davidmalcolm/jittest/blob/master/README.rst Some questions for the GCC steering committee: * is this JIT work a good thing? (I think so, obviously, but can I go ahead and e.g. add it to the wiki under "Current Projects"?) * do you like the general approach? I'm choosing to deliberately hide as much as possible of GCC's insides, trying to hit the use-case of being able to add a JIT to an existing interpreted language whilst avoiding scope-creep. * it seems worthwhile to have a place to discuss the JIT work: both in terms of development *of* the branch, and for developers wishing to *use* the library in their own projects. I strongly feel that the only good APIs are those that are developed alongside *users* of those APIs (this forces one to smooth off the rough edges from the API). Hence is it reasonable to have a "j...@gcc.gnu.org" mailing list for this? * what would need to happen to get this into 4.9? or is this an unrealistic goal? * should I be posting my patches to "dmalcolm/jit" to the gcc-patches mailing list as I commit them? Also, should this be just a "jit" branch? (i.e. not under "dmalcolm/") Thanks Dave
