build breakage due to r108059
Paolo, >toplevel: >2005-12-05 Paolo Bonzini <[EMAIL PROTECTED]> > > * configure.in (CONFIGURED_BISON, CONFIGURED_YACC, CONFIGURED_M4, > CONFIGURED_FLEX, CONFIGURED_LEX, CONFIGURED_MAKEINFO): Remove > "CONFIGURED_" from the AC_CHECK_PROGS invocation. Move below. > Find in-tree tools if available. > (EXPECT, RUNTEST, LIPO, STRIP): Find them and substitute them. > (CONFIGURED_*_FOR_TARGET): Don't set nor substitute. > (*_FOR_TARGET): Set them with GCC_TARGET_TOOL. > (COMPILER_*_FOR_TARGET): New. >... >config: >2005-12-05 Paolo Bonzini <[EMAIL PROTECTED]> > >* acx.m4 (GCC_TARGET_TOOL): New. the way GCC_TARGET_TOOL gets evaluated breaks builds in a tree without binutils sources, but with (some) binaries put into a binutils subdirectory of the output tree. Many years ago, I had been advised that putting ar, ranlib, and nm binaries in a binutils subdirectory would allow gcc's configure to find and use them, and in fact gcc is still looking there. However, since AR_FOR_TARGET gets passed on the make command line, the attempt to set AR_FOR_TARGET in gcc/Makefile is simply ignored. In the given case, building cross tools for i686-novell-netware on i686-pc-linux-gnu, I don't have i686-novell-netware-ar (and similar other tools; I entirely dislike this naming scheme), but I do have (which doesn't seem to matter at all, and never did) /usr/local/i686-novell-netware/bin/ar etc, which (prior to running configure) I create links to in $(objdir)/binutils/. I would suppose that GCC_TARGET_TOOL should not only check whether the directory of $4 is among $(configdirs), but also if $4 itself pre-exists. Thanks, Jan
Re: GCC 3.4.6 Release status
On Wed, 7 Dec 2005, Gabriel Dos Reis wrote: > As in the previous round, please consider every weekly snapshot from > gcc-3_4-branch as a release candidate for testing. > > Schedule: > >The tentative release date is end of February 2006. > >I'll make official prerelease tarballs on February 16, 2005. > >For reasons that would be classified as personal, I anticipate not > being available during the week of mid January 2006. I noticed that the homepage states that the 3.4 branch is open for regression and documentation fixes only, yet I have seen several patches go in that were not marked as regression fixes. Would you mind clarifying? (If we accept non-regression fixes, the policy for 3.4 would be less stringent than the one for 4.0.) Gerald
Re: Mention gcc 4.1 in News/Announcements
On Tue, 6 Dec 2005, Diego Novillo wrote: > Yes, they're collectively pretty clueless. However, in the midst of > that /. interchange I did see one posting that made a relatively good > point: If you go to gcc.gnu.org, you will see "Current release series: > GCC 4.1.0". > > For the uninformed, that may be construed as "GCC 4.1.0 has been released". > That may have tripped the original /. poster into thinking that. No, I'm > not defending them. That's not just for the uninformed, I consider this a real bug with our web pages Gerald
Re: GCC 3.4.6 Release status
Gerald Pfeifer <[EMAIL PROTECTED]> writes: | On Wed, 7 Dec 2005, Gabriel Dos Reis wrote: | > As in the previous round, please consider every weekly snapshot from | > gcc-3_4-branch as a release candidate for testing. | > | > Schedule: | > | >The tentative release date is end of February 2006. | > | >I'll make official prerelease tarballs on February 16, 2005. | > | >For reasons that would be classified as personal, I anticipate not | > being available during the week of mid January 2006. | | I noticed that the homepage states that the 3.4 branch is open for | regression and documentation fixes only, yet I have seen several | patches go in that were not marked as regression fixes. | | Would you mind clarifying? The branch is open for regression fixes only as I restated in the Dec 1st message. Do you have a particular patch in mind that did not fix a regression? -- Gaby
Re: GCC 3.4.6 Release status
On Fri, 9 Dec 2005, Gabriel Dos Reis wrote: > The branch is open for regression fixes only as I restated in the Dec > 1st message. Do you have a particular patch in mind that did not fix > a regression? Most of Volker's patches didn't state they were regression fixes on the gcc-patches submission; they may have have, but it wasn't clear from the context. Gerald
Re: GCC 3.4.6 Release status
Gerald Pfeifer <[EMAIL PROTECTED]> writes: | On Fri, 9 Dec 2005, Gabriel Dos Reis wrote: | > The branch is open for regression fixes only as I restated in the Dec | > 1st message. Do you have a particular patch in mind that did not fix | > a regression? | | Most of Volker's patches didn't state they were regression fixes on the | gcc-patches submission; they may have have, but it wasn't clear from the | context. According to the analysis (and the summary) found in bugzilla c++/21383 is [3.4 regression] c++/22352 is [3.4 regression] c++/22464 is [3.4 regression] c++/23307 is [3.4 regression] those are the C++ fixes applied to gcc-3_4-branch between 2005-12-01 and now. The approvals weren't mechanical. -- Gaby
GNU violation?
Hi! I found a microcontroller-ported gcc. It used for Microchip's dsPIC products. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010065&part=SW006012 or http://www.microchip.com --> Development Tools --> MPLAB® C30 Compiler It's is a "60 day demo/upgrade" versions GCC, and has no source-code, I wrote a email for Microchip, but they dont give me the source. It's a GNU-GPL violation, or? Zsolt
Re: GNU violation?
http://www.microchip.com --> Development Tools --> MPLAB® C30 Compiler It's is a "60 day demo/upgrade" versions GCC, and has no source-code, I wrote a email for Microchip, but they dont give me the source. The source code is only a part of full GCC-binary. Zsolt
Re: GNU violation?
Hi! I found a microcontroller-ported gcc. It used for Microchip's dsPIC products. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010065&part=SW006012 or http://www.microchip.com --> Development Tools --> MPLABÂ C30 Compiler It's is a "60 day demo/upgrade" versions GCC, and has no source-code, I wrote a email for Microchip, but they dont give me the source. It's a GNU-GPL violation, or? Source packages appear to be available at: http://ww1.microchip.com/downloads/en/DeviceDoc/mplabc30v1_33.tgz http://ww1.microchip.com/downloads/en/DeviceDoc/mplabc30v2_00.tgz Cheers, Martin
Re: GNU violation?
On Fri, Dec 09, 2005 at 03:31:34PM +0100, Krüpl Zsolt wrote: > >http://www.microchip.com --> Development Tools --> MPLAB® C30 Compiler > > > >It's is a "60 day demo/upgrade" versions GCC, and has no source-code, I > >wrote a email for Microchip, but they dont give me the source. > > The source code is only a part of full GCC-binary. See http://www.gnu.org/licenses/gpl-violation.html
Nathan Sidwell as Morpho Technologies Co-Maintainer
The SC has approved Aldy's nomination of Nathan as a co-maintainer for the Morpho Technologies port. Nathan, please updated MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
PATCH for Re: Missing link to changes.html for 4.1...
On Tue, 6 Dec 2005, David Daney wrote: > After the 4.1 branch was created there appears to be no way to navigate to: > > http://gcc.gnu.org/gcc-4.1/changes.html > > from the gcc.gnu.org home page. Now there is. ;-) Thanks for the hint; I just installed the patch below. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.532 diff -u -3 -p -r1.532 index.html --- index.html 9 Dec 2005 16:58:14 - 1.532 +++ index.html 9 Dec 2005 22:25:49 - @@ -56,6 +56,7 @@ mission statement. Next release series: GCC 4.1.0 + (current changes) Branch status: http://gcc.gnu.org/ml/gcc/2005-10/msg00210.html";>2005-10-10
gcc-4.1-20051209 is now available
Snapshot gcc-4.1-20051209 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051209/ 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 108317 You'll find: gcc-4.1-20051209.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051209.tar.bz2 C front end and core compiler gcc-ada-4.1-20051209.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051209.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051209.tar.bz2 C++ front end and runtime gcc-java-4.1-20051209.tar.bz2 Java front end and runtime gcc-objc-4.1-20051209.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051209.tar.bz2The GCC testsuite Diffs from 4.1-20051202 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.
Re: htsearch broken?
On Thu, 8 Dec 2005, Paul Martinolich wrote: > I have noticed that when I search the mailing lists the earliest > messages > are from May 2005. I don't see anything before that. > > http://gcc.gnu.org/ml/gcc/ > > Search 'fortran' which shows the first message is: > > http://gcc.gnu.org/ml/gcc/2005-05/msg01645.html > > which was posted May 31, 2005. > > However, this message contains 'fortran' from just > earlier in the week: > > http://gcc.gnu.org/ml/gcc/2005-12/msg00126.html If you mean "latest" instead of "earliest", it's because the search engine has stopped indexing, permanently. No ETA; I'm not sure it'll be fixed at all. brgds, H-P
Re: htsearch broken?
On 2005-12-10, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote: > On Thu, 8 Dec 2005, Paul Martinolich wrote: >> I have noticed that when I search the mailing lists the earliest >> messages are from May 2005. I don't see anything before that. > > If you mean "latest" instead of "earliest", it's because the > search engine has stopped indexing, permanently. No ETA; I'm > not sure it'll be fixed at all. As an alternative, Gmane has a searchable archive of this list (gcc@gcc.gnu.org), which you can read on the web or via NNTP: http://search.gmane.org/?query=fortran&group=gmane.comp.gcc.devel&sort=date Currently the search index is being updated somewhere between daily and weekly. It should be switching to new messages being searchable within a few hours fairly soon. Cheers, Olly
RELOAD_OTHER bug?
I'm looking at a set of reloads that look like this:
(insn 238 3802 239 35 (set (reg/v:HI 175 [ ch ])
(sign_extend:HI (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8]))) 46
{extendqihi2} (nil)
(nil))
Note that the md pattern uses a "0" constraint; sign-extend is a
one-op insn.
Reloads for insn # 238
Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int -128))
A_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int -128))
reload_reg_rtx: (reg:HI 4 a0)
Reload 1: A_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int -128))
reload_reg_rtx: (reg:HI 4 a0)
Reload 2: reload_in (HI) = (mem/c:HI (plus:HI (plus:HI (reg/f:HI 7 fb)
(const_int -128))
(const_int -476)) [108 fmt+0 S2
A8])
A_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 0), can't combine
reload_in_reg: (reg/v/f:HI 176 [ fmt ])
reload_reg_rtx: (reg:HI 5 a1)
Reload 3: reload_in (QI) = (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8])
reload_out (HI) = (mem/c:HI (plus:HI (plus:HI (reg/f:HI 7 fb)
(const_int -128))
(const_int -474)) [107 ch+0 S2 A8])
HL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (mem:QI (reg/v/f:HI 176 [ fmt ]) [0 S1 A8])
reload_out_reg: (reg/v:HI 175 [ ch ])
reload_reg_rtx: (reg:HI 0 r0)
It generates insns for reloads 0, 2, and 3, but in this order:
reload 0 (OTHER) : insns 4152..4156
reload 2 (OADDR) : insn 4157
reload 3 (OTHER) : insns 4158..4159
(insn 4157 3802 4153 34 (set (reg:HI 5 a1)
(mem/c:HI (plus:HI (reg:HI 4 a0)
(const_int -476 [0xfe24])) [108 fmt+0 S2 A8])) 33
{movhi_op} (nil)
(nil))
(insn 4153 4157 4155 34 (set (reg:HI 4 a0)
(const_int -128 [0xff80])) 33 {movhi_op} (nil)
(nil))
(insn 4155 4153 4156 34 (set (reg:HI 4 a0)
(reg/f:HI 7 fb)) 33 {movhi_op} (nil)
(nil))
(insn 4156 4155 4158 34 (set (reg:HI 4 a0)
(plus:HI (reg:HI 4 a0)
(const_int -128 [0xff80]))) 2 {addhi3} (nil)
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 7 fb)
(const_int -128 [0xff80]))
(nil)))
(insn 4158 4156 238 34 (set (reg:QI 0 r0)
(mem:QI (reg:HI 5 a1) [0 S1 A8])) 32 {movqi_op} (nil)
(nil))
(insn 238 4158 4159 34 (set (reg:HI 0 r0)
(sign_extend:HI (reg:QI 0 r0))) 46 {extendqihi2} (nil)
(nil))
(insn 4159 238 4160 34 (set (mem/c:HI (plus:HI (reg:HI 4 a0)
(const_int -474 [0xfe26])) [107 ch+0 S2 A8])
(reg:HI 0 r0)) 33 {movhi_op} (nil)
(nil))
Note that 4157 is out of order. I *think* what's happening is that
the MERGE_TO_OTHER macro isn't taking into account that if you merge
RELOAD_OTHER and RELOAD_FOR_OTHER_ADDRESS, you can't end up with a
RELOAD_OTHER.
Either that or there's an earlier bug in that reload 0 should be
RELOAD_FOR_OTHER_ADDR too. I think fixing either would solve
my problem.
Comments?
Re: htsearch broken?
Hans-Peter Nilsson-2 wrote: > > If you mean "latest" instead of "earliest", it's because the > search engine has stopped indexing, permanently. No ETA; I'm > not sure it'll be fixed at all. > Try search Nabble, the gcc user list is archived here: http://www.nabble.com/gcc---General-f1157.html Posts from the list are updated to the minute. The new posts will be almost immediately searchable. Nabble also have a combined gcc archive which combines all the lists from gcc - this includes the gcc-fortran, gcc-help, gcc-java... Instead of searching every list individually, you can search all the lists in one place: http://www.nabble.com/gcc-f1154.html Regards, Will L Nabble.com -- Sent from the gcc - General forum at Nabble.com: http://www.nabble.com/htsearch-broken--t704225.html#a1879186
Re: RELOAD_OTHER bug?
DJ Delorie <[EMAIL PROTECTED]> writes: > Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb) > (const_int -128)) > A_REGS, RELOAD_OTHER (opnum = 0) > reload_in_reg: (plus:HI (reg/f:HI 7 fb) > (const_int -128)) > reload_reg_rtx: (reg:HI 4 a0) ... > Either that or there's an earlier bug in that reload 0 should be > RELOAD_FOR_OTHER_ADDR too. I think fixing either would solve > my problem. It does seem like reload 0 should be RELOAD_FOR_ something _ADDR. What set it to RELOAD_OTHER? Ian
