implicit type cast problem of reference of ponter to const type

the following code can not compile. is it due to the standard? void testfun(const int *&pr) { } main() { int *p; testfun(p); }

An old timer returns to the fold

For those of you who I've worked with in the past on various GCC issues, I have returned back to GCC land after a long sojourn in other compilation systems. I will start work at AMD on Monday, April 18th, 2005, but I suspect it will be some time before I'm back up to speed. -- Michael Meissner e

Re: Template and dynamic dispatching

Gabriel Dos Reis wrote: C++ templates do not involve dynamic dispatching (I would suspect the same to be true for Ada generics) so I do not understand your comment. Maybe there are unsopken assumptions? As I said, templates and Ada generics cause trouble with certification requirements in two respe

Re: Template and dynamic dispatching

[ I changed the title so that the main topic -- volatile and C++ -- not be diluted ] Robert Dewar: > Paul Koning wrote: >>>"Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: >> >> >> Marcin> On 2005-04-15, at 20:18, Mike Stump wrote: >> >> >> On Thursday, April 14, 2005, at 08:48 PM, M

Re: Heads-up: volatile and C++

Paul Koning wrote: "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: Marcin> On 2005-04-15, at 20:18, Mike Stump wrote: >> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: >>> Templates are a no-go for a well known and well defined subset >>> for C++ for embedded programmin

Re: Heads-up: volatile and C++

Marcin Dalecki: >> Don't accept the marketing explanation either. > > Agreed. Maybe the idea of a subset of C++ basically coming down what > would be a C with inheritance > was somehow over-hyped by too much marketing bragging as an excuse for > some defective C++ compiler > implementation at int

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

