Re: lto and compile flag associations
On Mon, May 17, 2010 at 5:18 AM, Jack Howarth wrote: > What is the current LTO design with regards to the > retention of compiler flags during the actual link > time optimization compilation steps. For example, if > one is linking mixed fortran and c object files which > have distinct flags passed in FFLAGS and CFLAGS, are > these embedded with the LTO information when generating > the object files in the initial compilation or do they > have to be explicitly passed later? If the latter is > the case, how would one deal with the situation of a > linkage with mixed fortran and c LTO object files which > would require conflicting compilation flags? Thanks in > advance for any clarifications. You have to pass correct flags at link time and those and only those flags will be used for LTO optimizations. There is no working code to save options from the compile stage and to detect mismatches or re-use them during link stage. Richard. > Jack >
build flags/options
Sorry for the newbie question ... I need the build process to look for libelf in /usr/lib but gmp, ppl, cloog, etc. in /usr/local/lib. I've tried lots of combinations of the flags/options listed by 'configure --help' including this: ~/GCC/gcc-4.5.0/configure --program-suffix=-4.5.0 --with-libelf-include=/usr/include --with-libelf-lib=/usr/lib --with-mpc=/usr/local/lib --with-mpfr=/usr/local/lib --with-gmp=/usr/local/lib --with-ppl=/usr/local/lib --with-cloog=/usr/local/lib but what always happens is that when it goes into i686-pc-linux-gnu/libgcc in the object directory I get this: configure:3233: /home/mike/GCC-obj-dir/./gcc/xgcc -B/home/mike/GCC-obj-dir/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include-c -g -O2 conftest.c >&5 /home/mike/GCC-obj-dir/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory configure:3237: $? = 1 configure: failed program was: and there is this in config.log in the object libgcc directory: configure:3020: /home/mike/GCC-obj-dir/./gcc/xgcc -B/home/mike/GCC-obj-dir/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include-o conftest -g -O2 conftest.c >&5 /home/mike/GCC-obj-dir/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory configure:3023: $? = 1 Depending on what flags/options I use with 'configure' it might not find libelf.so.0 instead. Thanks, Mike
Re: build flags/options
On Mon, May 17, 2010 at 1:44 PM, mike wrote: > Sorry for the newbie question ... > > I need the build process to look for libelf in /usr/lib but gmp, ppl, cloog, > etc. in /usr/local/lib. I've tried lots of combinations of the > flags/options listed by 'configure --help' including this: > >> ~/GCC/gcc-4.5.0/configure --program-suffix=-4.5.0 >> --with-libelf-include=/usr/include --with-libelf-lib=/usr/lib >> --with-mpc=/usr/local/lib --with-mpfr=/usr/local/lib >> --with-gmp=/usr/local/lib --with-ppl=/usr/local/lib >> --with-cloog=/usr/local/lib > > but what always happens is that when it goes into i686-pc-linux-gnu/libgcc > in the object directory I get this: > >> configure:3233: /home/mike/GCC-obj-dir/./gcc/xgcc >> -B/home/mike/GCC-obj-dir/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ >> -B/usr/local/i686-pc-linux-gnu/lib/ -isystem >> /usr/local/i686-pc-linux-gnu/include -isystem >> /usr/local/i686-pc-linux-gnu/sys-include -c -g -O2 conftest.c >&5 >> /home/mike/GCC-obj-dir/./gcc/cc1: error while loading shared libraries: >> libmpc.so.2: cannot open shared object file: No such file or directory >> configure:3237: $? = 1 >> configure: failed program was: > > and there is this in config.log in the object libgcc directory: > >> configure:3020: /home/mike/GCC-obj-dir/./gcc/xgcc >> -B/home/mike/GCC-obj-dir/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ >> -B/usr/local/i686-pc-linux-gnu/lib/ -isystem >> /usr/local/i686-pc-linux-gnu/include -isystem >> /usr/local/i686-pc-linux-gnu/sys-include -o conftest -g -O2 conftest.c >> >&5 >> /home/mike/GCC-obj-dir/./gcc/cc1: error while loading shared libraries: >> libmpc.so.2: cannot open shared object file: No such file or directory >> configure:3023: $? = 1 > > Depending on what flags/options I use with 'configure' it might not find > libelf.so.0 instead. This question is more appropriate for gcc-help. You need to set your LD_LIBRARY_PATH environment to point to the installed libraries or ensure to configure your ld.so to pick them up. Richard. > Thanks, > Mike > >
Re: build flags/options
On 05/17/2010 12:46 PM, Richard Guenther wrote: On Mon, May 17, 2010 at 1:44 PM, mike wrote: Sorry for the newbie question ... This question is more appropriate for gcc-help. Sorry. Wasn't sure which to send to. You need to set your LD_LIBRARY_PATH environment to point to the installed libraries or ensure to configure your ld.so to pick them up. Thanks for that.
Re: lto and compile flag associations
On 5/16/10 23:18 , Jack Howarth wrote: >What is the current LTO design with regards to the > retention of compiler flags during the actual link > time optimization compilation steps. For example, if Some options are embedded, but not all (see lto-opts.c). You will need to pass the same flags to the compile and link commands. The options that are saved are reapplied at link-time, but no merging is done (the options taken from the first file in the link command are used). Diego.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 2:27 PM, Diego Novillo wrote: > On 5/16/10 23:18 , Jack Howarth wrote: >> What is the current LTO design with regards to the >> retention of compiler flags during the actual link >> time optimization compilation steps. For example, if > > Some options are embedded, but not all (see lto-opts.c). You will need > to pass the same flags to the compile and link commands. The options > that are saved are reapplied at link-time, but no merging is done (the > options taken from the first file in the link command are used). That's not really true - they are sort-of merged. But also only literally passed options do count, so option pre-/post-processing done by the frontends are disregarded if not replicated by the lto frontend. Instead of trying to record switches that way we should instead save the final settings of relevant flag_* values somewhere and simply complain on mismatches. Richard.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 08:39, Richard Guenther wrote: > Instead of trying to record switches that way we should instead > save the final settings of relevant flag_* values somewhere and > simply complain on mismatches. What would be the difference? The flags are reapplied as if they had been given on the command line. Diego.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 2:46 PM, Diego Novillo wrote: > On Mon, May 17, 2010 at 08:39, Richard Guenther > wrote: > >> Instead of trying to record switches that way we should instead >> save the final settings of relevant flag_* values somewhere and >> simply complain on mismatches. > > What would be the difference? The flags are reapplied as if they had > been given on the command line. For example the C++ frontend sets flag_exceptions to 1 but the command-line does not contain -fexceptions. Or the Fortran frontend might set flag_no_signed_zeros but the command-line does not contain -fno-signed-zeros. Similar the Java frontend sets flag_wrapv but it's not on the command-line either. Looking at the command-line for exactly those options we try to match (as they change semantics) does not work reliably because of that issue. And for those that would work (optimization options) it doesn't really matter (and we don't care at the moment). The only thing where it might actually work sort-of is for target options, but even that's fragile as we don't merge options but take those of the first (or last) TU (so if one unit selects -msse2 and one -mavx we don't necessarily get -mavx for the link step). Richard. > > Diego. >
RE: Adding "soft-fp" support to a new target
Hi David, Thank you for the reply. > > Did you include soft-fp/t-softfp in tmake_file? Please see > gcc/config/soft-fp/t-softfp for more details about configuring GCC to > use soft-fp. > Yes, I have also added the soft-fp/t-softfp to tmake_file. I have defined the variables mentioned in the file 'gcc/config/soft-fp/ t-softfp' in 't-fprules-softfp' file. It is copied to the target folder in config directory. But still the soft-fp routines are not getting used. Do we need to specify any configure options to gcc? Also, please let me know the name of library built for soft-fp and how to verify that the soft-fp files are compiled and linked with the gcc executable? Thanks Rathish.C > -Original Message- > From: David Edelsohn [mailto:dje@gmail.com] > Sent: Thursday, May 13, 2010 7:51 PM > To: Rathish C > Cc: gcc@gcc.gnu.org > Subject: Re: Adding "soft-fp" support to a new target > > On Thu, May 13, 2010 at 7:10 AM, Rathish C > wrote: > > Hi, > > > > I am trying to add the soft-fp support to a new target. I have > > checked the implementation done in rs6000 port, and done the > > similar modifications to our port. I have made the following > > changes. > > > > (1) Added the following files > > t-fprules-softfp > > sfp-machine.h > > > > (2) Modified the file '/gcc/config.gcc' > > to include the above 2 files in 'tmake_file' > > > > But still the soft-fp routines are not getting linked. The default > > libraries are being taken. > > > > Please suggest the additional modifications required to support > > the soft-fp support. Also, please let me know the name of > > library built for soft-fp? > > Did you include soft-fp/t-softfp in tmake_file? Please see > gcc/config/soft-fp/t-softfp for more details about configuring GCC to > use soft-fp. > > David
Re: C++0x Memory model and gcc
Hi, On Wed, 12 May 2010, Andrew MacLeod wrote: > Well, you get the same thing you get today. Any synchronization done > via a function call will tend to be correct since we never move shared > memory operations across calls. Depending on your application, the > types of data races the options deal with may not be an issue. Using > the options will eliminate having to think whether they are issues or > not at a (hopefully) small cost. > > Since the atomic operations are being built into the compiler, the > intent is to eventually optimize and inline them for speed... and in the > best case, simply result in a load or store. That's further work of > course, but these options are laying some of the groundwork. Are you and the other proponents of that memory model seriously proposing it as an alternative to explicit locking via atomic builtins (that map to some form of atomic instructions)? Ciao, Michael.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote: > > For example the C++ frontend sets flag_exceptions to 1 but the > command-line does not contain -fexceptions. Or the Fortran > frontend might set flag_no_signed_zeros but the command-line > does not contain -fno-signed-zeros. Similar the Java frontend > sets flag_wrapv but it's not on the command-line either. > > Looking at the command-line for exactly those options we try > to match (as they change semantics) does not work reliably > because of that issue. > > And for those that would work (optimization options) it doesn't > really matter (and we don't care at the moment). > > The only thing where it might actually work sort-of is for > target options, but even that's fragile as we don't merge options > but take those of the first (or last) TU (so if one unit selects > -msse2 and one -mavx we don't necessarily get -mavx for the > link step). > > Richard. > Richard, In the case of xplor-nih, there are linkages of shared libraries which contain a mix of c, c++ and fortran code. In these cases, I am worried about flags like -fno-second-underscore and -fdefault-integer-8 which are passed only on FFLAGS. So I guess I need to explicitly look at the linker command outputted using -v to insure that the proper flags are being retained. Whether they are actually being passed properly for the final lto compilations is yet another question. Jack ps It would be really nice if lto were smart enough to tag the lto information in the object files with the some of the optimization flags such that the lowest common denominator could be used. For instance, if you had a.o, b.o and c.o where a.o was compiled with -O1, b.o with -O2 and c.o with -O3, when lto with -fwhole-program tried to inline between a.o and c.o, the optimization would be dropped to -O1. Likewise of inlining was shared between b.o and c.o, the optimization would be dropped to -02. The trick would be to trigger this only in those cases of inlining so as to not pessimize the code generation unnecessarily,
Re: lto and compile flag associations
On Mon, May 17, 2010 at 3:21 PM, Jack Howarth wrote: > On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote: > >> >> For example the C++ frontend sets flag_exceptions to 1 but the >> command-line does not contain -fexceptions. Or the Fortran >> frontend might set flag_no_signed_zeros but the command-line >> does not contain -fno-signed-zeros. Similar the Java frontend >> sets flag_wrapv but it's not on the command-line either. >> >> Looking at the command-line for exactly those options we try >> to match (as they change semantics) does not work reliably >> because of that issue. >> >> And for those that would work (optimization options) it doesn't >> really matter (and we don't care at the moment). >> >> The only thing where it might actually work sort-of is for >> target options, but even that's fragile as we don't merge options >> but take those of the first (or last) TU (so if one unit selects >> -msse2 and one -mavx we don't necessarily get -mavx for the >> link step). >> >> Richard. >> > > Richard, > In the case of xplor-nih, there are linkages of shared libraries > which contain a mix of c, c++ and fortran code. In these cases, I am > worried about flags like -fno-second-underscore and -fdefault-integer-8 > which are passed only on FFLAGS. So I guess I need to explicitly look > at the linker command outputted using -v to insure that the proper > flags are being retained. Whether they are actually being passed > properly for the final lto compilations is yet another question. These are Frontend flags and they should take effect during the compile-stage and thus be not necessary for the link stage. > Jack > ps It would be really nice if lto were smart enough to tag the > lto information in the object files with the some of the optimization > flags such that the lowest common denominator could be used. For > instance, if you had a.o, b.o and c.o where a.o was compiled with -O1, > b.o with -O2 and c.o with -O3, when lto with -fwhole-program tried to > inline between a.o and c.o, the optimization would be dropped to -O1. > Likewise of inlining was shared between b.o and c.o, the optimization > would be dropped to -02. The trick would be to trigger this only in > those cases of inlining so as to not pessimize the code generation > unnecessarily, Well, something would be nice, but not magically choosing something, only complaining if the result won't work as expected. Richard.
FW: [Bug c/44166] New: -fvisibility=protected doesn't work?
> Date: Mon, 17 May 2010 13:41:57 +
> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work?
> To: jay.kr...@cornell.edu
> From: gcc-bugzi...@gcc.gnu.org
>
> -fvisibility=protected doesn't work?
>
> a...@xlin2:~$ cat 1.c
> void F1() { }
> void* F2() { return F1; }
>
> j...@xlin2:~$ $HOME/bin/gcc 1.c -fPIC -shared -fvisibility=protected
>
> /usr/bin/ld: /tmp/cc0d6EQ3.o: relocation R_386_GOTOFF against protected
> function `F1' can not be used when making a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> j...@xlin2:~$ $HOME/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/home/jay/bin/gcc
> COLLECT_LTO_WRAPPER=/home/jay/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: /src/gcc-4.5.0/configure -verbose -prefix=/home/jay
> -disable-bootstrap -disable-multilibs
> Thread model: posix
> gcc version 4.5.0 (GCC)
>
>
> --
> Summary: -fvisibility=protected doesn't work?
> Product: gcc
> Version: 4.5.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: jay dot krell at cornell dot edu
> GCC build triplet: i686-pc-linux-gnu
> GCC host triplet: i686-pc-linux-gnu
> GCC target triplet: i686-pc-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44166
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 03:34:26PM +0200, Richard Guenther wrote: > On Mon, May 17, 2010 at 3:21 PM, Jack Howarth > wrote: > > On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote: > > > >> > >> For example the C++ frontend sets flag_exceptions to 1 but the > >> command-line does not contain -fexceptions. Or the Fortran > >> frontend might set flag_no_signed_zeros but the command-line > >> does not contain -fno-signed-zeros. Similar the Java frontend > >> sets flag_wrapv but it's not on the command-line either. > >> > >> Looking at the command-line for exactly those options we try > >> to match (as they change semantics) does not work reliably > >> because of that issue. > >> > >> And for those that would work (optimization options) it doesn't > >> really matter (and we don't care at the moment). > >> > >> The only thing where it might actually work sort-of is for > >> target options, but even that's fragile as we don't merge options > >> but take those of the first (or last) TU (so if one unit selects > >> -msse2 and one -mavx we don't necessarily get -mavx for the > >> link step). > >> > >> Richard. > >> > > > > Richard, > > In the case of xplor-nih, there are linkages of shared libraries > > which contain a mix of c, c++ and fortran code. In these cases, I am > > worried about flags like -fno-second-underscore and -fdefault-integer-8 > > which are passed only on FFLAGS. So I guess I need to explicitly look > > at the linker command outputted using -v to insure that the proper > > flags are being retained. Whether they are actually being passed > > properly for the final lto compilations is yet another question. > > These are Frontend flags and they should take effect during the > compile-stage and thus be not necessary for the link stage. > > > Jack > > ps It would be really nice if lto were smart enough to tag the > > lto information in the object files with the some of the optimization > > flags such that the lowest common denominator could be used. For > > instance, if you had a.o, b.o and c.o where a.o was compiled with -O1, > > b.o with -O2 and c.o with -O3, when lto with -fwhole-program tried to > > inline between a.o and c.o, the optimization would be dropped to -O1. > > Likewise of inlining was shared between b.o and c.o, the optimization > > would be dropped to -02. The trick would be to trigger this only in > > those cases of inlining so as to not pessimize the code generation > > unnecessarily, > > Well, something would be nice, but not magically choosing something, > only complaining if the result won't work as expected. > > Richard. Richard, It would be nice if the lto had some sort of verbose mode which would show you the compiler flags being used for each object file as it was processed (since there does appear to be a crude automatic association of compiler flags done internally). Jack
Re: lto and compile flag associations
On Mon, May 17, 2010 at 09:34, Richard Guenther wrote: > Well, something would be nice, but not magically choosing something, > only complaining if the result won't work as expected. Agreed. I don't think there are silver bullets here. I would like to get to a point where: 1- The IL saved by the front end is independent from all (or most) compiler flags. 2- The final link is the one that determines what flags are used to generate final code This way, one could generate completely independent byte-code files that can be shipped and re-compiled with any flags. This doesn't address the problem of what happens if a single file needs special code generation flags. For those cases, one could generate final code from the byte-code file separately and link it to the final executable: $ gcc -c special-file.o $ gcc -flto special-file.o -o prog This would probably not cover all the use cases, but right now we don't even have (1). Diego.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 09:48, Jack Howarth wrote: > It would be nice if the lto had some sort of verbose mode which > would show you the compiler flags being used for each object file > as it was processed (since there does appear to be a crude automatic > association of compiler flags done internally). This is something that you could add to lto-opts.c. Diego.
Re: lto and compile flag associations
On Mon, May 17, 2010 at 3:49 PM, Diego Novillo wrote: > On Mon, May 17, 2010 at 09:48, Jack Howarth wrote: > >> It would be nice if the lto had some sort of verbose mode which >> would show you the compiler flags being used for each object file >> as it was processed (since there does appear to be a crude automatic >> association of compiler flags done internally). > > This is something that you could add to lto-opts.c. Or simply use -v which shows you all invocations of lto1. Richard.
Re: C++0x Memory model and gcc
Michael Matz writes: > On Wed, 12 May 2010, Andrew MacLeod wrote: > >> Well, you get the same thing you get today. Any synchronization done >> via a function call will tend to be correct since we never move shared >> memory operations across calls. Depending on your application, the >> types of data races the options deal with may not be an issue. Using >> the options will eliminate having to think whether they are issues or >> not at a (hopefully) small cost. >> >> Since the atomic operations are being built into the compiler, the >> intent is to eventually optimize and inline them for speed... and in the >> best case, simply result in a load or store. That's further work of >> course, but these options are laying some of the groundwork. > > Are you and the other proponents of that memory model seriously proposing > it as an alternative to explicit locking via atomic builtins (that map to > some form of atomic instructions)? I'm not sure what you mean here. Do you an alternative way to implement the C++0x proposed standard? Or are you questioning the approach taken by the standard? Ian
Re: C++0x Memory model and gcc
Michael Matz wrote: Hi, On Wed, 12 May 2010, Andrew MacLeod wrote: Well, you get the same thing you get today. Any synchronization done via a function call will tend to be correct since we never move shared memory operations across calls. Depending on your application, the types of data races the options deal with may not be an issue. Using the options will eliminate having to think whether they are issues or not at a (hopefully) small cost. Since the atomic operations are being built into the compiler, the intent is to eventually optimize and inline them for speed... and in the best case, simply result in a load or store. That's further work of course, but these options are laying some of the groundwork. Are you and the other proponents of that memory model seriously proposing it as an alternative to explicit locking via atomic builtins (that map to some form of atomic instructions)? Proposing what as an alternative? These optimization restrictions defined by the memory model are there to create predictable memory behaviour across threads. This is applicable when you use the atomic built-ins for locking. Especially in the case when the atomic operation is inlined. One goal is to have unoptimized program behaviour be consistent with the optimized version. If the optimizers introduce new data races, there is a potential behaviour difference. Lock free data structures which utilize the atomic built-ins but do not require explicit locking are potential applications built on top of that. Andrew
Re: C++0x Memory model and gcc
Hi, On Mon, 17 May 2010, Ian Lance Taylor wrote: > >> Since the atomic operations are being built into the compiler, the > >> intent is to eventually optimize and inline them for speed... and in > >> the best case, simply result in a load or store. That's further work > >> of course, but these options are laying some of the groundwork. > > > > Are you and the other proponents of that memory model seriously > > proposing it as an alternative to explicit locking via atomic builtins > > (that map to some form of atomic instructions)? > > I'm not sure what you mean here. Do you an alternative way to > implement the C++0x proposed standard? I actually see no way to implement the proposed memory model on common hardware, except by emitting locked instructions and memory barriers for all memory accesses to potentially shared (and hence all non-stack) data. And even then it only works on a subset of types, namely those for this the hardware provides such instructions with the associated guarantees. > Or are you questioning the approach taken by the standard? I do, yes. Ciao, Michael.
Re: FW: [Bug c/44166] New: -fvisibility=protected doesn't work?
On 17/05/2010 14:47, Jay K wrote: > > >> Date: Mon, 17 May 2010 13:41:57 + >> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work? Every newly-created bugzilla entry automatically sends a post to the gcc-bugs list; there's no need to spam the main list with them too. cheers, DaveK
Re: C++0x Memory model and gcc
Hi, On Mon, 17 May 2010, Andrew MacLeod wrote: > > > Well, you get the same thing you get today. Any synchronization > > > done via a function call will tend to be correct since we never move > > > shared memory operations across calls. Depending on your > > > application, the types of data races the options deal with may not > > > be an issue. Using the options will eliminate having to think > > > whether they are issues or not at a (hopefully) small cost. > > > > > > Since the atomic operations are being built into the compiler, the > > > intent is to eventually optimize and inline them for speed... and in > > > the best case, simply result in a load or store. That's further work > > > of course, but these options are laying some of the groundwork. > > > > > > > Are you and the other proponents of that memory model seriously > > proposing it as an alternative to explicit locking via atomic builtins > > (that map to some form of atomic instructions)? > > Proposing what as an alternative? The guarantees you seem to want to establish by the proposed memory model. Possibly I misunderstood. I'm not 100% sure on the guarantees you want to establish. The proposed model seems to merge multiple concepts together, all related to memory access ordering and atomicity, but with different scope and difficulty to guarantee. The mail to which I reacted seemed to me to imply that you would believe the guarantees from the memory model alone would relieve users from writing explicit atomic instructions for data synchronization. If you didn't imply that, then I'm also interested to learn what other advantages you expect to derive from the guarantees. And third, I'm interested to learn how you intend to actually guarantee the guarantees given by the model. So, in short, I'd like to know What (guarantees are established), Why (are those sensible and useful), and How (are those intended to be implemented) I've tried to find this in the Wiki, but it only states some broad goals it seems (not introduce data races). I also find the papers of Boehm somewhat lacking when it comes to how to actually implement the whole model on hardware, especially because he himself acknowledges the obvious problems on real hardware, like: * load/store reorder buffers, * store->load forwarding, * cache-line granularity even for strict coherency models, * existence of weak coherency machines (have to aquire whole cache line for exlusive write) * general slowness of locked (or atomic) instructions compared to normal stores/loads * existence of store granularity on some hardware (we don't even have to enter bit-field business, alpha e.g. has only 64 bit accesses) But for all of these to be relevant questions we first need to know what exactly are the intended guarantees of that model; say from the perspective of observable behaviour from other threads. > These optimization restrictions defined by the memory model are there to > create predictable memory behaviour across threads. With our without use of atomics? I.e. is the mem behaviour supposed to be predictable also in absense of all mentions of explicitely written atomic builtins? And you need to defined predictable. Predictable == behaves according to rules. What are the rules? > This is applicable when you use the atomic built-ins for locking. > Especially in the case when the atomic operation is inlined. One goal > is to have unoptimized program behaviour be consistent with the > optimized version. We have that now (because atomics are memory barriers), so that's probably not why the model was devised. Ciao, Michael.
Re: libgcc2
Andrew Pinski schrieb: On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote: Is there any implementation with less registers like this. libgcc2 is written in C; so if it fails to compile you need to fix up your backend. There might need some middle-end fixes too with this small number of registers used. You might just want to disable double register sized integer types to fix this in the end. Thanks, Andrew Pinski How can I disable double register sized integer types. Is there a constant to do this. Thanks Egge
Re: C++0x Memory model and gcc
Michael Matz wrote: Hi, On Mon, 17 May 2010, Andrew MacLeod wrote: The guarantees you seem to want to establish by the proposed memory model. Possibly I misunderstood. I'm not 100% sure on the guarantees you want to establish. The proposed model seems to merge multiple concepts together, all related to memory access ordering and atomicity, but with different scope and difficulty to guarantee. I think the standard is excessively confusing, and overly academic. I even find the term memory model adds to the confusion. Some effort was clearly involved in defining behaviour for hardware which does not yet exist, but the language is "prepared" for. I was particularly unhappy that they merged the whole synchronization thing to an atomic load or store, at least originally. I would hazard a guess that it evolved to this state based on an observation that synchronization is almost inevitably required when an atomic is being accessed. Thats just a guess however. However, there is some fundamental goodness in it once you sort through it. Lets see if I can paraphrase normal uses and map them to the standard :-) The normal case would be when you have a system wide lock, and when you acquire the lock, you expect everything which occurred before the lock to be completed. ie process1 :otherglob = 2; global = 10; set atomic_lock(1); process2: wait (atomic_lock() == 1);print (global) you expect 'global' in process 2 to always be 10. You are in effect using the lock as a ready flag for global. In order for that to happen in a consistent manner, there is more involved than just waiting for the lock. If process 1 and 2 are running on different machines, process 1 will have to flush its cache all the way to memory, and process 2 will have to wait for that to complete and visible before it can proceed with allowing the proper value of global to be loaded. Otherwise the results will not be as expected. Thats the synchronization model which maps to the default or 'sequentially consistent' C++ model. The cache flushing and whatever else is required is built into the library routines for performing atomic loads and stores. There is no mechanism to specify that this lock is for the value of 'global', so the standard extends the definition of the lock to say it applies to *all* shared memory before the atomic lock value is set. so process3: wait (atomic_lock() == 1) print (otherglob); will also work properly. This memory model will always involve some form of synchronization instructions, and potentially waiting on other hardware to complete. I don't know much about this , but Im told machines are starting to provide instructions to accomplish this type of synchronization. The obvious conclusion is that once the hardware starts to be able to do this synchronization with a few instructions, the entire library call to set or read an atomic and perform synchronization may be inlinable without having a call of any kind, just straight line instructions. At this point, the optimizer will need to understand that those instructions are barriers. If you are using an atomic variable simply as an variable, and don't care about the synchronization aspects (ie, you just want to always see a valid value for the variable), then that maps to the 'relaxed' mode. There may be some academic babble about certain provisions, but this is effectively what it boils down to. The relaxed mode is what you use when you don't care about all that memory flushing and just want to see the values of the atomic itself. So this is the fastest model, but don't depend on the values of other shared variables. This is also what you get when you use the basic atomic store and load macros in C. The sequential mode has the possibility of being VERY slow if you have a widely distributed system. Thats where the third mode comes in, the release/acquire model. Proper utilization of it can remove many of the waits present in the sequential model since different processes don't have to wait for *all* cache flushes, just ones directly related to a specific atomic variable in a specific other process. The model is provided to allow code to run more efficiently, but requires a better understanding of the subtleties of multi-processor side effects in the code you write. I still don't really get it completely, but I'm not implementing the synchronization parts, so I only need to understand some of it :-) It is possible to optimize these operations, ie you can do CSE and dead store elimination which can also help the code run faster. That comes later tho. The optimization flags I'm currently working on are orthogonal to all this, even though it uses the term memory-model. When a program is written for multi-processing the programmer usually attempts to write it such that there are no data races, otherwise there may be inconsistencies during execution. If a program
Re: Adding "soft-fp" support to a new target
On Mon, May 17, 2010 at 9:08 AM, Rathish C wrote: > But still the soft-fp routines are not getting used. Do we need to specify > any configure options to gcc? > > Also, please let me know the name of library built for soft-fp and how to > verify that the soft-fp files are compiled and linked with the gcc executable? The soft-fp functions are included in libgcc. I believe the functions only are invoked if named patterns for the operations do not exist in the machine description or the named patterns report the operation as unsupported in hardware through the FAIL code path. David
Does `-fwhole-program' make sense when compiling shared libraries?
Hi! PR42904 is a bug where, when compiling a windows DLL using -fwhole-program, the compiler optimises away the entire library body, because there's no dependency chain related to 'main' to anchor it. It's pointed out that we could perhaps resolve this by inferring attribute externally_visible anywhere we see dllexport is applied, but I wondered whether Linux (or any other target) does anything like this (perhaps based on default visibility or explicit attributes?), or if you are just expected to annotate all your externally-visible functions if you want to be able to meaningfully combine -fwhole-program with -shared compilation? cheers, DaveK
Re: Does `-fwhole-program' make sense when compiling shared libraries?
On 05/17/2010 08:08 PM, Dave Korn wrote: Hi! PR42904 is a bug where, when compiling a windows DLL using -fwhole-program, the compiler optimises away the entire library body, because there's no dependency chain related to 'main' to anchor it. Aren't "shared library" and "whole program" mutually exclusive concepts ? The mere fact that you are building a library means that it cannot be the whole program, and because a shared library cannot be determined to have being used by any fixed program, by definition cannot be "the whole program". Or so I'd think. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: Does `-fwhole-program' make sense when compiling shared libraries?
On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote: > On 05/17/2010 08:08 PM, Dave Korn wrote: > > > > Hi! > > > >PR42904 is a bug where, when compiling a windows DLL using > > -fwhole-program, > > the compiler optimises away the entire library body, because there's no > > dependency chain related to 'main' to anchor it. Not a bug, but perhaps the beginning of a reasonable enhancement project. > Aren't "shared library" and "whole program" mutually exclusive concepts ? > > The mere fact that you are building a library means that it cannot be > the whole program, and because a shared library cannot be determined to > have being used by any fixed program, by definition cannot be "the whole > program". > > Or so I'd think. The concept would need to be extended so that the compiler would be told exactly what interfaces of the shared library are considered free, and which are considered internal calls. Then a -fwhole-library could make sense.
Re: libgcc2
Eggenmüller Bernd writes: > Andrew Pinski schrieb: >> On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote: >> >>> Is there any implementation with less registers like this. >>> >> >> libgcc2 is written in C; so if it fails to compile you need to fix up >> your backend. There might need some middle-end fixes too with this >> small number of registers used. You might just want to disable double >> register sized integer types to fix this in the end. >> >> Thanks, >> Andrew Pinski >> >> > How can I disable double register sized integer types. Is there a > constant to do this. Make sure that LONG_TYPE_SIZE and LONG_LONG_TYPE_SIZE are single register sized. Make TARGET_SCALAR_MODE_SUPPORTED_P return false for DImode. You'll probably have to tweak the way that libgcc2 is built, but I'm not sure just how. Ian
Design Considerations of GIMPLE Front End
Hi, As part of GSoC 2010, I am developing a front end for GIMPLE. You can find the basic theme of the project at: http://gcc.gnu.org/wiki/GimpleFrontEnd One of the most important components in this GIMPLE Front End is to convert the GIMPLE tuples into text. How such a textual representation should be, will obviously dictate the design and complexity of the subsequent parsing component. So, as per Diego's suggestion, to have a view on some of the issues I have started this thread. Following are some of the issues/questions that have come up: 1. What should be the format of representation of the GIMPLE tuples in text? Ideally, the textual representation should be satisfying two goals: Easy to parse and easy for a programmer to write by hand.Considering this,what is the best way in which the GIMPLE tuples be represented. For example: A textual GIMPLE tuple for the statement a=b+c can be like > (As demonstrated by the internal manual also). Is such a representation easy to parse? The other alternative is to represent the tuples in a C-like syntax much like what -fdump-tree-gimple flag does. Which is more better? In terms of ease in parsing, intuitiveness for a programmer to code by hand etc. Any other alternative? 2. The most important aspect in the representation is that of types. Since there are many possibilities in the types, mapping each in a common representation can be difficult. An approach suggested by Diego is to read what fields are read from 'tree' structures and then lay out the tuples as follows: > So, we make all the sub-structures into nested tuples. This seems to be easy to parse. Again the question: Are there any ideas from anybody about the way the types be represented so that the parsing becomes simple? 3. Finally, what could be the overall structure of such a textual gimple file. A possible way could be to have the same structure as the sections encoded in the bytestream.So we can have a section for types, symbols, function bodies etc. Such a simple structure will be helpful for any programmer and be relatively easy to parse. Any other ideas? arguments against such a structure? So, If there are any alternative ideas to any one of these or arguments in favour of /against the ideas presented in this mail. Please add it to this thread. If there are any more vital points which are missing in this mail but require serious discussions, please add them to this thread too. -- Cheers Sandy
Re: C++0x Memory model and gcc
Michael Matz writes: > On Mon, 17 May 2010, Ian Lance Taylor wrote: > >> >> Since the atomic operations are being built into the compiler, the >> >> intent is to eventually optimize and inline them for speed... and in >> >> the best case, simply result in a load or store. That's further work >> >> of course, but these options are laying some of the groundwork. >> > >> > Are you and the other proponents of that memory model seriously >> > proposing it as an alternative to explicit locking via atomic builtins >> > (that map to some form of atomic instructions)? >> >> I'm not sure what you mean here. Do you an alternative way to >> implement the C++0x proposed standard? > > I actually see no way to implement the proposed memory model on common > hardware, except by emitting locked instructions and memory barriers for > all memory accesses to potentially shared (and hence all non-stack) data. > And even then it only works on a subset of types, namely those for this > the hardware provides such instructions with the associated guarantees. I'm sure the C++ standards committee would like to hear a case for why the proposal is unusable. The standard has not yet been voted out. As far as I understand the proposal, though, your statement turns out not to be the case. Those locked instructions and memory barries are only required for loads and stores to atomic types, not to all types. Ian
Re: Design Considerations of GIMPLE Front End
On 05/17/2010 09:15 PM, Sandeep Soni wrote: > Hi, > > As part of GSoC 2010, I am developing a front end for GIMPLE. > You can find the basic theme of the project at: > http://gcc.gnu.org/wiki/GimpleFrontEnd > > One of the most important components in this GIMPLE Front End is to > convert the GIMPLE tuples into text. > How such a textual representation should be, will obviously dictate > the design and complexity of the > subsequent parsing component. So, as per Diego's suggestion, to have a > view on some of the issues > I have started this thread. > > Following are some of the issues/questions that have come up: > > 1. What should be the format of representation of the GIMPLE tuples in text? > >Ideally, the textual representation should be satisfying two goals: > Easy to parse and easy for a programmer >to write by hand.Considering this,what is the best way in which the > GIMPLE tuples be represented. > >For example: >A textual GIMPLE tuple for the statement a=b+c can be like >> (As demonstrated by the internal > manual also). >Is such a representation easy to parse? S-expressions are easier to parse and more compact, and are consistent with gcc's back end. Also, there are editors that already know how to edit and indent S-expressions. Andrew.
Re: Does `-fwhole-program' make sense when compiling shared libraries?
> On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote: > > On 05/17/2010 08:08 PM, Dave Korn wrote: > > > > > > Hi! > > > > > >PR42904 is a bug where, when compiling a windows DLL using > > > -fwhole-program, > > > the compiler optimises away the entire library body, because there's no > > > dependency chain related to 'main' to anchor it. > > Not a bug, but perhaps the beginning of a reasonable enhancement project. This is what __attribute__ ((externally_visible)) is intended for. If you want to build shared library with whole program, you need to explicitely mark all the entry points. Alternatively with LTO we might take the existing hidden linkage hints for same effect, but this is not implemented (yet). Honza > > > Aren't "shared library" and "whole program" mutually exclusive concepts ? > > > > The mere fact that you are building a library means that it cannot be > > the whole program, and because a shared library cannot be determined to > > have being used by any fixed program, by definition cannot be "the whole > > program". > > > > Or so I'd think. > > The concept would need to be extended so that the compiler would be told > exactly what interfaces of the shared library are considered free, and > which are considered internal calls. Then a -fwhole-library could make > sense.
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote: >> For example: >> A textual GIMPLE tuple for the statement a=b+c can be like >> > (As demonstrated by the internal >> manual also). >> Is such a representation easy to parse? > > S-expressions are easier to parse and more compact, and are consistent > with gcc's back end. Also, there are editors that already know how to > edit and indent S-expressions. Thanks Andrew . Any thoughts on the 3rd point? > > Andrew. > -- Cheers Sandy
