Re: GCC 4.3 target deprecation proposals

Joseph S. Myers wrote: Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent testing or development. Joern Rennecke was intending to improve ARC I have no objection to mt. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery

Re: GCC 4.3 target deprecation proposals

On Jan 21, 2008, at 3:01 PM, Ben Elliston wrote: I didn't propose it for removal because of a single patch reported to have been tested on vax-netbsdelf. If the maintainers wish to propose deprecation and no-one else wishes to come f

Re: Plugin Branch

Joe Buck wrote: > > Nothing final has been decided. There are some efforts under way of > finding ways to reassure RMS that it's possible to do plugins in a way > that doesn't open the door to unrestricted use of gcc internals by > proprietary compilers, so it would be counterproductive right now

Re: mutex lock competing -one side always wins

> I wrote a program ,which has two threads(A,B) and one mutex. This is the wrong mailing list for your question. This list is used for discussing the development of GCC, not how to use it or program threads. You might like to try posting to gcc-help. Thanks, Ben

mutex lock competing -one side always wins

I wrote a program ,which has two threads(A,B) and one mutex. Thread A :loop (mutex_lock -> some process ->mutex_unlock ) Thread B :mutex_lock when needed -> some process ->mutex_unlock I expected that Thread B can get mutex_lock when thread A unlock,but Thread B don't get any locks .gcc is 4.1.1. /

Re: GCC 4.3 target deprecation proposals

> > I didn't propose it for removal because of a single patch > > reported to have > > been tested on vax-netbsdelf. If the maintainers wish to propose > > deprecation and no-one else wishes to come forward to maintain it, we can > > c

Re: Plugin Branch

On Tue, Jan 22, 2008 at 10:45:13AM +1100, Brendon Costa wrote: > Hi all, > > I have been away from the GCC mailing list for a while. I searched the > archives but could not find a resolution to the issue of inclusion of > plugins to GCC. > > Has it been decided if the GCC plugin branch will be

c++0x concepts in gcc call

Hello all! Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to discuss implementation of the compiler and library parts of the C++0x concepts proposals. This is to be a brainstorming session, where we discuss the best way to complete the work, what can be taken from existing br

Re: Segmentation fault in df-scan.c

On Sun, 20 Jan 2008, Kenneth Zadeck wrote: > If you > build your compiler with --enable-checking=df,yes (basically add "df" > onto what ever you normally set for --enable-checking) it will check that > there have been no unauthorized changes to any instructions after > every rtl pass. For the reco

Plugin Branch

Hi all, I have been away from the GCC mailing list for a while. I searched the archives but could not find a resolution to the issue of inclusion of plugins to GCC. Has it been decided if the GCC plugin branch will be added to GCC or not? I am not after a discussion on the merits/issues of d

Re: GCC 4.3 target deprecation proposals

> I didn't propose it for removal because of a single patch > reported to have > been tested on vax-netbsdelf. If the maintainers wish to propose > deprecation and no-one else wishes to come forward to maintain it, we can > certainly in

gcc-4.1-20080121 is now available

Snapshot gcc-4.1-20080121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080121/ 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

Re: Segmented Register file Implementation

On Tuesday 15 January 2008, Balaji V. Iyer wrote: > Hello Everyone, > I am currently working on dividing the register file into two > different processing element. In the first processing element (PE) I > want to have certain operations (add, sub, mult, div, branch, > jumps..etc) in first PE

Re: GCC 4.3 target deprecation proposals

On Mon, 21 Jan 2008, Eric Botcazou wrote: > > People may also make their own proposals for deprecations, including > > relating to targets which have had results posted in the past year, > > and including deprecations of particular subconfigurations (e.g. using > > a particular target without the

Re: hard_regno_nregs == 0 ?

> Hence, I now believe that your suggested doc change is correct, and is > OK to check in to mainline. Committed. Thanks! Index: ChangeLog === --- ChangeLog (revision 131702) +++ ChangeLog (working copy) @@ -1,6 +1,11 @@ +2008-

Re: GCC 4.3 target deprecation proposals

On Mon, 21 Jan 2008, John David Anglin wrote: > There is still a small amount of vax related activity but I don't > expect the GCC port to be actively maintained. The community is too > small. So, I think it is reasonable to consider it for removal. > I recall in the last go around that some peo

Re: GCC 4.3 target deprecation proposals

>> The following target architectures have seen no test results >> posted in the past year: arc, c4x (as listed above), crx, iq2000, >> mt, pdp11, score, stormy16, vax. Thanks David. I fixed my gcc list subscriptions which had become lost at some point due to malfunctions of internal mailers.

Re: GCC 4.3 target deprecation proposals

> People may also make their own proposals for deprecations, including > relating to targets which have had results posted in the past year, > and including deprecations of particular subconfigurations (e.g. using > a particular target without the GNU assembler, or with a particular > debug format)

Re: GCC 4.3 target deprecation proposals

> The following target architectures have seen no test results posted in > the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11, > score, stormy16, vax. Regarding vax, I don't have the time to maintain it. HPPA has taken all my free time in the past year. I probably should remove my

Re: Status of GCC 4.3 on HPPA (Debian)

> I recently compiled the Debian archive (around 7000 packages that need > to be compiled) on HPPA (PA RISC) using trunk to identify new issues > before GCC 4.3 is released. I compiled the archive with optimization set > to -O3 and found the following ICEs with trunk from 20071212: Thanks Martin

GCC 4.3 target deprecation proposals

No targets have been deprecated since 4.0, so it seems time to consider deprecating unused targets again. The usual procedure would apply: targets would require --enable-obsolete to build them in 4.3, then the code (and docs, testsuite support etc.) would be removed some time after 4.3.0 is releas

Re: Segmentation fault in df-scan.c

However,making this simpler works: rtx tmp_reg_rtx = copy_to_mode_reg (QImode,gen_rtx_MEM (QImode, addr1)); emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx)); aka Rx=[Ry] Ry=Ry+1 For now I have gone back to the second case, though the code is not quite as good. When your patter

