Re: Different sized data and code pointers

Thomas Gill wrote: Hi all. I'm working on a GCC backend for a small embedded processor. We've got a Harvard architecture with 16 bit data addresses and 24 bit code addresses. How well does GCC support having different sized pointers for this sort of thing? The macros POINTER_SIZE and Pmode seem to

Re: Pascal front-end integration

Mark Mitchell wrote: James A. Morrison wrote: I made this post, with my changes posted, to see if I would get any support. I'd also suggesting contacting the GCC SC to see what their reaction would be. Personally, I'm not necessarily convinced that adding Pascal to GCC is a good idea. I like

Re: Extension compatibility policy

Paul Schlie wrote: More specifically, there seem to be two predominant motivating reasons why it may be desired to attach a target specified attributes to compiler generated static constant objects: 1 - To enable their identification so that their compile/link time storage location/type may be i

Re: Extension compatibility policy

Paul Schlie wrote: After having the chance to experiment a little, it would seem most ideal in the short term to enable GCC to add an explicit target specific attribute to the effective implied __FUNCTION__ declaration; in AVR's case for example: #define ROM __attribute__((__progmem__)) /* an avr

Re: RFC: New pexecute interface

Ian Lance Taylor wrote: As noted in PR 14316, collect2 doesn't build on Windows due to the use of vfork. There have been at least two patches to address this, one of them from me, one from Zack. My patch is here: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01445.html Zack had some comments:

Re: Questions about trampolines

Robert Dewar wrote: Øyvind Harboe wrote: - Many backends do not support trampolines. Are trampolines something that is ultimately being added to the backends? We have not encountered any targets not supporting nested functions in porting Ada to many different targets. It's interesting that this

Re: Questions about trampolines

Michael N. Moran wrote: Robert Dewar wrote: But there must be a way to write stuff into the instruction data space, or how would you load code? So you just have to setup an auxiliary stack in code space. The AVR is an embedded processor, and the instruction space is is Flash *not* RAM. We're not t

Re: Suggestion for a fix to Bug middle-end/20177

Richard Kenner wrote: That's one of the reasons why very few (any?) machines use CC0 anymore. IIUC, according to there are 12 targets that use cc0, out of a list of 32 targets. Eric

Re: building GCC 4.0 for arm-elf target on mingw host