Peter Barada wrote: pp_pack.c:2220: error: unable to find a register to spill in class `ADDR_REGS' pp_pack.c:2220: error: this is the insn: (insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421]) (plus:SI (subreg:SI (reg:QI 1420) 0) (const_int -32 [0xffe0]))) 121

Re: Heads-up: volatile and C++

On 2005-04-16, at 00:38, Mike Stump wrote: Seriously, what does that have to do with anything? Well perhaps my view is somehow shed by the project I'm currently sitting on. It's actually kernel programming. And this occurs for me quite to be quite the kind of stuff, which may be very well put thi

gcc-3.4-20050415 is now available

Snapshot gcc-3.4-20050415 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050415/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050415 You'll

Re: Heads-up: volatile and C++

On Friday, April 15, 2005, at 03:19 PM, Marcin Dalecki wrote: You can read it as, it was and will always be, just a bad idea. When will be a full and standard conforming template implementation in GCC finished then? ? Seriously, what does that have to do with anything? I know, let's not recommend

Re: Vectorizing my loops. Some problems.

Richard Guenther wrote: Try typedef float v4sf __attribute__((vector_size(16))); note that the base type (float) now matters, and the vector size is in bytes. This works even for gcc 3.3, so I don't know exactly when it was introduced. D'oh! ...but now I get a more serious problem /msys/1.0/lo

Re: Heads-up: volatile and C++

On 2005-04-15, at 23:59, Mike Stump wrote: On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote: My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. You dare to explain what's so funny about it? Oh, it wasn't funny. Maybe the English is slightl

Re: Heads-up: volatile and C++

> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: Marcin> On 2005-04-15, at 20:18, Mike Stump wrote: >> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: >>> Templates are a no-go for a well known and well defined subset >>> for C++ for embedded programming known comm

Vectorizing my loops. Some problems.

Hi, I just started to work on some loop vectorizing for my project. Some weeks ago I got a snapshot of GCC-4.1-20050313. It compiled my code but I was not able to get the auto-vectorization working. (Yes, I understand why) I decided to try sse intrinsics (X86 Built-in Functions as the manual s

Re: Heads-up: volatile and C++

On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote: My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. You dare to explain what's so funny about it? Oh, it wasn't funny. Maybe the English is slightly too idiomatic? I'd need someone that un

Re: Heads-up: volatile and C++

On 2005-04-15, at 19:58, Gabriel Dos Reis wrote: | Templates are a no-go for a well known and well defined subset for C++ | for embedded programming known commonly as well embedded C++. You'd be surprised to learn that embedded systems people do use templates for various things -- among which, ma

Re: Heads-up: volatile and C++

On 2005-04-15, at 20:18, Mike Stump wrote: On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. My god, you didn't actually buy into that did you? Hint,

Re: inline-unit-growth trouble

On Friday, April 15, 2005, at 01:49 PM, Christopher Jefferson wrote: Mike Stump wrote: On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? Because I'm not an exper

Re: struct __attribute((packed));

Ralf Corsepius wrote: On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote: What?! That whole section in the docs talks about attributes on types. If it doesn't work as described, then the docs need some serious rework. From what I see, the example for packed types doesn't even compile:

Re: struct __attribute((packed));

On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote: > What?! That whole section in the docs talks about attributes on types. > If it doesn't work as described, then the docs need some serious rework. >From what I see, the example for packed types doesn't even compile: (Direct cut'n'paste fr

Re: inline-unit-growth trouble

Mike Stump wrote: On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? Because I'm not an expert on linkers :) It seems to me that this might lead to very, very dif

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: GCC 4.0 RC1 Available

Paolo Bonzini wrote: Kaveh R. Ghazi wrote: Nathanael removed the surrounding for-stmt but left the break inside the if-stmt. http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html 2005-04-12 Paolo Bonzini <[EMAIL PROTECTED]> * acx.m4 (ACX_PROG_GNAT): Remove stray break. OK for 4.0.0. --

Re: inline-unit-growth trouble

On Fri, Apr 15, 2005 at 12:18:54PM -0700, Mike Stump wrote: > On Friday, April 15, 2005, at 09:01 AM, Andreas Krebbel wrote: > >on S/390 we have currently a plenty of testsuite failures > >due to inlining effects. > > > >ld complains about testcases which try to link two files containing > >the s

Re: inline-unit-growth trouble

On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? It seems to me that this might lead to very, very difficult to track down bugs Nope. All those bugs are tr

Re: inline-unit-growth trouble

On Friday, April 15, 2005, at 09:01 AM, Andreas Krebbel wrote: on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. This is

Re: Objective-C++ Status

On Thursday, April 14, 2005, at 09:50 PM, Douglas Charles wrote: 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? I don't believe anyone is working on it at the

rtx/tree calling function syntax

I am trying to backport how -finstrument-functions is handled from gcc 4.0 to gcc 3.4.2. If function instrumentation is enabled, the whole function is wrapped in a try finally block, where the exit call is done from the finally block. So I think the whole function is generated in tree_rest_of_c

Re: inline-unit-growth trouble

Richard Guenther wrote: On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote: Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different c

Re: Processor-specific code

On 2005-04-15 18:56:23 +0100, Paul Brook wrote: > On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > > It is not possible to change the rounding precision with . > > That's because it's an x86/m68k specific implementation detail and > the compiler should be setting it for you. Setting the ro

Re: Heads-up: volatile and C++

> From: Paul Koning <[EMAIL PROTECTED]> >> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: > >>> Michael N. Moran wrote: I'm very much in favor of fine grained >>> synchronization primitives in the compiler, but not of changes to >>> volatile semantics. > > Paul> I wonder if it would be su

Re: Processor-specific code

On Friday, April 15, 2005, at 09:55 AM, Paul Koning wrote: That only works if the notion of switchable rounding mode exists. It doesn't on VAX, PDP-11, PDP-10, ... What, you mean VAX isn't turing complete? :-)

Re: Heads-up: volatile and C++

On Friday, April 15, 2005, at 10:58 AM, Gabriel Dos Reis wrote: Embedded C++ was a mistake, alas a mistake that seems to last. No, there are just confused people in the world that think that it is relevant because they just don't know better, treat the as you'd treat a person that talks about a

Re: Semi-Latent Bug in tree vectorizer

On Fri, Apr 15, 2005 at 10:18:35AM -0600, Jeffrey A Law wrote: > I went ahead and ran this through the usual bootstrap and regression > test. Installed this morning... > Excellent. Thanks. Diego.

Re: Heads-up: volatile and C++

On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke.

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

Peter Barada <[EMAIL PROTECTED]> writes: > >> The problem is that there is no valid QImode instruction that can move > >> values in/out of an address register > > > >I know. I'm suggesting that QImode values have to move in and out of > >address registers via data registers, so you just put t

Re: inline-unit-growth trouble

> > On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote: > > Hi, > > > > on S/390 we have currently a plenty of testsuite failures > > due to inlining effects. > > > > ld complains about testcases which try to link two files containing the > > same function > > in .gnu.linkonce sections but w

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

>> Would it help to rearrange the constraints to have reg += >> mem|reg|constant before the addreg += ... ? > >Probably not in this case. You could try it. It is true that when >two alternatives have the same cost, reload will pick the first one >listed. With my luck that will cause a bigger p

Re: inline-unit-growth trouble

On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote: > Hi, > > on S/390 we have currently a plenty of testsuite failures > due to inlining effects. > > ld complains about testcases which try to link two files containing the same > function > in .gnu.linkonce sections but with different code si

Re: Processor-specific code

On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > > All that said, C99 has to control just about anything you > > could want about the fpu. > > It is not possible to change the rounding precision with . That's because it's an x86/m68k

Re: Heads-up: volatile and C++

Paul Schlie wrote: Michael N. Moran wrote: I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. I wonder if it would be sufficient (if not preferable) to only extend (modify) the semantics for heap/stack and const volatile var

Re: Processor-specific code

On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > All that said, C99 has to control just about anything you > could want about the fpu. It is not possible to change the rounding precision with . -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible valida

Re: Heads-up: volatile and C++

Gabriel Dos Reis wrote: Marcin Dalecki <[EMAIL PROTECTED]> writes: | Templates are a no-go for a well known and well defined subset for C++ | for embedded programming known commonly as well embedded C++. You'd be surprised to learn that embedded systems people do use templates for various things --

RE: Processor-specific code

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> Original Message >> From: Paul Koning Sent: 15 April 2005 17:56 >>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: >> Dave> Doesn't the C language spec require the mode to be switchable Dave> at runtime? >> Dave> In

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

Peter Barada <[EMAIL PROTECTED]> writes: > >So register 1420 is being assigned to a data register. The > >constraints for addsi3_5200 permit the following alternatives: > >mem += datareg > >addrreg = addrreg + reg|constant > >addrreg = reg|constant + addrreg > >reg += mem|reg|cons

Re: struct __attribute((packed));

Andrew Haley wrote: gcc.info: The `aligned' attribute can only increase the alignment; but you can decrease it by specifying `packed' as well. See below. Thanks for the correction. Bleah. :-P I'll go back into lurk mode now Eric

