Re: -fno-ira removal

> The following ports haven't been converted yet: > > m32c I've tried and tried to get IRA for m32c working. I asked Vlad and Jeff to look at it, which they have/are, with no definite results yet.

Re: register class constraints question

Joern Rennecke <[EMAIL PROTECTED]> writes: > I'm not sure if this changed with IRA, Acts the same with 4.3 and 4.4. > reload will look for the alternative with the cheapest total cost of > alternative and reloads. This was the key. Disparaging the smaller class's alternative with '?' works -

register class constraints question

I've got this code: (define_insn "andhi3_24" [(set (match_operand:HI 0 "mra_operand" "=Sd,Sd,*Rhl,*Rhl,RhiSd,??Rmm,RhiSd,??Rmm") (and:HI (match_operand:HI 1 "mra_operand" "%0,0,*0,*0,0,0,0,0") (match_operand:HI 2 "mrai_operand" "Imb,Imw,*Imb,*Imw,iRhiSd,?Rmm,?Rmm,iRhiS

Re: m32c: pointer math vs sizetype again

This seems to work, with a suitable extendhipsi2 pattern for m32c: Index: expr.c === --- expr.c (revision 140759) +++ expr.c (working copy) @@ -8455,12 +8459,34 @@ expand_expr_real_1 (tree exp, rtx target if (

Re: m32c: pointer math vs sizetype again

> Ok, I just looked for POINTER_PLUS_EXPR and tried to make sure its > offset is always sign-extended. Can you check where on the call > path above we miss this special treatment? It looks like it drops past them all and gets the generic treatment, just before the MINUS_EXPR case.

Re: m32c: pointer math vs sizetype again

Ok, here's where it's getting expanded: #12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450, unsignedp=1) at ../../gcc/gcc/expr.c:859 #13 0x0831f83a in expand_binop_directly (mode=945, binoptab=0x8824de0, op0=0xb7f63410, op1=0xb7f63450, target=0xb7f63440, unsign

Re: m32c: pointer math vs sizetype again

This is what I get with your patch and not mine: neg.w r0 ; 7neghi2/1 mov.w r0,a0; 9 zero_extendhipsi2 add.l a0,r3r1 ; 15 add

Re: m32c: pointer math vs sizetype again

> (what is the current sizetype mode?) HImode > There are no bitfield instructions. What I suggest is that you make > sizetype 16bits (HImode), as if I remember correctly you are not > concerned anyway about pointer offsets larger than what fits into > signed 16bits. If you then use the expans

Re: m32c: pointer math vs sizetype again

> Can you look in the CVS/SVN archives and see what the mn102 port did -- It used SImode for size_type but I think I tried that and it blew up in useless_type_conversion_p. I can try again if you're interested in the details.

Re: m32c: pointer math vs sizetype again

> I think this is the wrong place to fix this. If you would override > the sizetypes precision from your target, would that fix it? That > is, in stor-layout.c set_sizetype make the target allow adjusting > the passed type (which is supposed to be sizetype). If at all then > these types should

Re: m32c: pointer math vs sizetype again

> Is this related to the loop termination bug I reported > on the m32c? > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665 Probably related, but I don't know if a patch to fix one will fix the other.

Re: m32c: pointer math vs sizetype again

I've got a partial patch which works with older (4.3) gccs, but fails gimple's check for trunk (attached). My trivial test case... char * foo (char *a, int b) { return a-b; } ...fails thusly: constant 32> unit size constant 4> align 8 symtab 0 alias set -1 canonical type 0xb7f52c

Re: m32c: pointer math vs sizetype again

> NEGATE_EXPR on an unsigned type is fully defined. It's what you > should get when you say "unsigned int i, j; ...; i = - j;". I didn't say it was undefined, I said it seemed wrong. Esp since the example starts with a plain "int" value. > I think the problem you are facing may be that POINTER

Re: m32c: pointer math vs sizetype again

> Does the following fix it? Nope, sorry. I was looking at this code in c-common.c, where the expr is first created, but I don't know what that ends up calling: /* Create the sum or difference. */ if (resultcode == MINUS_EXPR) intop = fold_build1 (NEGATE_EXPR, sizetype, intop); ret

Re: Pmode != INT (e.g., SImode)

Michael Eager <[EMAIL PROTECTED]> writes: > Are there any architectures which have Pmode != INT? m32c has Pmode == PSImode, at least with -mcpu=m32c. The r8c/m16c variants have Pmode == HImode == int. > I'm running into a number of problems. Yup! GCC doesn't like ports where sizeof(pointer) !

m32c: pointer math vs sizetype again

m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles this: int *foo (int *a, int b) { return a-b; } as this: _foo: enter #0 ; 30prologue_enter_24 pushm r1,r3,a0; 31pushm ; end of prologue ; 32prologue_end

Re: IRA_COVER_CLASSES for m32c

> Sure, DJ. I'll look at this but unfortunately I can do it on next week > because I am busy with numerous other IRA bugs. Next week would be fine :-) > As I wrote m32c is pretty nasty case and may be will need even insn > description changes. I'm OK with that.

Re: IRA_COVER_CLASSES for m32c

Opening this up to the gcc public, since I appear to be unable to get this to work right. Still no luck defining a working IRA_COVER_CLASSES for m32c. My latest attempt: #define IRA_COVER_CLASSES \ { \ HC_REGS, MEM_REGS, LIM_REG_CLASSES\ } (effectively GENERAL_REGS (which I also tried),

Re: GCC 4.4.0 Status Report (2008-09-09)

> Presumably you're discussing these with Vlad? We did exchange some emails about it, yes.

Re: GCC 4.4.0 Status Report (2008-09-09)

> The following ports are unconverted and I don't recall seeing people > saying they were working on IRA ports, although I may have missed such > statements: > > m32c I am working on m32c but so far have not had good results. All class combinations I've tried so far result in build failures in

Re: Inconsistent use of allocator wrapper macros in libiberty

> Is there some reason for the inconsistency, Not really. Patches welcome.

Re: [m32c] newlib build failure in reload

> If reload is generally flaky like this for m32c, perhaps a target macro to > say not to reload addresses in the particular case my patch affects would > be a sensible approach, if things worked better without reloading them > even though as far as reload knows they need reloading. I wouldn't

Re: [m32c] newlib build failure in reload

> You should file a PR in any case. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827 > Does m32c handle some addresses specially in any way at all similar to the > special SH handling discussed in PR 36780 and > ? Because some > sort

[m32c] newlib build failure in reload

Been getting this for a while, finally had time and resources to track it down. It was introduced by 137639: 2008-07-08 Joseph Myers <[EMAIL PROTECTED]> * reload.c (find_reloads_subreg_address): Do not require validity of address in original mode before reloading address. It w

Re: What may be the reason behind not implementing some instructions of H8SX targets in H8300 port?

"Deepen Mantri" <[EMAIL PROTECTED]> writes: > Does anybody know the reason behind not implementing these > instructions for H8SX targets? Most likely, it's just a case of nobody volunteering to add them yet. For some instructions, it may be difficult to teach GCC the nuances of how they work.

forcing non-cse'd symbols

The R8C has a 20-bit addressing mode for data outside its normal addressing range. However, gcc *really* wants to CSE these and put their addresses in registers, which is not going to work (pointers are 16 bit, these addresses are 20 bit). How can I force gcc to use [sym] or [sym+reg] addressing

[EMAIL PROTECTED]: v850-elf failure in gcc-make]

All my builds returned this error last night. Is anyone else seeing this? --- Start of forwarded message --- Date: Thu, 19 Jun 2008 02:41:26 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: v850-elf failure in gcc-make Failure step: v850-elf-gcc-ma

Re: 4.4 deprecation proposals

> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think > having generic CPU-*-OBJFMT triplets that really refer to a > particular OS is a good idea. It's only certain generic triplets > I'm proposing to deprecate. DJGPP is ix86-pc-msdosdjgpp, yes. However, it's based on the ix86-coff

Re: 4.4 deprecation proposals

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > i[34567]86-*-coff* DJGPP is ix86-coff - how would this deprecation affect djgpp?

Re: [EMAIL PROTECTED]: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf]