Dave Murphy wrote: After 3 or 4 restarts it finally appears to proceed normally until building libgcc make[3]: Leaving directory `/c/projects/devkitPro/sources/arm-elf/gcc/gcc' /c/projects/devkitPro/sources/arm-elf/gcc/gcc/xgcc -B/c/projects/devkitPro/sources/arm-elf/gcc/gcc/ -Bc:/devkitARM_r1

Re: RFC: #pragma optimization_level

Richard Guenther wrote: But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only wo

Re: RFC: #pragma optimization_level

Richard Guenther wrote: On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote: Is your objection to a grain finer than the function level? Or is it to the whole concept of having pragmas change the optimization level per function? It would be a general objection - I t

Re: RFC: #pragma optimization_level

Georg Bauhaus wrote: We have just been discussing a similar topic in a de.* newsgroup. A busy-loop function is used to effect a delay, not too precise, but portably. Like #define COUNT 1000 void f() { /*volatile*/ /*register*/ int i; for (i = 0; i < COUNT; ++i) ; } If volatile is used

Re: RFC: #pragma optimization_level

Joe Buck wrote: Georg Bauhaus <[EMAIL PROTECTED]> writes: | A busy-loop function is used to effect a delay, not too precise, | but portably. Like | | #define COUNT 1000 | | void f() { |/*volatile*/ /*register*/ int i; | |for (i = 0; i < COUNT; ++i) | ; Unfortunately, wh

Re: Obsoleting c4x last minute for 4.0

Joseph S. Myers wrote: One possible way of assessing activity would be to say that after 4.1 maintained CPU ports should have test results for mainline regularly sent to gcc-testresults and monitored for regressions, though this rather depends on the willingness of maintainers of embedded ports

Re: building GCC 4.0 for arm-elf target on mingw host

Dave Murphy wrote: E. Weddington wrote: Dave Murphy wrote: copying the compile line and removing the spurious -I and the -I../../../gcc-4.0-20050319-new/gcc/ results in no errors. I'm having a little trouble finding where this line is built up in the makefiles, can anyone point me in the

Re: 2 suggestions

Hugh Sasse Staff Elec Eng wrote: So, I'd like to know if the variations in how to build GCC are so numerous that having a collection of example build scripts is a stupid idea. I think that examples are valuable in aiding understanding. Examples often seem clearer than descriptive text, though the

Re: building GCC 4.0 for arm-elf target on mingw host

Danny Smith wrote: Danny, according to that bug report in SF, you said that you're not submitting that bug to GCC because you couldn't test it on Win 2K and XP. Now it's been tested on both platforms, are you willing to submit that patch to GCC? No, I have an alternative patch that also

Re: GCC Cross Compilation

Vishal Kothari wrote: Hi, Can someone tell me how do I use GCC to build for ARM target? See Dan Kegel's crosstool: And questions regarding building cross-toolchains are better off posted on the crossgcc list: Eric

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: 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

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 ref

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: 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: 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));

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

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: 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 ev

Re: FW: GCC Cross Compiler for cygwin

Amir Fuhrmann wrote: Does anyone have a working recipe to build gcc as a cross compiler for powerpc, to execute under cygwin I've been able to compile binutils, and build the c/c++ compiler, but am failing in: configure: error: No support for this host/target combination. make: *** [configure-targe

Re: FW: GCC Cross Compiler for cygwin

James E Wilson wrote: Amir Fuhrmann wrote: ../gcc-3.4.3/configure --exec-prefix=/usr/local --program-prefix=ppc- --with-stabs -with-cpu=603 --target=powerpc-eabi --with-gnu-as=ppc-as --with-gnu-ld=ppc-ld --enable-languages=c,c++ The suggestion to look at Dan Kegel's crosstool is a good one, but

Re: Targets using implicit extern "C"

Ian Lance Taylor wrote: Joe Buck <[EMAIL PROTECTED]> writes: On Tue, May 10, 2005 at 02:26:12PM -0400, Ian Lance Taylor wrote: How would people feel about adding a configure option --with-implicit-extern-c? Then we could justifiably flip the default for the generic *-elf, etc., targets. I

Re: Targets using implicit extern "C"

Joe Buck wrote: Ian Lance Taylor wrote: It would be hard to make that completely reliable for embedded systems development, where the header files may or not be available in any standard place at the time that gcc is configured. On Tue, May 10, 2005 at 04:30:43PM -0600, E. Weddington

Link to reporter's article regarding Borland patent.

Here's the article in case anyone was interested: Eric

Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?

Paul Albrecht wrote: Is there a way to generate a cross reference listing for a c/c++ program using gcc? -Wl,-Map=mapfile.map,--cref Docs for -Wl option: Docs for linker options (-Map, --cref):

Re: typo in french error message

Segher Boessenkool wrote: There is a typo in french translation of error messages (at least in 4.0 release and in 4.1 snapshot of 05/05/15). It affects gcc/po/fr.po and libcpp/po/fr.po : "sasn effet" should be "sans effet" "sasn lien" should be "sans lien" (The word "sasn" does not exist in frenc

Re: Killing fixproto (possible target obsoletion)

Nathanael Nerode wrote: Propose to stop using fixproto immediately: avr-*-* I'm not even sure exactly what fixproto is supposed to do, but I *highly* doubt that it is needed for the AVR target. The AVR target is an embedded processor that uses it's own C library, avr-libc:

Re: Will Apple still support signed overflow?

Daniel Kegel wrote: I don't know about everybody else, but the subject lines are starting to run together for me :-) Agreed, but will they also support what is wrong with Bugzilla? or was that GCC and floating point? Eric LMAO

Re: Reporting bugs: there is nothing to gain in frustrating reporters

Scott Robert Ladd wrote: 1) Bugmasters could be less perfunctory and pejorative in their comments. Examples have been given. Quoting ESR these days is perhaps not really in vogue, but I've always found this document to be extremely helpful:

Re: named address spaces (update)

Martin Koegler wrote: I continued to work on the support for named address spaces in GCC. I managed to move much of the managing code for the namespace attribute into the create funtions of tree nodes, so in most cases, only the language frontends need to assign and check the named address space

Re: named address spaces (update)

DJ Delorie wrote: Limitations are: * All pointer have Pmode size. The ability to have various pointer widths would be nice too. I would agree with this too. It would be very useful, e.g. for the AVR port. Eric

Re: Hi I want to implement new target AVR MCU's for GCC

Rikard S wrote: Where do I start? I guess there is only some few files that I need to write or edit, using files for similar MCU's as "templates". If I would like to implement new AVR targets, which files are involved? Who knows, maby I can contribute :-) /Best Regards Rikard Strömmer Ple