Re: Different sized data and code pointers

[E. Weddington]

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 suggest 
that there's one pointer size for everything.

The backend that I've inherited gets most of the way with some really
horrible hacks, but it would be nice if those hacks weren't necessary. 
In any case, the hacks don't cope with casting function pointers to 
integers.

I too would be interested in different size pointer support as this may 
be needed to further improve the AVR port (add new bigger devices).

Eric

Re: Pascal front-end integration

[E. Weddington]

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 Pascal just fine, but because every new language 
adds to the load on everyone.  (In my ideal world, we'd have stable 
enough interfaces that it was easy to maintain front ends separately 
from the rest of the compiler, but, though I've been extolling that 
vision for years, I've made little progress in realizing it...)

So, the changes for 4.0/4.1 still don't help the situation enough? Or is 
it too early to tell?

Or would you just want to make sure that the Pascal maintainers play "by 
the rules, as everybody else", a la Ada?

Eric

Re: Extension compatibility policy

[E. Weddington]

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 influenced by the target.
2 - To enable their identification so that their run-time access method may
   be influenced by the target. (Likely due to their storage location/type)
 

I know that you are doing this for the AVR target.
You are under the assumption that it is acceptable to attach attributes 
to static constant objects to put data in Program Space for the AVR target.

As Joseph pointed out to you in bug #20258,

implementing DTR 18037 is the best way to go about this.
You consistently do not check with the official AVR maintainers (Denis 
Chertykov and Marek Michalkiewicz), or on the avr-gcc-list 
 to see if any of this will 
fly with the rest of the AVR community.

Eric

Re: Extension compatibility policy

[E. Weddington]

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 attribute */
 

This is unnecessary as you should already know; avr-libc already 
#defines PROGMEM as the attribute specified above.

 something (ROM __FUNCTION__);
Thereby effectively implying the local declaration/use of __FUNCTION__ as:
 ROM static const char __FUNCTION__[4] = "foo";
 something (__FUNCTION__);
Which would enable the backward compatible addition of target specific
attributes to the implied declaration of __FUNCTION__, enabling avr's
backend to place it in progmem, and be explicitly accessed using PSTR()
macros.
 

You're lost. You really don't know what the PSTR() macro does in 
avr-libc, do you?


(Although I know there's concern about enabling fine grain specification
of attributes for implied static const initializer objects; but now believe
that both both fine grain as well as having the ability to define a target
specific attribute in bulk for all implied static const initializer objects
as may be most appropriate in different circumstances
 

No, Joseph Myers already told you that overloading "static const" as 
defining the attribute for objects in different address spaces is NOT 
the way to do it. There should not be an implied way of doing this that 
overloads C keywords. It should be explicit.

This issue has already been talked to death. But, hey, everybody is 
waiting for a patch from you, Paul.

Eric

Re: RFC: New pexecute interface

[E. Weddington]

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:
   http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00227.html
   http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00637.html
   http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01044.html
And at that point I kind of ran out of steam.
Anyhow, I've returned to the issue, and I've tried to put together an
interface based on Zack's suggestion which can handle everything we
might want to handle.  I'm not too crazy about it--there are several
different requirements, and so the interface has again gotten kind of
complicated.  It implements what collect2 needs, and I think can also
do most of what gcc.c needs to implement -time, -pipe, and
--save-temps.
At the moment I've implemented a Unix version.  Versions for other
operating systems should not be difficult.
 

Thanks for taking a look at this again. A solution is badly needed.
Would this be targeted for 4.0, perhaps?
Eric

Re: Questions about trampolines

[E. Weddington]

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 subject was brought up.
There is a project called AVR-Ada, to add Ada to the AVR target:

And there was recent discussion on the avr-gcc-list about the role of 
nested functions which led to discussion about trampolines and Ada for 
the AVR:


Basically, trampolines don't work for the AVR because it is a Harvard 
Architecture device.

This will also affect other similar devices, for example, the new MaxQ 
target support that is going into GCC. IIRC, It's also a Harvard 
Architecture device.


- Do (theoretical?) alternatives to trampolines exist? I.e. something
  that does not generate code runtime.

Yes, you could have double length pointers for function pointers (pointer
to code + static link). This is the more conventional implementation, but
it introduces an overhead when not using nested functions. This overhead
is more than acceptable in Ada, where it would be very nice to get rid
of trampolines for efficiency's sake. But for C this would not be 
acceptable.

Any alternatives that would work for Harvard Architecture devices such 
as the AVR would be welcome.

Eric

Re: Questions about trampolines

[E. Weddington]

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 talking about a system that loads
programs at run-time.
Right. These address spaces are totally seperate. There is no way to run 
code in the data space (RAM). One can store some data in the program 
space (Flash), but it requires special instruction sequences to access it.


These devices typically have a "large" amount of Flash ROM
(32K-68K bytes), and a smaller amount of RAM (512-2K bytes).
Don't hold me to these numbers, but you get the idea.
Code space (Flash): 8K-256K bytes
Data space (SRAM): 512-8K bytes
Non-volatile EEPROM: 256-4K bytes (typically half of SRAM, also requires 
special instruction sequences to access).

Eric

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

[E. Weddington]

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

[E. Weddington]

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_r12/arm-elf/bin/ -Bc:/devkitARM_r12/arm-elf/lib/ 
-isystem c:/devkitARM_r12/arm-elf/include -isystem 
c:/devkitARM_r12/arm-elf/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition  -isystem ./include  -Dinhibit_libc -fno-inline 
-g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I 
-I../../../gcc-4.0-20050319-new/gcc 
-I../../../gcc-4.0-20050319-new/gcc/ 
-I../../../gcc-4.0-20050319-new/gcc/../include 
-I../../../gcc-4.0-20050319-new/gcc/../libcpp/include  -DL_muldi3 -c 
../../../gcc-4.0-20050319-new/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:43:
./tm.h:5:28: error: config/dbxelf.h: No such file or directory
./tm.h:6:27: error: config/elfos.h: No such file or directory
./tm.h:7:37: error: config/arm/unknown-elf.h: No such file or directory
./tm.h:8:29: error: config/arm/elf.h: No such file or directory
./tm.h:9:30: error: config/arm/aout.h: No such file or directory
./tm.h:10:29: error: config/arm/arm.h: No such file or directory
./tm.h:11:23: error: defaults.h: No such file or directory
In file included from ../../../gcc-4.0-20050319-new/gcc/libgcc2.c:56:
../../../gcc-4.0-20050319-new/gcc/libgcc2.h:230:3: error: #error 
"expand the table"
../../../gcc-4.0-20050319-new/gcc/libgcc2.c: In function '__mulhi3':
../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: 
'BITS_PER_UNIT' undeclared (first use in this function)
../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: (Each 
undeclared identifier is reported only once
../../../gcc-4.0-20050319-new/gcc/libgcc2.c:527: error: for each 
function it appears in.)
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory 
`/c/projects/devkitPro/sources/arm-elf/gcc/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory 
`/c/projects/devkitPro/sources/arm-elf/gcc/gcc'
make: *** [all-gcc] Error 2

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 right direction to solve this 
problem?

Interesting.
I just got a similar error with building an avr cross in  the latest 
MinGW/MSYS for gcc 3.4.3. Reported here:


Now I'm wondering whether it's a gcc bug or if it's an MSYS bug. I can 
successfully build gcc for the avr target using cygwin with -mno-cygwin 
and explicitly setting the build and host.

Eric

Re: RFC: #pragma optimization_level

[E. Weddington]

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
working around bugs in a particular compiler release).  All opposition
that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too.
So what is your opinion to all this babysitting-the-compiler?
 

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?

Re: RFC: #pragma optimization_level

[E. Weddington]

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 thought we're trying to minimize the
knobs the user can turn, both for simplicity and maintainance reasons.
And I cannot, offhand, think of an example where improving the compiler
could not do better than allowing the user specifying optimization options
(or parameters -- anyone for changing --param values per function?  This
would make attribute((leafify)) unnecessary, as I could bump inlining
limits for the to-be-leafified functions).
Giving fine-grained control to the user should be done only if it is for
correctness, not for him to feel better and maybe make one version of
the compiler generate slightly better code for him.
 

That would not be the only reason
Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I 
explained that the various optimization passes, while theoretically 
orthogonal, are not entirely orthogonal in practice, and that truning 
on another pass (GCSE, in this caes) avoided other bugs.  For that 
reason, I'm not actually convinced that all the -f options for turning 
on and off passes are useful for end-users, although they are clearly 
useful for debugging the compiler itself.  I think we might have more 
satisfied users if we simply had -Os, -O0, ..., -O3.  However, many 
people in the GCC community itself, and in certain other vocal areas 
of the user base, do not agree.)
(As an OT aside: what about increasing the number of optimization levels 
to handle fine grain control of the -f options for turning on/off 
passes? Let me know if this has been discussed and rejected previously; 
a link would be nice.)

