Re: Unnesting of nested subreg expressions
Thank you for your answer! Am Donnerstag, 21. April 2005 05:11 schrieb James E Wilson: > Björn Haase wrote: > > The mid-end seems not to be able to simplify nested subreg expressions. > > I.e. it seems that there is no known transformation > >(subreg:QI (subreg:HI (reg:SI xx) 0) 0) > > Nested subregs aren't valid. You should refrain from creating them. OK, understood now. So it's up to the back-ends that they prevent that such expression is ever emitted, both in define_expand and define_split. > > (define_expand "xorhi3" > > [(set (subreg:QI (match_operand:HI 0 "register_operand" "=r") 0) > >(xor:QI (subreg:QI (match_operand:HI 1 "register_operand" "%0") 0) > >(subreg:QI (match_operand:HI 2 "register_operand" "r") > > 0))) (set (subreg:QI (match_dup 0) 1) > >(xor:QI (subreg:QI (match_dup 1) 1) > >(subreg:QI (match_dup 2) 1)))] > > If you have 16-bit registers, then I don't think there is any way to > make this work as written. Intra-register high-part subregs aren't > generally valid either. A high-part subreg is generally only valid when > it is an entire-register of a multi-register value. For AVR, we indeed have *only* 8 bit registers, so the template above works quite well as long as operands[2] does not accidently happen to be a subreg expression. The best solution I am seeing now probably then is, to avoid using a subreg-type template for generating the low- and high parts of operands[2] but use special functions for generating the high- and low parts of operands[2]. For this purpose, one probably would consider extending the existing gen_highpart and gen_lowpart functions so that they are also able to work on subreg input operands. > > You will have to use some other kind of rtl here, such as shift and > masks, or zero_extract. > This might be true for >=16 bit targets. For AVR, the only difficulty I have been experiencing with above expand-pattern is the case of subreg input operands. > > It seems that the cleanest solution would be to teach gcc how to unnest > > subregs. Therefore my question: Is this possible and where would be the > > place for doing this? > > Or you can fix your expander to stop creating nested subregs. That is > proabably much simpler than trying to teach the rest of the compiler to > accept them. > You can't rely on the fact that any expanded rtl will get simplified, so > if we allow nested subregs, then everyplace that handles them needs to > accept them, and that means an awful lot of code will have to change. > OK understood. > > BTW. I have stepped over a similar issue when using the gen_highpart and > > gen_lowpart functions for splitters after reload. > > I can't comment without details. > > > are working on a label reference immediate operand. It seems that in > > their present form gen_lowpart and gen_highpart should be used only in > > DI-SI-mode splitters since then there is no danger that the DI mode > > expression itself is a subreg of an even larger mode. > > Except that the DImode expression could be a paradoxical subreg of a > smaller mode, in which case you might have similar problems. So far, I now think that the solution of the issue would be to extend gen_lowpart and gen_highpart so that they are able to handle also subreg inputs and use them at all places that emmit RTL (i.e. expand and split). Question is whether I should try to simultaneously implement support for the case of paradoxial subregs as input operand, once I am working on the code? (I had been hoping that, there is a possibility to implement the HI->QI and SI->QI lowering by restricting the changes to the back-end's config directory. But, ok, it seems that one would have to touch at least some of the support functions ...) Thank you again for your comment. Very important for a beginner to have such support. Yours, Björn
Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)
On Wed, Apr 20, 2005 at 06:42:08PM -0700, James E Wilson wrote: > Martin Koegler wrote: > > Placing variables in a specfic section is only a part of the problem. > > I am aware of that. There are already many targets that have special > handling for section attributes, that result in different code being > generated when a section attribute is present. Mostly these have to do > with generating different kinds of address and/or addressing modes > though, and your case sounds more complicated. Handling different kinds > of addresses can be done by setting SYMBOL_REF_FLAGS on a symbol_ref. I also thought about using the SYMBOL_REF_FLAGS, but this would not have worked for pointers in all cases. > >My prototype for the m68hc05 does currently the following (based on GCC > >4.1): > > It looks like a reasonable plan. > > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to > stack slots may not have MEM_EXPR set, but then they can't possibly have > the eeprom attribute either, so that is OK. This not important for my solution, as the conversation is done while creating the RTL. After the expand pass, the RTL contains library calls, instead of the writes to the eeprom. RTL based optimiziations should have no problem with them. I don't think, that an RTL optimizer can even create a new store expression to the eeprom, if non is present in the RTL (the library calls are not recognizable as such a expression). > >+ if (expr == NULL_TREE) > >+expr = t; > > This is setting MEM_EXPR to a type. Yes, this may happen, I should change the code. My RTL expander has even no problem with only a type in MEM_EXPR. > I see that this does work by accident, because MEM_EXPR can be either a > decl or a COMPONENT_REF, and all of the code that excludes > COMPONENT_REFs will also happen to excludes types. > > I don't think it is a good idea in general though. Overloading a field > to have either an expression or a type may result in confusion later. > > Presumably this is only a problem because some MEMs don't have the > MEM_EXPR field set, in which case a better solution is to find the > places that forget to set it and fix them. In my test cases, set_mem_attributes_minus_bitpos can be called with eg. unit size align 8 symtab 0 alias set 2 attributes > precision 16 min max pointer_to_this > arg 0 public unsigned HI size unit size align 8 symtab 0 alias set -1> arg 0 used unsigned ignored HI file t10.c line 15 size unit size align 8 context (reg:HI 27 [ D.1314 ]) chain > arg 1 >> as t. Such an expression will not be stored in the original code. Tree based optimizer create in higher optimization levels statements like *(y+10)=3; which result in this expression. So, how to change this function? As a MEM_EXPR may only be a DECL or a COMPONENT_REF, storing a indriect_ref of a plus_expr is also not valid. This is, why I had to change the other functions. I peronally like to stay for my port at my current solution, until I hit a problem or I find a more compilant way for solving this issue. Storing also types has the advantage, that even in that case, the replacement will work. If I would change the code to if(expr ==NULL_TREE&&INDIRECT_REF_P(t)) expr=t; I could miss some cases (I have mostly worked on RTL level, so I don't know what other tree expressions are relevant for me). mfg Martin Kögler [EMAIL PROTECTED]
Re: different address spaces (was Re: internal compiler error at dwarf2out.c:8362)
Martin, I think that the AVR people would very much appreciate if you would report occasionally on your progresses concerning your realization of the different address space issue on your personal HC05 port. (In my opionion, the lack for support of different memory spaces is the key weakness of the present avr port and I think that any avr-gcc user would be very happy if this weakness could be removed some day.) While I think, that I now have quite a clear picture on which kind of modifications would be required for the back-end (namely more sophisticated define_expand patterns and possibly some new unspecs (and corresponding define_insn/define_split patterns) for EEPROM and PMEM ), I don't have any idea on how complicated the work on the tree level would be and of course, whether your approach generally would be suitable for being included in mainline gcc. Yours, Björn
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
> >> : build/genattrtab > >> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > >> rs6000.md > tmp-attrtab.c > >> : > >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes > > > > You need to increase the application limits for data on your system. > > No, something is very wrong here, I think. genattrtab has allocated > *4Gb*! Yes, a total of more than 4GB has been allocated. However, most of this memory has been freed. Thus, the total isn't particularly informative. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
Dave, > > : build/genattrtab > > /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > > rs6000.md > tmp-attrtab.c > > : > > : out of memory allocating 12016 bytes after a total of 4161654476 bytes > > You need to increase the application limits for data on your system. > That's what the above rather uninformative message is trying to say. Thanks. Following your suggestion, I was able to build gcc-4.0.0 RC2 on powerpc-ibm-aix5.2.0.0. My original limits were % limit cputime unlimited filesize1048575 kbytes datasize131072 kbytes stacksize 32768 kbytes coredumpsize1048575 kbytes memoryuse 32768 kbytes % I then did % unlimit datasize % unlimit stacksize (not sure both are necessary) and my new limits were % limit cputime unlimited filesize1048575 kbytes datasizeunlimited stacksize 4194304 kbytes coredumpsize1048575 kbytes memoryuse 32768 kbytes % With these limits, I was able to build gcc-4.0.0 RC2 on powerpc-ibm-aix5.2.0.0. I still do not know what AIX 5.1 and AIX 5.2 PTFs David Edelsohn was referring to ... or where they are referenced. But evidently increasing the data limit was sufficient. Kate Minola University of Maryland, College Park
Re: RFA: .opt files for x86, darwin and lynxos
#if TARGET_MACHO - darwin_one_byte_bool = ""; + darwin_one_byte_bool = 1; #endif > A general comment is this vaporizes lots of comments. I'm not sure > how I feel about that, but thought I would point that out. Alternatively to Richard's more correct suggestion, you could also put them into the respective .opt file preceding them with a ";". I took this option when I moved most of the -f options to common.opt. Kelley Cook
Help Required on HP-UX 11.0 & 11.11
Dear Sir / Madam I'm Vijay from McAfee.We are working on HP-UX 11.11& HP-UX 11.0 presently .We are getting an error while we work on HP-UX 11.11. System Configurations : * HP -UX 11.11 & 11.0 * Patched with GOLDQPK11i_11.11.depot * gcc 3.4.2 & gcc 3.4.3 * Gettext 0.14.1 * Libiconv 1.9.2 Our application (ebs) is giving this error when we run it on HP-UX . #ebs /usr/lib/dld.sl: Can't open shared library: libc.2 /usr/lib/dld.sl: No such file or directory /sbin/init.d/ebssdkd[9]: 5094 Abort(coredump) Please let us know where we are going wrong .An early response would be appreciated. Thanks Vijay Kumar Senior Software QA Engineer McAfee Inc Bangalore India Phone :91-80-25009415 Cell :91-09448353194
Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0
On Thu, 21 Apr 2005, John David Anglin said:
> Yes, a total of more than 4GB has been allocated. However, most of
> this memory has been freed. Thus, the total isn't particularly
> informative.
[insert moan about absence of xfree() to adjust count down here]
--
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
--- Peter da Silva
What's the fate of VARRAY_*?
Hi Nathan, Now that you've checked in your new VEC API, I think that's strictly more powerful than VARRAY. Should we start converting uses of VARRAY to VEC? I'd be happy to help out here. Kazu Hirata
Re: What's the fate of VARRAY_*?
Kazu, Now that you've checked in your new VEC API, I think that's strictly more powerful than VARRAY. Should we start converting uses of VARRAY to VEC? I'd be happy to help out here. I think it would be an excellent idea! I'm still going through assertifying things. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Some small optimization issues with gcc 4.0 20050418
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello!
I just tested the prerelease of gcc 4.0 (to see whether my programs
still compile and work), and I must say: Congratulations, no real
problems so far.
But I noticed some smaller optimization issues on x86, and on of them is
a regression to gcc 3.3 so I'm reporting this here. Accept my apologies
if this is already known, but I think it's worth noting.
So, for the real stuff, take this c program:
=== example1.c ===
#include
void test()
{
int i;
for (i=10; i>=0; i--) {
printf("%d\n", i);
}
}
int main()
{
test();
return 0;
}
===
Everthing was compiled using:
gcc -S -O3 -fomit-frame-pointer -o output input
gcc 3.3 compiles the test() function to the following x86 assembler:
===
test:
pushl %ebx
subl$8, %esp
movl$10, %ebx
.p2align 4,,15
.L30:
movl%ebx, 4(%esp)
movl$.LC0, (%esp)
callprintf
decl%ebx
jns .L30
addl$8, %esp
popl%ebx
ret
===
I guess that can't be improved.
But gcc 4.0 thinks so! It compiles the very same code to
===
test:
pushl %esi
movl$-1, %esi[1]
pushl %ebx
movl$10, %ebx
subl$20, %esp[2]
.p2align 4,,15
.L2:
movl%ebx, 4(%esp)
decl%ebx
movl$.LC0, (%esp)
callprintf
cmpl%ebx, %esi [3]
jne .L2
addl$20, %esp
popl%ebx
popl%esi
ret
===
[1] Why keep the -1 constant in %esi? The cmpl with constant is only 1
byte longer.. this doesn't justify this.
[2] It's allocating 5 words on stack while 2 would be enough. I know
that gcc isn't very smart at optimizing the stack slots but this is a
regression
[3] Why use the cmpl at all? gcc 3.3 did this right, I don't think the
cmpl is faster than a decl (and even then, the cmpl could be replaced by
a "subl $1, %ebx")
NB: When gcc inlines this function, it will be compiled to
===
main:
pushl %ebp
movl%esp, %ebp
pushl %ebx
movl$10, %ebx
subl$20, %esp
andl$-16, %esp
subl$16, %esp
.p2align 4,,15
.L9:
movl%ebx, 4(%esp)
decl%ebx
movl$.LC0, (%esp)
callprintf
cmpl$-1, %ebx <-
jne .L9
movl-4(%ebp), %ebx
xorl%eax, %eax
leave
ret
==
(test() is inlined in main())
As you can see, now gcc doesn't use a register for the -1 constant.
Quite odd I think.
**
Now for a second example:
== example2.c ===
#include
int i;
void test()
{
for (i=10; i>=0; i--) {
printf("%d\n", i);
}
}
int main()
{
test();
return 0;
}
==
This is roughly the same as example 1, but "i" is now a global variable.
We can directly take a look on how gcc-4.0 compiles this, because
gcc-3.3 does almost the same:
==
test:
movl$10, %eax [2]
subl$12, %esp [1]
movl%eax, i
movl$10, %eax [2]
.p2align 4,,15
.L2:
movl%eax, 4(%esp)
movl$.LC0, (%esp)
callprintf
movli, %eax
decl%eax[3]
testl %eax, %eax [3]
movl%eax, i
jns .L2
addl$12, %esp
ret
==
[1] Again, the wasted stack. gcc-3.3 doesn't get this right, too.
[2] Even a peephole optimizer could optimize this :)
[3] The testl is unneeded, the flags are already prepared by the decl.
Is this a hard optimization to accomplish? It's quite obvious for a
human, but I don't know how this looks from a compiler perspective...
Sebastian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBQme5/f81M8QtvOSJAQLRGggAnpufAt1xuImGpsw0aTk/gCD+FmGUq2LR
3mPPX+E0zCbJCVfyuJl45j0fbyjhrEpqKdQ+rkpUhvBpC/BN2kO3clDZktHczMuq
WjjPQxbcBGX1jSvGQVS5bfgXIaeYRF5V9quzm3N4c0hXSsPHlwHCa4jbAQxCqdly
8XH9wzCUyjpfxDKG4zSzAS5DUg/hdAbBCekLBAjTSZhCqr1XmZJ5SmNIu9ZH0anU
rMDYaZPFJ4Cq291xON4R1g5enSnwkdlxh6zGmtvsXwY+KbJW1Tpq5q80lSjx7RUF
P5IZsvoqOzdV6PvUBhqft/w1xCRWn/11bgyuAfJ3Wna8j3IXeJHoiA==
=5WkM
-END PGP SIGNATURE-
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
> James E Wilson wrote: > ... > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to stack > slots may not have MEM_EXPR set, but then they can't possibly have the > eeprom attribute either, so that is OK. > > This could be a maintenance problem if other developers make changes and > forget to keep the MEM_EXPR fields accurate. The more we use the MEM_EXPR > fields, the less of a problem this will be. - Might it be possible to introduce and use by convention a new macro which will always wrap a new pointer in a mem expression with attributes copied from the previous mem/symbol's reference enforced? (Thereby hopefully making it more convenient and less error prone? Ideally possibly supporting at least a few generic target definable attributes which are correspondingly preserved for all variable, literal-data, and function result and parameter object declaration references by default.) > ... > Presumably this is only a problem because some MEMs don't have the > MEM_EXPR field set, in which case a better solution is to find the places > that forget to set it and fix them. - One of the things that's been eluding me, is that I can't seem to find where literal string constant mem references aren't being properly declared and/or preserved as READONLY/unchanging references, resulting in MEM_READONLY_P failing to identify them; although literal char array references, which seem logically equivalent, do seem to be properly declared/preserved? Any insight would be appreciated, -paul-
Re: [gnu.org #232052] FW: GNU Mailing Lists Question #1
> Hi. I'm hoping you can help me with the questions in this e-mail and > the one that follows. I'd sent each originally to [EMAIL PROTECTED], > thinking that that person would be the best one to answer questions > about GNU mailing lists, but James Blair responded by recommending > that I look at the site (which I already have) or contact you. > Hello, <[EMAIL PROTECTED]> is not a mailing list; it's the general contact address for the FSF and the GNU project, and not for technical support. Please remove us as a CC from this thread. Thanks. -- John Sullivan Program Administrator| Phone: (617)542-5942 59 Temple Place, Suite 330 | Fax: (617)542-2652 Boston, MA 02111-1307 USA|
Re: [gnu.org #232057] FW: GNU Mailing Lists Question #2
> Hi. Here's the second e-mail my previous message referred to. As > that e-mail explained, I'd sent my questions originally to > [EMAIL PROTECTED], thinking that that person would be the best one to > answer questions about GNU mailing lists, but James Blair responded by > recommending that I look at the site (which I already have) or contact > you. > Hello, Please remove us as a CC from this thread as well. Thanks. -- John Sullivan Program Administrator| Phone: (617)542-5942 59 Temple Place, Suite 330 | Fax: (617)542-2652 Boston, MA 02111-1307 USA| # Get RMS's voice on your answering machine: # http://member.fsf.org/referral-2004
Re: 转发: Call into a function?
Zhenyu Guo wrote:
> gcc --static test.c -o test
Hmm, it turns out that the code really does do that. This had me
puzzled for a bit until I remembered that a weak function call would
look like this. This would have been easier if I had the source code to
look at, but I couldn't find gmon_initializer in either gcc or glibc. I
am not sure where it is coming from. Maybe I am looking at the wrong
version of the gcc and glibc sources.
Anyways, the input is going to be something like this:
extern void __gmon_start__ (void) __attribute__ ((weak));
void
gmon_initializer (void)
{
...
if (__gmon_start__)
__gmon_start__ ();
...
}
So in a normal link, __gmon_start__ will not be defined, the body of the
if statement will never execute, and the __gmon_start__ call will be
compiled to an offset of 0, which will be a recursive call to itself.
Compile with -pg, and you will see that you now have a call to
__gmon_start__ because it is now defined.
You can also do "objdump -d -r /usr/lib/crti.o" to see the input code
with relocations, and run "nm /usr/lib/crti.o" to see that
__gmon_start__ is weak.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Java field offsets
On Tue, 19 Apr 2005 18:03:58 -0700, Per Bothner <[EMAIL PROTECTED]> wrote: > Does Dwarf support "computed field offsets"? DWARF 2 does, yes. Jason
IA64 Pointer conversion question / convert code already wrong?
I am looking at a bug/oddity in the HP-UX IA64 GCC compiler in ILP32
mode. Here is some code (cut out from libffi):
typedef void *PTR64 __attribute__((mode(DI)));
extern void bar(PTR64);
void foo(void * x) { bar(x); }
Now the issue is whether or not this is legal and how x should get
extended. I am assuming that it is legal and that, on IA64, we would
like the pointer extended via the addp4 instruction.
When I do not optimize this program I do not get any addp4 instructions,
when I do optimize the program I do get the desired addp4 instructions.
I believe the problem in the unoptomized case is in expand_expr_real_1,
where we have:
case NON_LVALUE_EXPR:
case NOP_EXPR:
case CONVERT_EXPR:
.
.
.
else if (modifier == EXPAND_INITIALIZER)
op0 = gen_rtx_fmt_e (unsignedp ? ZERO_EXTEND : SIGN_EXTEND, mode, op0);
else if (target == 0)
op0 = convert_to_mode (mode, op0,
TYPE_UNSIGNED (TREE_TYPE
(TREE_OPERAND (exp, 0;
else
{
convert_move (target, op0,
TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 0;
op0 = target;
}
The EXPAND_INITIALIZER if looks wrong (for IA64) because it assumes that
ZERO_EXTEND and SIGN_EXTEND are the only possibilities and and if op0 is
a pointer then we have a third possibility for ia64. Is the use of
gen_rtx_fmt_e an optimization that could be replaced by convert_to_mode
or convert_move or is there some underlying reason why that has to be a
gen_rtx_fmt_e call for an initializer?
The existing convert_to_mode and convert_move calls look suspicious to
me too because they use the TYPE_UNSIGNED macro to determine wether to
do signed or unsigned extensions and I am not sure if that would be set
correctly for pointer types based on a platforms setting of
POINTERS_EXTEND_UNSIGNED.
Anyone have any insights?
Steve Ellcey
[EMAIL PROTECTED]
Re: IA64 Pointer conversion question / convert code already wrong?
I believe the problem in the unoptomized case is in expand_expr_real_1, where we have: case NON_LVALUE_EXPR: case NOP_EXPR: case CONVERT_EXPR: This is a conversion between what, two pointer types? If so, I think there should be a special case here to check for converting between two pointer types and call convert_memory_address if so. Also, I think convert_memory_address ought to have a gcc_assert (GET_MODE (x) == to_mode); in the #ifndef case.
Re: IA64 Pointer conversion question / convert code already wrong?
> This is a conversion between what, two pointer types? Yes. From 'void *' to 'void * __attribute__((mode(DI)))' where the first is 32 bits (HP-UX ILP32 mode) and the second is 64 bits. > If so, I think there should be a special case here to check for converting > between two pointer types and call convert_memory_address if so. I don't know why I didn't think of using convert_memory_address. I just tried it and it seems to work in my test case. I will do a bootstrap and test overnight to see how that goes. > Also, I think convert_memory_address ought to have a > gcc_assert (GET_MODE (x) == to_mode); > in the #ifndef case. OK, I'll toss that in too. It won't be seen on the HP-UX side but I'll do a Linux build as well. Steve Ellcey [EMAIL PROTECTED]
Re: Help Required on HP-UX 11.0 & 11.11
> Our application (ebs) is giving this error when we run it on HP-UX . > #ebs > /usr/lib/dld.sl: Can't open shared library: libc.2 This is the wrong list for general HP-UX questions. Your application has not been correctly linked. Read the documentation for chatr and ld. The search path for the above library is incorrectly set in either ebs or one of the shared libraries it uses. A recent linker patch needs to be installed for GCC weak support. See the GCC installation documentation for details. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
c54x port
Hello everyone, I am working on porting GCC to the TI C54x. I have worked alone for a few months, similar to others who have attempted this project, but I am now in the process of setting up a repository on BerliOS so I can work with others. Thus, the primary purpose of this email is to introduce you to my project's website, http://gcc-c54x.berlios.de. Please excuse the layout; web design isn't my forte. However, since I'm already writing, I might as well ask a few questions. :) 1. I chose BerliOS (after speaking with the maintainer of the SF project) because I have heard it is superior to SF. I am also planning on choosing Subversion over CVS for the same reason. However, I have no experience with any of these things-- does anybody have concerns with my choices? It just occurred to me that GCC itself uses CVS; when it comes time to merge the port into GCC, would the use of svn cause undue strife? 2. I plan on taking a GCC release (say, gcc-4.0.0-20050417), treating it as a constant, and building the port on top of it. That way I won't have to concern myself with the development of the rest of GCC (which would hardly affect me). Is this the best method? 3. On a slightly sillier note, what's the best NAME for this port? c54x seems a logical extension of c4x, but then tic54x also seems logical, based on e.g. m68k and i386. I chose gcc-c54x because of the name gcc-cris used by Nilsson in "Portnig GCC for Dunces", and I am planning on using c54x internally as well. Any complaints? Finally, I have a channel on Freenode, #gcc-c54x, and I just set up a mailing list on BerliOS, [EMAIL PROTECTED] If anyone is interested in working on this, I would appreciate the companionship. Also, I am extremely new to this; I hadn't seen GCC source code nor c54x assembly code before starting. If any of you are interested in `mentoring' by signing on to the list and helping out on difficult questions, I would appreciate that as well. However, be aware that the list will not go live for another 6-24 hours, since the changes to BerliOS will not be visible until then. Thanks! -Bryan -- Bryan Richter UCDTT President UC Davis Undergrad, Physics Dept. - A PGP signature is (probably) attached to this email. PGP Key ID: BB8E6CCC signature.asc Description: Digital signature
Regression on mainline in tree-vrp.c
kargl[266] gfc41 -c cher2k.f kargl[267] gfc41 -c -O cher2k.f kargl[268] gfc41 -c -O2 cher2k.f cher2k.f: In function 'cher2k': cher2k.f:1: internal compiler error: in set_value_range, at tree-vrp.c:124 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. gfc41 is a symlink to gfortran. The file cher2k.f is from LAPACK, which used to compile fine at -O2. Candidate commits that break gfortran are 2005-04-17 Kazu Hirata <[EMAIL PROTECTED]> * tree-vrp.c (compare_values): Check that VAL1 and VAL2 are both pointers or both integers. * tree-vrp.c (maybe_add_assert_expr): Don't assert ASSERT_EXPRs for single-use variable. * tree-into-ssa.c: Fix a comment typo. 2005-04-14 Kazu Hirata <[EMAIL PROTECTED]> PR tree-optimization/21021 * tree-vrp.c (compare_values): Work around a bug in the front end that produces a comparison of mismatched types. 2005-04-14 Kazu Hirata <[EMAIL PROTECTED]> PR tree-optimization/20657 * tree-vrp.c (extract_range_from_expr): Notice INTEGER_CST to create an appropriate range from it. 2005-04-13 Kazu Hirata <[EMAIL PROTECTED]> PR tree-optimization/20913 * tree-ssa-copy.c (copy_prop_visit_cond_stmt): Fold COND_EXPR. PR tree-optimization/20702 * tree-vrp.c (maybe_add_assert_expr): Recurse into dominator children that haven't been walked into. -- Steve
Help installing & using GCC
Hi, I am wondering where I can find instructions on how to install GCC on my Windows XP computer. Thanks. Regards, Zhaohui Zhou
Re: SMS in gcc4.0
Steven Bosscher <[EMAIL PROTECTED]>: > On Thursday 21 April 2005 17:37, Mostafa Hagog wrote: > > The other thing is to analyze this problem more deeply but I don't have > > IA64. > ...and I don't care enough about it. Canqun? > > Gr. > Steven > > Ok, I'll try this. Canqun Yang Creative Compiler Research Group. National University of Defense Technology, China.
Re: GCC 4.0 build fails on Mac OS X 10.3.9/Darwin kernel 7.9
On Apr 21, 2005, at 10:58 PM, [EMAIL PROTECTED] wrote: [anandatirtha:~/bin/gnu] shrao% ../gcc-4.0.0/config.guess powerpc-apple-darwin7.9.0 Make always ends like this: Does anyone read the installation instructions? -- Pinski
gcc-4.0.0 build failed
FYI, Downloaded gcc-core-4.0.0.tar.bz and gcc-g++-4.0.0.tar.bz2. Uncompressed both and did a configure followed by a make. Got the following error from make: make[1]: *** No rule to make target `../include/ansidecl.h', needed by `regex.o'. Stop. make[1]: Leaving directory `/usr/local/src/redhat/BUILD/gcc-4.0.0/build- i686-pc-linux-gnu/libiberty' So I created a link in build-i686-pc-linux-gnu to ../include and proceeded. Ran into this error: configure: error: cannot find install-sh or install.sh in .. ./.. So again, I had to create links for install-sh and config.sub in order to proceed with the build. Haven't run into any other errors yet but the build is still going... Eric.
Re: gcc-4.0.0 build failed
On Thu, 2005-04-21 at 22:27 -0600, Eric Lemings wrote: ... > So again, I had to create links for install-sh and config.sub in order > to proceed with the build. Haven't run into any other errors yet but > the build is still going... > > Eric. Build was successful after that.
Re: gcc-4.0.0 build failed
On Apr 22, 2005, at 12:27 AM, Eric Lemings wrote: FYI, Downloaded gcc-core-4.0.0.tar.bz and gcc-g++-4.0.0.tar.bz2. Uncompressed both and did a configure followed by a make. Got the following error from make: Why do people don't read the installation instructions? Yes this is a bug but a known one, see PR 17383 which is fixed on the mainline. There is an easy work around if you just read the installation instructions. -- Pinski
Re: emit_no_conflict_block breaks some conditional moves
Greg McGary wrote: I found that emit_no_conflict_block() reordered insns gen'd by expand_doubleword_shift() in a way that violated dependency between compares and associated conditional-move insns that had the target register as destination. You didn't say precisely what went wrong, but I'd guess you have cmpsi ... movsicc target, ... cmpsi ... movsicc target, ... which got reordered to cmpsi ... cmpsi ... movsi target, ... movsi target, ... which obviously does not work if your condition code register is a hard register. Perhaps a check like && GET_MODE_CLASS (GET_MODE (SET_DEST (set))) != MODE_CC or maybe check for any hard register && (SET_DEST (set) != REG || REGNO (set) >= FIRST_PSEUDO_REGISTER) Safer is probably to do both checks, so that we only reject CCmode hard regs here, e.g. && (GET_MODE_CLASS (GET_MODE (SET_DEST (set))) != MODE_CC || SET_DEST (set) != REG || REGNO (set) >= FIRST_PSEUDO_REGISTER)) which should handle the specific case you ran into. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: SMS in gcc4.0
On Friday 22 April 2005 04:43, Canqun Yang wrote: > Steven Bosscher <[EMAIL PROTECTED]>: > > On Thursday 21 April 2005 17:37, Mostafa Hagog wrote: > > > The other thing is to analyze this problem more > > deeply but I don't have > > > > IA64. > > > > ...and I don't care enough about it. Canqun? > > > > Gr. > > Steven > > Ok, I'll try this. Thanks! For the record, this refers to a patch I sent to Mostafa and Canqun to do what Mostafa suggested last month to make SMS work for ia64, see http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02848.html. Gr. Steven
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
Paul Schlie wrote: - Might it be possible to introduce and use by convention a new macro which will always wrap a new pointer in a mem expression with attributes copied from the previous mem/symbol's reference enforced? This is already an easy function call. I don't see how adding a macro makes it easier to remember to call the function. If you have a concrete suggestion, then you are welcome to post it. - One of the things that's been eluding me, is that I can't seem to find where literal string constant mem references aren't being properly declared and/or preserved as READONLY/unchanging references, resulting in MEM_READONLY_P failing to identify them; although literal char array references, which seem logically equivalent, do seem to be properly declared/preserved? The tree to RTL conversion happens in expand_expr. Just search for STRING_CST in that function and then follow the call chain in the debugger til you find the place that is trying to set RTX_UNCHANGING_P. Old code set it unconditionally, but current code is a bit more complciated. Maybe there is something wrong with the new code. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Unnesting of nested subreg expressions
Björn Haase wrote: So far, I now think that the solution of the issue would be to extend gen_lowpart and gen_highpart so that they are able to handle also subreg inputs and use them at all places that emmit RTL (i.e. expand and split). Question is whether I should try to simultaneously implement support for the case of paradoxial subregs as input operand, once I am working on the code? You were never very clear about what was wrong with gen_highpart and gen_lowpart with respect to subregs. rtl examples are always helpful, e.g. showing RTL input and RTL output and pointing out what is wrong. gen_lowpart already has support for subreg input and presumably should work. gen_lowpart is already pretty involved. If you need something other than a trivial fix, it might be better to try to solve the problem in your md file. I would suggest only trying to fix things that you have testcases for. So if you don't have a paradoxical subreg testcase, then don't try to fix it. You might accidentally make things worse than they already are. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
