Re: GCC 4.6.0 Released

Hello On 28.03.11, you wrote: > > I think that the right place for the note is at > > http://gcc.gnu.org/install/specific.html#x-x-cygwin > > It should say something like: > > Versions of Cygwin older than x.y.z fail to build the decimal floating > point library, libbid. You will either nee

Re: GCC_NO_EXECUTABLES vs. libtool

On Mon, 28 Mar 2011, Ian Lance Taylor wrote: > We have several bug reports for 4.6.0 about failures of the form > > checking dynamic linker characteristics... configure: error: Link tests are > not allowed after GCC_NO_EXECUTABLES. > > http://gcc.gnu.org/PR47836 > http://gcc.gnu.org/PR46586 >

[CFARM] New Intel donated servers and hosting donation by IRILL

Hi, We're pleased to announce that Intel (1) has donated three servers and that IRILL (2) has donated hosting for them. All machines are now online in the GCC Compile Farm (3). - gcc20: a dual Xeon X5670 2.93 GHz 12 cores 24 threads 24 GB RAM system - gcc46/47: two Atom D510 systems Roberto Di

Re: RFC: Representing vector lane load/store operations

Richard Sandiford writes: > Richard Guenther writes: >> Well, I meant if the user compiles with -msse, declares such a >> global var (which means it gets V4SFmode and not BLKmode) >> and then uses it in a function where he explicitly disables SSE >> then something is wrong. If he declares a BLKm

Re: GCC 4.6.0 Released

On 28/03/2011 19:52, FX wrote: >> this is a known issue and strictly cygwin related. Please update your >> cygwin environment to newest version, or disable decimal-floating >> point by option. > > Well, maybe this is known, but it is not noted on the GCC 4.6.0 release > notes, nor on the target-s

Re: GCC 4.6.0 Released

On 29/03/2011 09:50, Bernd Roesch wrote: > Hello > > On 28.03.11, you wrote: > >> I think that the right place for the note is at >> >> http://gcc.gnu.org/install/specific.html#x-x-cygwin >> >> It should say something like: >> >> Versions of Cygwin older than x.y.z fail to build the decimal fl

Re: RFC: Representing vector lane load/store operations

On Tue, Mar 29, 2011 at 2:44 PM, Richard Sandiford wrote: > Richard Sandiford writes: >> Richard Guenther writes: >>> Well, I meant if the user compiles with -msse, declares such a >>> global var (which means it gets V4SFmode and not BLKmode) >>> and then uses it in a function where he explicitl

Re: [C++-0X] User-defined literals, gsoc

Hi Ed, I am working on a proposal to implement user-defined literals as a Google Summer of Code project. I was unaware that someone was already working on it. If you have already done some work, maybe it is better for me to pick another project. Or maybe you would be interested in mentoring me and

Re: GCC 4.6.0 Released

On 28/03/2011 08:25, Jakub Jelinek wrote: > The GNU Compiler Collection version 4.6.0 has been released. Were there any changes (other than perhaps repackaging) after the second RC (dated 20110321)? cheers, DaveK

Re: [C++-0X] User-defined literals, gsoc

On 03/29/2011 10:05 AM, Levon Haykazyan wrote: Hi Ed, I am working on a proposal to implement user-defined literals as a Google Summer of Code project. I was unaware that someone was already working on it. If you have already done some work, maybe it is better for me to pick another project. Or

Re: GCC_NO_EXECUTABLES vs. libtool

"Joseph S. Myers" writes: > In general link tests *are* required for GNU/Linux targets, because of > e.g. uClibc configurations where some functions may be disabled and this > can sometimes only be detected through a link test. Furthermore, when > building shared libraries you need a shared l

Re: [C++-0X] User-defined literals, gsoc

On Tue, Mar 29, 2011 at 2:16 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > On 03/29/2011 10:05 AM, Levon Haykazyan wrote: >> >> Hi Ed, >> >> I am working on a proposal to implement user-defined literals as a Google >> Summer of Code project. I was unaware that someone was already working on >>

Re: GCC 4.6.0 Released

On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: > On 28/03/2011 08:25, Jakub Jelinek wrote: > > The GNU Compiler Collection version 4.6.0 has been released. > > Were there any changes (other than perhaps repackaging) after the second RC > (dated 20110321)? You can easily look at svn.

Re: Bootstrap failure on sparc-sun-solaris2.10

Hi Art, > This morning's build on sparc-sun-solaris2.10 failed for me; the error > message in 'stage_2' is below: > > options.c:753:3: error: enum conversion in initialization is invalid in C++ > [-Werror=c++-compat] > options.c:753:3: error: (near initialization for > 'global_options_init.x_spa

Re: GCC 4.6.0 Released