However, function-level optimization control seems to be something 
lots of people really want, and other compilers do offer it.  I think 
it can be particularly useful to people who want to work around 
compiler bugs in a particular routine, without refactoring their code, 
or losing all optimization for a translation unit.

Finer-grained optimization control seems like something that should 
indeed have to pass a relatively strong utility test.

This has been an oft-requested feature in the AVR community (and I would 
also add for the wider embedded community), not so much to work around 
compiler issues but to work out space/speed tradeoffs. Many times the 
embedded user wants practically all of the code to be optimized for 
space except for the few timing cricital functions that need to be 
compiled for speed to run as fast as possible. There are cases where it 
is terribly inconvenient to seperate these functions into seperate files 
(e.g. access to C static variables). The compiler cannot easily make 
this design decision. So this feature is very much desired.

As to anything more fine-grained than functions (which I agree is 
insanity), or the whole inlining mess, I'll leave that to experts.

Thanks
Eric

Re: RFC: #pragma optimization_level

[E. Weddington]

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 to instruct the compiler to actually produce
a loop even when optimizing, then we get copying from/to the stack,
or memory access (ARM). What the compiler users have expected their
compiler to do is to produce an obvious loop using registers.
What do you get if you use the C99 construct of declaring the variable 
in the for statement? Like so:

for(volatile int i = 0; i < COUNT; ++i);
Eric

Re: RFC: #pragma optimization_level

[E. Weddington]

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, where there is a good argument for not using empty loops
as busy-waits, at one time it was documented GCC behavior that it would
work, so we can't really blame the users for trusting the doc.
That's not to say that it was ever a good idea, because of the lack of
control.  If you need a precisely timed busy-wait, an inline assembly
construct is the best bet.
 

Yeah, but that just raises the "barrier for entry" for a lot of people 
starting out in e.g. embedded programming. It's much easier to throw 
together a do-nothing for loop in C then it is to try and wade through 
understanding how to do GCC inline assembly. Would it be reasonable to 
implement what Georg wants iff volatile and register are used, even if 
it has to be restricted to the C99 construct?:

for(register volatile int i = 0; i < COUNT; ++i);
I know it's terribly inaccurate as a delay, and it should be 
discouraged, but unfortunately it seems to be a common idiom in embedded 
code.

Thanks
Eric

Re: Obsoleting c4x last minute for 4.0

[E. Weddington]

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 to do this 
testing; ports without such testing and regression monitoring could be 
considered at risk.

Only the following ports seem to have had results for 4.1.0-mainline (i.e. 
mainline since 4.0 branched) sent to gcc-testresults: alpha, arm, hppa, 
i?86/x86_64, ia64, mips, powerpc, s390, sh, sparc, although cris and mmix 
are evidently monitored for regressions even though they don't get test 
results to gcc-testresults.

Add the AVR to the list of ports that (so far) haven't had test results 
sent to gcc-testresults. It's only been recently that the GCC test suite 
has been able to run for the AVR using an outside simulator. Hopefully 
in the future this will change; there's a lot of work being done on the 
AVR port.

I would also venture to say that the 68HC11/12 port is active as well. 
Though I don't know the status of testing on that port.

Eric

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

[E. Weddington]

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 right direction to solve 
this problem?

Interesting.
I just got a similar error with building an avr cross in  the latest 
MinGW/MSYS for gcc 3.4.3. Reported here:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594>

Now I'm wondering whether it's a gcc bug or if it's an MSYS bug. I 
can successfully build gcc for the avr target using cygwin with 
-mno-cygwin and explicitly setting the build and host.

Danny pointed me to a patch on the mingw mailing list which fixes it 
for me on win2kpro

http://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053052&group_id=2435 


Thanks, Dave, for that pointer.
This patch also works for me for WinXP.
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?

Thanks
Eric

Re: 2 suggestions

[E. Weddington]

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 they can't cover all cases, of course.
*chuckle*
Have you ever seen Dan Kegel's crosstool, as an example?:

This has now become invaluable to the GCC cross toolset community.
Eric

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

