Re: Hack in gcc/c-decl.c?
Hi,
Sorry, I didn't see that each identifier *is* a lang_identifier, that's
a weird way to keep bindings. It's not that easy for someone new to GCC
to get around the code. What was the design decision behind that hack
(instead of something like:
struct tree_identifier {
struct tree_common common;
struct c_binding *binds[3];
struct ht_identifier id;
})?
I see that make_node_stat allocates a large enough piece of
memory, but which function actually writes to
I_SYMBOL_X(node)->Y_binding ?
Thx.
Domagoj
- Original Message -
From: "Mike Stump" <[EMAIL PROTECTED]>
To: "Domagoj D" <[EMAIL PROTECTED]>
Subject: Re: Hack in gcc/c-decl.c?
Date: Wed, 28 Dec 2005 23:30:22 -0800
> On Dec 28, 2005, at 8:49 PM, Domagoj D wrote:
> > Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
> > be unchanged in 4.2)?
>
> What part was unclear?
>
> > #define I_SYMBOL_BINDING(node) \
> > (((struct lang_identifier *)
> > IDENTIFIER_NODE_CHECK(node))->symbol_binding)
>
> Yes, each identifier is a lang_identifier:
>
>/* sizeof (struct lang_identifier), so make_node () creates
> identifier nodes long enough for the language-specific slots. */
>size_t identifier_size;
>
> > Let's assume that new_decl is a VAR_DECL node. Than,
> > IDENTIFIER_NODE_CHECK(DECL_NAME(new_decl))
> > = new_decl->decl->name, which is an IDENTIFIER_NODE. How is it
> > possible to cast it to (struct lang_identifier *) ??
>
> Because that is the type of the pointer?
>
> > [The worst thing is that it seems to work fine.]
>
> As designed?
--
___
Play 100s of games for FREE! http://games.mail.com/
Objective-C exceptions on the GNU runtime?
Hi, As far as I can tell the -fobjc-exceptions flag is supposed to work with the GNU runtime as of GCC 4.0. However, invoke.texi still states that "Currently, this option is only available in conjunction with the NeXT runtime on Mac OS X 10.3 and later." Shouldn't this be corrected to say "and the GNU runtime in GCC 4.0 and later" as well? Also, PR23306 — that -fobjc-exceptions only works with -fno-unit-at-a- time — still affects GCC 4.0.2. I tried applying the patch in the bug to a clean 4.0.2 checkout, and works fine. Perhaps you could consider backporting the patch to the 4.0 branch? -- - Dan Villiom Podlaski Christiansen
extract register input, output and operator from rtl right before peepholes
Hi,
I'd doing some coding right before peephole2 pass. I'd like to have a
function that takes rtl as input and returns the values of register
inputs, register output and operator. For example,
input:
(insn 496 34 29 1 (set (reg/f:SI 3 r3 [235])
(plus:SI (reg/f:SI 3 r3 [235])
(const_int 4 [0x4]))) 20 {addsi3} (insn_list:REG_DEP_ANTI 28 (nil))
(nil))
returns:
inputs: r3, 4. ouput r3. operator: plus.
I know sched_analyze() in sched-deps.c builds the dependencies in
basic blocks and hope I can find some useful functions there. I
roughly went through the code and didn't really understand.
Because the rtl's are right before peephole2, they're much processed,
which makes things easier. I hope I can find some existing function to
use instead of using something like REGNO(XEXP(SET_SRC(PATTERN(x)),
0)). I believe sched-deps.c has something useful. Can someone help on
this?
Regards,
Haibin
Re: Objective-C exceptions on the GNU runtime?
On Dec 29, 2005, at 8:05 AM, Dan Villiom Podlaski Christiansen wrote: Hi, As far as I can tell the -fobjc-exceptions flag is supposed to work with the GNU runtime as of GCC 4.0. However, invoke.texi still states that "Currently, this option is only available in conjunction with the NeXT runtime on Mac OS X 10.3 and later." Shouldn't this be corrected to say "and the GNU runtime in GCC 4.0 and later" as well? Well I am willing just to remove the comment about being about NeXT runtime since the manual is always the one that comes with the installed GCC. Also, PR23306 — that -fobjc-exceptions only works with -fno-unit-at-a-time — still affects GCC 4.0.2. I tried applying the patch in the bug to a clean 4.0.2 checkout, and works fine. Perhaps you could consider backporting the patch to the 4.0 branch? Since this is not a regression, I am not going to back port my fix, if someone else wants to do it, it is up to them. Thanks, Andrew Pinski
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 12:38 AM, Domagoj D wrote:
Sorry, I didn't see that each identifier *is* a lang_identifier,
that's
a weird way to keep bindings. It's not that easy for someone new to
GCC
to get around the code. What was the design decision behind that hack
(instead of something like:
struct tree_identifier {
struct tree_common common;
struct c_binding *binds[3];
struct ht_identifier id;
})?
That can't work, not all tree_identifiers have a c_binding, for
example, java doesn't.
Also, not all identifiers in all languages have an ht_identifier,
again, for example, java doesn't.
After you check all the language front ends, (grep "lang_ident", it
only takes a few seconds), you discover that the only thing they have
in common is common.
I see that make_node_stat allocates a large enough piece of
memory, but which function actually writes to
I_SYMBOL_X(node)->Y_binding ?
Grep should find it, why not use that?
grep("symbol_binding"), then grep what you find, then just look at
those 20 places.
If you have a patch that makes gcc more understandable, more
conforming to what most people would expect, faster and easier to
maintain and(/or?) smaller please submit it. :-)
Targets
Hello: I was wondering if the team could add the following targets to GCC\G++\G77: Basically make it even more crossplatform compiliant and emulator friendly eg: add the following cpu series : 8080, z80, 6502, 6800, and cpm/8000? :) Maybe OS Specific librarys too (eg CP/M-86\CP/M-86 Also does G77 support Fortran-66? PS: Can I help in any way(testing the mingw port(i don't have linux\bsd\unix\vms\os/2 or mac, just windows and dos Matt Ritchie
Re: Objective-C exceptions on the GNU runtime?
On Dec 29, 2005, at 8:37 AM, Andrew Pinski wrote: As far as I can tell the -fobjc-exceptions flag is supposed to work with the GNU runtime as of GCC 4.0. However, invoke.texi still states that "Currently, this option is only available in conjunction with the NeXT runtime on Mac OS X 10.3 and later." Shouldn't this be corrected to say "and the GNU runtime in GCC 4.0 and later" as well? Well I am willing just to remove the comment about being about NeXT runtime since the manual is always the one that comes with the installed GCC. The comment contains information that is still useful to know, since quite a few people still target 10.[12], so, I'd like it left. I'd counter with: This option is unavailable in conjunction with the NeXT runtime on Mac OS X 10.2 and earlier. ?
Re: Hack in gcc/c-decl.c?
Hi, > That can't work, not all tree_identifiers have a c_binding, for > example, java doesn't. I see. > Also, not all identifiers in all languages have an ht_identifier, > again, for example, java doesn't. Hmm... But tree_identifier in tree.h has an ht_identifier struct. So, is gcc/tree.h C-specific? > If you have a patch that makes gcc more understandable, more > conforming to what most people would expect, faster and easier to > maintain and(/or?) smaller please submit it. :-) Ok, will do :-) Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: Objective-C exceptions on the GNU runtime?
On Dec 29, 2005, at 1:39 PM, Mike Stump wrote: On Dec 29, 2005, at 8:37 AM, Andrew Pinski wrote: As far as I can tell the -fobjc-exceptions flag is supposed to work with the GNU runtime as of GCC 4.0. However, invoke.texi still states that "Currently, this option is only available in conjunction with the NeXT runtime on Mac OS X 10.3 and later." Shouldn't this be corrected to say "and the GNU runtime in GCC 4.0 and later" as well? Well I am willing just to remove the comment about being about NeXT runtime since the manual is always the one that comes with the installed GCC. The comment contains information that is still useful to know, since quite a few people still target 10.[12], so, I'd like it left. I'd counter with: This option is unavailable in conjunction with the NeXT runtime on Mac OS X 10.2 and earlier. ? Woops, I should had read the docs said before saying removing it fully. Anyways yes that is better. -- PinskI
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 10:39 AM, Domagoj D wrote: Also, not all identifiers in all languages have an ht_identifier, again, for example, java doesn't. Hmm... But tree_identifier in tree.h has an ht_identifier struct. So, is gcc/tree.h C-specific? Oops, uhm, I mean, just checking to make sure you're paying attention. :-) I was thinking of cpp_hashcode...
Re: extract register input, output and operator from rtl right before peepholes
Liu Haibin <[EMAIL PROTECTED]> writes:
> I'd doing some coding right before peephole2 pass. I'd like to have a
> function that takes rtl as input and returns the values of register
> inputs, register output and operator. For example,
>
> input:
> (insn 496 34 29 1 (set (reg/f:SI 3 r3 [235])
> (plus:SI (reg/f:SI 3 r3 [235])
> (const_int 4 [0x4]))) 20 {addsi3} (insn_list:REG_DEP_ANTI 28
> (nil))
> (nil))
> returns:
> inputs: r3, 4. ouput r3. operator: plus.
>
> I know sched_analyze() in sched-deps.c builds the dependencies in
> basic blocks and hope I can find some useful functions there. I
> roughly went through the code and didn't really understand.
>
> Because the rtl's are right before peephole2, they're much processed,
> which makes things easier. I hope I can find some existing function to
> use instead of using something like REGNO(XEXP(SET_SRC(PATTERN(x)),
> 0)). I believe sched-deps.c has something useful. Can someone help on
> this?
You can't pull out a single operator in the general case, since there
can be more than one. For an obvious example, consider a multiply/add
instruction.
You can iterate over all the subexpressions by using for_each_rtx on
the PATTERN of the insn.
Ian
Re: Targets
Matt Ritchie <[EMAIL PROTECTED]> writes: > Basically make it even more crossplatform compiliant > and emulator friendly > eg: add the following cpu series : 8080, z80, 6502, > 6800, and cpm/8000? :) gcc is driven by volunteer efforts and by paid efforts. The way to get gcc to support these targets is to write support yourself, or to pay somebody else to do it. If the code is written, I'm sure the gcc maintainers would accept the ports. Otherwise, simply stating that it is a goal of gcc to support these processors will, unfortunately, accomplish nothing. It is already a stated goal for gcc to support multiple architectures: http://gcc.gnu.org/gccmission.html That said, I should note that none of those processors would be an easy port. gcc's register allocator and reload pass are generally designed for targets with many registers and/or flexible addressing modes. None of the chips you mention have either. The ports are definitely doable (at least, they are doable for the processors I know: 8080, z80, and 6502). But they would be a poor choice for somebody's first gcc backend port. And especially for the 6502 the resulting code would likely compare poorly to hand written assembler code. Ian
Re: Hack in gcc/c-decl.c?
Mike Stump <[EMAIL PROTECTED]> writes: | On Dec 29, 2005, at 10:39 AM, Domagoj D wrote: | >> Also, not all identifiers in all languages have an ht_identifier, | >> again, for example, java doesn't. | > | > Hmm... But tree_identifier in tree.h has an ht_identifier struct. So, | > is gcc/tree.h C-specific? | | Oops, uhm, I mean, just checking to make sure you're paying | attention. :-) | | I was thinking of cpp_hashcode... I believe, but I'm not sure, that GCC is using type puning not guaranteed to work (except "common sense" from "obvious model".) I guess we just have to wait till GCC is miscompiled (probably by itself) to see whether the Middle End would cite chapter and verse :-) Or, we just bite the bullet abd "fix" it. -- Gaby
Porting GCC to RDOS and C++ issues
I've successfully ported GCC and Newlib to RDOS. It seems to work with a "hello world" app. However, my main focus is not C, but C++. I found out that libstdc++ didn't compile without modifying it's configuration files to support RDOS. Where do I send patches for libstdc++? To this list? However, now I still get unresolved externals related to C++ exception-handling (_Unwind_resume and so on). Where are these functions implemented, and does there exist some example implementations of these? Why can't newlib or libstdc++ implement these functions? Or have I simply misconfigured libstdc++? The configure script for libstdc++ is *huge* and largely incomprehensible. I used the same ABIs as gnu and linux uses to get it to compile. Leif
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 11:32 AM, Gabriel Dos Reis wrote:
I believe, but I'm not sure, that GCC is using type puning not
guaranteed to work (except "common sense" from "obvious model".)
I think the C family of language standards should think about the
issue and clarify their exact intent... I know C at least was kinda
inadequate from my perspective.
I guess we just have to wait till GCC is miscompiled (probably by
itself) to see whether the Middle End would cite chapter and verse :-)
Or, we can talk about it first. I'd prefer that we talk though the
corner cases instead of just assuming and putting them in. I'd argue
that we should enhance the manual with the corner cases so as to
guide the language standard into making the `right' decision.
In this area, I don't think we do anything unfriendly. What was your
concern?
I see we make use of
struct S { int first; } s;
&s == &s.first, and we upcast and down cast via pointer arithmetic,
and we assume we can change type when a pointer has the right value,
none of these run afoul of what gcc does afaik.
Re: Porting GCC to RDOS and C++ issues
On Dec 29, 2005, at 11:45 AM, Leif Ekblad wrote: However, now I still get unresolved externals related to C++ exception-handling (_Unwind_resume and so on). mrs $ nm libgcc_s.1.dylib | grep Unwind_Re 8c24 T __Unwind_Resume mrs $ nm libgcc/unwind-dw2.o | grep Unwind_Res 24c0 T __Unwind_Resume Where are these functions implemented grep will show you the code that should be used to build it. unwind- dw2.c is the usual place. and does there exist some example implementations gcc contains many examples of ports that work. I'd recommend compiling up gcc on linux, targeted at linux, and you can compare and contrast your port and how it works with it. nm `find -name \*.o` | grep Unwind_Res for example woudl have told you in what file it was defined and should be faster and more accurate than email turn around.
Re: Hack in gcc/c-decl.c?
Mike Stump <[EMAIL PROTECTED]> writes:
| On Dec 29, 2005, at 11:32 AM, Gabriel Dos Reis wrote:
| > I believe, but I'm not sure, that GCC is using type puning not
| > guaranteed to work (except "common sense" from "obvious model".)
|
| I think the C family of language standards should think about the
| issue and clarify their exact intent...
I completely agree.
| I know C at least was kinda
| inadequate from my perspective.
|
| > I guess we just have to wait till GCC is miscompiled (probably by
| > itself) to see whether the Middle End would cite chapter and verse :-)
I suspect that humor does not travel well through emails :-) Sorry.
| Or, we can talk about it first. I'd prefer that we talk though the
| corner cases instead of just assuming and putting them in. I'd argue
| that we should enhance the manual with the corner cases so as to
| guide the language standard into making the `right' decision.
|
| In this area, I don't think we do anything unfriendly. What was your
| concern?
|
| I see we make use of
|
| struct S { int first; } s;
|
| &s == &s.first,
this is guaranteed to work.
| and we upcast and down cast via pointer arithmetic,
It is also defined to upcast and downcast to the first fields.
I was under the impression that we got some core language issues with
pointer arithmetic that will poke at the middle of the structure,
where reasonable people (well respected regular GCC contributors)
disagreed about whether it is well-defined.
| and we assume we can change type when a pointer has the right value,
| none of these run afoul of what gcc does afaik.
Indeed.
-- Gaby
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 12:16 PM, Gabriel Dos Reis wrote:
| > I guess we just have to wait till GCC is miscompiled (probably by
| > itself) to see whether the Middle End would cite chapter and
verse :-)
I suspect that humor does not travel well through emails :-) Sorry.
As my 4 year old would say, that's not funny. :-)
I was under the impression that we got some core language issues
For our purposes, the issue was decided and resolved. We welcome
dissenters to take the issue up with the C committee and see if they
want to clarify the language standard in the way that is yet more
restrictive than what gcc currently does, if they did, then we can
decide if we want to take advantage of the latitude granted by the
language standard.
Another interesting issue would be:
struct S {
int i;
float j;
} s;
*(float *)((char*)&s + 4);
on a platform that generated the program by printf("%d", offsetof(s,
j)) to get the 4. My take, it is valid. Reasonably, I can see
people say, but I want the optimizer to be able to notice that field
j isn't used, and optimize it out. I'd counter with, the optimizer
knows that j is at offset 4, and it can see the +4 and `know' the
field is used. I would love to see the language in the standard that
makes this perfectly clear, one way, or the other.
Re: Porting GCC to RDOS and C++ issues
Where are these functions implemented Mike Stump: grep will show you the code that should be used to build it. unwind- dw2.c is the usual place. OK, I found unwind-dw2.c in the GCC directory. I also found the object files in the linux host directory, but not in the RDOS cross compilation directory. I cannot run the GCC configuration process natively on RDOS (yet), so I must somehow build libgcc with the cross-compiler. Any idea (FAQs) on how to do this? Leif
Re: Hack in gcc/c-decl.c?
Mike Stump <[EMAIL PROTECTED]> writes:
| On Dec 29, 2005, at 12:16 PM, Gabriel Dos Reis wrote:
| > | > I guess we just have to wait till GCC is miscompiled (probably by
| > | > itself) to see whether the Middle End would cite chapter and
| > verse :-)
| >
| > I suspect that humor does not travel well through emails :-) Sorry.
|
| As my 4 year old would say, that's not funny. :-)
|
| > I was under the impression that we got some core language issues
|
| For our purposes, the issue was decided and resolved. We welcome
| dissenters to take the issue up with the C committee and see if they
| want to clarify the language standard in the way that is yet more
| restrictive than what gcc currently does, if they did, then we can
| decide if we want to take advantage of the latitude granted by the
| language standard.
|
| Another interesting issue would be:
|
| struct S {
| int i;
| float j;
| } s;
|
| *(float *)((char*)&s + 4);
I was actually referring to this case (or something to that effect) --
I believe Mark Mitchell was of the opinion that it is undefined
(though, apologies if I misrepresent exactly the opposite of what he
said) and another camp thought it should be defined (or the opposite.)
I don't recall we ever reached an agreement.
| on a platform that generated the program by printf("%d", offsetof(s,
| j)) to get the 4. My take, it is valid. Reasonably, I can see
| people say, but I want the optimizer to be able to notice that field
| j isn't used, and optimize it out. I'd counter with, the optimizer
| knows that j is at offset 4, and it can see the +4 and `know' the
| field is used. I would love to see the language in the standard that
| makes this perfectly clear, one way, or the other.
-- Gaby
Re: Porting GCC to RDOS and C++ issues
On Dec 29, 2005, at 1:01 PM, Leif Ekblad wrote: OK, I found unwind-dw2.c in the GCC directory. I also found the object files in the linux host directory, but not in the RDOS cross compilation directory. I cannot run the GCC configuration process natively on RDOS (yet), so I must somehow build libgcc with the cross-compiler. Any idea (FAQs) on how to do this? make will build libgcc for the target, specifically, you should be able to cd gcc && make libgcc.a to build it. If your port doesn't use dwarf for EH, then it won't build that file, but then again, there will be (should be) no unresolved references to _Unwind_Resume if that were the case. In you makefile, do you have something like: # Additional sources to handle exceptions; overridden by targets as needed. LIB2ADDEH = $(srcdir)/unwind-dw2.c $(srcdir)/unwind-dw2-fde.c \ $(srcdir)/unwind-sjlj.c $(srcdir)/gthr-gnat.c $(srcdir)/unwind-c.c LIB2ADDEHSTATIC = $(LIB2ADDEH) LIB2ADDEHSHARED = $(LIB2ADDEH) LIB2ADDEHDEP = $(UNWIND_H) unwind-pe.h unwind.inc unwind-dw2-fde.h unwind-dw2.h # Don't build libunwind by default. LIBUNWIND = LIBUNWINDDEP = SHLIBUNWIND_LINK = SHLIBUNWIND_INSTALL = ? Anyway, compare and contrast with linux. Build a linux cross, if you want an easier to compare layout.
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 1:25 PM, Gabriel Dos Reis wrote: I was actually referring to this case This is well defined, save for possibly the fact that 4 is written as 4 and not offsetof () and uncontested. The case I think you're thinking of was upcasting; - offsetof(). It was decided. The decision was that upcasting is allowed.
Re: Hack in gcc/c-decl.c?
> | Another interesting issue would be:
> |
> | struct S {
> | int i;
> | float j;
> | } s;
> |
> | *(float *)((char*)&s + 4);
>
> I was actually referring to this case (or something to that effect) --
> I believe Mark Mitchell was of the opinion that it is undefined
> (though, apologies if I misrepresent exactly the opposite of what he
> said) and another camp thought it should be defined (or the opposite.)
> I don't recall we ever reached an agreement.
> -- Gaby
In the case anybody cares about code verifiability... It's exteremely hard
to automatically prove the correctness of the code that uses pointer
arithmetic and casts as in the example above.
Consider the following example:
enum ftype {T1, T2, T3};
static int calls=0;
union x {
double dparam;
float fparam;
long lparam;
int iparam;
};
struct coefs {
union x ux;
float c1;
float c2;
float c3;
int (*offset_callback)(enum ftype t);
} filter_s;
void init(void) {
filter_s.offset_callback = offset;
int offset(enum ftype t) {
int off = sizeof(union x);
calls++;
switch (t) {
case T1: return off;
case T2: return off + sizeof(float);
case T3: return off + 2*sizeof(float);
}
}
float get_coef(enum ftype t) {
return *(float *)((char *)&filter_s + filter_s.offset_callback(t));
}
enum ftype set_coef(enum ftype t, float val) {
*(float *)((char *)&filter_s + filter_s.offset_callback(t)) = val;
return t;
}
How is the compiler going to figure out that c1,c2 and c3 are actually
used?
Proving more interesting properties like
enum ftype tx;
float fx;
... (assign to tx and fx)
assert(get_coef(set_coef(tx, fx)) == fx);
would be even harder.
Domagoj
--
___
Play 100s of games for FREE! http://games.mail.com/
gcc-4.0-20051229 is now available
Snapshot gcc-4.0-20051229 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051229/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 109154 You'll find: gcc-4.0-20051229.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051229.tar.bz2 C front end and core compiler gcc-ada-4.0-20051229.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051229.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051229.tar.bz2 C++ front end and runtime gcc-java-4.0-20051229.tar.bz2 Java front end and runtime gcc-objc-4.0-20051229.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051229.tar.bz2The GCC testsuite Diffs from 4.0-20051222 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Hack in gcc/c-decl.c?
Mike Stump <[EMAIL PROTECTED]> writes: | On Dec 29, 2005, at 1:25 PM, Gabriel Dos Reis wrote: | > I was actually referring to this case | | This is well defined, save for possibly the fact that 4 is written as | 4 and not offsetof () and uncontested. | | The case I think you're thinking of was upcasting; - offsetof(). It | was decided. The decision was that upcasting is allowed. I finally played with Google and found a link to the GCC resolution of the issue http://gcc.gnu.org/ml/gcc/2005-05/msg00537.html (I don't know what happens to the respective C and C++ committee DRs.) I guess, that still leaves open the question of bootstrapping GCC with a compiler that does something else. And apologies to Mark for having represented exactly the opposite of this position. -- Gaby