Finding out what backend instruction pattern matches instruction

I am working on AVR port and seek advice of the best way working out what instructions patterns have been natched to RTL. This requires adjustment of instruction length to assist branching - when operands are finally known. Before this, worst case lengths are used from pattern length attribut

GCC 4.2.3 Status Report (2008-01-21)

Status == The 4.2 branch is in regression-only mode. Since it has been more than two months since the last release, I propose to prepare 4.2.3-rc1 on Friday 25 January, with either rc2 or the final release on Friday 1 February. Therefore, the branch will go into slush (all changes must be ap

Re: Segmentation fault in df-scan.c

Alas, enable-checking produced no different result or additional warnings or errors (though it might help me in the future!) I have a work around but don't fully understand why a define_expand should have caused segmentation fault. I believe the issue might be that gcse does not expect to see

GCC 4.3.0 Status Report (2008-01-21)

Status == We are in Stage 3. When we reach 100 open regressions, we will go to regression-only mode; one of the release managers will announce the exact time the mode is entered. When we approach the 4.3.0 release, we will create a branch, and open Stage 1 for 4.4.0. Quality Data ==

Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? (filed bug 34903)[Emcraft #11717]

Hello all, I've filed bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903 Regards, Sergei Andrew Haley wrote: David Edelsohn wrote: Andrew Haley writes: Andrew> I suspect that the real reason for the change in save/restore is because Andrew> not using lmw/stmw is faster. That's just a

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

On 21/01/2008, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Christian Joensson wrote: > > Now, is there some funny stuff going on here that I simply miss or is > > this what to expect currently? > > > I would suggest compiling the testcase outside the testsuite and having > a look to the pre-processe

Help with compiling pdf manual

Hi, I tryed to compile manul to pdf format but I completely stuck. When I run 'make pdf' it ends with error report: invoke.texi:1250: I can't find file `'. @begingroup @value ->@begingroup @makevalueexpandable @valuexxx @temp ->@input @value

Re: Vectorization with computed stride...

> Hi, > > I've noticed that GCC doesn't like to vectorize my loop. > > 1. When the loop has non-unit stride, I get 'complicated access pattern' > message. Are non-unit strides supported? > > res(1:nS) = grid(1:(43-1)*7+1:7)*Dummy ! COMPLICATED ACCESSPATTERN > Currently only power-of-2 strides are

Re: [cygwin] how do I get libiconv working correctly?

Dave Korn wrote: > Are we missing -lintl in the link flags perhaps? > Thanks. It would be nice if people knowledgeable in this are could have a look to a thread on the libstdc++ mailing list occurred between january and february of last year, "[v3] use AM_ICONV" . Apparently there are some lon

Re: [cygwin] how do I get libiconv working correctly?

2008/1/21, Dave Korn <[EMAIL PROTECTED]>: > On 21 January 2008 10:52, Christian Joensson wrote: > > > For example in http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00738.html > > I get a few libstdc++ failures and taking a look at them I see that a > > quite a few of them have an error due to tha

RE: [cygwin] how do I get libiconv working correctly?

On 21 January 2008 10:52, Christian Joensson wrote: > For example in http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00738.html > I get a few libstdc++ failures and taking a look at them I see that a > quite a few of them have an error due to that undefined reference to > `_libiconv'. > > Is the

Vectorization with computed stride...

Hi, I've noticed that GCC doesn't like to vectorize my loop. 1. When the loop has non-unit stride, I get 'complicated access pattern' message. Are non-unit strides supported? res(1:nS) = grid(1:(43-1)*7+1:7)*Dummy ! COMPLICATED ACCESSPATTERN 2. When a stride is not a compile time constant, then

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

Christian Joensson wrote: > Now, is there some funny stuff going on here that I simply miss or is > this what to expect currently? > I would suggest compiling the testcase outside the testsuite and having a look to the pre-processed output. On all the other targets I have available things are fi

[cygwin] how do I get libiconv working correctly?

For example in http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00738.html I get a few libstdc++ failures and taking a look at them I see that a quite a few of them have an error due to that undefined reference to `_libiconv'. Is there some easy way out of this that I have missed -- Cheers, /Ch

[libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

For some time now, I've been getting libstdc++ testsuite failures on my sparc biarch system running the libstdc++ testsuite with -m64. A lot of these failures seems to me to have in common the following failure, that only shows up using -m64, not running in default, ie, 32 bit mode: /usr/local/src