[E. Weddington]

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 fixes failure of mingw-hosted
gcc to remove duplicate include paths (because of lack of meaningful
inodes).  I will submit that as soon as I can afford to fix some
hardware problems on my gcc development  machine.  It may be awhile. I
can post the patch to you privately for testing in the meantime.
Danny
 

Yes, could you send me your new patch? I always prefer to use what will 
hopefully go into mainline. Thanks. I'll report how it works as well in 
that bug report.

Good luck with your repairs!
Eric

Re: GCC Cross Compilation

[E. Weddington]

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

[E. Weddington]

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 port is migrating to using DWARF2, especially on 
Windows hosts. But there are known bugs regarding AVR and DWARF2:





Eric

Re: struct __attribute((packed));

[E. Weddington]

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 wanted e1 and e2 to point to a 
"packed struct entrystruct", but this doesn't seem to be what GCC
interprets this code.

 

Take a look at the manual in the section about attributes of variables,

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 e1 
and e2 is pointing to. Though I'm not sure what putting the packed 
attribute on e1 will buy you.

HTH
Eric

Re: struct __attribute((packed));

[E. Weddington]

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 e1 
and e2 is pointing to.
   

That's what I found out by experimenting and is the reason why I am
asking. From what I see on i386,
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 pointer to struct. The 
"packed" attribute is on the variable itself, not the type of the 
variable (pointer to struct)

i.e. this construct is not meaningful.
 

Is it?
The manual says
"The |packed| attribute specifies that a variable or structure field 
should have the smallest possible alignment".

So it sounds like that:
struct entrystruct * entry __attribute__ ((packed));
by itself would mean that the variable entry has the smallest possible 
alignment. I don't know if that is meaningful just by itself or whether 
it is meaningful in your context.
And realise that I'm just postulating from looking at the manual. 
Somebody with more expertise would have to comment about this.

You've got the point - I am collecting ammunition to fight a stubborn
original author :-)
 

Yeah, if that author was thinking that the packed attribute applied to 
what the variable pointed to, then I would think that it is wrong usage 
of the attribute.
I would suggest pointing the author to the description of "packed" in 
the section on attributes of types:
<http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes>

HTH
Eric

Re: struct __attribute((packed));

[E. Weddington]

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
nightmare.   (The application was a piece of legacy code that was
writing via int pointers, but sometimes things were not aligned.  The
fix was much more invasive than it should have been because I could
find no way to define a pointer to packed int.)  If there IS a way to
do that, it sure would be nice for the docs to explain it.  Right now
the documentation of "packed" is essentially unintellegible.
 

According to the docs here:

what about doing something like this?:
---
typedef int packed_int __attribute__ ((aligned (1)));
packed_int *ppi;
---
Eric

Re: struct __attribute((packed));

[E. Weddington]

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))  * entry;
 ==  pointer to packed struct
 I haven't done an exhaustive survey of attributes, but I know it doesn't
work that way for section attributes, and there have been times when I would
have liked it to.
 

That's got my vote! (As if anyone's counting). That would make things so 
much easier, for example, in the AVR port for dealing with multiple 
memory spaces.

Eric

Re: struct __attribute((packed));

[E. Weddington]

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 worked for me.  It seems that
attributes don't apply to type names, only to variables and members. 

 

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.

Eric

Re: struct __attribute((packed));

[E. Weddington]

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:
typedef int pi __attribute__((packed));
 

No, look what I wrote above. Can you try using the *aligned* attribute?:
typedef int packed_int __attribute__ ((aligned (1)));

void set(void *p, int v)
{
   pi *ppi;
   
   ppi = (pi *) p;
   *ppi = v;
}

 

Eric

Re: struct __attribute((packed));

[E. Weddington]

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

[E. Weddington]

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:
(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):
# cat tmp.c
struct my_unpacked_struct
{
 char c;
 int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
 char c;
 int i;
 struct my_unpacked_struct s;
};
# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token
# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
 

Saved as PR 21052
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21052>
Eric

Re: FW: GCC Cross Compiler for cygwin

[E. Weddington]

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-target-libstdc++-v3] Error 1
My configure command is :
../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++ 

Any help/pointers would be appreciated.
Amir
 

You can see if Dan Kegel's crosstool covers that combination:

Eric

Re: FW: GCC Cross Compiler for cygwin