Re: "make bootstrap" for cross builds

On Fri, Apr 15, 2005 at 01:23:39AM -0400, Andrew Pinski wrote: > > 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 thi

RE: Processor-specific code

Original Message >From: Richard Earnshaw >Sent: 15 April 2005 18:08 >> In any case, the ARM or Alpha isn't prevented from working in such a >> fashion just because the rounding mode is encoded in the instruction; it >> just means that fp primitives have to be compiled as intrinsics that

RE: Processor-specific code

Original Message >From: Paul Koning >Sent: 15 April 2005 17:56 >> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> Doesn't the C language spec require the mode to be switchable > Dave> at runtime? > > Dave> In any case, the ARM or Alpha isn't prevented from working in >

Re: struct __attribute((packed));

E. Weddington writes: > Paul Koning wrote: > > >>"E" == E Weddington <[EMAIL PROTECTED]> writes: > >> > >> > > > > > > E> typedef int packed_int __attribute__ ((aligned (1))); > > > >I'd rather the compiler got the work than the docs. > > > >Maybe it's better i

Re: struct __attribute((packed));

Paul Koning wrote: "E" == E Weddington <[EMAIL PROTECTED]> writes: E> typedef int packed_int __attribute__ ((aligned (1))); I'd rather the compiler got the work than the docs. Maybe it's better in newer versions; I don't have anything newer than 3.4.1 built right now. Test program: ty