On 29/03/2011 15:32, Jakub Jelinek wrote: > On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: >> On 28/03/2011 08:25, Jakub Jelinek wrote: >>> The GNU Compiler Collection version 4.6.0 has been released. >> Were there any changes (other than perhaps repackaging) after the second RC >> (d

Re: Possible Bug

>>> As some digging shows, already GCC 1.35 had effectively the same code. >>> As soon as parameters are passed in registers GCC loads the parts fitting >>> into registers as full words.  We could simply sorry() for these cases, as >>> they never worked correctly.  Though I suppose that's quite unf

Re: GCC_NO_EXECUTABLES vs. libtool

On 03/29/2011 01:33 PM, Joseph S. Myers wrote: But some of those bug reports refer to target libiberty - which I still maintain should never be built by GCC - and some to target zlib, which I think should only be relevant when building Java. Agreed on both counts. Paolo

Re: GCC 4.6.0 Released

On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn wrote: > On 29/03/2011 15:32, Jakub Jelinek wrote: >> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: >>> On 28/03/2011 08:25, Jakub Jelinek wrote: The GNU Compiler Collection version 4.6.0 has been released. >>>   Were there any changes

Re: [C++-0X] User-defined literals, gsoc

> - Original Message - > From: Ed Smith-Rowland <3dw...@verizon.net> > To: gcc@gcc.gnu.org > Subject: Re: [C++-0X] User-defined literals, gsoc > Date: Tue, 29 Mar 2011 10:16:52 -0400 > > > On 03/29/2011 10:05 AM, Levon Haykazyan wrote: > > Hi Ed, > > > > I am working on a proposal to imp

[google] Merged google/gcc-4_6 from 4.6.0 release

I've merged gcc-4_6-branch at the 4.6.0 release tag point into google/gcc-4_6. I have not removed the prerelease marker from DEV-PHASE, however. Tested on x86_64. Diego.

Re: GCC 4.6.0 Released

On 03/29/2011 05:53 AM, Dave Korn wrote: >> I think it can too in readme add that on current cygwin on win 64 and >> multicore CPU GCC compile lots slower as on single CPU systems. To speed up >> GCC and compile 3* faster in windows taskmanager can the CPU number set to >> 1 for the shell task. >>

old software versions on ftp://gcc.gnu.org/pub/gcc/infrastructure/

ftp://gcc.gnu.org/pub/gcc/infrastructure/ contains old versions of some libraries (like GMP, MPFR and MPC). Shouldn't they be updated? GNU MPFR can also be downloaded from: http://ftp.gnu.org/gnu/mpfr/ -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: <

On the toplevel configure and build system

Having been cleaning up the toplevel configure.ac in various ways following removing deprecated targets for GCC 4.7, I would like to propose some principles relating to the toplevel configure and build system. These are intended as principles to guide future development and indicate the direct

Re: On the toplevel configure and build system

> 2. If you put directories from the GCC repository into your build, you > should expect GCC and its libraries to be built; toplevel should not > disable GCC on the grounds that GCC does not support a given target. I disagree. We have a single combined gcc+binutils+etc internal tree that's u

Re: On the toplevel configure and build system

"Joseph S. Myers" writes: > 2. If you put directories from the GCC repository into your build, you > should expect GCC and its libraries to be built; toplevel should not > disable GCC on the grounds that GCC does not support a given target. I'd appreciate it if creating a combined tree and b

gcc-4.4-20110329 is now available

Snapshot gcc-4.4-20110329 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110329/ 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: On the toplevel configure and build system

On Tue, 29 Mar 2011, DJ Delorie wrote: > > 2. If you put directories from the GCC repository into your build, you > > should expect GCC and its libraries to be built; toplevel should not > > disable GCC on the grounds that GCC does not support a given target. > > I disagree. We have a single

Re: On the toplevel configure and build system

"Joseph S. Myers" writes: > Specifically, I propose removal of all support for building: ash autoconf > automake bash byacc bzip2 diff dosutils fileutils findutils find gawk > gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl > prms rcs release recode sed send-pr shell

Re: On the toplevel configure and build system

dj wrote: >> [...] > I see no reason to stop people from building in a combined source tree > for multiple targets, and expecting it to work. Perhaps if we do move to git for all the /src stuff, we can have a /toplevel git repository with different branches suitable for each of your tastes of su

Re: On the toplevel configure and build system

On Tue, 29 Mar 2011, Ian Lance Taylor wrote: > "Joseph S. Myers" writes: > > > Specifically, I propose removal of all support for building: ash autoconf > > automake bash byacc bzip2 diff dosutils fileutils findutils find gawk > > gettext gnuserv gzip hello indent libiconv libtool make mmalloc

Re: On the toplevel configure and build system

> Perhaps if we do move to git for all the /src stuff, we can have a > /toplevel git repository with different branches suitable for each > of your tastes of such policy. Perhaps I misunderstand how this would work (/me hates git) but I'm not looking forward to adding support to umpteen million b

Re: On the toplevel configure and build system

On Tue, 29 Mar 2011, Frank Ch. Eigler wrote: > Perhaps if we do move to git for all the /src stuff, we can have a It is very strongly in my principle 6 that there should be no "we" moving "for all the /src stuff" - that it should be made possible for each project (a) through (i) to make its own

Re: how can I split 1 mov insn into 2 sub_mov and 1 combine?

On Thu, Mar 17, 2011 at 2:11 PM, WANG.Jiong wrote: > define_split should be the correct way to handle this. > You should first use define_split to break your 256bit pattern and generate > legitimized 128bit rtl pattern sequence  for you processor > mips_output_move should only be used to handle th