> I should start posting these to the testing list. Lots of m16c > improvements, but some m32c regressions. I haven't tried to diagnose > these yet, but if nobody claims it's their fault I will ;-) > > Anyone know why the regressions happened? > > PASS-FAIL: gcc.c-torture/execute/builtins/vspr

[EMAIL PROTECTED]: Results for 4.4.0 20080613 (experimental) [trunk revision 136737] (GCC) testsuite on iq2000-unknown-elf]

Showed up for v850, iq2000, and m32c... Manual compilation results in zero warnings. --- Start of forwarded message --- Date: Fri, 13 Jun 2008 11:21:27 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080613 (experimental) [trunk re

[EMAIL PROTECTED]: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf]

Date: Thu, 12 Jun 2008 07:01:34 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf gcc result changes... Multilib: m32c-sim/-mcpu=m16c FAIL-PASS: gcc.c-torture/execute/

Re: [EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf]

> If i read this right, it says it was a pass, and is now an XFAIL? Yes. > If so, that is the expected result of Richi's patch, and he > mentioned it when he changed it to xfail Ok.

[EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on m32c-unknown-elf]

Same regression, but m32c is overall better since yesterday :-) --- Start of forwarded message --- Date: Wed, 28 May 2008 06:57:46 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) tes

[EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf]