RE: Processor-specific code

On Fri, 2005-04-15 at 17:49, Dave Korn wrote: > Original Message > >From: Richard Earnshaw > >Sent: 15 April 2005 17:42 > > > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > >> Richard Earnshaw wrote: > >> > >>> Not all environments can change the rounding mode dynamically. For > >>>

Re: Heads-up: volatile and C++

Marcin Dalecki <[EMAIL PROTECTED]> writes: | 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

Re: struct __attribute((packed));

On Apr 15, 2005, at 8:27 AM, E. Weddington wrote: Ralf Corsepius wrote: Hi, I just tripped over this snipped below in a piece of code, I didn't write and which I don't understand: ... struct somestruct { struct entrystruct *e1 __attribute__ ((packed)); struct entrystruct *e2 __attribute__ ((packe

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

>> (insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421) >> (plus:SI (subreg:SI (reg:QI 1420) 0) >> (const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list >> 5558 (nil)) >> (nil)) > >So register 1420 is being assigned to a data register. The >constraints for ad

RE: struct __attribute((packed));

On Fri, 15 Apr 2005, Dave Korn wrote: > I've often wished that __attribute__s would behave like CV-quals: The syntax of attributes is documented in the Attribute Syntax section of the manual. http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html Nested in pointer sequences they do act like

RE: Processor-specific code

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> Doesn't the C language spec require the mode to be switchable Dave> at runtime? Dave> In any case, the ARM or Alpha isn't prevented from working in Dave> such a fashion just because the rounding mode is encoded in the Dave> instruct

Re: struct __attribute((packed));

> "E" == E Weddington <[EMAIL PROTECTED]> writes: E> Paul Koning wrote: According to the docs here: E> >> E> what about doing something like this?: >> E> typedef int packed_int __attribute__ ((aligned (1)

RE: Processor-specific code

Original Message >From: Richard Earnshaw >Sent: 15 April 2005 17:42 > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: >> Richard Earnshaw wrote: >> >>> Not all environments can change the rounding mode dynamically. For >>> example, on the FPA co-processor for ARM, rounding is set by the

Re: Processor-specific code

On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > Richard Earnshaw wrote: > > > Not all environments can change the rounding mode dynamically. For > > example, on the FPA co-processor for ARM, rounding is set by the > > instruction selected -- so the concept of having an environment variable > >

Re: struct __attribute((packed));

Paul Koning wrote: E> According to the docs here: E> E> what about doing something like this?: E> typedef int packed_int E> __attribute__ ((aligned (1))); E> packed_int *ppi; That would make sense, but it has never

Re: struct __attribute((packed));

> "E" == E Weddington <[EMAIL PROTECTED]> writes: E> Paul Koning wrote: >> It sure would be useful, though, if there were a construct that >> does mean "pointer to packed T". In particular, I've often needed >> "pointer to packed int" and found no way to produce that. I ended >> up crea

Re: struct __attribute((packed));

Dave Korn wrote: I've often wished that __attribute__s would behave like CV-quals: char * const ptr; == const pointer to char struct entrystruct * __attribute__ ((packed)) entry; == packed pointer to struct char const * ptr; == pointer to const char struct entrystruct __attribute__ ((packed))

Re: Heads-up: volatile and C++

> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes: >> Michael N. Moran wrote: I'm very much in favor of fine grained >> synchronization primitives in the compiler, but not of changes to >> volatile semantics. Paul> I wonder if it would be sufficient (if not preferable) to only Paul> ext

RE: struct __attribute((packed));

Original Message >From: E. Weddington >Sent: 15 April 2005 17:10 > Ralf Corsepius wrote: >> struct entrystruct * entry __attribute__ ((packed)); >> >> is interpreted as "packed pointer to struct" >> not as "pointer to packed struct", >> >> > I would interpret it that way too: packed po

Re: struct __attribute((packed));

Paul Koning wrote: It sure would be useful, though, if there were a construct that does mean "pointer to packed T". In particular, I've often needed "pointer to packed int" and found no way to produce that. I ended up creating a one-member struct with a packed int inside, which is a syntactic nig

Re: Heads-up: volatile and C++

> Michael N. Moran wrote: > I'm very much in favor of fine grained synchronization primitives > in the compiler, but not of changes to volatile semantics. I wonder if it would be sufficient (if not preferable) to only extend (modify) the semantics for heap/stack and const volatile variables, as en

Re: Semi-Latent Bug in tree vectorizer

On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote: > On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote: > > > When we vectorize the store we copy the virtual operands from the > > original statement to the new vectorized statement via this code: > > > > /* Copy the V_MAY_DEFS r

Re: struct __attribute((packed));

Ralf Corsepius wrote: On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote: It seems that GCC will interpret the above as e1 and e2 is packed within the struct somestruct so that e2 "immediately follows e1" (according to the manual). The packed attribute in this case does not refer to what e

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

inline-unit-growth trouble

Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem

Re: struct __attribute((packed));

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> struct entrystruct * entry __attribute__ ((packed)); Ralf> is interpreted as "packed pointer to struct" not as "pointer to Ralf> packed struct", i.e. this construct is not meaningful. Yes it's meaningful, it may not be what you

Re: struct __attribute((packed));

On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote: > Ralf Corsepius wrote: > > >Hi, > > > >I just tripped over this snipped below in a piece of code, I didn't > >write and which I don't understand: > > > >... > >struct somestruct { > > struct entrystruct *e1 __attribute__ ((packed)); > > st

Successful bootstrap of GCC 3.4.3 on i586-pc-interix3 (with one little problem)

bash-3.00$ ../gcc-3.4.3/config.guess i586-pc-interix3 bash-3.00$ gcc/xgcc -v Using built-in specs. Configured with: ../gcc-3.4.3/configure --verbose --disable-shared --with-stabs --enable-nls --with-gnu-as --with-gnu-ld --enable-targets=i586-pc-interix3 --enable-threads=posix --enable-languages=c,c

Re: struct __attribute((packed));

Ralf Corsepius wrote: Hi, I just tripped over this snipped below in a piece of code, I didn't write and which I don't understand: ... struct somestruct { struct entrystruct *e1 __attribute__ ((packed)); struct entrystruct *e2 __attribute__ ((packed)); }; ... Is this meaningful? I guess the author

struct __attribute((packed));

Hi, I just tripped over this snipped below in a piece of code, I didn't write and which I don't understand: ... struct somestruct { struct entrystruct *e1 __attribute__ ((packed)); struct entrystruct *e2 __attribute__ ((packed)); }; ... Is this meaningful? I guess the author wanted e1 and e

Re: Questions on CC

Timothy Bowers wrote: I am trying to install gcc on RedHat Enterprise Linux 3. I do not have a compiler installed on the system. I see that gcc requires a ISO C90 compiler. Where can I get one? Also, when I try to configure gcc for install, I get an error that states that I need to set cc en

Re: Processor-specific code

Richard Earnshaw wrote: Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. Right, such a feature obviously does

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

Peter Barada <[EMAIL PROTECTED]> writes: > Which debugging dump has the output from "local-alloc"? If its > pp_pack.c.24.lreg, then that is the output I supplied in the original > message which contains(for all bits regarding register 1420 up until > the compilation fails): Sorry, guess I missed

re: some problem about cross-compile the gcc-2.95.3

"zouq" <[EMAIL PROTECTED]> wrote: first i download the release the version of gcc-2.95.3, binutils 2.15, and i use the o32 lib, include of gcc3.3.3 . 1. compile the binutils and install it mkdir binutils-build; cd binutils-build; ../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux

Re: Processor-specific code

On Thu, 2005-04-14 at 18:35, 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 > > execution

Questions on CC

--- Begin Message --- I am trying to install gcc on RedHat Enterprise Linux 3. I do not have a compiler installed on the system. I see that gcc requires a ISO C90 compiler. Where can I get one? Also, when I try to configure gcc for install, I get an error that states that I need to set cc e

Re: Re: Stack and Function parameters alignment

Hmm, I tried to define a peephole like this: // (define_peephole2 [ (set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 "general_operand" "b") ) (set (reg:HI S_HREG)

Re: Heads-up: volatile and C++

> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: Marcin> Templates are a no-go for a well known and well defined Marcin> subset for C++ for embedded programming known commonly as Marcin> well embedded C++. I don't think that's a good argument. If people want to emasculate the la

Re: Objective-C++ Status

"Douglas Charles" <[EMAIL PROTECTED]> writes: > 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 I'm sure integrating Obj-C++ wil

Re: Stack and Function parameters alignment

On Friday 15 April 2005 13:33, Petar Penchev wrote: > Hello All, > The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte) > and PUSH instruction for word as well. > GCC is using them well, until I was told to add a command-line option > which allows GCC to align on word. > It has

Stack and Function parameters alignment

Hello All, The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte) and PUSH instruction for word as well. GCC is using them well, until I was told to add a command-line option which allows GCC to align on word. It has been done, however, there samoe problems. GCC generates foll

Re: Heads-up: volatile and C++

Jason Merrill wrote: On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: For example, device drivers that perform memory mapped I/O on memory spaces which are "guarded" and thus need no additional ordering/synchronization instructions. You mentioned PowerPC in a previo

Re: Heads-up: volatile and C++

Jason Merrill wrote: The device driver case seems like a more plausible objection to me, but I'd like to see an example there, too. Though not widely used, download the OSCL and grep for volatile. http://mnmoran.org/oscl-v1.1.tgz There are many device drivers in this tar-ball, mostly related to the

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

Original Message >From: Zack Weinberg >Sent: 12 April 2005 18:31 > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> Then the error message *really* ought to say >> >> gcc: -E or -x required when input is from standard input >> >> since it is thoroughly obtuse and non-explanatory as it sta

ppc32/e500/no float - undefined references in libstdc++ _Unwind_*

Hello! I guess I need some help to verify my toolchain. My host=target=embedded mpc8540 (e500 core) processor which has no fpu. I am working with: [EMAIL PROTECTED]:/$gcc -v Reading specs from /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4-20050408/configure --

Re: some problem about cross-compile the gcc-2.95.3

On 15 Apr 2005 at 14:56, zouq wrote: > first i download the release the version of gcc-2.95.3, binutils 2.15, This message should go to the crossgcc list... But it is nowadays filled with bolsheviks demanding everyone to start from absolute scratch, so wacky advices expected there :-( So maybe

Re: Patches for coldfire v4e

--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > 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 > > >>t

Re: GCC 4.0 RC2

On Thursday 14 April 2005 21:05, Mark Mitchell wrote: > > Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html > > to your list? If the patch is OKed by rth (ping! :-), it would fix a > > -fPIC ICE regression on IA32 and AMD64. > > So added. Will you please let me know if the pat

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

On Apr 15, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > 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, plea

Re: Heads-up: volatile and C++

On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: > Again, I understand the need for ordering/synchronization, I > simply do not believe that volatile should be overloaded to > include these semantics. > > Part of my point is that there are existing uses of volatil

Re: Heads-up: volatile and C++

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | Richard Henderson <[EMAIL PROTECTED]> writes: | | | 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

Re: Processor-specific code

[speaking of an environnement variable used to set IEEE rounding mode] You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. Further, when folks need rounding modes other than round-to-nearest, they tend to need to switc

some problem about cross-compile the gcc-2.95.3

first i download the release the version of gcc-2.95.3, binutils 2.15, and i use the o32 lib, include of gcc3.3.3 . 1. compile the binutils and install it mkdir binutils-build; cd binutils-build; ../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux -v; make;make install; 2. cp -r

Re: Heads-up: volatile and C++

On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote: > 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 c

  1   2   >