Re: Patches for coldfire v4e

Daniel Jacobowitz wrote: > On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote: >> >>So it seems adding coldfire-linux is the only way >>to address this... > > Why? Adding support (if it isn't already there) for something like > --with-arch=coldfire should work just as well. But h

Re: GCC 4.0 RC2

Richard Sandiford <[EMAIL PROTECTED]> writes: > Mark, > > I tried running some MIPS16 tests against RC1 and found a regression > from 3.4. The problem is the following hack in mips.h: > [...] > The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures > from 203 to 58 with no regression

RE: 2 suggestions

Original Message >From: Kaveh R. Ghazi >Sent: 14 April 2005 01:11 > > I'm afraid we'll have to rename all of these in some way, either by > > replacing "*" by "x" or by prepending some string. I'm not too fond > > of either, but just using "x" instead "*" might be less ugly. > > Somew

RE: gcc for syntax check only (C): need to read source from stdin

Original Message >From: James E Wilson >Sent: 13 April 2005 20:29 > Dave Korn wrote: >> [EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log > > Always use "make -k check". Some testsuites exit with an error if one > or more tests failed, and because this is the norma

RE: 2 suggestions

Original Message >From: Dave Korn >Sent: 14 April 2005 10:12 > Original Message >> From: Kaveh R. Ghazi >> Sent: 14 April 2005 01:11 > >> > I'm afraid we'll have to rename all of these in some way, either by >> > replacing "*" by "x" or by prepending some string. I'm not too fo

Re: reload-branch created

Bernd Schmidt <[EMAIL PROTECTED]> wrote on 11.04.2005 14:43:38: >* reload.c (find_reloads): Only set INC field if we know we have an >autoinc reload. Yes, this helps for s390. With the current reload-branch, and just my scan_rtx patch on top, I was able to bootstrap and run the test suit

Re: internal compiler error at dwarf2out.c:8362

On Wed, Apr 13, 2005 at 01:55:07PM -0700, James E Wilson wrote: > Martin Koegler wrote: > > tree type = TREE_TYPE (*node); > > tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type)); > > tree newtype = build_type_attribute_variant (type, attr); > > TYPE_MAIN_

Re: Patches for coldfire v4e

