GCC 4.3.1 Released
GCC 4.3.1 has been released. GCC 4.3.1 is a bug-fix release, containing fixes for regressions in GCC 4.3.0 relative to previous GCC releases. See: http://gcc.gnu.org/gcc-4.3/changes.html and particularly http://gcc.gnu.org/gcc-4.3/changes.html#4.3.1 for more information about changes in GCC 4.3.1. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.3.1/ subdirectory. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!
Re: New picoChip port and maintainers
Hi David/SC, Thanks again for accepting the picochip port in GCC. Although the picochip port has been accepted by the Steering Committee, we have had trouble getting a GWP maintainer to review the port. All the GWP maintainers seem to be extremely busy. I have emailed all of them, but haven't been successful in getting a review. In light of this, would it be possible for the SC to allow the port to be reviewed by other port maintainers? Regards Hari David Edelsohn wrote: I am pleased to announce that the GCC Steering Committee has accepted the picoChip port for inclusion in GCC and appointed Hariharan Sandanagobalane and Daniel Towner as port maintainers. The initial patch needs approval from a GCC GWP maintainer before it may be committed. Please join me in congratulating Hari and Daniel on their new role. Please update your listing in the MAINTAINERS file. Happy hacking! David
[gomp3][tuples] TM for GCC
Dear GCC-Developers, my name is Martin Schindewolf and I am a student about to start his PhD. Currently, my funding comes from HiPEAC, a European Network that has been encouraging and funding GCC related projects in the past. Please have a look at the home page for details about HiPEAC[1] and the compilation platform[2]. The goal of my particular project is to come up with a robust and stable implementation of transactional memory support for GCC. We plan to release the implementation as a development branch of the GCC under the GPL. Hopefully, other people interested in TM research will be inspired and base their research on it. On the other hand, our work should help to facilitate the use of TM among programmers and we hope to see some real applications using TM. For now our major design goals are to be orthogonal to other parallel programming models (such as OpenMP), to support exception handling and to concentrate on the basic STM features (such as the closed nesting of transactions). We are open for discussion on the features and hoping to get some recommendations which STMs you would like to see supported. Our initial pick is the tinySTM because it is released under the GPL and the maintaining people are willing to answer to our questions. Of course we want to support other STM implementations as well so that the user may choose from different STMs. Since a lot of ongoing work in GCC may have a great effect on our implementation, we are interested in particular feedback from the developers of the Tuple and the GOMP 3.0 branches. Thank you very much for getting back to us. Our initial design document is available [3]. Regards, Martin Schindewolf [1] http://www.hipeac.net/ [2] http://www.hipeac.net/node/2169 [3] http://www.hipeac.net/node/2419
[tuples] Merge from [EMAIL PROTECTED]
On Sun, Jun 08, 2008 at 06:49:39PM -0400, Diego Novillo wrote: > This brings in everything from trunk just before the new OMP3 changes. > Jakub, you can do the omp3 merge now. David, this converts > tree-call-cdce.c to use tuples. The only change is the removal of the > flag that I mentioned earlier, if this is something you think it > shouldn't be merged into mainline, please let me know. And I've merged with trunk -r136432:136433, i.e. the OpenMP 3.0 commit. Now you can merge -r136433:REVISION_OF_THE_DAY from the trunk again. Jakub
Default warnings and useless extensions (e.g. arithmetic on void *)
Is there any reason why "gcc -Wall" doesn't emit warnings by default
on some useless extensions such as pointer arithmetic on (void *)?
IMHO, such an extension is useless because there's an easy workaround:
use casts to char *. And since g++ barfs on pointer arithmetic on
void *, such a warning would be very useful. BTW, gcc is also silent
when -Wc++-compat is used! With gcc/g++ 4.3.1:
vin% cat ptrarith.c
void *foo (void *p)
{
return p + 1;
}
vin% gcc -Wall -Wc++-compat -c ptrarith.c
vin% g++ -c ptrarith.c
ptrarith.c: In function 'void* foo(void*)':
ptrarith.c:3: error: pointer of type 'void *' used in arithmetic
vin%
So, basically shouldn't -Wpointer-arith (and possible other ones) be
added to the options enabled by -Wall?
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:
Re: Default warnings and useless extensions (e.g. arithmetic on void *)
On Mon, Jun 9, 2008 at 3:46 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote: > Is there any reason why "gcc -Wall" doesn't emit warnings by default > on some useless extensions such as pointer arithmetic on (void *)? Use -pedantic to warn about extensions. It doesn't make sense to warn for extensions if they are not deprecated. After all they are extensions. Richard.
Re: Default warnings and useless extensions (e.g. arithmetic on void *)
2008/6/9 Richard Guenther <[EMAIL PROTECTED]>: > On Mon, Jun 9, 2008 at 3:46 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote: >> Is there any reason why "gcc -Wall" doesn't emit warnings by default >> on some useless extensions such as pointer arithmetic on (void *)? > > Use -pedantic to warn about extensions. It doesn't make sense to > warn for extensions if they are not deprecated. After all they are > extensions. Nonetheless, I think that the part about -Wc++-compat not warning about pointer of type 'void *' used in arithmetic is a valid criticism. Don't you agree? Cheers, Manuel.
Re: Default warnings and useless extensions (e.g. arithmetic on void *)
On Mon, Jun 9, 2008 at 4:07 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > 2008/6/9 Richard Guenther <[EMAIL PROTECTED]>: >> On Mon, Jun 9, 2008 at 3:46 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote: >>> Is there any reason why "gcc -Wall" doesn't emit warnings by default >>> on some useless extensions such as pointer arithmetic on (void *)? >> >> Use -pedantic to warn about extensions. It doesn't make sense to >> warn for extensions if they are not deprecated. After all they are >> extensions. > > Nonetheless, I think that the part about -Wc++-compat not warning > about pointer of type 'void *' used in arithmetic is a valid > criticism. Don't you agree? Yes. But -Wc++-compat is far from complete. Richard.
Re: RFC: Extend x86-64 psABI for 256bit AVX register
> On Fri, Jun 06, 2008 at 06:50:26AM -0700, H.J. Lu wrote: > > On Fri, Jun 06, 2008 at 10:28:34AM +0200, Jan Hubicka wrote: > > > > > > > > ymm0 and xmm0 are the same register. xmm0 is the lower 128bit > > > > of xmm0. I am not sure if we need separate XMM registers from > > > > YMM registers. > > > > > > > > > Yes, I know that xmm0 is lower part of ymm0. I still think we ought to > > > be able to support varargs that do save ymm0 registers only when ymm > > > values are passed same way as we touch SSE only when SSE values are > > > passed via EAX hint. > > > > Which register do you propose for hint? The current psABI uses RAX > > for XMM registers. We can't change it to AL and AH for YMM without > > breaking backward compatibility. > > > > > This way we will be able to support e.g. printf that has YMM printing % > > > construct but don't need YMM enabled hardware when those are not used. > > > > > > This is why I think extending EAX to contain information about amount of > > > XMM values to save and in addition YMM values to save is sane. Then old > > > non-YMM aware varargs prologues will crash when YMM values are passed, > > > but all other combinations will work. > > > > I don't think it is necessary since -mavx will enable AVX code > > generation for all SSE codes. Unless the function only uses integer, > > it will crash on non-YMM aware hardware. That is if there is one > > SSE register is used, which is hinted in RAX, varargs prologue will > > use AVX instructions to save it. We don't need another hint for AVX > > instructions. > > > > > > > > > > > > > > > > I personally don't have much preferences over 1. or 2.. 1. seems > > > > > relatively easy to implement too, or is packaging two 128bit values to > > > > > single 256bit difficult in va_arg expansion? > > > > > > > > > > > > > Access to 256bit register as lower and upper 128bits needs 2 > > > > instructions. For store > > > > > > > > vmovaps %xmm7, -143(%rax) > > > > vextractf128 $1, %ymm7, -15(%rax) > > > > > > > > For load > > > > > > > > vmovaps -143(%rax),%xmm7 > > > > vinsert128 $1, -15(%rax),%ymm7,%ymm7 > > > > > > > > If we go beyond 256bit, we need more instructions to access > > > > the full register. For 512bit, it will be split into lower 128bit, > > > > middle 128bit and upper 256bit. 1024bit will have 4 parts. > > > > > > > > For #2, only one instruction will be needed for 256bit and > > > > beyond. > > > > > > Yes, but we will still save half of stack space. Well, I don't have > > > much preferences here. If it seems saner to simply save whole thing > > > saving lower part twice, I am fine with that. > > > > I was told that it wasn't very easy to get decent performance with > > split access. I extended my proposal to include a 16bit bitmask to > > indicate which YMM regisetrs should be saved. If the bit is 0, > > we should only save the the lower 128bit in the original register > > save area. Otherwise, we should only save the same whole YMM register. > > > > My second thought. How useful is such a bitmask? Do we really > need it? Is that accepetable to save the lower 128bit twice? I dont' see much benefit in bitmask. I think we only should try to enforce: 1) that AVX prologue will not ICE on non-AVX hardware for functions not using AVX va_arg constructs. 2) backward compatibility with current va_lists. That is make calling AVX function from non-AVX code work as well as calling non-AVX function from AVX code. I don't think unconditionally saving the AVX registers or guarding them same way as we do for SSE is good because it breaks 1). We can't use new register to hint number of AVX operands, because the register would be uninitialized in non-AVX code. Still it seems to me that we can use extend current eax convention. Currently the value must be in range 0...8 as it specify number of SSE registers. We can pack both numbers into it. This way we get unforutnately wild jump on case of AVX code calling non-AVX function and passing in AVX arguments, but this seems less important than 1) and 2) to me and I don't see how to get all three cases working. Duplicating the value seems OK with me if it simplifies implementation significandly. Honza > > Thanks. > > > H.J.
LLVM 2.3 Released
Hi all, For anyone who is interested, we just released LLVM 2.3: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-June/27.html http://llvm.org/releases/2.3/docs/ReleaseNotes.html It has many improvements over the 2.2 release from February, including better support for gfortran and Ada, better generated code, and lower compile time among other things. Please see the release notes for details. -Chris
Re: LLVM 2.3 Released
Chris, Are there any specific plans for moving llvm-gcc from the gcc 4.2 to the gcc 4.3 code base? Jack On Mon, Jun 09, 2008 at 09:09:29AM -0700, Chris Lattner wrote: > Hi all, > > For anyone who is interested, we just released LLVM 2.3: > > http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-June/27.html > http://llvm.org/releases/2.3/docs/ReleaseNotes.html > > It has many improvements over the 2.2 release from February, including > better support for gfortran and Ada, better generated code, and lower > compile time among other things. Please see the release notes for details. > > -Chris >
Re: LLVM 2.3 Released
>Are there any specific plans for moving llvm-gcc from the > gcc 4.2 to the gcc 4.3 code base? I plan to port llvm-gcc to gcc head, since I'm interested in the Ada front-end and the Ada support in gcc-4.4 is much better than in gcc-4.2. However I can't say when this will happen, since I don't have much time to spend on it. Best wishes, Duncan.
[graphite] Loop tiling
Hi Sebastian, Hi Cedric,
since Thursday I think about how to implement loop tiling in graphite.
Lets start with a simple example:
for (i=0;i<=10;i++) {
for (j=0;j<=20;j++) {
S1 ;
}
}
# eq/in i j n 1
1 1 0 0 0 # i >= 0
1 -1 0 0 10 # i <= 10
1 0 1 0 0 # j >= 0
1 0 -1 0 20 # j <= 20
What I would like to generate is:
for (p1=0;p1<=10;p1+=2) {
for (p2=0;p2<=20;p2+=2) {
for (i=p1;i<=min(10,p1+1);i++) {
for (j=p2;j<=min(20,p2+1);j++) {
S1 ;
}
}
}
}
So there seem to be different ways to make cloog generate this code:
Solution 1: Change the cloog domain matrix.
===
What to do:
- Add two more dimensions.
- Copy the restrictions of i and j to p1 and p2.
- Add the new restrictions to connect i and j.
The domain for S1:
# eq/in p1 p2 i j n 1
1 1 0 0 0 0 0 # p1 >= 0
1 -1 0 0 0 0 10 # p1 <= 10
1 0 1 0 0 0 0 # p2 >= 0
1 0 -1 0 0 0 20 # p2 <= 20
1 -1 0 1 0 0 0 # i >= p1
1 1 0 -1 0 0 1 # i <= p1 + 1
1 0 -1 0 1 0 0 # j >= p2
1 0 1 0 -1 0 1 # j <= p2 + 1
1 0 0 1 0 0 0 # i >= 0
1 0 0 0 1 0 0 # i <= 10
1 0 0 -1 0 0 10 # j >= 0
1 0 0 0 -1 0 20 # j <= 20
What I get:
for (p1=0;p1<=10;p1++) {
for (p2=0;p2<=20;p2++) {
for (i=p1;i<=min(10,p1+1);i++) {
for (j=p2;j<=min(20,p2+1);j++) {
S1 ;
}
}
}
}
The problem:
This code is not correct, as we iterate over all values of p1, but we
only should iterate over the even values.
I have no idea how to restrict p1 only to even values. But this seems to
be the only way to change "p1++" to "p1+=2".
Solution 2: Use scattering function:
To create this code I used the cloog scattering functions and the
original unmodified domain:
for (p1=0;p1<=5;p1++) {
for (p2=0;p2<=10;p2++) {
for (i=max(2*p1,0);i<=min(10,2*p1+1);i++) {
for (j=max(2*p2,0);j<=min(20,2*p2+1);j++) {
S1 ;
}
}
}
}
Scattering:
# eq/in p1 p2 p3 p4 p5 p6 p7 p8 i j n 1
12 0 0 0 0 0 0 0 -1 0 0 1 # 2 * p1 >= i
1 -2 0 0 0 0 0 0 0 1 0 0 0 # 2 * p1 <= i + 1
10 2 0 0 0 0 0 0 0 -1 0 1 # 2 * p2 >= j
10 -2 0 0 0 0 0 0 0 1 0 0 # 2 * pr <= j + 1
00 0 1 0 0 0 0 0 0 0 0 0
00 0 0 1 0 0 0 0 0 0 0 0
00 0 0 0 1 0 0 0 0 0 0 0
00 0 0 0 0 1 0 0 0 0 0 0
00 0 0 0 0 0 1 0 0 0 0 0
00 0 0 0 0 0 0 1 0 0 0 0
Domain:
# eq/in i j n 1
1 1 0 0 0 # i >= 0
1 -1 0 0 10 # i <= 10
1 0 1 0 0 # j >= 0
1 0 -1 0 20 # j <= 20
This solution has some advantages:
1. The code is correct
2. It is very easy. Just add two lines to the scattering function.
But some problems:
1. It is not very efficient. As we have many multiplications in the
code.
Will later gcc optimization passes convert these multiplications to
additions?
2. I could not find any documentation about scattering functions, that
describe this way of using the scattering functions.
3. At the moment I have to investigate, if we can mix this approach with
the normal scattering to regenerate the original control flow.
Solution 3. Other ideas??
===
Has someone another idea, how to implement loop tiling?
Another graphite specific problem is, how we connect the real loop
variables to the cloog variables. Before loop tiling this was easy.
Loops of the same depth in the cloog output correspond to the loops of
the same depth in the original gimple loop nest. But know we have to add
some data structure, that connects the gimple loops, with the cloog
loops.
Thanks
Tobi
Re: [graphite] Loop tiling
Hi Tobi, Thanks for working on this. Solution 2 is the right one. On Mon, Jun 9, 2008 at 11:58 AM, Tobias Grosser <[EMAIL PROTECTED]> wrote: > 1. It is not very efficient. As we have many multiplications in the > code. > Will later gcc optimization passes convert these multiplications to > additions? > Yes, you should not worry about scalar optimizations at all. > 2. I could not find any documentation about scattering functions, that > describe this way of using the scattering functions. > I think that the best place to look at this is: page 4 of http://www.lri.fr/~girbal/publi/ics05_facilitating.ps also have a look at the other reports from: http://www.lri.fr/~girbal/site_wrapit/ Albert probably has some other pointers for reports that describe how to do loop tiling. > Another graphite specific problem is, how we connect the real loop > variables to the cloog variables. Before loop tiling this was easy. > Loops of the same depth in the cloog output correspond to the loops of > the same depth in the original gimple loop nest. But know we have to add > some data structure, that connects the gimple loops, with the cloog > loops. > This was also the case before: we needed a map between the old induction variable and the new ones. Sebastian Pop -- AMD - GNU Tools
gcc-4.1-20080609 is now available
Snapshot gcc-4.1-20080609 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080609/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 136601 You'll find: gcc-4.1-20080609.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080609.tar.bz2 C front end and core compiler gcc-ada-4.1-20080609.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080609.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080609.tar.bz2 C++ front end and runtime gcc-java-4.1-20080609.tar.bz2 Java front end and runtime gcc-objc-4.1-20080609.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080609.tar.bz2The GCC testsuite Diffs from 4.1-20080602 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
constified note_stores
I have been using note_stores to modify selected assignments. Now when I try to move this code to gcc 4.4, I find that I get a warning because my walker function takes a non-const rtx - and if I make it take a const rtx, there will be a warning somewhere inside because there is a code path where a SET_SRC is modified. data is in use to point to a libiberty hash table. So, am I supposed to ignore the warning? Roll my own copy of the original note_stores? Resurrect the original note_stores in rtlanal.c (by whatever name)?
Re: constified note_stores
Joern Rennecke <[EMAIL PROTECTED]> writes: > I have been using note_stores to modify selected assignments. Now when I > try to move this code to gcc 4.4, I find that I get a warning because > my walker function takes a non-const rtx - and if I make it take a const rtx, > there will be a warning somewhere inside because there is a code path > where a SET_SRC is modified. > data is in use to point to a libiberty hash table. > > So, am I supposed to ignore the warning? > Roll my own copy of the original note_stores? > Resurrect the original note_stores in rtlanal.c (by whatever name)? Use CONST_CAST_RTX where necessary. Ian
Thread safety annotations and analysis in GCC
Hi, We have been working on creating program annotations for C/C++ (in GCC attributes) to help developers document locks and how they need to be used to safely read and write shared variables in multi-threaded code. We've also implemented a new GCC pass that uses the annotations to identify and warn about the issues that could potentially result in race conditions and deadlocks. Here is the design doc for the proposed annotations: http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr Attached please find also find the patch file that contains the initial implementation of the annotations and analysis. Please let me know if you have any feedback/comments/questions on the proposed annotations and the GCC implementation. We will be creating a public branch for people who are interested to start contributing to the project (before the patch is accepted and checked into the trunk). We will send out another email once the public branch is created. Thanks, Le-Chun Wu ts_annotations.patch.gz Description: GNU Zip compressed data
Re: constified note_stores
From: "Ian Lance Taylor" <[EMAIL PROTECTED]> Joern Rennecke <[EMAIL PROTECTED]> writes: I have been using note_stores to modify selected assignments. Now when I try to move this code to gcc 4.4, I find that I get a warning because my walker function takes a non-const rtx - and if I make it take a const rtx, there will be a warning somewhere inside because there is a code path where a SET_SRC is modified. data is in use to point to a libiberty hash table. So, am I supposed to ignore the warning? Roll my own copy of the original note_stores? Resurrect the original note_stores in rtlanal.c (by whatever name)? Use CONST_CAST_RTX where necessary. Ian Or pass in a struct pointer to the "data" parameter containing both your hash table and the rtx to be modified. Pull out either member in the walker function as necessary. Me, I prefer being const-correct, but I understand not everyone shares my enthusiasm for it. :-/ --Kaveh -- Kaveh R. Ghazi
Using __sync_* builtins within libgcc code
I'm making some modifications to exception handling inside of unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't seem to figure out how to correctly use builtins in the context of libgcc. I've tried a bunch of different things, but I consistently get the error bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined reference to `__sync_bool_compare_and_swap_4' so clearly I'm not getting this symbol included correctly when I build. Any advice would be appreciated. Luke
Re: Thread safety annotations and analysis in GCC
"Le-Chun Wu" <[EMAIL PROTECTED]> writes: > > Please let me know if you have any feedback/comments/questions on the > proposed annotations and the GCC implementation. I was surprised that there was no consideration of C indirect function calls in your design document. e.g. I would have expect some way to give a hint that a indirect function call is always called from X to propagate the lock sets. Right now it looks like they will disable the analysis completely, correct? -Andi
Mirror
Hello, I noticed I miss few important things in the first email regarding mirror. Mirror name: gcc.releasenotes.org Mirror url: http://gcc.releasenotes.org Location: USA, TX Supporter: [EMAIL PROTECTED] I hope all fine now. Thnaks. Alex Korolev [EMAIL PROTECTED]
Re: LLVM 2.3 Released
On Jun 9, 2008, at 9:44 AM, Jack Howarth wrote: Chris, Are there any specific plans for moving llvm-gcc from the gcc 4.2 to the gcc 4.3 code base? I don't know of any specific plans for this, though several people have expressed interest. What we need is someone to step forward and do it. I guess this is the classic "patches welcome" answer :). In the meantime, llvm-gcc 4.2 is being well supported and is under active development. -Chris Jack On Mon, Jun 09, 2008 at 09:09:29AM -0700, Chris Lattner wrote: Hi all, For anyone who is interested, we just released LLVM 2.3: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2008-June/ 27.html http://llvm.org/releases/2.3/docs/ReleaseNotes.html It has many improvements over the 2.2 release from February, including better support for gfortran and Ada, better generated code, and lower compile time among other things. Please see the release notes for details. -Chris
Re: Using __sync_* builtins within libgcc code
Luke Dalessandro wrote: I'm making some modifications to exception handling inside of unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't seem to figure out how to correctly use builtins in the context of libgcc. I've tried a bunch of different things, but I consistently get the error bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined reference to `__sync_bool_compare_and_swap_4' so clearly I'm not getting this symbol included correctly when I build. Any advice would be appreciated. Isn't this the well know, annoying, issue that the default sub-architecture is i386 and the builtins are only available on i486 and later? Maybe you can usefully exploit the recently added __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros or add a few more along the same way... Paolo.
