Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target x86_64-pc-mingw32 (cross build from i686-pc-cygwin)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224] (GCC) Platform: x86_64-pc-mingw32 configure flags: - --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw - --with-sysroot=/opt/devel/gnu/cross-gcc/gcc

Re: {gSoc}application : Automatic parallelization in Graphite

Tobias Grosser wrote on 26/03/2009 09:17:26: > On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote: > > Hi all, > > > > Below is the proposal of this gSoc project. I'd really like you review and > > comment on this and then I can plan this project better. > > Hi Li, > > this looks nice. Thanks

gcc.gnu.org ftp down?

Does anyone know why the gcc.gnu.org ftp site is no longer available? Oddly it seems to have also disappeared for at least one of the ftp mirrors in the last day as well... ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc Are we supposed to access the gcc infrastructure directories from

gcc99 inlining rules

Hello, I found the following code doesn't compile with gcc4.4. and -std=c99. Does this behaviour conform to standard? inline int foo(){ return 10; } int main(int argc, char **argv){ return foo(); } I goolged the c99 inlining rule as follows. They does't seem to say such code cannot be

Re: gcc99 inlining rules

On Tue, Mar 31, 2009 at 4:24 PM, Bingfeng Mei wrote: > Hello, > I found the following code doesn't compile with gcc4.4. and -std=c99. Does > this behaviour conform to standard? > > inline int foo(){ >  return 10; > } > > int main(int argc, char **argv){ >  return foo(); > } It works for me. Wha

Re: gcc99 inlining rules

On Tue, 31 Mar 2009, Bingfeng Mei wrote: > Hello, > I found the following code doesn't compile with gcc4.4. and -std=c99. > Does this behaviour conform to standard? It does compile. It may or may not link depending on compilation options, since you are missing an external definition for foo,

new cloog-ppl-0.15.tar.gz broken on darwin

The gcc.gnu.org ftp server is back up. However, the newer cloog-ppl-0.15.tar.gz in the infrastructure directory is broken on darwin. The size is now much smaller which makes me suspect that autogen.sh wasn't run before the tarball was created. On darwin, the build fails with... /bin/sh ./libtoo

Re: gcc.gnu.org ftp down?

Jack Howarth writes: > Does anyone know why the gcc.gnu.org ftp site > is no longer available? FTP on gcc.gnu.org is up again. The outage was accidentally caused while updating the machine. Thanks for reporting it. Ian

RE: gcc99 inlining rules

Link error. /tmp/ccqpP1D1.o: In function `main': tst.c:(.text+0x15): undefined reference to `foo' collect2: ld returned 1 exit status As Joseph said, I found the original text in c99 standard in section 6.7.4. " EXAMPLE The declaration of an inline function with external linkage can result in

RE: GCC at Google Summer of Code'2009

Hi Phil, Sorry I couldn't reply earlier to your email (have a few deadlines at the moment) so will reply here: I would be extremely interested to see the support for OpenCL and either GPU or CELL implemented in GCC. My personal interest here is to extend work on adaptive scheduling. A few years

[cond-optab] update and first call for review

I meant to start the big assembly comparison run today, but I was busy and tomorrow I have to leave. So I'll create the branch before doing that but after finishing building newlibs. There were no other target-independent change to make. I fixed the Blackfin regressions. I also fixed a few mini

Re: GCC 4.4 Branch Created

Daniel Berlin writes: > On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers > wrote: > > On Fri, 27 Mar 2009, Mark Mitchell wrote: [...] > > If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not > > need 4.5.1 or subsequent versions in this script), there is still time to > > do so

Re: GCC 4.4 Branch Created

On Tue, Mar 31, 2009 at 2:46 PM, Rainer Orth wrote: > Daniel Berlin writes: > >> On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers >> wrote: >> > On Fri, 27 Mar 2009, Mark Mitchell wrote: > [...] >> > If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not >> > need 4.5.1 or subseq

Re: GCC 4.4 Branch Created

Daniel Berlin writes: > > No wonder: it didn't work for quite some time (reports didn't make it > > through), and despite several request from me you couldn't make time to > > find out what was going on. > > This is true, I don't have time to maintain an incoming email script > used solely by you

Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target i686-pc-mingw32 (cross build from i686-pc-cygwin)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224] (GCC) Platform: i686-pc-mingw32 configure flags: - --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32/mingw - --with-sysroot=/opt/devel/gnu/cross-gcc/gcc-4.4.

Re: GCC 4.4 Branch Created