On Thu, Apr 14, 2005 at 09:36:59AM +0200, Bernardo Innocenti wrote: > Daniel Jacobowitz wrote: > > On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote: > >> > >>So it seems adding coldfire-linux is the only way > >>to address this... > > > > Why? Adding support (if it isn't already

Heads-up: volatile and C++

The C++ committee (well, a subgroup represented at this meeting by Hans Boehm) is working on a memory model that supports threaded programs. One proposed change is to the semantics of volatile. Currently, volatile semantics are constrained by: 6 The observable behavior of the abstract machin

install

I would like to install gcc can you give me some directions or where to find instructions please as this is my first time doing it thanks

install

I would like to install gcc on solaris 9 sun4u sparc SUNW,Sun-Fire-V440 can you give me some directions or where to find instructions please as this is my first time doing it thanks

Re: install

On Thu, 14 Apr 2005, Master Faris wrote: > I would like to install gcc on solaris 9 > sun4u sparc SUNW,Sun-Fire-V440 > > can you give me some directions or where to find instructions please as this > is my first time doing it Please have a look at our website http://gcc.gnu.org, specifically http

libstdc++ link failures on ppc64

My ppc64 tester started failing last night while trying to create libstdc++ libraries with: - /home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/./gcc/xgcc -shared-l ibgcc -B/home/cygnus/dnovillo/perf/sbox/gcc/loc

RE: install

Original Message >From: Gerald Pfeifer >Sent: 14 April 2005 13:45 > On Thu, 14 Apr 2005, Master Faris wrote: >> I would like to install gcc on solaris 9 >> sun4u sparc SUNW,Sun-Fire-V440 >> >> can you give me some directions or where to find instructions please as >> this is my first time

ld segfaults on ia64 trying to create libgcj.so

Is anybody seeing this failure on ia64? ld segfaults trying to create libgcj.so in mainline. This was working as of 2005-04-13: - /home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/./gcc/xgcc -shared-libg cc -B/hom

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 09:33:52AM -0400, Diego Novillo wrote: > My ppc64 tester started failing last night while trying to create > libstdc++ libraries with: > I forgot to mention. This is on mainline. Diego.

Re: Heads-up: volatile and C++

Jason Merrill wrote: The C++ committee (well, a subgroup represented at this meeting by Hans Boehm) is working on a memory model that supports threaded programs. As someone who uses the C++ language and multi-threading extensively in embedded systems, I have come to the following belief/opinion.

[m68k]: More trouble with byte moves into Address registers

This is driving me up a tree. I have a fix for 18421(on mainline & gcc-3.4.3) that uses HARD_REGNO_MODE_OK to prevent bytes into address registers, and modified movqi for ColdFire to drop the '*a' in d*a/di*a constraint, as well as modified addsi3_5200 to us 'i' instead of 's'. My current proble

Re: Heads-up: volatile and C++

"Michael N. Moran" <[EMAIL PROTECTED]> writes: [...] | While I'm on my soap-box ... | I would like to see some sort of alignment qualifiers | added to the C++ language for those of us that need | to deal with directly with page/cache alignment | (for both types and objects.) We just discuss (aga

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > which I see you've already committed a patch for, and a large number > > of Java failures. > > > > > > > > for 4.0.0-20050410. > > Same failure as on Solaris. > > Andrew, do you have a Darwin machine

Re: Heads-up: volatile and C++

> "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes: Michael> Jason Merrill wrote: >> One proposed change is to the semantics of volatile. Michael> Since IANALL, but I believe (as obviously you do) that Michael> changing the semantics of volatile should be under-taken Michael> with

Processor-specific code

Hi all, I'm working on implementation of the different FPU options for libgfortran, the runtime library for gfortran (e.g., on which floating-point exception do we want a SIGFPE to be raised, what rounding-mode does the user want, etc.). There is nothing in standard C (or even POSIX) to do that,

Re: Processor-specific code

On Thu, Apr 14, 2005 at 04:39:30PM +0200, Fran??ois-Xavier Coudert wrote: > > I'm working on implementation of the different FPU options for libgfortran, > the runtime library for gfortran (e.g., on which floating-point exception > do we want a SIGFPE to be raised, what rounding-mode does the us

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

David, Kate> Err ... what target-specific installation notes for AIX? Kate> Where are you looking? David> *-ibm-aix* Hmm ... The ordering of targets seems rather confusing. I guess I expect that *-*-freebsd* *-*-linux-gnu *-*-solaris2* *-*-sysv* *-*-vxworks* *-ibm-aix* will be c

Re: 2 suggestions

On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote: > I like prepending a string, for example target= or triplet=, etc. Okay. However,... On Thu, 14 Apr 2005, Georg Bauhaus wrote: > If "*-*-solaris2*" should appear as/in the "name" attribute of an , > prepending a name start character is not enough, beca

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> It looks like it wouldn't be too hard to overcome this problem by >> generating the artificial labels in case_index order, instead of in >> goto_queue order, but it's not ob

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> Kate Minola writes: Kate> will be contiguous and at the front of the list. As they Kate> are currently scattered among the targets it can be Kate> difficult to find them. In particular, I do not understand Kate> why *-ibm-aix* is between ia64-*-hpus* and ip2k-*-elf: Kate> ia64-*-hpux* Ka

Re: GCC 4.0 RC2

Richard Sandiford wrote: Richard Sandiford <[EMAIL PROTECTED]> writes: Mark, I tried running some MIPS16 tests against RC1 and found a regression from 3.4. The problem is the following hack in mips.h: [...] The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures from 203 to 58 with no

Re: Processor-specific code

Can you explain in a little more detail what you are trying to accomplish? gfortran can already pass the -m and -f options suppported by gcc. For example, -ffast-math works. Runtime library reads GFORTRAN_FPU_* environment variables if they exist, and set up the FPU accordingly. One other thing

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

David, > Kate> ia64-*-hpux* > Kate> *-ibm-aix* > Kate> ip2k-*-elf > > Alphabetical. > > IA > IB > IP I guess we will have to agree to disagree as to the ordering. I do not like an ordering that has "i < * < i" !!! > Please look at the AIX information again. There are AIX 5.1 and > AIX 5.2 P

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: > Jason Merrill wrote: >> The C++ committee (well, a subgroup represented at this meeting by Hans >> Boehm) is working on a memory model that supports threaded programs. > > As someone who uses the C++ language and

Re: 2 suggestions

On Thu, 14 Apr 2005, Gerald Pfeifer wrote: On Thu, 14 Apr 2005, Georg Bauhaus wrote: If "*-*-solaris2*" should appear as/in the "name" attribute of an , prepending a name start character is not enough, because this attribute is of type NMTOKEN. Therefore it cannot contain * at all. ...if we are abs

Re: Heads-up: volatile and C++

Jason Merrill wrote: The C++ committee (well, a subgroup represented at this meeting by Hans Boehm) is working on a memory model that supports threaded programs. One proposed change is to the semantics of volatile. Currently, volatile semantics are constrained by: 6 The observable behavior of

Re: libstdc++ link failures on ppc64

Diego Novillo wrote: I see no changes in libstdc++ since the previous run and nothing in the C++ FE, so I'm not sure whether it may be something broken in my box. Anybody else seeing this failure? Yep. I see this here on the PPC64 nightly autotester. Br, Jon

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

On Apr 13, 2005, at 10:39 PM, Michael Matz wrote: So PRE is trying to compare two types, and they contains something which can't be handled. Either because they were silently overwritten, or because of a logical error. Or because the C++ front-end does not handle SSA_NAME, there was a thread abo

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

On Apr 13, 2005, at 9:25 PM, Nick Rasmussen wrote: I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. If I minimally change the source file in some ways

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote: > Diego Novillo wrote: > > > > > >I see no changes in libstdc++ since the previous run and nothing > >in the C++ FE, so I'm not sure whether it may be something broken > >in my box. > > > >Anybody else seeing this failure? > > > > Yep. I

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote: > * tree-eh.c (lower_try_finally_copy): Generate new code in > response to goto_queue entries as if the queue was sorted by > index, not pointers. > (lower_try_finally_switch): Likewise. Ok. r~

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 12:46:08PM -0400, Diego Novillo wrote: > On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote: > > Diego Novillo wrote: > > > > > > > > > >I see no changes in libstdc++ since the previous run and nothing > > >in the C++ FE, so I'm not sure whether it may be something

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote: > Jason Merrill wrote: >> 7 Accessing an object designated by a volatile lvalue (_basic.lval_), >> modifying an object, calling a library I/O function, or calling a >> function that does any of those operati

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote: Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Is there any more information that I provide that would be helpful? I've attached the command line, specs and a stacktra

Re: 2 suggestions

> ...if we are absolutely disallowed to use "*", probably just > replacing "*" by "x" without any prefix might be the lesser of all > evils? I guess "x" is fine with me. However can we use "x" only in the anchor and not the link's text label? E.g.: alpha*-*-* That way, the part peop

Re: GCC 4.0 RC1 Available

On Wed, 13 Apr 2005, Paul Jarc wrote: > gcc/doc/install.texi still mentions gcc 3.5 in a few places. Fixed thus (and a similar reference in cpp.texi). It passes "make info", "make dvi" and "install.texi2html". Applied to mainline and 4.0 branch (as a doc patch for which the branch is still op

Re: GCC 4.0 RC1 Available

Joseph S. Myers wrote: On Wed, 13 Apr 2005, Paul Jarc wrote: gcc/doc/install.texi still mentions gcc 3.5 in a few places. Fixed thus (and a similar reference in cpp.texi). It passes "make info", "make dvi" and "install.texi2html". Applied to mainline and 4.0 branch (as a doc patch for which t

Re: ld segfaults on ia64 trying to create libgcj.so

On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote: > GNU ld version 2.14.90.0.4 20030523 Worked for me with 2.15.94. r~

Re: ld segfaults on ia64 trying to create libgcj.so

On Thu, Apr 14, 2005 at 10:24:32AM -0700, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote: > > GNU ld version 2.14.90.0.4 20030523 > > Worked for me with 2.15.94. > OK. Thanks. Diego.

Re: Processor-specific code

On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote: > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > library is loaded, while TR 15580 commands will be ran afterwards (during > execution). You'll find that globally changing the rounding mode will

Re: Processor-specific code

On Thu, Apr 14, 2005 at 10:35:06AM -0700, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 05:27:16PM +0200, Fran?ois-Xavier Coudert wrote: > > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > > library is loaded, while TR 15580 commands will be ran afterwards (during

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: > On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote: >> * tree-eh.c (lower_try_finally_copy): Generate new code in >> response to goto_queue entries as if the queue was sorted by >> index, not pointers. >> (lower_try_final

Re: Processor-specific code

On Apr 14, 2005, at 1:47 PM, Steve Kargl wrote: Does gcc support #pragma STDC FENV_ACCESS No, there is a bug about that somewhere. -- Pinski

Re: GCC 4.0 RC2

Steven Bosscher wrote: On Tuesday 12 April 2005 19:59, Mark Mitchell wrote: Therefore, I'm going to allow some of the queued patches into 4.0 at this time. If your patch isn't on this list, but is here: http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0 I'm still considering it. I'll le

Re: libstdc++ link failures on ppc64

Diego Novillo wrote: On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote: Diego Novillo wrote: I see no changes in libstdc++ since the previous run and nothing in the C++ FE, so I'm not sure whether it may be something broken in my box. Anybody else seeing this failure? Yep. I see this here

Re: Heads-up: volatile and C++

Paul Koning wrote: "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes: Michael> Jason Merrill wrote: >> One proposed change is to the semantics of volatile. Michael> I'm not familiar with ia64 barrier instructions, but I *am* Michael> familiar with PowerPC barrier and synchronization Mic

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 12:20:05PM -0700, Mark Mitchell wrote: > Would you report your as + ld version numbers? Again, I'm guessing that > you have an assembler with COMDAT and a linker without, or a broken > assembler. > binutils-2.15.92.0.2-5 $ ld --version GNU ld version 2.15.92.0.2 200409

Re: GCC 4.0 RC1 Available

On Thu, 14 Apr 2005, Joseph S. Myers wrote: >> gcc/doc/install.texi still mentions gcc 3.5 in a few places. > Fixed thus (and a similar reference in cpp.texi). It passes "make info", > "make dvi" and "install.texi2html". Applied to mainline and 4.0 branch > (as a doc patch for which the branch

Re: Heads-up: volatile and C++

Jason Merrill wrote: On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: Jason Merrill wrote: The C++ committee (well, a subgroup represented at this meeting by Hans Boehm) is working on a memory model that supports threaded programs. As someone who uses the C++ lang

Re: Heads-up: volatile and C++

Jason Merrill wrote: On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote: ... though I suppose you could argue that they aren't required to be visible outside the current thread. This is my interpretation since (to my knowledge) the C++ language does not generally address t

Re: Heads-up: volatile and C++

One interesting thing to consider here is how the C++ semantics compares with that of pragma Volatile in Ada, which is roughly intended to be equivalent to volatile in C.

Re: Heads-up: volatile and C++

On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote: > But the memory model for the language must provide semantics that make it > possible for threaded programs to be written. Currently, if you want to > write a portable pthreads program you need to use a mutex around all uses > of sha

Re: Heads-up: volatile and C++

Robert Dewar <[EMAIL PROTECTED]> writes: | One interesting thing to consider here is how the C++ semantics | compares with that of pragma Volatile in Ada, which is roughly | intended to be equivalent to volatile in C. The suggestion made by Hans is to improve over the existing semantics in C++ (w

Re: Processor-specific code

On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > Does gcc support > #pragma STDC FENV_ACCESS No, but we currently act like access is "on". r~

Re: 2 suggestions

Gerald Pfeifer wrote: On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote: Not necessary. If people would simply follow the directions here: by setting Also, when I click on the link above, it doesn't follow down the page to the anchor. I'm not sure w

Re: Heads-up: volatile and C++

Diego Novillo <[EMAIL PROTECTED]> writes: [...] | Seems to me that if C++ is all of the sudden interested in | dictating memory semantics for threaded programs, it should also | provide language capabilities for other synchronization models | and for threads (as in Java, though the memory model o

Re: 2 suggestions

Gerald Pfeifer wrote: On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote: I like prepending a string, for example target= or triplet=, etc. Okay. However,... On Thu, 14 Apr 2005, Georg Bauhaus wrote: If "*-*-solaris2*" should appear as/in the "name" attribute of an , prepending a name start char

Re: Heads-up: volatile and C++

On Thu, Apr 14, 2005 at 11:19:19PM +0200, Gabriel Dos Reis wrote: > Diego Novillo <[EMAIL PROTECTED]> writes: > > [...] > > | Seems to me that if C++ is all of the sudden interested in > | dictating memory semantics for threaded programs, it should also > | provide language capabilities for other

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 03:29:36PM -0400, Diego Novillo wrote: > On Thu, Apr 14, 2005 at 12:20:05PM -0700, Mark Mitchell wrote: > > > Would you report your as + ld version numbers? Again, I'm guessing that > > you have an assembler with COMDAT and a linker without, or a broken > > assembler. >

Re: Processor-specific code

On Thu, 14 Apr 2005, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 10:47:26AM -0700, Steve Kargl wrote: > > Does gcc support > > #pragma STDC FENV_ACCESS > > No, but we currently act like access is "on". I thought we acted like it is "off", allowing CSE and constant folding which might be

Re: libstdc++ link failures on ppc64

On Thu, Apr 14, 2005 at 01:29:53PM -0700, H. J. Lu wrote: > You need at least > > http://sourceware.org/ml/binutils/2004-12/msg7.html > > for COMDAT. Otherwise, you will get what you saw and > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01606.html > OK, thanks. Diego.

Re: Heads-up: volatile and C++

Gabriel Dos Reis wrote: Seriously, could you give the Ada standardese even though I'm not supposed to understand? -- Gaby Here is the relevant RM quote 15 For an atomic object (including an atomic component) all reads and updates of the object as a whole are indivisible. 16 For a volatile objec

Cross Compile PowerPC for ReactOS

Hi! I started resurrecting PowerPC WinNT GCC support, Ha! I'm running into this atm. /home/gcc-3.4.3-ros/CROSS/gcc/xgcc -B/home/gcc-3.4.3-ros/CROSS/gcc/ -B/usr/powerpcle-pe/bin/ -B/usr/powerpcle-pe/lib/ -isystem /usr/powerpcle-pe/include -isystem /usr/powerpcle-pe/sys-include -O2 -DIN_GCC -DCROS

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote: > On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote: > >> But the memory model for the language must provide semantics that make it >> possible for threaded programs to be written. Currently, if you want to >

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote: > [Ada standard] Yep, sounds a lot like C/C++: volatile reads and writes are required to have sequential ordering relative to each other, but (outside the current thread) they are not ordered relative to non-volatile reads

Re: 2 suggestions

On Thu, 14 Apr 2005, Hugh Sasse Staff Elec Eng wrote: >> ...if we are absolutely disallowed to use "*", probably just replacing >> "*" by "x" without any prefix might be the lesser of all evils? > So long as things to get ported to the x-box? That port wouldn't be called x-box, because dash separa

Joseph appointed i18n maintainer

It is my pleasure to announce that the steering committee has appointed Joseph Myers i18n maintainer, an area he's been taking care of for quite some time now. Please adjust the MAINTAINERS file accordingly, Joseph, and Happy hacking! Gerald

Re: internal compiler error at dwarf2out.c:8362

Martin Koegler wrote: I changed the attribute handler to only return NULL_TREE in any case, but the result is still the same (using the same gcc core). But you are still creating the types in the attribute function right? If so, that is probably why you still have a problem. You mentioned that th

Re: Heads-up: volatile and C++

I'm including the standard annotations, they have no standard value but sometimes do help. Laurent C.6 Shared Variable Control Dynamic Semantics 15For an atomic object (including an atomic component) all reads and updates of the object as a whole are indivisibl

Re: Heads-up: volatile and C++

> "Jason" == Jason Merrill <[EMAIL PROTECTED]> writes: Jason> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar Jason> <[EMAIL PROTECTED]> wrote: >> [Ada standard] Jason> Yep, sounds a lot like C/C++: volatile reads and writes are Jason> required to have sequential ordering relative to ea

Re: internal compiler error at dwarf2out.c:8362

James E Wilson wrote: I tried grepping the sources, and I see this same code appears in the avr and ip2k ports. That gives me a way to try to reproduce the problem with FSF sources. Avr doesn't support DWARF2, and ip2k is being obsoleted because it is unmaintained. As a side note, the AVR por

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> : build/genattrtab > /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > rs6000.md > tmp-attrtab.c > : > : out of memory allocating 12016 bytes after a total of 4161654476 bytes You need to increase the application limits for data on your system. That's what the above ra

Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

For the last few days, since April 8th, I get bootstrap failures on mainline like this: stage1/xgcc -Bstage1/ -B/ices/bangerth/tmp/build-gcc/gcc-install/i686-pc-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long

Re: GCC 4.0 RC2

Joel Sherrill <[EMAIL PROTECTED]> wrote: I know I asked late in the process but this fix for a m68k/coldfire failure just showed up: [Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391 Any chance at it getting considered? This is OK if approved for mainline by a 68K mainta

Re: GCC 4.0 RC2

Richard Sandiford wrote: Mark, I tried running some MIPS16 tests against RC1 and found a regression from 3.4. The problem is the following hack in mips.h: /* When generating mips16 code we want to put the jump table in th

Re: Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

On Apr 14, 2005, at 6:51 PM, Wolfgang Bangerth wrote: For the last few days, since April 8th, I get bootstrap failures on mainline like this: stage1/xgcc -Bstage1/ -B/ices/bangerth/tmp/build-gcc/gcc-install/i686-pc-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-proto

Re: Heads-up: volatile and C++

On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: > Consider Double-Checked Locking > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html). > I used DCL with explicit memory barriers to implement thread-safe > initialization of function-local statics > (libstdc++-v3

Re: Mainline bootstrap failure in tree-ssa-pre.c:create_value_expr_from

Isn't this the normal always_inline problem from the kernel headers? Yes, good spot. Thanks for the help! W. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.i

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

Alexandre Oliva wrote: On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote: * tree-eh.c (lower_try_finally_copy): Generate new code in response to goto_queue entries as if the queue was sorted by index, not pointers. (lower_

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Apr 14, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> On Apr 14, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote: >> >>> On Thu, Apr 14, 2005 at 12:13:59PM -0300, Alexandre Oliva wrote: >>> * tree-eh.c (lower_try_finally_copy): Generate new code in res

Re: Heads-up: volatile and C++

On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: > I shouldn't have used the term "sequential memory ordering." Nobody is > suggesting that C++ should enforce sequential consistency between threads. > But even in the weakest memory models...*especially* in the weakest memory > model

Re: [m68k]: More trouble with byte moves into Address registers

Peter Barada <[EMAIL PROTECTED]> writes: > This is driving me up a tree. I have a fix for 18421(on mainline & > gcc-3.4.3) that uses HARD_REGNO_MODE_OK to prevent bytes into address > registers, and modified movqi for ColdFire to drop the '*a' in > d*a/di*a constraint, as well as modified addsi3_

Re: Heads-up: volatile and C++

On 2005-04-15, at 01:10, Richard Henderson wrote: On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: Consider Double-Checked Locking (http://www.cs.umd.edu/~pugh/java/memoryModel/ DoubleCheckedLocking.html). I used DCL with explicit memory barriers to implement thread-safe initializati

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote: > Richard, what's your level of confidence here? I'd rather not break C++ > or Java... I think it's pretty safe. r~

Objective-C++ Status

What is the status of Objective-C++ support in mainline GCC? Ziemowit Laski was working on integrating such support late last year, but has Apple since halted such integration efforts? Douglas -- ___ NEW! Lycos Dating Search. The only place t

Re: Heads-up: volatile and C++

On Apr 14, 2005, at 8:11 PM, Diego Novillo wrote: The device driver case seems like a more plausible objection to me, but I'd like to see an example there, too. Perhaps Windows? I'd think Windows is chok full of device drivers written in C++. Here in Mac OS X land, many device drivers are writt

"make bootstrap" for cross builds

Hi, I think "make bootstrap" does not make sense for cross builds. We however seem to allow it but fail in a weird way later on (as on mainline). I think this should not be allowed. I discovered this when I mistakenly typed "make bootstrap" out of habit on a cross build. Ranjit. -- Ranjit Ma

Re: [m68k]: More trouble with byte moves into Address registers

>For some reason reload has decided that it needs ADDR_REGS for the >register being reloaded, namely (reg:QI 1420). So gcc looks for a >register in ADDR_REGS which can hold QImode. Because of your changes, >it doesn't find one. So it crashes. > >The question is why reload thinks that it needs A

Re: "make bootstrap" for cross builds

On Apr 15, 2005, at 1:19 AM, Ranjit Mathew wrote: Hi, I think "make bootstrap" does not make sense for cross builds. We however seem to allow it but fail in a weird way later on (as on mainline). I think this should not be allowed. I discovered this when I mistakenly typed "make bootstrap" out of

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

Richard Henderson wrote: On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote: Richard, what's your level of confidence here? I'd rather not break C++ or Java... I think it's pretty safe. OK, Alexandre, please install the patch. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916)

Re: Heads-up: volatile and C++

On Apr 15, 2005, Marcin Dalecki <[EMAIL PROTECTED]> wrote: > On 2005-04-15, at 01:10, Richard Henderson wrote: >> template T acquire(T *ptr); >> template void release(T *ptr, T val); >> >> where the functions do the indirection plus the memory ordering? > Templates are a no-go for a well known