[E. Weddington]

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 
crosstool only handles cross compilers to linux, and hence isn't 
relevant here.
There have been patches to it for building on Cygwin, plus the 
occasional success story on Cygwin, IIRC. (Perhaps Dan can comment). 
IIRC, there are patches to crosstool for newlib too.

I don't know if the specific combination will work, but one could always 
try. At least it's sometimes a better starting point for building a lot 
of cross-toolchains.

Eric

Re: Targets using implicit extern "C"

[E. Weddington]

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.  In fact in general we could
then take the macro out of the tm.h files and into config.gcc, which
is probably a more reliable place to put it anyhow.
 

I think that the decision should be made at configure time, by checking
the #include headers to see if they are C++-ready.  Look for the string
"__cplusplus" in some set of standard headers, if it is not found,
assume that we'll need implicit extern C.  For cross-builds, we still
have a path to the headers to be checked.
   

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.
 

E.g. the AVR target, which normally uses avr-libc:

but only builds avr-libc after gcc is built.
Eric

Re: Targets using implicit extern "C"

[E. Weddington]

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

E.g. the AVR target, which normally uses avr-libc:
<http://savannah.nongnu.org/projects/avr-libc/>
but only builds avr-libc after gcc is built.
   

Right, but you don't need the answer to the question until it's time to
build libstdc++, and you can't build libstdc++ without a C library.
So can't the test be deferred until that point?
 

Seems reasonable, sure.
Eric

Link to reporter's article regarding Borland patent.

[E. Weddington]

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?

[E. Weddington]

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

Questions like this are more topical for the gcc-help mailing list:

Eric

Re: typo in french error message

[E. Weddington]

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 french language).

Yep.  But translations of (GNU) packages are not handled by the
maintainers of those packages; instead, please look at
http://www.iro.umontreal.ca/translation
and join the translation team of your choice!
The link above gives a 404 error here. Do you have one that works?
Eric

Re: Killing fixproto (possible target obsoletion)

[E. Weddington]

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:


So there aren't any "old system headers" around. The RTEMS target for 
the AVR *may* use newlib, but I don't what the status of that is. Ralf 
or Joel would have to chime in on this aspect.
The AVR target no longer uses fixincludes anyway. If there are any 
problems with the headers, we should be able fix them directly in avr-libc.


HTH
Eric

Re: Will Apple still support signed overflow?

[E. Weddington]

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

[E. Weddington]

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:



Specifically, this section:

which I think is very applicable both to bug comments as well as the gcc 
list and this thread in particular. ;-)



2) A mentoring system could help bring along new GCC developers. I'm not
talking about hand-holding, I'm suggesting that having some place for
people to ask a few questions, one on one, to get over certain
conceptual humps.
 



Geez, I've seen this happen many a time on the gcc list. Jim Wilson, in 
particular, I've noticed does a tremendous job in helping new people out 
by pointing them in the right direction (IMHO). Why should something new 
be created?


Anyway, I'll go back to lurking now.

Eric

Re: named address spaces (update)

[E. Weddington]

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 spaces.

I moved to creation of the namespace list to the gen-modes program
(all examples are taken out of my m68hc05 GCC port
http://www.auto.tuwien.ac.at/~mkoegler/index.php/gcc ). A named
address space is allocated with NAMESPACE(name) in the mode definition
file of the port, eg:

NAMESPACE(EEPROM);
NAMESPACE(LORAM);

(I know, that the NAMESPACE is not the correct naming, but named
address space is a bit too long. Any suggestions?)
 

Because it's a space of addresses (as opposed to a space of names), how 
about this?:


ADDRESSSPACE (EEPROM);
ADDRESSSPACE (LORAM);

Eric

Re: named address spaces (update)

[E. Weddington]

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

[E. Weddington]

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

 

Please note that the avr-libc project has all of the developers working 
on the AVR port of the GNU toolchain. avr-libc can be found at Savannah at:



If you would like to implement new devices in the AVR target then be 
aware that:

- you will have to modify GNU Binutils, GCC, and avr-libc.
- and that your device may already be implemented. The avr-libc Patch 
Manager has a number of patches already that implement a lot of new 
devices. We've been waiting for one of the AVR maintainers of GCC (in 
the CC list) to find the time to formally commit them to Binutils or GCC.


If you want more information about the AVR target, I would suggest 
getting on the avr-libc-dev mailing list (part of the avr-libc project 
at Savannah).


Eric Weddington