On Tue, Mar 31, 2009 at 2:51 PM, Rainer Orth wrote: > Daniel Berlin writes: > >> >  I don't blame you at all, but find it highly >> > unfortunate to be forced to use a browser for initial submission instead of >> > being able to use a proper mailer/editor. >> I'm sorry you feel that way, but I si

Re: GCC 4.4 Branch Created

On Tue, Mar 31, 2009 at 3:01 PM, Gabriel Dos Reis wrote: > On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth > wrote: >> Daniel Berlin writes: > >> Understood, but I wonder how other projects deal with this.  I cannot >> possibly be the only one in the world who wants to submit structured bug >> repor

Re: GCC 4.4 Branch Created

On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth wrote: > Daniel Berlin writes: > Understood, but I wonder how other projects deal with this.  I cannot > possibly be the only one in the world who wants to submit structured bug > reports by mail. No, you are not the only one. Unless my memory is fai

Re: GCC 4.4 Branch Created

On Tue, Mar 31, 2009 at 2:05 PM, Daniel Berlin wrote: > On Tue, Mar 31, 2009 at 3:01 PM, Gabriel Dos Reis wrote: >> On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth >> wrote: >>> Daniel Berlin writes: >> >>> Understood, but I wonder how other projects deal with this.  I cannot >>> possibly be the on

gcc-4.4-20090331 is now available

Snapshot gcc-4.4-20090331 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090331/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax

On Mar 13, 2009, Paolo Bonzini wrote: > For 4.5 I would like to improve our RTL canonicalization so that no > out-of-range shifts are ever in the RTL representation. FR-V non-vector shifts truncate a register shift count to 5 bits; it's from the ISA specs, it doesn't appear that the same truncat

stdint.h type information needed

GCC now supports providing the header (required by C99 of freestanding implementations) and having information within the compiler about the types used in this header. For further discussion of this and its benefits, see . Right now, t

Re: stdint.h type information needed

DJGPP has its own , at least in DJGPP 2.04.

Re: stdint.h type information needed

On Tue, 31 Mar 2009, DJ Delorie wrote: > DJGPP has its own , at least in DJGPP 2.04. I expect most of the OSes listed do; the types should still be entered into GCC (so the Fortran front end can know them, for example), and use_gcc_stdint set to "wrap" unless there is a particular problem with

Re: stdint.h type information needed

> I expect most of the OSes listed do; the types should still be entered > into GCC (so the Fortran front end can know them, for example), and Well, I'm not a big fan of duplicating information, but if that's what you want to do, here it is. Enjoy. /* Copyright (C) 2003 DJ Delorie, see COPYI

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Sun, 29 Mar 2009 14:11:37 -0500 Sebastian Pop wrote: > I committed the attached fix to the cloog-ppl repo, and I will prepare > a new tar.gz for the gcc infrastructure. Is changing the contents of the tarball without changing the name going to be a habit or just something we'll have to live w

Revised GCC Runtime Library Exception

The revised GCC Runtime Library Exception now is published on the FSF website: http://www.gnu.org/licenses/gcc-exception.html The FSF carefully considered the comments and concerns of the community about the terminology and hopes that this new text clarifies the permissions in conjunction with th

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Tue, Mar 31, 2009 at 21:41, Ryan Hill wrote: > On Sun, 29 Mar 2009 14:11:37 -0500 > Sebastian Pop wrote: > >> I committed the attached fix to the cloog-ppl repo, and I will prepare >> a new tar.gz for the gcc infrastructure. > > Is changing the contents of the tarball without changing the name

Re: [PPL-devel] PPL broken for Canadian-cross builds

On Wed, 1 Apr 2009 00:02:43 -0500 Sebastian Pop wrote: > On Tue, Mar 31, 2009 at 21:41, Ryan Hill wrote: > > On Sun, 29 Mar 2009 14:11:37 -0500 > > Sebastian Pop wrote: > > > >> I committed the attached fix to the cloog-ppl repo, and I will > >> prepare a new tar.gz for the gcc infrastructure.

Re: bitfields: types vs modes?

So... can I/we move forward on this? Or will such a change be rejected? BTW, Since sending this I discovered that gcc treats these differently wrt TARGET_NARROW_VOLATILE_BITFIELD: volatile struct { unsigned int a:8; unsigned int b:24; } t1; volatile struct { unsigned int a:7; unsigned

Re: bitfields: types vs modes?

DJ Delorie writes: > So... can I/we move forward on this? Or will such a change be > rejected? > > BTW, Since sending this I discovered that gcc treats these > differently wrt TARGET_NARROW_VOLATILE_BITFIELD: > > volatile struct > { > unsigned int a:8; > unsigned int b:24; > } t1; > > volati