when will gcc 4.4.5 be?
"GCC 4.4.5 is planned roughly for end of July, unless some severe issue forces us to release it earlier." - http://gcc.gnu.org/ml/gcc/2010-04/msg01018.html Is a 4.4.5 release still planned? When? thanks, -Kenny
GNAT building fails on MinGW wiith gcc-4.6.020100904 weekly snapshot
Hello, Please forgive my poor english, but it isn't my mother language. When trying to build gnat from this snapshot, i had an issue at line 280 from gcc/ada/g-socthi-mingw.adb due to: g-socthi.adb:280:45 value not in range of type "Interfaces.C.unsigned" g-socthi.adb:280:45 static expression fails Constraint-check Is it all an known issue ? This line is an declaration for Fill as boolean like this Fill : constant Boolean := (C.unsigned (Flags) and SOSC.MSG_WAITALL) /= 0; -- Is the MSG_WAITALL flag set? If so we need to fully fill all vectors and i've temporary changed for Fill : constant Boolean := Flags = C.int (SOSC.MSG_WAITALL); -- Is the MSG_WAITALL flag set? If so we need to fully fill all vectors Is this change correct? Should i submit a bug-report or a patch ? Thanks a lot
Re: Merging Apple's Objective-C 2.0 compiler changes
On Thu, Sep 09, 2010 at 02:11:43PM -0700, Chris Lattner wrote: > On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote: > > Perhaps a rational approach would be to contact whoever at Apple > > currently is > > charged with maintaining their objc languages about the issue. > > Apple does not have an internal process to assign code to the FSF anymore. I > would focus on the code that is already assigned to the FSF. To clarify, anything not checked in on gcc.gnu.org somewhere must be assumed to be copyright Apple, not copyright FSF, and has not been contributed, and Apple has no plans to contribute more code. However, anything on gcc.gnu.org has been contributed. I understand that the main issue is that Apple objects to GPLv3, but the exact reason doesn't necessarily matter that much.
RE: How to avoid auto-vectorization for this loop (rolls at most 3 times)
>> It seems the auto-vectorizer could not recognize that this loop will
>> roll at most 3 times.
>> And it will generate quite messy code.
>>
>> int a[1024], b[1024];
>> void foo (int n)
>> {
>> int i;
>> for (i = (n/4)*4; i< n; i++)
>> a[i] = a[i] + b[i];
>> }
>>
>> How can we correctly estimate the number of iterations for this case
>> and use this info for the vectorizer?
>Does it recognise it if you rewrite the loop as follows:
>for (i = n&~0x3; i< n; i++)
>a[i] = a[i] + b[i];
NO.
But it is OK for the following case:
for (i = n-3; i< n; i++)
a[i] = a[i] + b[i];
It seems it fails at the case of "unknown but small". Anyway, this mostly
affects compilation time and code size, and has limited impact on
performance.
For
for (i = n&~0x3; i< n; i++)
a[i] = a[i] + b[i];
The attached foo-O3-no-tree-vectorize.s is what we expect from the optimizer.
foo-O3.s is too bad.
Thanks,
Changpeng
foo-O3-no-tree-vectorize.s
Description: foo-O3-no-tree-vectorize.s
foo-O3.s
Description: foo-O3.s
gcc-4.5-20100909 is now available
Snapshot gcc-4.5-20100909 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100909/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 164132 You'll find: gcc-4.5-20100909.tar.bz2 Complete GCC (includes all of below) MD5=56fe5f0e3f02c6e5f0cf7f6abb75be46 SHA1=c39379a4552ce4bdf0c57db299620630b04b0bc6 gcc-core-4.5-20100909.tar.bz2C front end and core compiler MD5=8cca31532d3acd3ebd2d7f8af1764e67 SHA1=cbf2395bc92f20245775687e6475e5a15656a5c7 gcc-ada-4.5-20100909.tar.bz2 Ada front end and runtime MD5=9ac36f15a6074cb370aeb895febc5993 SHA1=801aabcb27be7cd3962c822a85fa9d9ccadcc12b gcc-fortran-4.5-20100909.tar.bz2 Fortran front end and runtime MD5=6844ca9b9d301733a3e91c9357a3574b SHA1=4b120de75c755d4f131d96546df94b6c5d034a1f gcc-g++-4.5-20100909.tar.bz2 C++ front end and runtime MD5=db3ada43f267a2ec4f9834a57a6d171e SHA1=0970b9cbb781b5a7f75b2ec92c9f85d66174de6b gcc-java-4.5-20100909.tar.bz2Java front end and runtime MD5=305b17c639a1a631fd98bcc1a1d2f795 SHA1=53a3a159fdb15a9fab460f3c58572ba4410b8781 gcc-objc-4.5-20100909.tar.bz2Objective-C front end and runtime MD5=fc6051a36da8e990bd6b8618a6fd8159 SHA1=0bed00e7fb98ceabecb5dc6c382d3b85cf1bbad3 gcc-testsuite-4.5-20100909.tar.bz2 The GCC testsuite MD5=225b2d4e30ba4118814f1c33ee9aafb3 SHA1=f56e8ba9c3b9aeff262aec0377ec48db6c2be84f Diffs from 4.5-20100902 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 9, 2010, at 11:55 AM, Nicola Pero wrote: > Why don't you upload one of the recent Apple GCC tarballs in a branch on the > FSF server ? > ... > You don't have to do it, but contributing changes back to the original > project seems to be the right, honourable thing to do, particularly when it > doesn't cost anything. Hi Nicola, I don't have the authority to do this, it is not my copyright to assign. -Chris
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 9, 2010, at 12:19 PM, Jack Howarth wrote: > Perhaps a rational approach would be to contact whoever at Apple currently > is > charged with maintaining their objc languages about the issue. Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF. -Chris
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 9, 2010, at 12:27 PM, Dave Korn wrote: > *Until and unless* Apple itself submits the code to the FSF, Apple retains > the copyright; which means that nobody else has the right to submit it to the > FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment > that allows them to sub-assign but that sounds even more complicated to > me.) Right, that's why it is reasonable (to me) to assume that stuff in the apple branch on the fsf servers are fair game. -Chris
Re: -Os is weak...
On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie wrote:
> $ grep optimize_size *.c
> genconditions.c: { "! optimize_size && ! TARGET_READ_MODIFY_WRITE",
> genconditions.c: __builtin_constant_p (! optimize_size && !
> TARGET_READ_MODIFY_WRITE)
> genconditions.c: ? (int) (! optimize_size && ! TARGET_READ_MODIFY_WRITE)
These are in comments, not actual tests of optimize_size.
> opts.c: optimize_size = 0;
> opts.c: optimize_size = 0;
> opts.c: optimize_size = 1;
> opts.c: optimize_size = 0;
> opts.c: flag_schedule_insns = opt2 && ! optimize_size;
> opts.c: if (optimize_size)
> opts.c: optimize_size = 1;
> opts.c: OPTIMIZATION_OPTIONS (optimize, optimize_size);
Various initialization bits for optimize_size, this is OK.
> predict.c: if (optimize_size)
This looks like a bug, it should proabably be:
if (optimize_function_for_size_p (DECL_STRUCT_FUNCTION (edge->caller->decl))
Honza, what do you think about this one?
> predict.c: return (optimize_size
This is OK, this is inside optimize_function_for_size_p.
> toplev.c: The only valid values are zero and nonzero. When optimize_size is
> toplev.c:int optimize_size = 0;
> toplev.c: if (flag_prefetch_loop_arrays > 0 && optimize_size)
These are OK.
> tree-inline.c: if (size < 0 || size > MOVE_MAX_PIECES * MOVE_RATIO
> (!optimize_size))
This lacks context to call one of the optimize_*_for_size_p functions.
So this is OK.
> tree-inline.c: || (caller_opt->optimize_size != callee_opt->optimize_size))
This is inside an #if 0'ed block and would not be a reference to the
global variable optimize_size anyway. It looks like this code, if
enabled again, would need modifications to make it compile again.
In general, any reference to the global var optimize_size should be
checked to verify that there shouldn't be a more fine-grained check
instead.
Ciao!
Steven
Re: -Os is weak...
On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie wrote: > $ grep optimize_size *.c Try egrep "optimize_.*_for_speed|optimize_.*_for_size" * config/*/* Ciao! Steven
Re: Merging Apple's Objective-C 2.0 compiler changes
On 09/09/2010 20:19, Jack Howarth wrote: >> On 09/09/2010 12:01, Mike Stump wrote: >>> Chris Lattner could provide an Apple answer, I'd recommend contacting him. >Perhaps a rational approach would be to contact whoever at Apple currently > is > charged with maintaining their objc languages about the issue. Yep, Mike suggested it, and I was just enlarging on why it is really the only valid way to get the changes into trunk. cheers, DaveK
Re: Merging Apple's Objective-C 2.0 compiler changes
On Thu, Sep 09, 2010 at 08:27:16PM +0100, Dave Korn wrote: > On 09/09/2010 12:01, Mike Stump wrote: > > On Sep 9, 2010,@3:11 AM, Nicola Pero wrote: > >> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications > >> to GCC into FSF GCC trunk ? > > > > My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. > > Chris Lattner could provide an Apple answer, I'd recommend contacting him. > > We've just had a similar discussion on the binutils list about some changes > in Atmel's AVR32 compilers, and the conclusion we arri...@was that this > can't "just be done" by a third party, even in the presence of a blanket > corporate assignment: > > >> If we start producing patches to the current FSF GCC trunk that merge > >> these modifications, would they be accepted ? > > > > Sure, after Apple or the FSF (or someone else around here) weighs in on the > > matter. I wouldn't expect it to be a problem, as Apple does have an > > assignment and Apple does own the work in question and Apple does > > distribute it to the general public under a GPL v 2 or later clause. > > But: the assignment only applies to patches that are *explicitly* submitted > by the copyright holder to the FSF (via the -patches list or similar suitable > mechanism) for inclusion in the upstream source base. (Anything they only use > internally rather than distribute, for example, they don't have to submit or > assign, and even anything they distribute publicly, they aren't obliged to > send upstream, just to fulfill the source guarantee to downstream recipients.) > > *Until and unless* Apple itself submits the code to the FSF, Apple retains > the copyright; which means that nobody else has the right to submit it to the > FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment > that allows them to sub-assign but that sounds even more complicated to > me.) > > cheers, > DaveK Perhaps a rational approach would be to contact whoever at Apple currently is charged with maintaining their objc languages about the issue. If the issue is framed in terms of insuring that their definition of the Objective C language has availability outside of their own platforms, the issue might have more traction. The major question is what happens to their own internal branches? Hopefully FSF tolerates the idea that their own internal GPLv2 branches retain their same status and that only FSF trees with the contributed code exist under GPL v3. That is the code effectively forks again at the contribution revision point (just as if the relicensing of gcc at 4.2.1 had happened at a later date). Jack
Re: Merging Apple's Objective-C 2.0 compiler changes
On 09/09/2010 12:01, Mike Stump wrote: > On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: >> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications >> to GCC into FSF GCC trunk ? > > My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. > Chris Lattner could provide an Apple answer, I'd recommend contacting him. We've just had a similar discussion on the binutils list about some changes in Atmel's AVR32 compilers, and the conclusion we arrived at was that this can't "just be done" by a third party, even in the presence of a blanket corporate assignment: >> If we start producing patches to the current FSF GCC trunk that merge >> these modifications, would they be accepted ? > > Sure, after Apple or the FSF (or someone else around here) weighs in on the > matter. I wouldn't expect it to be a problem, as Apple does have an > assignment and Apple does own the work in question and Apple does > distribute it to the general public under a GPL v 2 or later clause. But: the assignment only applies to patches that are *explicitly* submitted by the copyright holder to the FSF (via the -patches list or similar suitable mechanism) for inclusion in the upstream source base. (Anything they only use internally rather than distribute, for example, they don't have to submit or assign, and even anything they distribute publicly, they aren't obliged to send upstream, just to fulfill the source guarantee to downstream recipients.) *Until and unless* Apple itself submits the code to the FSF, Apple retains the copyright; which means that nobody else has the right to submit it to the FSF. (Unless Apple gives /them/ (the hypothetical third party) an assignment that allows them to sub-assign but that sounds even more complicated to me.) cheers, DaveK
Re: Merging Apple's Objective-C 2.0 compiler changes
Chris thanks a lot for your answer. That makes sense - I had not realized that most of the Apple GCC Objective-C / Objective-C++ changes were already sitting on the FSF servers in an Apple branch :-) Can someone from the FSF confirm that it's OK to merge code from there ? I did look at the branch, and it contains most of the functionality (so it's very useful) but unfortunately it's quite old (eg. it's still using c-parse.in to parse). Why don't you upload one of the recent Apple GCC tarballs in a branch on the FSF server ? It won't change/cost anything for Apple (the code is already distributed to the world under GPL v2+) but it means changes could be merged back into the FSF GCC which could have much better support for Apple platforms. More choice of compilers for Apple users is surely good for Apple. :-) You don't have to do it, but contributing changes back to the original project seems to be the right, honourable thing to do, particularly when it doesn't cost anything. And most/all improvements you make to GCC are for Apple machines, so certainly you want these improvements back into the FSF GCC to get more software work on Apple machines and sell more of them. :-) Thanks
Re: Cross-platform build problem
Hello Piotr, * Piotr Wyderski wrote on Thu, Sep 09, 2010 at 12:24:07PM CEST: > I'm trying to compile a GCC toolchain with target=arm-elf > and hosted on Cygwin/PC. Unfortunately, both GCC 4.5.1, > taken from the official mirror, and 4.6 trunk taken from SVN > fail to compile with the following error message: > > checking dynamic linker characteristics... no > checking how to hardcode library paths into programs... immediate > checking for shl_load... configure: error: Link tests are not allowed after > GCC_ > NO_EXECUTABLES. > make[1]: *** [configure-target-libstdc++-v3] Error 1 > > They were configured with: > > $ ../configure --prefix=/opt/arm/gcc-4.5.1 --target=arm-elf --enable-interwork > --enable-multilib --enable-languages=c,c++ The explanation for this is probably analog to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174#13 and the current set of configure cache variables you might have to override can be found at http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at (there's one more missing for IRIX that I know of). So a workaround would be to manually add ac_cv_lib_dld_shl_load=no to $target/libstdc++-v3/config.cache, and then rerunning make. This still needs to be fixed in an automatic way. Cheers, Ralf
Re: -Os is weak...
> Some backends also check optimize_size to change their cost algorithms > to favor shorter instruction sequences. But why doesn't it do what the documentation says? -falign-* seems like an obvious one - aligning labels and such always makes the code bigger.
Re: -Os is weak...
On Thu, Sep 9, 2010 at 10:16 AM, Ian Lance Taylor wrote: > Some backends also check optimize_size to change their cost algorithms > to favor shorter instruction sequences. Also see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996 for all the other known code size improvements that could be done. Thanks, Andrew Pinski
Re: -Os is weak...
DJ Delorie writes: > But in reality, the only thing -Os does beyond -O2, aside from a few > niche special cases, is enable inlining, and maybe scheduling, which > for some cases may be the wrong thing to do. Some backends also check optimize_size to change their cost algorithms to favor shorter instruction sequences. Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: > Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to > GCC into FSF GCC trunk ? > Any legal obstacles ? > > If we start producing patches to the current FSF GCC trunk that merge these > modifications, would they be accepted ? > > I think Apple would benefit from merging of their modifications in that we'd > merge the Apple/NeXT runtime support as well. :-) > They don't have to do any work. Be aware that none of the changes that haven't been committed to the FSF trees are copyright-assigned to the FSF. In practice, since the FSF cares about copyright assignment, this probably means that you can probably merge whatever is in the apple branch on the FSF server, but you can't take things out of llvm-gcc or the apple gcc tarballs that get pushed out on opendarwin. I'm not a lawyer, so this isn't legal advice, just my understanding of FSF policies and the mechanics of how the copyright transfer works. -Chris
Re: g++ segfault when using C++0x feature
On 7 September 2010 22:50, James Dennett wrote: > I suspect we don't want to put a lot of effort into fixing C++0x > experimental support in GCC 4.4.x. In general that's correct, but in this case it's already fixed on the 4.4 branch, 4.4.4 doesn't crash. Nate, It's always worth trying an up-to-date release when using experimental features.
-Os is weak...
The docs say...
@item -Os
@opindex Os
Optimize for size. @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size. It also performs further
optimizations designed to reduce code size.
@option{-Os} disables the following optimization flags:
@gccoptlist{-falign-functions -falign-jumps -falign-loops @gol
-falign-labels -freorder-blocks -freorder-blocks-and-partition @gol
-fprefetch-loop-arrays -ftree-vect-loop-version}
But in reality, the only thing -Os does beyond -O2, aside from a few
niche special cases, is enable inlining, and maybe scheduling, which
for some cases may be the wrong thing to do.
Is this what we want?
flag_schedule_insns = opt2 && ! optimize_size;
if (optimize_size)
{
/* Inlining of functions reducing size is a good idea regardless of them
being declared inline. */
flag_inline_functions = 1;
/* Basic optimization options. */
optimize_size = 1;
if (optimize > 2)
optimize = 2;
/* We want to crossjump as much as possible. */
set_param_value ("min-crossjump-insns", 1);
}
else
set_param_value ("min-crossjump-insns", initial_min_crossjump_insns);
$ grep optimize_size *.c
genconditions.c: { "! optimize_size && ! TARGET_READ_MODIFY_WRITE",
genconditions.c: __builtin_constant_p (! optimize_size && !
TARGET_READ_MODIFY_WRITE)
genconditions.c: ? (int) (! optimize_size && ! TARGET_READ_MODIFY_WRITE)
opts.c: optimize_size = 0;
opts.c: optimize_size = 0;
opts.c: optimize_size = 1;
opts.c: optimize_size = 0;
opts.c: flag_schedule_insns = opt2 && ! optimize_size;
opts.c: if (optimize_size)
opts.c: optimize_size = 1;
opts.c: OPTIMIZATION_OPTIONS (optimize, optimize_size);
predict.c: if (optimize_size)
predict.c: return (optimize_size
toplev.c: The only valid values are zero and nonzero. When optimize_size is
toplev.c:int optimize_size = 0;
toplev.c: if (flag_prefetch_loop_arrays > 0 && optimize_size)
tree-inline.c: if (size < 0 || size > MOVE_MAX_PIECES * MOVE_RATIO
(!optimize_size))
tree-inline.c:|| (caller_opt->optimize_size != callee_opt->optimize_size))
Bootstrap failure on x86 and sparc Solaris
Hi. No luck with today's GCC builds - both my x86 and sparc builds failed this morning. i386-pc-solaris2.10: The build failed in 'stage2': /home/ahaas/gnu/gcc.git/gcc/dwarf2out.c: In function 'get_ref_die_offset_label':/home/ahaas/gnu/gcc.git/gcc/dwarf2out.c:6549:5: error: format '%lld' expects type 'long long int', but argument 4 has type 'dw_offset' [-Werror=format] cc1: all warnings being treated as errors make[3]: *** [dwarf2out.o] Error 1 make[3]: *** Waiting for unfinished jobs My build from yesterday was successful: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/ahaas/gnu/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --enable-checking=release --enable-threads=posix --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --enable-objc-gc --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.0 20100908 (experimental) (GCC) sparc-sun-solaris2.10: The build failed in 'stage1': /var/tmp//ccYaGaCW.s: Assembler messages: /var/tmp//ccYaGaCW.s:1401: Error: value of 0289029f33c2 too large for field of 4 bytes at 011a /var/tmp//ccYaGaCW.s:1407: Error: value of 0289029f3440 too large for field of 4 bytes at 012a gmake[3]: *** [_moddi3.o] Error 1 gmake[3]: *** Waiting for unfinished jobs My build from two days ago was successful: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.6.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /export/home/arth/src/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local --enable-checking=release --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --with-cpu=ultrasparc3 --with-tune=ultrasparc3 Thread model: posix gcc version 4.6.0 20100907 (experimental) (GCC) Art Haas
Re: Merging Apple's Objective-C 2.0 compiler changes
> I assume Apple had signed a copyright assignment to the FSF for all > changes to GCC, moreover I checked > the modified GCC source code that Apple distributes and all the > copyright notices on all files mention the > "Free Software Foundation Inc." as the copyright holder. > > I guess that means the changes have already been assigned to the FSF > and we're free to merge ? :-) The copyright notice on the files has no legal significance. You need to make sure that: (1) There is a copyright assignment on file. (2) You get the files from Apple directly in a way that makes it clear that the assignment applies to those files.
Re: question on points-to analysis
On Thu, Sep 9, 2010 at 1:19 PM, Amker.Cheng wrote: > Hi, > I am studying gcc's points-to analysis right now and encountered a question. > In paper "Off-line Variable Substitution for Scaling Points-to > Analysis", section 3.2 > It says that we should not substitute a variable with other if it is > taken address. > But in GCC's implementation, it units pointer but not location > equivalent variables > in function unite_pointer_equivalences. > I am puzzled why gcc does this operation and How gcc keeps accuracy of > points-to > information after doing this. > > Further more, I did not found any words about this in paper > "Exploiting Pointer and Location Equivalence to Optimize Pointer > Analysis", which > according comments in gcc, is the basis of GCC's implementation. > > Any tips?Thanks in advance. Danny should have the answers to these questions buried deep in his mind. ;) Richard. > -- > Best Regards. >
question on points-to analysis
Hi, I am studying gcc's points-to analysis right now and encountered a question. In paper "Off-line Variable Substitution for Scaling Points-to Analysis", section 3.2 It says that we should not substitute a variable with other if it is taken address. But in GCC's implementation, it units pointer but not location equivalent variables in function unite_pointer_equivalences. I am puzzled why gcc does this operation and How gcc keeps accuracy of points-to information after doing this. Further more, I did not found any words about this in paper "Exploiting Pointer and Location Equivalence to Optimize Pointer Analysis", which according comments in gcc, is the basis of GCC's implementation. Any tips?Thanks in advance. -- Best Regards.
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote: > Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to > GCC into FSF GCC trunk ? My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. Chris Lattner could provide an Apple answer, I'd recommend contacting him. > If we start producing patches to the current FSF GCC trunk that merge these > modifications, would they be accepted ? Sure, after Apple or the FSF (or someone else around here) weighs in on the matter. I wouldn't expect it to be a problem, as Apple does have an assignment and Apple does own the work in question and Apple does distribute it to the general public under a GPL v 2 or later clause. Once someone else green lights that, I'd pre-approve the integration of gcc/objc/*.
Re: Merging Apple's Objective-C 2.0 compiler changes
Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to GCC into FSF GCC trunk ? Any legal obstacles ? I assume Apple had signed a copyright assignment to the FSF for all changes to GCC, moreover I checked the modified GCC source code that Apple distributes and all the copyright notices on all files mention the "Free Software Foundation Inc." as the copyright holder. I guess that means the changes have already been assigned to the FSF and we're free to merge ? :-) Thanks
Cross-platform build problem
Hello, I'm trying to compile a GCC toolchain with target=arm-elf and hosted on Cygwin/PC. Unfortunately, both GCC 4.5.1, taken from the official mirror, and 4.6 trunk taken from SVN fail to compile with the following error message: checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_ NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 They were configured with: $ ../configure --prefix=/opt/arm/gcc-4.5.1 --target=arm-elf --enable-interwork --enable-multilib --enable-languages=c,c++ Best regards, Piotr Wyderski
Arun Khanna would like to add you as a friend
Arun Khanna would like to add you as a friend on Skoost. To see some friend photos and find out more, follow the link below: http://www.skoost.com/?id=50711272_50670809&; People you may know already using Skoost: Arun Khanna, Debasish Tabla, Info, Rakesh Saxena, Sitar Indrani, Ved Pal, Shashi Moon, Madhavan Unni, Veera Mani, Satish Kolli, Shehnai Waden Wedding, Uday Kulkarni, Uday Raj, Soumya, Bibhuti Bhusan Sahoo, Aaa Gupta... - Skoost Team Skoost enables you to share short messages, virtual gifts and virtual emotions with your friends. Follow this link, http://www.skoost.com/?id=50711272_50670809_1&;, if you do not want to receive more e-mails from your friends.
Merging Apple's Objective-C 2.0 compiler changes
Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to GCC into FSF GCC trunk ? Any legal obstacles ? If we start producing patches to the current FSF GCC trunk that merge these modifications, would they be accepted ? I think Apple would benefit from merging of their modifications in that we'd merge the Apple/NeXT runtime support as well. :-) They don't have to do any work. Thanks
Re: Built-ins for C99 macros isfinite, isnan, isnormal, isinf, signbit
> I don't know if you noticed, but the C++ runtime library started using > the builtins exclusively in 4.4.0, we exposed a small bug (fixed by > Richard I think), where the compiler crashed for an integer type > argument, but otherwise *nobody* complained so far. Wow, now that's a pretty strong argument for it! Thanks, FX
Re: Built-ins for C99 macros isfinite, isnan, isnormal, isinf, signbit
On 09/09/2010 11:43 AM, FX wrote: > Thus, my question is: Is there any risk in doing so? > I don't know if you noticed, but the C++ runtime library started using the builtins exclusively in 4.4.0, we exposed a small bug (fixed by Richard I think), where the compiler crashed for an integer type argument, but otherwise *nobody* complained so far. Paolo.
Built-ins for C99 macros isfinite, isnan, isnormal, isinf, signbit
I have a questions regarding GCC C99 built-ins: isfinite, isnan, isnormal,
isinf and signbit.
Currently, libgfortran (which is compiled with -std=c99) has a few configure
tests and target-specific hacks to provide reasonable versions of the macros
above: using the ones in headers if they are present and seem to work,
relying on fpclassify for some targets that have it, and otherwise doing stuff
like:
#define isfinite(x) ((x) - (x) == 0)
#define isnan(x) ((x) != (x))
I'm tempted to remove all this, and have us use
__builtin_{isfinite,isnormal,isinf,signbit}. In addition, the GCC built-ins are
really type-generic, while the macros from the system headers don't handle
unusual fp types such as __float128.
Thus, my question is: Is there any risk in doing so? Are there targets where
the GCC built-ins perform significantly worse (e.g. being nonfunctional, or
incapable of handling some of the fp modes) than those from the system headers?
I don't expect so, but I'd be glad to have someone familiar with the middle-end
confirm this for me.
Thanks,
FX
Re: Question on TER
On Thu, Sep 9, 2010 at 10:46 AM, Richard Guenther wrote: >> 1) Is this a valid optimization in general to attempt wrt other targets >> (i.e. prevent replacement across calls)? > > I think it makes sense in general. ISTR we even used to do so in the past...? >> 2) Is there a way to recognize the __builtin_XXX() calls such that we know >> they result in simple insns an not a real call? > > Unfortunately not easily. What about just discounting all builtins? Or allow replacing across a BUILT_IN_MD but not other built-ins. BUILT_IN_NORMAL is more likely to result in a real function call than an MD builtin. I think you should allow TER across some GIMPLE calls if you can be reasonably sure that the GIMPLE call will not result in an actual call insn. It'd be a bit of "fake accuracy". For example, you also can't avoid replacing across GIMPLE non-call statements that expand to libcalls and such... Ciao! Steven
Re: Switch case ordering
Richard Henderson writes: > On 09/08/2010 02:25 PM, Paulo J. Matos wrote: >> Should I discuss it with someone? > > Almost certainly. How about everyone? I would post your progress > to gcc-patches and ask for comments. I will try to get something into gcc-patches soon. Thanks. -- PMatos
Re: Question on TER
On Thu, Sep 9, 2010 at 4:13 AM, Pat Haugen wrote:
> I'm looking into a case where TER is forward propagating a series of
> additions across a call.
>
> extern void foo(void);
> int bar(int a, int b, int c, int d, int e, int f, int g, int h) {
> int ret;
> ret = a + b + c + d + e + f + g + h;
> foo();
> return ret; /* 'ret' use replaced by rhs above */
> }
>
> Unfortunately by moving all the additions across the call we've extended the
> lifetimes of the parm regs across the call also and therefor they need to be
> copied into callee-saved regs to preserve their value across the call, which
> means bar() will have save/restore code for 8 regs instead of just 1 (to
> thold the result across the call).
>
> I tried hacking tree-ssa-ter.c to not perform the replacement if the def and
> use cross a call (i.e. cross an is_gimple_call() stmt), but ran into cases
> where we don't do a valid replacement because things like
> __builtin_sqrtf()/__builtin_powf() are marked as calls but expand to simple
> instructions (on PPC anyway). The __builtin_powf() calls were actually
> introduced on a transformation of y*y => __builtin_powf(y,2.0).
>
> A couple of questions:
>
> 1) Is this a valid optimization in general to attempt wrt other targets
> (i.e. prevent replacement across calls)?
I think it makes sense in general.
> I assume this could further be
> refined so that we still do replacement across calls if the source operands
> of the expression are already live at the use point, but haven't looked into
> that.
Hm, indeed - sinking of loads across a call might be still beneficial.
> 2) Is there a way to recognize the __builtin_XXX() calls such that we know
> they result in simple insns an not a real call?
Unfortunately not easily. What about just discounting all builtins?
Richard.
>
> -Pat
>
>
>
