Re: Making gcc -no-canonical-prefixes the default?

On 28/01/2011 23:05, Ian Lance Taylor wrote: > So it seems like people want it both ways. Some people want to invoke a > symlink which points to the real gcc, which requires canonicalization. > Some people want the real gcc to be a symlink which points elsewhere, > which requires non-canonicalizat

Re: Making gcc -no-canonical-prefixes the default?

Simon Baldwin writes: > By default, gcc calls realpath() on prefixes generated relative to > argv[0] in the gcc driver. If gcc is held as a "symlink farm" the > realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so > on). It complains about not finding cc1 or cc1plus in libexec

Re: Making gcc -no-canonical-prefixes the default?

On Fri, 28 Jan 2011, Simon Baldwin wrote: > A quick question about -no-canonical-prefixes... > > By default, gcc calls realpath() on prefixes generated relative to > argv[0] in the gcc driver. If gcc is held as a "symlink farm" the > realpath() makes it fail (absent a lot of messy -B, -L, -isyte

Re: GCC 4.3.5 Status Report (2010-05-22)

On Sun, 23 May 2010, Richard Guenther wrote: >> I am wondering, should I stop the weekly snapshot for the GCC 4.3 >> branch and just create them ad hoc when there is demand? > It would be nice if the scripts could check whether only DATESTAMP > changes were done since the last snapshot ... How can

Re: defining add in a new port

Jean-Marc Saffroy writes: > On 01/28/2011 06:44 PM, Ian Lance Taylor wrote: >> Jean-Marc Saffroy writes: >> >>> error: insn does not satisfy its constraints: >>> (insn 1424 1423 141 (set (reg:DI 2 r2) >>> (plus:DI (reg:DI 2 r2) >>> (const_int 40 [0x28]))) >>> /home/jmsaffroy

Making gcc -no-canonical-prefixes the default?

A quick question about -no-canonical-prefixes... By default, gcc calls realpath() on prefixes generated relative to argv[0] in the gcc driver. If gcc is held as a "symlink farm" the realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so on). It complains about not finding cc1 or

Re: defining add in a new port

On 01/28/2011 06:44 PM, Ian Lance Taylor wrote: > Jean-Marc Saffroy writes: > >> error: insn does not satisfy its constraints: >> (insn 1424 1423 141 (set (reg:DI 2 r2) >> (plus:DI (reg:DI 2 r2) >> (const_int 40 [0x28]))) >> /home/jmsaffroy/cygnus/src/newlib/libc/time/strptime

Re: NetBSD bootstrap (was: Target deprecations for 4.6)

On 1/28/2011 10:32 AM, Jonathan Wakely wrote: On 28 January 2011 01:11, Joseph S. Myers wrote: * a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*, i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd* not matching vax-*-netbsdelf*). This implies some x86 targets ar

Re: defining add in a new port

Jean-Marc Saffroy writes: > error: insn does not satisfy its constraints: > (insn 1424 1423 141 (set (reg:DI 2 r2) > (plus:DI (reg:DI 2 r2) > (const_int 40 [0x28]))) > /home/jmsaffroy/cygnus/src/newlib/libc/time/strptime.c:165 24 {adddi3} > (expr_list:REG_EQUIV (plus:DI (

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 05:48 PM, Joel Sherrill wrote: On 01/28/2011 09:17 AM, Ian Lance Taylor wrote: Andreas Schwab writes: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. But that seems strange to me as some of the configure scripts test f

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 09:17 AM, Ian Lance Taylor wrote: Andreas Schwab writes: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. But that seems strange to me as some of the configure scripts test for --with-newlib and adjust their configury ac

defining add in a new port

Hi gcc gurus, I'm trying to port GCC to a new architecture, I'm new to gcc, and have little problems defining add correctly. My target has 2 types of (DI mode) registers, so I defined 2 classes: - class D (data) regs can be used for computations, and that includes operations such as additions an

Re: Heads up: please help documenting *internal* GCC changes for 4.6

On Jan 28, 2011, at 8:04 AM, Laurynas Biveinis wrote: > 2011/1/28 Basile Starynkevitch : >>> Its intention is to mention noteworthy internal changes, i.e. changes >>> interesting for, say, maintainers of backends/frontends outside the >>> tree, and of course plugin developers upgrading from 4.5 t

Re: Heads up: please help documenting *internal* GCC changes for 4.6

Basile Starynkevitch writes: > I am not sure to understand what is the social rules to modify that. I > suppose that any patch to that page should be approved with the same > strong process as patches to trunk code? I would say that any gcc maintainer may update the changes file without explicit

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 04:17 PM, Ian Lance Taylor wrote: Andreas Schwab writes: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. But that seems strange to me as some of the configure scripts test for --with-newlib and adjust their configury ac

Re: Building Secondary Languages After Newlib is Installed

Andreas Schwab writes: > Ralf Corsepius writes: > >> - Remove newlib from the source tree > > --without-newlib should probably be enough. But that seems strange to me as some of the configure scripts test for --with-newlib and adjust their configury accordingly. This would put them in a positi

Re: The GNU Compiler Collection should be renamed the Jewish Compiler Collection

Matthew Plant wrote: > I'm just kidding, I was going to make a joke about being conservative > about memory but then I realized I would be making fun of my own > heritage. Well, there was that glaring bug that caused the compiler to betray a developer's trust by brutally mangling his private varia

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 04:58 AM, Ralf Corsepius wrote: On 01/28/2011 10:15 AM, Andreas Schwab wrote: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. Good point, agreed. In case of Joel and rtems the situation probably can be furtherly simplif

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

On Fri, Jan 28, 2011 at 4:52 AM, Laurynas Biveinis wrote: > 2011/1/27 H.J. Lu : >> I think it is useful. I have run --enable-checking=valgrind once and it >> took daays to finish.  But I haven't got time analyze the result. > > Do you mean, bootstrap + testsuite? IIRC someone submitted a f

Re: Proposal: Improving patch tracking and review using Rietveld

On Fri, Jan 28, 2011 at 08:25, Joseph S. Myers wrote: > If a patch (over 400kB) is being excluded from the message because of size > (and somewhat larger patches could still be included as gzipped I have not looked into upload.py's source code, so I don't know if the limits are set in the upload

Re: Proposal: Improving patch tracking and review using Rietveld

On Fri, 28 Jan 2011, Diego Novillo wrote: > On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers > wrote: > > On Wed, 26 Jan 2011, Diego Novillo wrote: > > > >> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided > >> the submitter added gcc-patches to the CC list). > > > >

Re: NetBSD bootstrap (was: Target deprecations for 4.6)

On Fri, 28 Jan 2011, Jonathan Wakely wrote: > On 28 January 2011 01:11, Joseph S. Myers wrote: > > > > * a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*, > > i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd* > > not matching vax-*-netbsdelf*). > > This implies s

Re: Proposal: Improving patch tracking and review using Rietveld

On Thu, Jan 27, 2011 at 19:44, Joseph S. Myers wrote: > On Wed, 26 Jan 2011, Diego Novillo wrote: > >> 1- Rietveld always send the patch sent to it to gcc-patches@ (provided >> the submitter added gcc-patches to the CC list). > > appears to

Re: Heads up: please help documenting *internal* GCC changes for 4.6

2011/1/28 Basile Starynkevitch : >> Its intention is to mention noteworthy internal changes, i.e. changes >> interesting for, say, maintainers of backends/frontends outside the >> tree, and of course plugin developers upgrading from 4.5 to 4.6. >> > > > I am not sure to understand what is the socia

Plans about increasing modularity by splitting tree/RTL more?

On gc-improv I am working on PCH (mis-)feature that it stores a few RTXes in a PCH file through tree (think tree_decl_with_rtl). I would like to keep GTY completely away from RTL and that requires keeping away RTL from PCH too. In recent discussions on increasing GCC modularity, were there any sug

Re: Heads up: please help documenting *internal* GCC changes for 4.6

On Fri, 28 Jan 2011 14:43:28 +0200 Laurynas Biveinis wrote: > I have just added a new section (approved by Gerald) to the bottom of > http://gcc.gnu.org/gcc-4.6/changes.html > > Its intention is to mention noteworthy internal changes, i.e. changes > interesting for, say, maintainers of backends/

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

2011/1/27 H.J. Lu : > I think it is useful. I have run --enable-checking=valgrind once and it > took daays to finish.  But I haven't got time analyze the result. Do you mean, bootstrap + testsuite? IIRC someone submitted a few bug reports (fixed now) in a row some three years ago which loo

Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option

2011/1/27 Richard Guenther : > On Thu, Jan 27, 2011 at 1:23 PM, Laurynas Biveinis > wrote: >> The --enable-checking=valgrind does two things. First, it provides >> Valgrind annotations for internal GCC allocators so that Valgrind has >> a better idea about memory blocks which are not supposed to b

Heads up: please help documenting *internal* GCC changes for 4.6

I have just added a new section (approved by Gerald) to the bottom of http://gcc.gnu.org/gcc-4.6/changes.html Its intention is to mention noteworthy internal changes, i.e. changes interesting for, say, maintainers of backends/frontends outside the tree, and of course plugin developers upgrading fr

gccsense patch against vanilla gcc 4.5.2

There is a discussion about codecompletion feature of gcc, see http://gcc.gnu.org/ml/gcc/2010-04/msg00433.html since the author did not update it for about nearly a year. Now, I have create a patch to against vanilla gcc 4.5.2, I have tested it under Windows, and it works fine. see: http://foru

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 10:15 AM, Andreas Schwab wrote: Ralf Corsepius writes: - Remove newlib from the source tree --without-newlib should probably be enough. Good point, agreed. In case of Joel and rtems the situation probably can be furtherly simplified: RTEMS has gcc-4.5.5-compiled newlib-rp

NetBSD bootstrap (was: Target deprecations for 4.6)

On 28 January 2011 01:11, Joseph S. Myers wrote: > > * a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*, > i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd* > not matching vax-*-netbsdelf*). This implies some x86 targets are expected to work, but NetBSD-current ca

Re: Building Secondary Languages After Newlib is Installed

Ralf Corsepius writes: > - Remove newlib from the source tree --without-newlib should probably be enough. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."

Re: libgo multilib issues.

Ian Lance Taylor writes: >> I would suggest: >> >> GOARCH=mips# o32 >> GOARCH=mips64n32 # Would you believe n32? >> GOARCH=mips64n64 # ...n64 > > I think the only real question is whether that first "64" helps. I don't think so: in the n64 case, it's just double, and for n32 it's pre

Re: Building Secondary Languages After Newlib is Installed

On 01/28/2011 07:49 AM, Ian Lance Taylor wrote: Ralf Corsepius writes: On 01/27/2011 07:15 PM, Joel Sherrill wrote: What is the preferred combination of --enable-newlib and --with-newlib settings to build with newlib in the gcc source tree but not build it and use the installed copy for the