This regression came through just today... --- Start of forwarded message --- Date: Wed, 28 May 2008 09:23:10 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unkno

Re: YAMP: ivopts vs sizetype

> I don't think you can tell that, but maybe look into tree-ssa-address.c where > it asks the target for costs via building some rtx-en. Ok, here's something... I adjusted my address_cost hook to figure costs of offsets more accurately, and even though it only tests "offset" vs "no offset", it do

Re: YAMP: ivopts vs sizetype

> I don't think you can tell that, but maybe look into tree-ssa-address.c where > it asks the target for costs via building some rtx-en. I've got a target_address_cost hook, but it's never passed an RTX with a negative displacement.

Re: Gnu C/C++ compiler

> Please how do I set environment variable DJGPP? What should I set it > to? Your best bet for DJGPP-related questions is still the [EMAIL PROTECTED] mailing list (or comp.os.msdos.djgpp newsgroup). See http://www.delorie.com/djgpp/ for details. The DJGPP ftp sites and mirrors have current gcc b

Re: YAMP: ivopts vs sizetype

> Uh, so sizetype is 32bit but pointer displacements are 24bit? :( Worse. sizetype is 16bit but pointer displacements are 24bit. There are no 24bit address registers, nor are there enough 24bit math opcodes to satisfy gcc (without switching to 32bit emulated math, which is REALLY slow). It's

YAMP: ivopts vs sizetype

(yet another m32c-related problem) Something in ivopts is converting this: ap.1_5 = ap_38 + 2; ap.2_6 = (struct tiny *) ap_38; SR.8_15 = ap.2_6->c; to this: ap.1_5 = ap_38 + 2; SR.8_15 = MEM[base: ap.1_5, offset: 65534]; Now, recall that for -mcpu=m32c size_t is 16 bits but pointers

Re: store_motion query

> But it looks like update_ld_motion_stores() and insert_store() also > call gen_move_insn without adding clobbers if necessary. I suppose the > insns produced there should also go through insn_invalid_p somewhere. > I sent a hack for that to DJ, but I guess the proper place to fix this > is insid

Re: store_motion query

> It looks like it replaced the store with a reg move, and it should > have inserted the store back to memory with the clobber back later in > the CFG. > > IE it pushed your store down to some later point in the CFG. It's not the store that needs the clobber, it's the shift. The R8C can only u

store_motion query

Why is store_motion doing this? STORE_MOTION delete insn in BB 2: (insn 8 7 27 2 dj.c:10 (parallel [ (set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0 .buf+0 S2 A8]) (ashift:HI (reg/v:HI 27 [ n ]) (subreg:QI (reg/

m32c failure at cfgrtl.c:2332 (purge_dead_edges)

I've got a number of test cases that are all failing in the same place: #1 0x081cf498 in purge_dead_edges (bb=0xb7f67834) at ../../gcc/gcc/cfgrtl.c:2332 2332 gcc_assert (single_succ_p (bb)); (similar to http://gcc.gnu.org/ml/gcc/2008-04/msg00473.html but I'm using trunk) What's up here?

Re: more m32c brokenness

> Ok, I'll take care of properly comitting the patch. Thanks!

Re: more m32c brokenness

> The patch simply enabled type checking by default. As I don't see how > we can easily address the underlying problem can you try the following > which simply makes this typechecking weaker? That seems to work. FYI test results show 98% pass rate for C++ and 98.6% pass rate for C, so I'm not s

Re: more m32c brokenness

More digging has identified this patch as the cause of the ongoing C++-related m32c build failures: 2008-03-24 Richard Guenther <[EMAIL PROTECTED]> PR c/22371 * gimplify.c (gimplify_modify_expr): For frontend type-correct pointer assignments change conversions according

Re: h8/300 build failure

Sorry, didn't help.

h8/300 build failure

Anyone else seeing this on trunk? if test -z "$objects"; then \ echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \ /sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc -B/sata/dj/gnu/newlib/h8300-elf/./gcc/ -B/sata/dj/gnu/install/h8300-elf/bin/ -

Re: Problem with reloading in a new backend...

> (call (mem:QI (match_operand:QI 1 "register_operand" "z")) Are you sure your "z" constraint only matches even numbered hard registers?

Re: Problem with reloading in a new backend...

> Maybe I should reserve a special register for this usage (say r0). That might be the only way, yes. Note that reload also assumes that such adds don't change the flags (i.e. a compare/jump pair must not have a flag-modifying add between them).

Re: more m32c brokenness

I tracked it down to this: /* Allow conversions between integral types and pointers only if there is no sign or zero extension involved. */ if (((POINTER_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (op))) || (POINTER_TYPE_P (TREE_TYPE (op)) && INTEGRAL_TY

Re: more m32c brokenness

Sigh, I cleaned out my local patches and now I'm tripping over this again: if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR) && arg0 && arg1 && tt && POINTER_TYPE_P (tt)) gcc_assert (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST); I had locall

Re: Problem with reloading in a new backend...

> switch (which_alternative) { > case 0: /* register to register */ Better to just use the @ syntax that gcc offers, to provide multiple patterns: "@ tfr %0,%1 ldih %0, hi(%1); ldil %0, lo(%1) ldih %0, hi(%1); ldil %0, lo(%1

Re: more m32c brokenness

FYI: my h8/300h builds are failing with the same message, but with different types. Haven't investigated yet. > What size is the internal 'sizetype'? 16 bits. > Is there an integer type with the same width as the pointer type? No. The m32c doesn't have enough operators to have a pointer-size

more m32c brokenness

Continuation of the last one, different bug, building libstdc++ ... Look familiar to anyone? If not, I'll try to hunt down the cause. The culprit is this line: D.25530 = (unsigned int) D.25529; For m32cm, "int" is 16 bits, "long" is 32 bits, and "void*" is 24 bits. A cast to unsigned int t

Re: m32c build fails

It now dies here: In file included from ../../../../../gcc/libstdc++-v3/src/strstream.cc:49: /greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream: In member function 'void std::ostrstream::_ZTv0_n12_NSt10ostrstreamD0Ev()': /greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/

Re: m32c build fails

> I will apply the following if you confirm this fixes m32c-elf. It fixed that particular bug, but another one elsewhere stopped the build and I don't know what caused the other one. m32c-elf is easily cross-build with newlib and binutils if you want to see for yourself.

Re: m32c build fails

> Is this problem reproducible with a cross-compiler? Yes, it's m32c-elf > Can you open a bug-report and attach pre-processed source in that > case? It's trying to cross-build libiberty, so just building shows the bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35834

Re: m32c build fails

> I'm sure it just exposed it. If so, any clues about what the underlying bug might be?

Re: m32c build fails

I narrowed it down to commit 133403 (although whether that caused the bug or merely expose it, I don't know): 2008-03-21 Richard Guenther <[EMAIL PROTECTED]> * tree-scalar-evolution.c (chrec_contains_symbols_defined_in_loop): Use is_gimple_min_invariant instead of TREE_INVARIA

Re: m32c build fails

#0 fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c", line=3107, function=0x87f2e43 "build2_stat") at ../../gcc/gcc/diagnostic.c:654 #1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7db5dd0, arg0=0xb7b19340, arg1=0xb7a7d5e4) at ../../gcc/gcc/tree.c:3107 #2 0x0822501e in fold_binar

m32c build fails

Is this obvious to someone, or should I try to track it down? [EMAIL PROTECTED] pts/6 ~/m32c/gcc/m32c-elf/m32c-elf/m32cm/libiberty $ make if [ x"" != x ]; then \ /greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/gcc/m32c-elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed

gcc_contrib bug

we use the following logic: ... : @for f in $? $@; do test -f $$f || exit 0; done; \ echo Touching [EMAIL PROTECTED]; \ touch $@ We have the following chain of dependencies: gcc/configure: gcc/configure.ac gcc/cstamp-h.in: gcc/configure.ac gcc/config.in: gcc/cstamp-h.in

Re: new regression on 4.3.0 branch

> > PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 > > -fomit-frame-pointer > > Can you pin-point the patch that caused this and investigate what is > going wrong? Looks like a schroedinbug. The .s file from before ("pass") is obviously wrong, but the right value *happens* to be i

Re: new regression on 4.3.0 branch

> Can you pin-point the patch that caused this and investigate what is > going wrong? Sure. It was some time yesterday at least (that script runs every night), but I'll try to narrow it down further.

new regression on 4.3.0 branch

Not a primary target, but still... Results for 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132798] (GCC) testsuite on m32c-unknown-elf --- Start of forwarded message --- gcc result changes... Multilib: m32c-sim/-mcpu=m32c PASS-FAIL: gcc.c-torture/execute/980707-1.c execution,

Re: sh-elf vs profiling

> I guess it probably doesn't apply in this case (if you've straced the > simulator), but please also keep in mind another gotcha: > > http://gcc.gnu.org/ml/gcc/2006-12/msg00561.html Yeah, doesn't apply. There were no *attempts* at I/O from the simulator. I'm more inclined to think that th

Re: sh-elf vs profiling

> Hmm... Did you try --with-headers? I'll give that a try.

Re: sh-elf vs profiling

> Is your gcc configured with --with-newlib --with-headers? $TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \ --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local I do a two-phase build. I build gcc (and let it fail for libgcc) to get xgcc/cc1, then build and install newlib,

sh-elf vs profiling

Is sh-elf/sim supposed to support profiling? My latest tests show all the profiling tests failing. For example, the bprob executable has the name of the gcda file in it, but doesn't attempt to write it out (verified with strace against the simulator).

Re: [m32c] type precedence rules and pointer signs

> It's correct to always sign-extend the offset to the pointer mode > width (or simply truncate it, if the offset width is larger than > pointer mode width). I'd argue against that if you're dereferencing a large structure pointer. P->foo would always be an unsigned offset. Similarly for arrays

Re: [m32c] type precedence rules and pointer signs

> case POINTER_PLUS_EXPR: > /* Even though the sizetype mode and the pointer's mode can be different > expand is able to handle this correctly and get the correct result > out > of the PLUS_EXPR code. */ Me thinks that comment now needs some rethinking ;-)

Re: [m32c] type precedence rules and pointer signs

> Can you represent all pointer offsets (well, those you actually > support) within sizetype? Yes. It's a limit, but we live with it. It would be nice if the offsets were extended according to their own sign, which gives us 1.5x the range of choosing a single signedness. > If so you probably o

Re: [m32c] type precedence rules and pointer signs

> The problem you are running into is that sizeof(sizetype) != > sizeof(void *). In the middle-end the type used as offset > (sizetype) doesn't have a defined signedness (it's unsigned for C, > signed for Ada for example), so we rely on the fact that its size > should match that of pointers (as t

[m32c] type precedence rules and pointer signs

I'm debugging an EH failure on m32c-elf (-mcpu=m32c). The test case is this: extern int U(); void *ra; main() { foo((ra + U()) - 1); } In the context of the bug, sizeof(void *) is 32 (well, PSImode = 24 bit) and sizeof(int) == 16. U() returns zero in this example. So, the call is this:

Re: dwarf2 EH address size

> The EH code does seem to use POINTER_SIZE pretty consistently. > DWARF2_ADDR_SIZE is for the debug info, not the exception frame > info. I haven't looked into the history of why this is so. Hmmm... I suppose the EH info is used by the runtime as well, right? So changing to a non-standard addr

Re: [M16C]: 20-bit access patch for review

Minor stylistic suggestions... + "* + switch (which_alternative) +{ +case 0: + if (TARGET_A16 + && GET_CODE (operands[2]) == SYMBOL_REF + && far_data_p (operands[2])== 1 + && near_data_p (operands[2])== 0) +return m32c_disp_pattern (insn, operands)

Re: GCC 4.3 target deprecation proposals

> message was truncated because of the massive number of failures. Or massive number of multilibs :-)

dwarf2 EH address size

The m32c port has this: #define DWARF2_ADDR_SIZE4 However, dwarf2asm.c has this: int size_of_encoded_value (int encoding) { . . . case DW_EH_PE_absptr: return POINTER_SIZE / BITS_PER_UNIT; The net result is that the EH sections have 2 byte pointers for the m16c variant (HIm

Re: GCC 4.3 target deprecation proposals

> I'm not actually convinced these long default multilib lists are a > good idea; If my goal was to write SH software, I'd agree. However, my goal is to try to get the port into shape, so a long list is useful. Internally, we use an even longer list, but the FSF sources don't support (by default

Re: GCC 4.3 target deprecation proposals

> Actively maintained targets need a maintainer doing enough work on > the results (fixing bugs and arranging for inapplicable tests to be > skipped or XFAILed) to get them down below that size. At the moment, I'm working on getting sh, h8300, and m32c in shape for 4.3 (or future). I can easily

Re: GCC 4.3 target deprecation proposals

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > * Any target with test results posted to gcc-testresults within the > past year, I did a test run of the sh-elf test results script. There are so many multilibs that the email is 437 Kb long. Still want it as-is? Summary attached.

Re: GCC 4.3 target deprecation proposals

IIRC, the problem was in syncronizing *anything* between the Linux host and the DOS emulator. It's like trying to use NFS to syncronize two Xen instances, except with a flakey NFS and programs that don't know about concurrency. With Cygwin and DJGPP you have the problem of long command lines bei

Re: GCC 4.3 target deprecation proposals

> If you're trying to at least test code generation, etc., you could > treat the DOS system like a basic target board and cross-compile > tests and transfer them over a serial line to execute them. That's > the way it was done in the bad old days. Yeah, I remember those. > However, it's just oc

Re: GCC 4.3 target deprecation proposals

> You can't cross-test, with DejaGnu running elsewhere? I've tried. The problem is communication between the DOS system (or emulator) and the host system. DOS isn't kind to networking, semaphores, or anything else that hints at multiprocessing.

Re: GCC 4.3 target deprecation proposals

> DJGPP, Please don't deprecate this. It's actively used, but the test harness doesn't run under DJGPP so testing it is difficult. I don't think we've *ever* run the testsuite for it. > s390x-ibm-tpf* Similar. TPF is cross, and there's no simulators, so no test results, yet still active. >

Re: hard_regno_nregs == 0 ?

+2008-01-21 DJ Delorie <[EMAIL PROTECTED]> + + * doc/tm.texi (HARD_REGNO_NREGS): Note that this macro must not + return zero. + 2008-01-21 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/34856 * tree-cfg.c (verify_expr): Allow all inv

Re: hard_regno_nregs == 0 ?

IIRC, the bug happened building either libgcc or newlib. If you want to revert my latest patch in a local source tree and just try a build, it's likely to show you an example ;-)

Re: hard_regno_nregs == 0 ?

> I find this somewhat unclear - It seems to imply that HARD_REGNO_NREGS may be > called even when HARD_REGNO_MODE_OK returns false. That's exactly the case that's happening for m32c, and for which the new text is needed.

Re: hard_regno_nregs == 0 ?

How about this change, then? (I'm still testing the m32c change, too) 2008-01-09 DJ Delorie <[EMAIL PROTECTED]> * doc/tm.texi (HARD_REGNO_NREGS): Note that this macro must not return zero. Index:

Re: hard_regno_nregs == 0 ?

> I would first ask why subreg_get_info is being called with ymode == > QImode for a hard register which can not hold QImode. That implies > that there is a QImode value in the register, which you say is > invalid. Are there any ports besides m32c that have registers which can hold HI (or SI I s

hard_regno_nregs == 0 ?

In rtlanal.c we have these lines: nregs_ymode = hard_regno_nregs[xregno][ymode]; ... && (GET_MODE_SIZE (ymode) % nregs_ymode) == 0) The m32c cc1 crashes here because xregno is 1 and ymode is QI, and register 1 cannot hold a QI value (there are no QImode ops that take that register), so

Re: Rant about ChangeLog entries and commit messages

Robert Dewar <[EMAIL PROTECTED]> writes: > I don't see much point, since a diff can always easily tell > you *what* was changed. A changelog does help recreate a change *set* though, since CVS is lacking such a thing. Thus, the CL helps you determine what files to diff. True that SVN solves par

Re: Link tests after GCC_NO_EXECUTABLES

> I would prefer to revert DJ's change, for the same reason as the > other changes under discussion, so that we're consistent across > architectures. I don't care as long as a combined tree still builds.

Re: problem with iv folding

> you cannot add two pointers. Please create a PR for this and assign it > to me. Done, pr 33915 Note that m32c-elf needs --with-newlib Thanks!

problem with iv folding

target: m32c-elf test case: cc1 -O3 -mcpu=m32c dj.c void cyg_hal_plf_serial_write(void* __ch_data, const unsigned char* __buf, unsigned long __len) { while(__len-- > 0) cyg_hal_plf_serial_putc(__ch_data, *__buf++); }

Re: Q about assignment expansion

Also, http://people.redhat.com/dj/all_l4.i and ./cc1 -fpreprocessed all_l4.i -quiet -dumpbase all_l4.c -mcpu=m32cm \ -auxbase-strip all_l4.o -g -O2 -O2 -Wall -Wstrict-prototypes \ -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings \ -std=gnu99 -version -o all_l4.s -dap -fdu

Re: Q about assignment expansion

> So it looks like we have D.3720 + (unsigned int) &sstride which > looks funny in of it self. Can you provide the tree dump before > iv-opts and the one of iv-opts? It might explain what is going > wrong? http://people.redhat.com/dj/all_l4.c.105t.cunroll http://people.redhat.com/dj/all_l4.c.10

Re: Q about assignment expansion

> From what I recall and what I remember the main issue is that IV-opts > like producing: > [MEM index: ] > Note it might be better to use debug_generic_expr instead of > debug_tree (it is easier to read in most cases). I like that! Not quite enough info for some needs (like it's missing the ma

<    1   2   3   4   5   6   7   8   >