Re: Help understanding gcc alias analysis
On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough wrote:
> Richard Guenther wrote:
>>
>> On Sun, Jan 11, 2009 at 7:59 PM, Raoul Gough
>> wrote:
>>
>
> [snip]
>>>
>>> I guess the situation is more complicated in C++, which has explicit
>>> destructors. Consider the following example, which is getting closer to
>>> the
>>> problem that originally got me interested in this subject:
>>>
>>> void** global_free_list = 0;
>>>
>>> inline void operator delete(void* p2) throw()
>>> {
>>> // Save "next" pointer in re-used client storage. TODO - check for NULL
>>> *static_cast(p2) = global_free_list;
>>> global_free_list = static_cast(p2);
>>> }
>>>
>>> double foo(double* p1)
>>> {
>>> double result = *p1;
>>> delete p1;
>>> return result;
>>> }
>>>
>>> Now, after inlining, this example looks very similar to my original one,
>>> except we have pointers of type double* and void** sharing the same
>>> storage
>>> space instead of int* and double*. Note - we can easily ensure that the
>>> corresponding operator new() always allocates storage suitably sized and
>>> aligned for a void*.
>>>
>>
>> This is also invalid. You have to use placement new to change the dynamic
>> type of memory.
>>
>>
>
> Yes, I guess that makes sense. I've modified the example like this:
>
> #include
>
> void** global_free_list = 0;
>
> inline void operator delete(void* p2) throw()
> {
> // Save "next" pointer in re-used client storage
> new (p2) (void *) (global_free_list);
> global_free_list = static_cast(p2);
> }
>
> double foo(double* p1)
> {
> double result = *p1;
> delete p1;
> return result;
> }
>
>
> I've included the complete alias debug output below. This now includes
> global_free_list in the may-alias lists, which is interesting. Also there is
> a NULL-pointer check and branch, but I assume another optimization phases
> could, under some circumstances, remove this. For example, if foo() started
> with assert(p1) then this NULL pointer check would be redundant. That would
> leave it with more or less the same code tree as before, aside from the
> differences in the aliasing information.
>
> So how is this example looking now? Does the alias analysis mean that g++
> will never reorder the read and write via p1 and p2?
Yes, as that would now be an invalid thing to do. Note that for C
there is no way to do "placement new", but the memory model of C
only has static typing, not the notion of a dynamic type. Which is
why some people (including me) say you cannot do a C conforming
implementation of malloc that ever re-uses memory.
Richard.
RE: Feature request concerning opcodes in the function prolog
Here's some code attached that actually works, but is far from perfect. The 'msvc_prologue' attribute is limited to 32 bit. None of the applications that try to place hooks are ported to Win64 yet, so it is impossible to tell what they'll need. Besides, maybe I am lucky that when they appear I can tell their autors to think about Wine. The first problem I (still) have is passing the msvc_prologue attribute around. I abused some other code to do that. How does the attribute handling work, and what would the prefered way be? The 2nd thing I have to figure out is how and when I have to set REG_FRAME_RELATED_EXPR. The msvc_prologue + frame_pointer_needed + !stack_realignment_needed case produces the best possible code. The fp setup from msvc_prologue is used for its purpose. The msvc_prologue + !frame_pointer_needed case could be optimized, as you said. However, that changes all the stack frame offsets and sizes, and I do not quite understand all the code I have to modify for that. I think this should be a separate patch, although arguably be ready before msvc_prologue is added. I personally don't care too much about this combination of parameters(Wine won't need/use it), so this optimization would get lost otherwise. With stack_realignment_needed frame_pointer_needed is on as well, and this code is created(copypasted together by hand, somehow the stack alignment attribute doesn't do anything on my Linux box) movl.s %edi, %edi pushl %ebp movl.s %esp, %ebp pop%ebp lea0x4(%esp),%ecx and$0xfff0,%esp pushl -0x4(%ecx) push %ebp mov%esp,%ebp If we try to get rid of the pop-push-mov, the following things change: *) The value of %ebp *) The location of the pushed ebp on the stack *) The alignment of %esp after the whole procedure(its alignment+4 before, and the +4 is lost afterwards) Now the question is, what parts are important for the stack realignment attribute? I think we can't correct point 2. If we correct (1) and (3) this has to be done with less than 3-4 extra instructions if it should be worth the effort. I don't see any code right now that would accomplish that, but maybe I'm missing something. msvc.diff Description: Binary data
Re: Feature request concerning opcodes in the function prolog
> movl.s %edi, %edi > pushl %ebp > movl.s %esp, %ebp Have you thought about making .s an assembler command-line flag, so that this flag could be passed automatically by the compiler under mingw? Paolo
RE: Feature request concerning opcodes in the function prolog
> Have you thought about making .s an assembler command-line flag, so > that > this flag could be passed automatically by the compiler under mingw? Yes. For my purposes it is not really suitable, because we have to make sure that the push %ebp and mov %esp, %ebp are there, no matter what the compiler arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't enough, and while I'm at it I can add the .s to the insns anyway. (see the archives for more details) However, an assembler command line flag and gcc setting it for msvc_prologue aren't mutually exclusive, so if mingw needs it it could be done anyway.
Re: Feature request concerning opcodes in the function prolog
> For my purposes it is not really suitable, because we have to make sure that > the push %ebp and mov %esp, %ebp are there, no matter what the compiler > arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't > enough, and while I'm at it I can add the .s to the insns anyway. (see the > archives for more details) Yes, I mentioned the commandline option because you talked about 31-c0 vs. 33-c0 for xor %eax, %eax somewhere else in the thread. Paolo
RE: Feature request concerning opcodes in the function prolog
Quoting Stefan Dösinger : Here's some code attached that actually works, but is far from perfect. The 'msvc_prologue' attribute is limited to 32 bit. None of the applications that try to place hooks are ported to Win64 yet, so it is impossible to tell what they'll need. Besides, maybe I am lucky that when they appear I can tell their autors to think about Wine. The first problem I (still) have is passing the msvc_prologue attribute around. I abused some other code to do that. How does the attribute handling work, and what would the prefered way be? Well, you could query the attribute every time you need it, but if that would cause performance issues or significant code bloat, caching information computed from the attributes in the machine specific struct is fine. If you only need a single bit and accesses are not too frequent / often, you can also consider making the machine struct member a char or bitfield, so that it can be effectively stored together with other small struct members. The 2nd thing I have to figure out is how and when I have to set REG_FRAME_RELATED_EXPR. It's when there is some operation affecting cfi which is not expressed (in simple enough terms for dwarf2out.c to grok it) in the rtl instruction pattern. Since your nop doesn't affect the call frame or registers, no call frame information needs to be emitted for it. You'll have to also change the third instruction in your 'magic' sequence so that it is or contains an unspec, to prevent it from going walkabout when optimizations like instruction scheduling is performed. If you make it a parallel where the actual oprtation is paired with an empty unspec, no REG_FRAME_RELATED_EXPR is needed. If the actual operation is hidden in the RTL, however, you have to add it in a REG_FRAME_RELATED_EXPR. The latter alternative is more complicated. However, there is a benefit to choosing this: win the stack realign or !frame_pointer_needed cases, the (early) move of esp to ebp is not really supposed to establish a frame pointer, and thus you then don't want any cfi information emitted for it. Thus, you can then simply leave out the REG_FRAME_RELATED_EXPR note. The msvc_prologue + frame_pointer_needed + !stack_realignment_needed case produces the best possible code. The fp setup from msvc_prologue is used for its purpose. The msvc_prologue + !frame_pointer_needed case could be optimized, as you said. However, that changes all the stack frame offsets and sizes, and I do not quite understand all the code I have to modify for that. I think this should be a separate patch, although arguably be ready before msvc_prologue is added. I personally don't care too much about this combination of parameters(Wine won't need/use it), so this optimization would get lost otherwise. The code needed shouldn't be large, but if nobody would use it, it wouldn't be tested either, so even if you got it right initially it would be prone to bitrot. So if you'd need extra code for it but nobody would use it, just add a comment in the code and the option documentation that this is an optimization that could be added / is not implemented. With stack_realignment_needed frame_pointer_needed is on as well, and this code is created(copypasted together by hand, somehow the stack alignment attribute doesn't do anything on my Linux box) movl.s %edi, %edi pushl %ebp movl.s %esp, %ebp pop%ebp lea0x4(%esp),%ecx and$0xfff0,%esp pushl -0x4(%ecx) push %ebp mov%esp,%ebp If we try to get rid of the pop-push-mov, the following things change: *) The value of %ebp Yes, you have to re-do the move from esp to ebp after stack realignment. *) The location of the pushed ebp on the stack That should be fine if you make your prologue expect it there. *) The alignment of %esp after the whole procedure(its alignment+4 before, and the +4 is lost afterwards) Alignment +0 is actually better - best would be to make the alignment offset so that no alignment padding is done for the first highly-aligned stack slot, but that would be really a general stack size optimization, i.e. it goes beyond the scope of the current problem, and I don't think you want to go into this right now. Basically, what we do with saving ebp before stack realignment is that we remove the ebp stack slot from the call frame proper. So you just need to say that the size of the saved registers - and thus the total frame size - is 4 bytes less than if the ebp slot was included in the frame. Make sure that the argument pointer still has the right value, and everything should be fine.
Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Hi everyone, HEAD isn't building for me right now. Since I haven't tried building graphite-enabled GCC before, I may be doing something wrong, so I figured I'd ask questions before opening any PR. (The actual questions are numbered for those who want to skip the detail.) I followed the instructions at http://gcc.gnu.org/wiki/Graphite. I'm using ppl-0.10 and a git clone of cloog from 2008-12-17. I configured PPL: with options \"'-v' '--disable-shared' '--enable-static' '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4' '--with-gnu-ld'\" and I configured CLOOG: with options \"'-v' '--disable-shared' '--enable-static' '--with-ppl=/opt/gcc-tools' '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4' '--with-gnu-ld'\" and part of the problem, at least, arises because I'm using static rather than shared libs; explained later. I'm building native GCC HEAD on i686-pc-cygwin. The three problems show up when linking cc1 at the end of each stage. Firstly, there's a multiply-defined symbol: -- ranlib libbackend.a gcc-4 -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o cygwin2.o msformat-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib -lmpfr -lgmp -L/opt/gcc-tools/lib -lcloog -L/opt/gcc-tools/lib -lppl_c -lppl -lgmpxx /opt/gcc-tools/lib/libcloog.a(domain.o): In function `debug_value': /gnu/gcc/prereq/cloog/source/ppl/domain.c:3579: multiple definition of `_debug_value' libbackend.a(graphite.o):/gnu/gcc/gcc/gcc/graphite.c:68: first defined here -- Q1) Sure enough there are two identical copies of this (trivial) debugging dump function. I commented out the copy in graphite.c and got past the problem, but this makes me wonder if there's some version skew between cloog and gcc? After that, there follows about 26000 lines of 'undefined reference to' linker error messages. These fall into two groups, missing _gmpz_* functions and missing libstdc++ functions. The missing gmpz functions are a consequence of static linking. The definition of BACKENDLIBS appers to be in the wrong order: from gcc/Makefile.in, -- BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) -- Q2) Since CLOOG and PPL call GMP functions, GMPLIBS should be at the end, shouldn't it? This doesn't cause any problem on platforms where CLOOG and PPL are dynamically linked, it just leaves some unresolved references to be filled in at runtime by ld.so, but when statically linking it fails. The third part of this problem has me really scratching my head. There are undefined references to operators new and delete, cxa_begin/end_catch, even iostream stuff. Q3) Why is there C++ in my libppl? Have I done something wrong to get it there in the first place, or is it supposed to work somehow? At the end of stage 1, I can work around the problem by manually running the final link command, but using the (native compiler's) g++ driver instead of the plain gcc driver, or by manually adding -lstdc++. But I can't do anything like that to get past the link failure at the end of stage 2; we're not using the native compiler any more but the stage 1 compiler and so we've only got a crude xgcc that doesn't understand "-x c++", and of course target libstdc++ hasn't been built yet. Something's really wrong here - I can't understand why there's C++ involved or how it could work. Maybe the default configure options of PPL have changed to include some C++ interface that wasn't built by default at the time the wiki page was written? Anyway, TIA for any enlightenment anyone can provide. I could file PRs or patches for the first two bugs if desired, but the third part has me totally confused, I don't know what to do with it. cheers, DaveK
marking ppc440 tests as unsupported
Hi, With the help of Janis, the ppc405 tests can now detect when the scan assembler won't pass. I moved on to do the same with the ppc440 tests and noticed that there is no cpp predefine to know when you are compiled for a ppc440. $ powerpc-rtems4.10-gcc -mcpu=440 -E - -dM 440 $ powerpc-rtems4.10-gcc -mcpu=405 -E - -dM 405 $ diff 405 440 34d33 < #define __PPC405__ 1 It is easy enough to add a cpp predefine but is this the right thing to do? Is there any alternative? The unfortunate thing is that I think these tests are really ensuring that MASK_DLMZB is used as expected. If this is right, then shouldn't there be a cpp predefine similar to __NO_LWSYNC__ for dlmzb? And the tests use that rather than testing for a specific CPU model? And then should there be tests for the other CPU models which have this feature to ensure the -mcpu=[405fp|440fp|464|464fp] also do the right thing? I don't see why 2 of the 6 CPU models have this test. I am happy to take care of this if I just know the right path. Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: marking ppc440 tests as unsupported
On Mon, Jan 12, 2009 at 10:10:18AM -0600, Joel Sherrill wrote: > The unfortunate thing is that I think these > tests are really ensuring that MASK_DLMZB is > used as expected. If this is right, then > shouldn't there be a cpp predefine similar > to __NO_LWSYNC__ for dlmzb? And the tests use > that rather than testing for a specific CPU model? This doesn't answer what you should do now, but I can explain the precedent: the only reason there is a predefine for 405 is so that the atomicity routines in libstdc++ know to avoid lwsync. -- Daniel Jacobowitz CodeSourcery
Re: marking ppc440 tests as unsupported
On Mon, 12 Jan 2009, Joel Sherrill wrote: > The unfortunate thing is that I think these > tests are really ensuring that MASK_DLMZB is > used as expected. If this is right, then > shouldn't there be a cpp predefine similar > to __NO_LWSYNC__ for dlmzb? And the tests use > that rather than testing for a specific CPU model? Exactly one of the tests (for each processor) is testing for dlmzb; the others are testing for half-word multiply instructions. The tests are that the compiler, generating code for those processors, with the options people are expected to use for those processors, generates the instructions. The tests are likely very sensitive to cost tuning. > And then should there be tests for the other > CPU models which have this feature to ensure > the -mcpu=[405fp|440fp|464|464fp] also do the > right thing? I don't see why 2 of the 6 CPU > models have this test. It happens that all those processors use ppc405_cost or ppc440_cost, so the most obvious variation is already covered. -- Joseph S. Myers jos...@codesourcery.com
Re: Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Hello Dave, Thanks for testing Graphite on i686-pc-cygwin. On Mon, Jan 12, 2009 at 9:52 AM, Dave Korn wrote: >Hi everyone, > > HEAD isn't building for me right now. Since I haven't tried building > graphite-enabled GCC before, I may be doing something wrong, so I figured I'd > ask questions before opening any PR. (The actual questions are numbered for > those who want to skip the detail.) > > I followed the instructions at http://gcc.gnu.org/wiki/Graphite. I'm using > ppl-0.10 and a git clone of cloog from 2008-12-17. I configured PPL: > > with options \"'-v' '--disable-shared' '--enable-static' > '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4' '--with-gnu-ld'\" > > and I configured CLOOG: > > with options \"'-v' '--disable-shared' '--enable-static' > '--with-ppl=/opt/gcc-tools' '--prefix=/opt/gcc-tools' 'CC=gcc-4' 'CXX=g++-4' > '--with-gnu-ld'\" > > and part of the problem, at least, arises because I'm using static rather than > shared libs; explained later. I'm building native GCC HEAD on i686-pc-cygwin. > > The three problems show up when linking cc1 at the end of each stage. > Firstly, there's a multiply-defined symbol: > > -- > ranlib libbackend.a > gcc-4 -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition > -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o > cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o > c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o > c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o > c-parser.o i386-c.o cygwin2.o msformat-c.o c-gimplify.o tree-mudflap.o > c-pretty-print.o c-omp.o dummy-checksum.o \ > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -liconv > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/lib -L/usr/lib > -lmpfr -lgmp -L/opt/gcc-tools/lib -lcloog -L/opt/gcc-tools/lib -lppl_c -lppl > -lgmpxx > /opt/gcc-tools/lib/libcloog.a(domain.o): In function `debug_value': > /gnu/gcc/prereq/cloog/source/ppl/domain.c:3579: multiple definition of > `_debug_value' > libbackend.a(graphite.o):/gnu/gcc/gcc/gcc/graphite.c:68: first defined here > -- > > Q1) Sure enough there are two identical copies of this (trivial) debugging > dump function. I commented out the copy in graphite.c and got past the > problem, but this makes me wonder if there's some version skew between cloog > and gcc? > > After that, there follows about 26000 lines of 'undefined reference to' > linker error messages. These fall into two groups, missing _gmpz_* functions > and missing libstdc++ functions. > > The missing gmpz functions are a consequence of static linking. The > definition of BACKENDLIBS appers to be in the wrong order: from > gcc/Makefile.in, > > -- > BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) > -- > > Q2) Since CLOOG and PPL call GMP functions, GMPLIBS should be at the end, > shouldn't it? > > This doesn't cause any problem on platforms where CLOOG and PPL are > dynamically linked, it just leaves some unresolved references to be filled in > at runtime by ld.so, but when statically linking it fails. > > The third part of this problem has me really scratching my head. There are > undefined references to operators new and delete, cxa_begin/end_catch, even > iostream stuff. > > Q3) Why is there C++ in my libppl? Have I done something wrong to get it > there in the first place, or is it supposed to work somehow? > > At the end of stage 1, I can work around the problem by manually running > the final link command, but using the (native compiler's) g++ driver instead > of the plain gcc driver, or by manually adding -lstdc++. But I can't do > anything like that to get past the link failure at the end of stage 2; we're > not using the native compiler any more but the stage 1 compiler and so we've > only got a crude xgcc that doesn't understand "-x c++", and of course target > libstdc++ hasn't been built yet. Something's really wrong here - I can't > understand why there's C++ involved or how it could work. Maybe the default > configure options of PPL have changed to include some C++ interface that > wasn't built by default at the time the wiki page was written? > > Anyway, TIA for any enlightenment anyone can provide. I could file PRs or > patches for the first two bugs if desired, I would highly appreciate this. > but the third part has me totally confused, I don't know what to do > with it. I'm forwarding this third question to the PPL folks, hoping that they already dealt with similar cases and probably al
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Sebastian Pop wrote: Q3) Why is there C++ in my libppl? Have I done something wrong to get it there in the first place, or is it supposed to work somehow? At the end of stage 1, I can work around the problem by manually running the final link command, but using the (native compiler's) g++ driver instead of the plain gcc driver, or by manually adding -lstdc++. But I can't do anything like that to get past the link failure at the end of stage 2; we're not using the native compiler any more but the stage 1 compiler and so we've only got a crude xgcc that doesn't understand "-x c++", and of course target libstdc++ hasn't been built yet. Something's really wrong here - I can't understand why there's C++ involved or how it could work. Maybe the default configure options of PPL have changed to include some C++ interface that wasn't built by default at the time the wiki page was written? Anyway, TIA for any enlightenment anyone can provide. I could file PRs or patches for the first two bugs if desired, I would highly appreciate this. but the third part has me totally confused, I don't know what to do with it. I'm forwarding this third question to the PPL folks, hoping that they already dealt with similar cases and probably already have a solution. Hi there, I am not sure I understand the question (and I am not familiar with Cygwin). The answer to the question "Why is there C++ in my libppl" is that libppl is written in C++. The C interface to the PPL, libppl_c, is also written in C++. Your description of the problem confuses me, as it seems to be system-independent; however, I have no problems bootstrapping HEAD on my GNU/Linux system. What am I missing? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: marking ppc440 tests as unsupported
Joseph S. Myers wrote: On Mon, 12 Jan 2009, Joel Sherrill wrote: The unfortunate thing is that I think these tests are really ensuring that MASK_DLMZB is used as expected. If this is right, then shouldn't there be a cpp predefine similar to __NO_LWSYNC__ for dlmzb? And the tests use that rather than testing for a specific CPU model? Exactly one of the tests (for each processor) is testing for dlmzb; the others are testing for half-word multiply instructions. The tests are that the compiler, generating code for those processors, with the options people are expected to use for those processors, generates the instructions. The tests are likely very sensitive to cost tuning. Then should the half-word multiply capability also have a predefine to indicate it is available? My understanding so far is that when you need to figure out if your test target platform supports a particular feature so it can be reported as unsupported, you have options like this: if a scan-assembler test - use a cpp predefine and effective target test if a run time test - if possible, use dynamic probe for feature to be tested - else use cpp predefined and report unsupported Since these are scan-assembler, I only know one option and am looking for the right solution. Do we need to define cpp predefines to indicate that dmlzb and half-world multiply are enabled? This way the knowledge would be available independent of the CPU model. That is similar to LWSYNC. And then should there be tests for the other CPU models which have this feature to ensure the -mcpu=[405fp|440fp|464|464fp] also do the right thing? I don't see why 2 of the 6 CPU models have this test. It happens that all those processors use ppc405_cost or ppc440_cost, so the most obvious variation is already covered. OK. I'm just a bit anal retentive when it comes to testing and don't mind adding cases for coverage. :) --joel
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
On Mon, 12 Jan 2009, Roberto Bagnara wrote: > I am not sure I understand the question (and I am not familiar with Cygwin). > The answer to the question "Why is there C++ in my libppl" is that libppl > is written in C++. The C interface to the PPL, libppl_c, is also written > in C++. Your description of the problem confuses me, as it seems to be > system-independent; however, I have no problems bootstrapping HEAD on my > GNU/Linux system. What am I missing? Try bootstrapping with only static versions of all the relevant libraries (GMP including C++ interface, PPL, libstdc++ etc.). I believe that is the issue here - all libraries must be listed in the right order when linking GCC, including -lstdc++, rather than relying on shared library dependencies. -- Joseph S. Myers jos...@codesourcery.com
Re: Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Sebastian Pop wrote: Hi Seb, >> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or >> patches for the first two bugs if desired, > > I would highly appreciate this. Righto, will get cracking. >> but the third part has me totally confused, I don't know what to do >> with it. > > I'm forwarding this third question to the PPL folks, hoping that they > already dealt with similar cases and probably already have a solution. I see Roberto downthread, will reply. cheers, DaveK
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Joseph S. Myers wrote: > On Mon, 12 Jan 2009, Roberto Bagnara wrote: > >> I am not sure I understand the question (and I am not familiar with Cygwin). >> The answer to the question "Why is there C++ in my libppl" is that libppl >> is written in C++. The C interface to the PPL, libppl_c, is also written >> in C++. Your description of the problem confuses me, as it seems to be >> system-independent; however, I have no problems bootstrapping HEAD on my >> GNU/Linux system. What am I missing? > > Try bootstrapping with only static versions of all the relevant libraries > (GMP including C++ interface, PPL, libstdc++ etc.). I believe that is the > issue here - all libraries must be listed in the right order when linking > GCC, including -lstdc++, rather than relying on shared library > dependencies. > Yep. It particularly shows up on win32 because i) all references have to be resolved at final link time in an executable - perhaps by reference to a DLL, but they can't just be left dangling to be filled in at runtime by the loader as they can in ELF formats - and ii) we tend to do static linking on win32, so where the order of libs is wrong on the command-line we get unresolved references (which then cause link failure, rather than being resolved at runtime). The big problem however is libstdc++ vs. bootstrap. If PPL links against libstdc++, and is part of the core C compiler, then we have to have libstdc++ available during the early part of each stage when we build the core compiler - but the only libstdc++ available is the system's one. Roberto, what does ldd show on the various cc1 binaries in the different stage directories of your most recent bootstrap? I'm guessing you'll see that the stage 2 cc1 is linked against the system libstdc++ rather than the newly-bootstrapped one. cheers, DaveK
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
On Mon, Jan 12, 2009 at 2:25 PM, Dave Korn wrote: > Yep. It particularly shows up on win32 because i) all references have to > be resolved at final link time in an executable - perhaps by reference to a > DLL, but they can't just be left dangling to be filled in at runtime by the > loader as they can in ELF formats - and ii) we tend to do static linking on > win32, so where the order of libs is wrong on the command-line we get > unresolved references (which then cause link failure, rather than being > resolved at runtime). > > The big problem however is libstdc++ vs. bootstrap. If PPL links against > libstdc++, and is part of the core C compiler, then we have to have libstdc++ > available during the early part of each stage when we build the core compiler > - but the only libstdc++ available is the system's one. > > Roberto, what does ldd show on the various cc1 binaries in the different > stage directories of your most recent bootstrap? I'm guessing you'll see that > the stage 2 cc1 is linked against the system libstdc++ rather than the > newly-bootstrapped one. I encountered this on AIX as well prior to recompiling GMP as a shared library. libppl references libstdc++ and libgmpxx. libgmpxx references libstdc++. libcloog and cc1 do not reference libstdc++. David
Re: [PPL-devel] Graphite/Cloog/PPL problems on Cygwin, HEAD broken maybe?
Dave Korn wrote: Roberto, what does ldd show on the various cc1 binaries in the different stage directories of your most recent bootstrap? I'm guessing you'll see that the stage 2 cc1 is linked against the system libstdc++ rather than the newly-bootstrapped one. $ find . -name cc1 ./prev-gcc/cc1 ./gcc/cc1 ./stage1-gcc/cc1 $ find . -name cc1 | xargs ldd ./prev-gcc/cc1: linux-vdso.so.1 => (0x7fffb37ff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x02027000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x015e7000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x0278a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0188) /lib64/ld-linux-x86-64.so.2 (0x003e3380) ./gcc/cc1: linux-vdso.so.1 => (0x7fff4e3fe000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x02fbc000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x064f1000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x06d01000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0110b000) /lib64/ld-linux-x86-64.so.2 (0x003e3380) ./stage1-gcc/cc1: linux-vdso.so.1 => (0x7fff7bdff000) libmpfr.so.1 => /usr/lib64/libmpfr.so.1 (0x003e3400) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x003e3b40) libppl_c.so.2 => /usr/local/lib64/libppl_c.so.2 (0x7f9f736e1000) libppl.so.7 => /usr/local/lib64/libppl.so.7 (0x0011) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x7f9f734dc000) libc.so.6 => /lib64/libc.so.6 (0x003e33c0) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003e3de0) libm.so.6 => /lib64/libm.so.6 (0x7f9f73256000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f9f7303f000) /lib64/ld-linux-x86-64.so.2 (0x003e3380) This is from HEAD of 20 minutes ago. Notice that I had to work around the multiple definition of debug_value() you already reported. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Help understanding gcc alias analysis
Richard Guenther wrote:
On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough wrote:
Richard Guenther wrote:
[snip]
This is also invalid. You have to use placement new to change the dynamic
type of memory.
Yes, I guess that makes sense. I've modified the example like this:
#include
void** global_free_list = 0;
inline void operator delete(void* p2) throw()
{
// Save "next" pointer in re-used client storage
new (p2) (void *) (global_free_list);
global_free_list = static_cast(p2);
}
double foo(double* p1)
{
double result = *p1;
delete p1;
return result;
}
[snip]
So how is this example looking now? Does the alias analysis mean that g++
will never reorder the read and write via p1 and p2?
Yes, as that would now be an invalid thing to do. Note that for C
there is no way to do "placement new", but the memory model of C
only has static typing, not the notion of a dynamic type. Which is
why some people (including me) say you cannot do a C conforming
implementation of malloc that ever re-uses memory.
I don't really see which part of the alias analysis shows that g++ won't
reorder the accesses via the double* and the void**. Is it because the
intersection of the "may aliases" lists is non-empty?
8< start
Symbol memory tags
SMT.7, UID D.1868, void *, is addressable, is global, score: 556356,
direct reads: 0, direct writes: 0, indirect reads: 0, indirect writes:
1, call clobbered (stored in global, is global var), may aliases: {
global_free_list }
SMT.8, UID D.1869, double, is addressable, is global, score: 320002,
direct reads: 0, direct writes: 0, indirect reads: 1, indirect writes:
0, call clobbered (is global var, is incoming pointer), may aliases: {
global_free_list }
[...]
Name memory tags
NMT.9, UID D.1870, double, is addressable, is global, score: 8, direct
reads: 1, direct writes: 0, indirect reads: 0, indirect writes: 0, call
clobbered (is global var, is incoming pointer), may aliases: {
global_free_list SMT.8 }
NMT.10, UID D.1871, void *, is addressable, is global, score: 16, direct
reads: 0, direct writes: 1, indirect reads: 0, indirect writes: 0, call
clobbered (stored in global, is global var), may aliases: {
global_free_list SMT.7 }
8< end
By the way, if I change the example very slightly, so it uses char* for
p1, the aliasing information is somewhat different. In particular, it
includes the void* in the may-aliases list for the char.
double bar(char* p1)
{
double result = *p1;
delete p1;
return result;
}
Alias information for double bar(char*)
[...]
Symbol memory tags
SMT.22, UID D.1898, void *, is addressable, is global, score: 876358,
direct reads: 0, direct writes: 0, indirect reads: 1, indirect writes:
1, call clobbered (stored in global, is global var, is incoming
pointer), may aliases: { global_free_list }
SMT.23, UID D.1899, char, is addressable, is global, score: 320002,
direct reads: 0, direct writes: 0, indirect reads: 1, indirect writes:
0, call clobbered (is global var, is incoming pointer), may aliases: {
global_free_list SMT.22 }
[...]
Name memory tags
NMT.24, UID D.1900, char, is addressable, is global, score: 8, direct
reads: 1, direct writes: 0, indirect reads: 0, indirect writes: 0, call
clobbered (is global var, is incoming pointer), may aliases: {
global_free_list SMT.22 SMT.23 }
NMT.25, UID D.1901, void *, is addressable, is global, score: 16, direct
reads: 0, direct writes: 1, indirect reads: 0, indirect writes: 0, call
clobbered (stored in global, is global var), may aliases: {
global_free_list SMT.22 }
So I guess I'm just trying to understand how the alias data structures
are used. In the one case (with a char*) it's pretty easy I guess, but I
don't really understand how it represents the potential aliasing in the
void** versus double* example.
--
Thanks,
Raoul Gough.
Re: Steve Kargle and Daniel Franke - reviewers.
On Sat, Jan 10, 2009 at 07:06:48PM +0100, Toon Moene wrote: > L.S., > > I have kept this under wraps for some weeks because I wanted to be sure > all Steering Committee members had a chance to review this request - in > spite of the holiday season. > > Now, however, I want to congratulate Daniel Franke and Steve Kargle (who > has been a GNU Fortran maintainer before) with their new status of > "reviewer". > > Steve, I suppose you want to have your write privileges (back). Please > use ://gcc.gnu.org/svnwrite.html#authenticated to renew your write > access - and name me as your sponsor. > > Thanks Daniel and Steve, for (re-)joining the club ! > I'm back. See Committed revision 143312. -- Steve
